Re: `u64` by `u64` div/mod in DRM QR for arm32

["Russell King (Oracle)" <linux@armlinux.org.uk>]

On Mon, Apr 14, 2025 at 09:21:42PM +0200, Christian Schrefl wrote:
> Hi Miguel,
> 
> On 14.04.25 8:14 PM, Miguel Ojeda wrote:
> > Hi Jocelyn, Christian,
> > 
> > I started build-testing arm 32-bit within my other usual routine
> > tests, and I hit:
> > 
> >     ld.lld: error: undefined symbol: __aeabi_uldivmod
> >     >>> referenced by drm_panic_qr.rs:417 (drivers/gpu/drm/drm_panic_qr.rs:417)
> >     >>> drivers/gpu/drm/drm_panic_qr.o:(<drm_panic_qr::SegmentIterator
> > as core::iter::traits::iterator::Iterator>::next) in archive vmlinux.a
> > 
> > which comes from both these `u64` by `u64`:
> > 
> >     let out = (self.carry / pow) as u16;
> >     self.carry = self.carry % pow;
> > 
> > Christian: I guess we can offer a set of `div64` functions using the C
> > ones, at least for the time being, and eventually wire the actual
> > operator with some support from upstream Rust. Or do you have
> > something else in mind? (i.e. I think you have been discussing
> > intrinsics lately)
> 
> I think using the C implementations is fine. Not sure how much the
> FFI is going to matter for performance, but it should be rare enough
> that is shouldn't matter (and hopefully we will get cross lang LTO 
> or something similar at some point).
> 
> We could also just implement the intrinsic(s) ourselves, but then 
> the u64 divisions would be implicit which is probably undesired.
> We could also rename the intrinsics so they are only usable from 
> specific crates. 
> 
> I think we need the opinion of the some arm people here.
> 
> CC Russell King and Linus Walleij.

The kernel has had the general position that u64 by u64 division is
silly and isn't supported. Several 32-bit architectures including
32-bit ARM don't support it.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!