Re: [PATCH V13 5/7] rust: Make __udivdi3() and __umoddi3() panic

["Gary Guo" <gary@garyguo.net>]

On Sun Apr 26, 2026 at 11:04 PM BST, David Laight wrote:
> On Sun, 26 Apr 2026 15:20:31 +0100
> "Gary Guo" <gary@garyguo.net> wrote:
>
>> On Sun Apr 26, 2026 at 8:52 AM BST, Mukesh Kumar Chaurasiya wrote:
>> > On Fri, Apr 24, 2026 at 01:43:43PM +0100, Gary Guo wrote:  
>> >> On Fri Apr 24, 2026 at 6:47 AM BST, Mukesh Kumar Chaurasiya (IBM) wrote:  
>> >> > From: Link Mauve <linkmauve@linkmauve.fr>
>> >> >
>> >> > The core crate currently depends on these two functions for i64/u64/
>> >> > i128/u128/core::time::Duration formatting, but we shouldn’t use that in
>> >> > the kernel so let’s panic if they are ever called.
>> >> >
>> >> > This doesn’t yet fix drm_panic_qr.rs, which also uses __udivdi3 when
>> >> > CONFIG_CC_OPTIMIZE_FOR_SIZE=y, but at least makes the rest of the kernel
>> >> > build on PPC32.  
>> >> 
>> >> Can we always build libcore with `-C opt-level=2` even if
>> >> `CONFIG_CC_OPTIMIZE_FOR_SIZE` is specified? It feels like a better fix than
>> >> stubbing things out.
>> >> 
>> >> Best,
>> >> Gary
>> >>   
>> > The issue is not coming from libcore itself. It's the driver that's
>> > causing this.  
>> 
>> Sorry. I quoted the wrong part. I was asking if compiling libcore with O2 gets
>> rid of its use of the builtins, as that's what the change this commit is for.
>> 
>> Formatting of u64 will be needed, so we should make sure that these works as
>> intended.
>
> This code (from nolibc) will convert u64 to ascii in any base:
>
> [snip]
>
> Not hard to do without any divides at all.

I mean, the exact same logic is when LLVM lowers code where divisor is constant.
It just that it decides that the multiply-by-inverse lowering shouldn't be done
with `Os`.

In this case libcore is provided by Rust (think it as freestanding headers),
that code is not part of kernel. And currently they just use constant-divisor
divide and have this task performed by LLVM. We could ask Rust to explicitly use
multiply-by-inverse to avoid generating __udivdi3 in the future, but even if we
do that it won't be available to already-released Rust compilers. 

In the mean time we need to workaround this.

Best,
Gary