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

[Segher Boessenkool <segher@kernel.crashing.org>]

On Fri, Apr 24, 2026 at 06:54:05AM -0500, Segher Boessenkool wrote:
> Hi!
> 
> On Fri, Apr 24, 2026 at 11:17:40AM +0530, Mukesh Kumar Chaurasiya (IBM) wrote:
> > 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.
> 
> GCC uses calls to functions like even __addsi3 whenever the (sub-)target
> does not implement some RTL, doesn't have a define_insn and the like for
> it.  When you write a new port you only *have* to implement a very few
> things, the rest is done in libgcc (you might still have to write some
> of that for your target, no free lunch etc.)
> 
> 32-bit PowerPC has no instructions for 64-bit divisions, nor
> instructions that help implementing it in software.  It still very often
> helps to hand-write machine code for it, it very easily can usually be
> more than twice as fast for example (for example if the divisor is less
> than half a word big, the common case -- it can be made tens of times
> faster then).
> 
> There can be many reasons why a GCC backend decides to call a libgcc
> routine.  For __udivdi3 on -m32 rs6000 you'll be good AFAICS :-)
> (but poisoning functions like you do is a terrible idea in general!)

Whoopsie, I forgot to mention:

Approved for trunk.


Segher