`u64` by `u64` div/mod in DRM QR for arm32
Christian Schrefl
chrisi.schrefl at gmail.com
Mon Apr 14 12:21:42 PDT 2025
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.
I'm not sure what could be done in upstream rust to help here
and that would probably need be a very specific features for the
kernel.
Cheers
Chrisitan
More information about the linux-arm-kernel
mailing list