From: Christian Schrefl <chrisi.schrefl@gmail.com>
To: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>,
Jocelyn Falempe <jfalempe@redhat.com>
Cc: Arnd Bergmann <arnd@arndb.de>,
rust-for-linux <rust-for-linux@vger.kernel.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
dri-devel <dri-devel@lists.freedesktop.org>,
Russell King <linux@armlinux.org.uk>,
Linus Walleij <linus.walleij@linaro.org>
Subject: Re: `u64` by `u64` div/mod in DRM QR for arm32
Date: Mon, 14 Apr 2025 21:21:42 +0200 [thread overview]
Message-ID: <38867e79-c0e3-4bcd-bdf9-3fb5b571d51e@gmail.com> (raw)
In-Reply-To: <CANiq72ke45eOwckMhWHvmwxc03dxr4rnxxKvx+HvWdBLopZfrQ@mail.gmail.com>
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
next prev parent reply other threads:[~2025-04-14 20:28 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-14 18:14 `u64` by `u64` div/mod in DRM QR for arm32 Miguel Ojeda
2025-04-14 19:21 ` Christian Schrefl [this message]
2025-04-14 19:46 ` Russell King (Oracle)
2025-04-15 9:14 ` Jocelyn Falempe
2025-04-15 12:50 ` Paolo Bonzini
2025-05-05 7:37 ` Geert Uytterhoeven
2025-04-14 20:04 ` Miguel Ojeda
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=38867e79-c0e3-4bcd-bdf9-3fb5b571d51e@gmail.com \
--to=chrisi.schrefl@gmail.com \
--cc=arnd@arndb.de \
--cc=dri-devel@lists.freedesktop.org \
--cc=jfalempe@redhat.com \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux@armlinux.org.uk \
--cc=miguel.ojeda.sandonis@gmail.com \
--cc=rust-for-linux@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).