On 31.01.25 8:37 PM, Arnd Bergmann wrote: > On Fri, Jan 31, 2025, at 19:58, Christian Schrefl wrote: >> On 31.01.25 5:05 PM, Andrew Lunn wrote: >>>> To fix this Rust would have to provide a way to build the core >>>> library without float support. I don't know if there is a plan >>>> already to allow this. >>> >>> Floating point is banned within the kernel, except for in very narrow >>> conditions, because the floating point registers are lazy saved on >>> context switch. If the kernel uses the floating point registers, you >>> can break user space in bad ways. >>> >>> I expect this has been discussed, since it is well known kernel >>> restriction. Maybe go see what happened to that discussion within RfL? >> >> After checking again, it seems the float intrinsics are actually not >> needed anymore at least for my config. > > Ah, nice! If this is true for all architectures using the current > rust compiler, it would be great to remove the FP stubs entirely > and have link errors instead of panicking, to make it consistent > with C. After a quick test it seems that (most?) intrinsics are not needed anymore on x86, but not sure if that's valid for all supported rust versions and config options. > >> Only `__aeabi_uldivmod` is still >> required for `parse_u64_into` since [0] allows disabling float formatting. >> >> Link error without the `__aeabi_uldivmod` symbol defined: >> >> ld.lld: error: undefined symbol: __aeabi_uldivmod >>>>> referenced by num.rs:580 (/home/chrisi/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/fmt/num.rs:580) >>>>> rust/core.o:(core::fmt::num::parse_u64_into::<39>) in archive vmlinux.a >>>>> referenced by num.rs:589 (/home/chrisi/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/fmt/num.rs:589) >>>>> rust/core.o:(core::fmt::num::parse_u64_into::<39>) in archive vmlinux.a >>>>> referenced by num.rs:589 (/home/chrisi/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/fmt/num.rs:589) >>>>> rust/core.o:(core::fmt::num::parse_u64_into::<39>) in archive vmlinux.a >>>>> referenced 34 more times >>>>> did you mean: __aeabi_uidivmod >>>>> defined in: vmlinux.a(arch/arm/lib/lib1funcs.o) >> >> Not sure if we should just implement `__aeabi_uldivmod`, keep the >> panicking intrinsic for it or somehow fix it in upstream Rust? > > The 64-bit division is particularly easy to introduce by accident > on 32-bit architectures, so ending up in a panic here is clearly > a problem. From the message above it appears that there is only > a single calling function (parse_u64_into()) in the rust library, > so I wonder if it might be sufficient to split that out into > another object file that then doesn't need to get linked into > the kernel, or for the kernel to override it with an implementation > that does not rely on __aeabi_uldivmod() but calls __do_div64() > instead. I don't think that we can split it into a different object file or do some weird redirect in Rust itself. > Since parse_u64_into seems to be a parsing function that is > expected to be slow, it should be acceptable to call __do_div64() > here, while we still prevent calling __aeabi_uldivmod() from > kernel source code. `parse_u64_into` seems to be used by Formatting for u128 and i128 so it would be fine to disable these with a flag. However `__aeabi_uldivmod` is used by some other parts of core as well, like logarithm calculation for 64 and 128 bit integers, not sure what else uses is. I would guess its fine for these to be slow. Can someone help me figure out how to get ld.lld to print every usage instead of just the first three? Not sure how easy it would be to disable these but it would probably require some effort and would probably be pretty hacky, so not sure if Rust would accept these. > > Note that on earlier ARMv7 (Cortex-A8, A9), even a 32-bit > division is implemented through an expensive software loop. > Later cores (Cortex-A7, A15, A17) have native 32-bit division > instructions but still no 64-bit ones. I would assume that a software implementation is fine. Cheers Christian
