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