[PATCH v3] arm: rust: Enable Rust support for ARMv7

[PATCH v3] arm: rust: Enable Rust support for ARMv7

[Christian Schrefl]

This commit allows building ARMv7 kernels with Rust support.

The rust core library expects some __eabi_... functions
that are not implemented in the kernel.
Those functions are some float operations and __aeabi_uldivmod.
For now those are implemented with define_panicking_intrinsics!.

This is based on the code by Sven Van Asbroeck from the original
rust branch and inspired by the AArch version by Jamie Cunliffe.

I have tested the rust samples and a custom simple MMIO module
on hardware (De1SoC FPGA + Arm A9 CPU).

Tested-by: Rudraksha Gupta <guptarud@gmail.com>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Acked-by: Miguel Ojeda <ojeda@kernel.org>
Tested-by: Miguel Ojeda <ojeda@kernel.org>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Christian Schrefl <chrisi.schrefl@gmail.com>
---
I've updated my Rust ARMv7 patches. 
Not much has changed since v2 but I want to send it out again
before sending it to Russell's ARM patch tracker, since I should
hopefully have more time to work on this again.

I'm not sure how exactly the patch tracker works, I assume I
should just sent it to the tracker once all review comments are 
addressed and it has sat in the mailing list for some time? 

I've kept the Tags from v2 since nothing signifficant has changed,
I hope thats fine with everyone.
---
Changes in v3:
- Rebased ontop of v6.13
    Removing the rust/bindgen_parameters changes which are
    already in 732cd686cdd6 (rust: fix `ARCH_SLAB_MINALIGN` multiple
    definition error) 
- Link to v2: https://lore.kernel.org/r/2dbd1491-149d-443c-9802-75786a6a3b73@gmail.com

Changes in v2:
- Removed unrelated whitespace change.
- Added target name to panic message in scripts/generate_rust_target.rs.
- Fixed the comment in rust/bindgen_parameters.
- Link to v1: https://lore.kernel.org/r/4e0f5932-c7bc-4878-862c-1186cbecd71d@gmail.com
---
 Documentation/rust/arch-support.rst |  1 +
 arch/arm/Kconfig                    |  1 +
 arch/arm/Makefile                   |  1 +
 rust/Makefile                       |  8 ++++++++
 rust/compiler_builtins.rs           | 24 ++++++++++++++++++++++++
 scripts/generate_rust_target.rs     |  4 +++-
 6 files changed, 38 insertions(+), 1 deletion(-)

diff --git a/Documentation/rust/arch-support.rst b/Documentation/rust/arch-support.rst
index 54be7ddf3e57a732dbbca85541b137c62e834d7d..6e6a515d08991a130a8e79dc4ad7ad09da244020 100644
--- a/Documentation/rust/arch-support.rst
+++ b/Documentation/rust/arch-support.rst
@@ -15,6 +15,7 @@ support corresponds to ``S`` values in the ``MAINTAINERS`` file.
 =============  ================  ==============================================
 Architecture   Level of support  Constraints
 =============  ================  ==============================================
+``arm``        Maintained        ARMv7 Little Endian only.
 ``arm64``      Maintained        Little Endian only.
 ``loongarch``  Maintained        \-
 ``riscv``      Maintained        ``riscv64`` and LLVM/Clang only.
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 202397be76d8037b531b34dee16c7dfcfd0124ef..3375c91e698c024f95a85682f5a91d9815c355e5 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -130,6 +130,7 @@ config ARM
 	select MMU_GATHER_RCU_TABLE_FREE if SMP && ARM_LPAE
 	select HAVE_REGS_AND_STACK_ACCESS_API
 	select HAVE_RSEQ
+	select HAVE_RUST if CPU_LITTLE_ENDIAN && CPU_32v7
 	select HAVE_STACKPROTECTOR
 	select HAVE_SYSCALL_TRACEPOINTS
 	select HAVE_UID16
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 00ca7886b18efe2d01f33bc079eda2483ec807a7..4808d3ed98e42d39afc676f2654381f288d1b5b7 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -150,6 +150,7 @@ endif
 KBUILD_CPPFLAGS	+=$(cpp-y)
 KBUILD_CFLAGS	+=$(CFLAGS_ABI) $(CFLAGS_ISA) $(arch-y) $(tune-y) $(call cc-option,-mshort-load-bytes,$(call cc-option,-malignment-traps,)) -msoft-float -Uarm
 KBUILD_AFLAGS	+=$(CFLAGS_ABI) $(AFLAGS_ISA) -Wa,$(arch-y) $(tune-y) -include asm/unified.h -msoft-float
+KBUILD_RUSTFLAGS += --target=arm-unknown-linux-gnueabi
 
 CHECKFLAGS	+= -D__arm__
 
diff --git a/rust/Makefile b/rust/Makefile
index a40a3936126d603836e0ec9b42a1285916b60e45..71932a088c860b9a129b9fe06811f67f5771b984 100644
--- a/rust/Makefile
+++ b/rust/Makefile
@@ -243,6 +243,7 @@ bindgen_skip_c_flags := -mno-fp-ret-in-387 -mpreferred-stack-boundary=% \
 # Derived from `scripts/Makefile.clang`.
 BINDGEN_TARGET_x86	:= x86_64-linux-gnu
 BINDGEN_TARGET_arm64	:= aarch64-linux-gnu
+BINDGEN_TARGET_arm	:= arm-linux-gnueabi
 BINDGEN_TARGET		:= $(BINDGEN_TARGET_$(SRCARCH))
 
 # All warnings are inhibited since GCC builds are very experimental,
@@ -394,6 +395,13 @@ redirect-intrinsics = \
 	__muloti4 __multi3 \
 	__udivmodti4 __udivti3 __umodti3
 
+ifdef CONFIG_ARM
+	# Add eabi initrinsics for ARM 32-bit
+	redirect-intrinsics += \
+		__aeabi_fadd __aeabi_fmul __aeabi_fcmpeq __aeabi_fcmple __aeabi_fcmplt __aeabi_fcmpun \
+		__aeabi_dadd __aeabi_dmul __aeabi_dcmple __aeabi_dcmplt __aeabi_dcmpun \
+		__aeabi_uldivmod
+endif
 ifneq ($(or $(CONFIG_ARM64),$(and $(CONFIG_RISCV),$(CONFIG_64BIT))),)
 	# These intrinsics are defined for ARM64 and RISCV64
 	redirect-intrinsics += \
diff --git a/rust/compiler_builtins.rs b/rust/compiler_builtins.rs
index f14b8d7caf89964198313deace1bcb06fea82964..dd16c1dc899cbc755630ef3bae71e6eb0fd2c62a 100644
--- a/rust/compiler_builtins.rs
+++ b/rust/compiler_builtins.rs
@@ -73,5 +73,29 @@ pub extern "C" fn $ident() {
     __umodti3,
 });
 
+#[cfg(target_arch = "arm")]
+define_panicking_intrinsics!("`f32` should not be used", {
+    __aeabi_fadd,
+    __aeabi_fmul,
+    __aeabi_fcmpeq,
+    __aeabi_fcmple,
+    __aeabi_fcmplt,
+    __aeabi_fcmpun,
+});
+
+#[cfg(target_arch = "arm")]
+define_panicking_intrinsics!("`f64` should not be used", {
+    __aeabi_dadd,
+    __aeabi_dmul,
+    __aeabi_dcmple,
+    __aeabi_dcmplt,
+    __aeabi_dcmpun,
+});
+
+#[cfg(target_arch = "arm")]
+define_panicking_intrinsics!("`u64` division/modulo should not be used", {
+    __aeabi_uldivmod,
+});
+
 // NOTE: if you are adding a new intrinsic here, you should also add it to
 // `redirect-intrinsics` in `rust/Makefile`.
diff --git a/scripts/generate_rust_target.rs b/scripts/generate_rust_target.rs
index 0d00ac3723b5e5971acb47478d6c2a63bc4ed6c6..f8e7fb38bf160ab35c9331a732fcd2fe4023fead 100644
--- a/scripts/generate_rust_target.rs
+++ b/scripts/generate_rust_target.rs
@@ -172,7 +172,9 @@ fn main() {
     let mut ts = TargetSpec::new();
 
     // `llvm-target`s are taken from `scripts/Makefile.clang`.
-    if cfg.has("ARM64") {
+    if cfg.has("ARM") {
+        panic!("arm uses the builtin rustc target");
+    } else if cfg.has("ARM64") {
         panic!("arm64 uses the builtin rustc aarch64-unknown-none target");
     } else if cfg.has("RISCV") {
         if cfg.has("64BIT") {

---
base-commit: ffd294d346d185b70e28b1a28abe367bbfe53c04
change-id: 20250123-rfl-arm32-f93334146367

Best regards,
-- 
Christian Schrefl <chrisi.schrefl@gmail.com>

Re: [PATCH v3] arm: rust: Enable Rust support for ARMv7

[Christian Schrefl]

On 23.01.25 11:40 PM, Christian Schrefl wrote:
> This commit allows building ARMv7 kernels with Rust support.
> 
> The rust core library expects some __eabi_... functions
> that are not implemented in the kernel.
> Those functions are some float operations and __aeabi_uldivmod.
> For now those are implemented with define_panicking_intrinsics!.
> 
> This is based on the code by Sven Van Asbroeck from the original
> rust branch and inspired by the AArch version by Jamie Cunliffe.
> 
> I have tested the rust samples and a custom simple MMIO module
> on hardware (De1SoC FPGA + Arm A9 CPU).
> 
> Tested-by: Rudraksha Gupta <guptarud@gmail.com>
> Reviewed-by: Alice Ryhl <aliceryhl@google.com>
> Acked-by: Miguel Ojeda <ojeda@kernel.org>
> Tested-by: Miguel Ojeda <ojeda@kernel.org>
> Acked-by: Ard Biesheuvel <ardb@kernel.org>
> Signed-off-by: Christian Schrefl <chrisi.schrefl@gmail.com>
> ---
> I've updated my Rust ARMv7 patches. 
> Not much has changed since v2 but I want to send it out again
> before sending it to Russell's ARM patch tracker, since I should
> hopefully have more time to work on this again.
> 
> I'm not sure how exactly the patch tracker works, I assume I
> should just sent it to the tracker once all review comments are 
> addressed and it has sat in the mailing list for some time? 
> 
> I've kept the Tags from v2 since nothing signifficant has changed,
> I hope thats fine with everyone.
> ---

I have now submitted this as:
https://www.armlinux.org.uk/developer/patches/viewpatch.php?id=9441/1

I hope I've done that correctly.

Cheers
Christian

Re: [PATCH v3] arm: rust: Enable Rust support for ARMv7

[Arnd Bergmann]

On Thu, Jan 23, 2025, at 23:40, Christian Schrefl wrote:
> This commit allows building ARMv7 kernels with Rust support.
>
> The rust core library expects some __eabi_... functions
> that are not implemented in the kernel.
> Those functions are some float operations and __aeabi_uldivmod.
> For now those are implemented with define_panicking_intrinsics!.

I see you are doing this part the same as the other architectures,
but I don't see why it's done like this in the first place:

In C code, we really want to get a link failure rather than a
runtime error in order to catch those bugs as early as possible
and fix them before even trying to run the kernel. Is there a
reason this doesn't work in rust, or is there a plan to change
this later when the existing callers of those functions have
been fixed?

202397be76d8037b531b34dee16c7dfcfd0124ef..3375c91e698c024f95a85682f5a91d9815c355e5 
> 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -130,6 +130,7 @@ config ARM
>  	select MMU_GATHER_RCU_TABLE_FREE if SMP && ARM_LPAE
>  	select HAVE_REGS_AND_STACK_ACCESS_API
>  	select HAVE_RSEQ
> +	select HAVE_RUST if CPU_LITTLE_ENDIAN && CPU_32v7

The ARMv7 dependency makes sense, but I think it needs
be disabled on combined v6/v7 kernels, like (CPU_V7 && !CPU_V6 && !CPU_V6K).

      ARnd

Re: [PATCH v3] arm: rust: Enable Rust support for ARMv7

[Christian Schrefl]

On 31.01.25 8:40 AM, Arnd Bergmann wrote:
> On Thu, Jan 23, 2025, at 23:40, Christian Schrefl wrote:
>> This commit allows building ARMv7 kernels with Rust support.
>>
>> The rust core library expects some __eabi_... functions
>> that are not implemented in the kernel.
>> Those functions are some float operations and __aeabi_uldivmod.
>> For now those are implemented with define_panicking_intrinsics!.
> 
> I see you are doing this part the same as the other architectures,
> but I don't see why it's done like this in the first place:
> 
> In C code, we really want to get a link failure rather than a
> runtime error in order to catch those bugs as early as possible
> and fix them before even trying to run the kernel. Is there a
> reason this doesn't work in rust, or is there a plan to change
> this later when the existing callers of those functions have
> been fixed?

I agree having a linker error instead of a runtime panic would
be ideal, but it is currently impossible to build without these
intrinsics.

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.

> 
> 202397be76d8037b531b34dee16c7dfcfd0124ef..3375c91e698c024f95a85682f5a91d9815c355e5 
>> 100644
>> --- a/arch/arm/Kconfig
>> +++ b/arch/arm/Kconfig
>> @@ -130,6 +130,7 @@ config ARM
>>  	select MMU_GATHER_RCU_TABLE_FREE if SMP && ARM_LPAE
>>  	select HAVE_REGS_AND_STACK_ACCESS_API
>>  	select HAVE_RSEQ
>> +	select HAVE_RUST if CPU_LITTLE_ENDIAN && CPU_32v7
> 
> The ARMv7 dependency makes sense, but I think it needs
> be disabled on combined v6/v7 kernels, like (CPU_V7 && !CPU_V6 && !CPU_V6K).

That might be correct, I don't know much about the build
system for the kernel. I've tried it and it still builds
with this change.

Also it should probably be relatively easy to support 
armv6 as well.

Cheers
Christian

Re: [PATCH v3] arm: rust: Enable Rust support for ARMv7

[Andrew Lunn]

> 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?

	Andrew

Re: [PATCH v3] arm: rust: Enable Rust support for ARMv7

[Christian Schrefl]

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. 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?

Miguel do you know how this is best handled?

Link: https://github.com/rust-lang/rust/pull/86048 [0]

Cheers
Christian

Re: [PATCH v3] arm: rust: Enable Rust support for ARMv7

[Arnd Bergmann]

On Fri, Jan 31, 2025, at 16:34, Christian Schrefl wrote:
202397be76d8037b531b34dee16c7dfcfd0124ef..3375c91e698c024f95a85682f5a91d9815c355e5 
>>> 100644
>>> --- a/arch/arm/Kconfig
>>> +++ b/arch/arm/Kconfig
>>> @@ -130,6 +130,7 @@ config ARM
>>>  	select MMU_GATHER_RCU_TABLE_FREE if SMP && ARM_LPAE
>>>  	select HAVE_REGS_AND_STACK_ACCESS_API
>>>  	select HAVE_RSEQ
>>> +	select HAVE_RUST if CPU_LITTLE_ENDIAN && CPU_32v7
>> 
>> The ARMv7 dependency makes sense, but I think it needs
>> be disabled on combined v6/v7 kernels, like (CPU_V7 && !CPU_V6 && !CPU_V6K).
>
> That might be correct, I don't know much about the build
> system for the kernel. I've tried it and it still builds
> with this change.
>
> Also it should probably be relatively easy to support 
> armv6 as well.

ARMv6K should be trivial to support, as it contains the same
set of barriers and atomics as ARMv7, the main difference
being the lack of Thumb2 mode. The plain ARMv6 may be
a little harder to get right since that needs special barriers
and can only do 32-bit atomics but not 8/16/64.

As there is only really one relevant machine left with the
original ARMv6 (Nokia N8x0), we already plan to drop that
in a year, and I wouldn't put too much work into supporting
it. ARMv5 and earlier will stay around for a while longer,
but are getting rare enough that you probably don't need to
worry about those either.

     Arnd

Re: [PATCH v3] arm: rust: Enable Rust support for ARMv7

[Arnd Bergmann]

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.

> 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.

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.

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.

       Arnd

Re: [PATCH v3] arm: rust: Enable Rust support for ARMv7

[Christian Schrefl]

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

Re: [PATCH v3] arm: rust: Enable Rust support for ARMv7

[Christian Schrefl]

On 31.01.25 7:58 PM, 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. Only `__aeabi_uldivmod` is still
> required for `parse_u64_into` since [0] allows disabling float formatting.

Seems like Rust 1.78 still needs at least __aeabi_fcmpeq __aeabi_fcmpun
__aeabi_dcmpun and __aeabi_uldivmod.

> 
> 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?
> 
> Miguel do you know how this is best handled?
> 
> Link: https://github.com/rust-lang/rust/pull/86048 [0]
> 
> Cheers
> Christian

Re: [PATCH v3] arm: rust: Enable Rust support for ARMv7

[Christian Schrefl]

On 01.02.25 12:42 AM, Christian Schrefl wrote:
> 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.

On Rust 1.84.1 only __udivti3 is requied, with 1.78 most of the
intrinsics seem to still be required.

Cheers
Christian

Re: [PATCH v3] arm: rust: Enable Rust support for ARMv7

[Christian Schrefl]

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.
> 
>> 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.
> 
> 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.
> 
> 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.

It seems be possible to implement `__aeabi_uldivmod` like this [0]:

#[naked]
#[cfg(target_arch = "arm")]
#[export_name = "__rust__aeabi_uldivmod"]
pub unsafe extern "C" fn __aeabi_uldivmod() {
    unsafe {
        core::arch::naked_asm!(
            "push {{r4, lr}}",
            "sub sp, sp, #16",
            "add r4, sp, #8",
            "str r4, [sp]",
            "bl __udivmoddi4",
            "ldr r2, [sp, #8]",
            "ldr r3, [sp, #12]",
            "add sp, sp, #16",
            "pop {{r4, pc}}",
        );
    }
}

However that requires the `naked_functions` unstable feature.
Or it should be possible to just implement in a asm file.

I think it would be very difficult to entirely build core 
without needing `__aeabi_uldivmod`. 

Link: https://github.com/rust-lang/compiler-builtins/blob/6f96bccc5d4aa3ba4c4cebdf23a3ccc3bc7fe77c/src/arm.rs#L64-L77 [0]

Christian

Re: [PATCH v3] arm: rust: Enable Rust support for ARMv7

[Miguel Ojeda]

On Fri, Jan 31, 2025 at 5:05 PM Andrew Lunn <andrew@lunn.ch> wrote:
>
> 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?

Yeah, it has been discussed, including in the last couple weeks in the
Rust Zulip due to the upcoming move to the aarch64 `softfloat` target
(the disallowing of disabling `neon` in the hardfloat one).

Ideally, I think upstream Rust could perhaps give us a way to do
something like `-mgeneral-regs-only` or `-march=...+nofp` (in the form
GCC does it, i.e. a hard error if one even tries to use the floating
point types even within a function implementation, not just in
interfaces like in Clang), i.e. a way to avoid unintended use of
floating point facilities:

    https://godbolt.org/z/o1E5nrrzc

Currently it is unclear what form that could take (e.g. whether a
`-nofloat` target could be possible, "disabling" the `f*` types, just
Clippy...).

Cc'ing Catalin in case he wants to be in the loop, since I discussed
it with him recently.

Cheers,
Miguel

Re: [PATCH v3] arm: rust: Enable Rust support for ARMv7

[Alice Ryhl]

On Wed, Feb 5, 2025 at 2:12 PM Miguel Ojeda
<miguel.ojeda.sandonis@gmail.com> wrote:
>
> On Fri, Jan 31, 2025 at 5:05 PM Andrew Lunn <andrew@lunn.ch> wrote:
> >
> > 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?
>
> Yeah, it has been discussed, including in the last couple weeks in the
> Rust Zulip due to the upcoming move to the aarch64 `softfloat` target
> (the disallowing of disabling `neon` in the hardfloat one).
>
> Ideally, I think upstream Rust could perhaps give us a way to do
> something like `-mgeneral-regs-only` or `-march=...+nofp` (in the form
> GCC does it, i.e. a hard error if one even tries to use the floating
> point types even within a function implementation, not just in
> interfaces like in Clang), i.e. a way to avoid unintended use of
> floating point facilities:
>
>     https://godbolt.org/z/o1E5nrrzc
>
> Currently it is unclear what form that could take (e.g. whether a
> `-nofloat` target could be possible, "disabling" the `f*` types, just
> Clippy...).

Seems like we already have a warning for it:

warning: floating-point arithmetic detected
  --> /home/aliceryhl/rust-for-linux/rust/kernel/lib.rs:89:5
   |
89 |     a + b
   |     ^^^^^
   |
   = help: for further information visit
https://rust-lang.github.io/rust-clippy/master/index.html#float_arithmetic
   = note: requested on the command line with `-W clippy::float-arithmetic`

> Cc'ing Catalin in case he wants to be in the loop, since I discussed
> it with him recently.
>
> Cheers,
> Miguel

Re: [PATCH v3] arm: rust: Enable Rust support for ARMv7

[Linus Walleij]

Hi Christian,

thanks for your patch!

Sorry for being late to the show. I missed this very nice patch
that was actually on my personal TODO but I have to much
to do and also I'm not smart with Rust, but I'm a big supporter.

On Thu, Jan 23, 2025 at 11:40 PM Christian Schrefl
<chrisi.schrefl@gmail.com> wrote:

> +       select HAVE_RUST if CPU_LITTLE_ENDIAN && CPU_32v7

Nothing in the patch series really explains this restriction, so it
should be in the commit message. Arnd mentions some atomics
etc, but we really need to know exactly why this is in the patch.

I'm a bit surprised by this since the rustc LLVM backend nowadays
support all old ARM ISAs. I would have expected:

select HAVE_RUST if AEABI

Ideally this should work on any ARM core, but it's fair to require
EABI.

The big reason: I think we want to be able to use Rust in kernel
core components sooner than ARMv5 goes away from the kernel.

If testing is the only issue, I can provide testing on ARMv4, v5,
ARMv5 BE etc, just tell me how to test. (But I guess it's more than
that...)

Yours,
Linus Walleij

Re: [PATCH v3] arm: rust: Enable Rust support for ARMv7

[Christian Schrefl]

Hi Linus,

On 21.03.25 8:24 AM, Linus Walleij wrote:
> Hi Christian,
> 
> thanks for your patch!
> 
> Sorry for being late to the show. I missed this very nice patch
> that was actually on my personal TODO but I have to much
> to do and also I'm not smart with Rust, but I'm a big supporter.
> 
> On Thu, Jan 23, 2025 at 11:40 PM Christian Schrefl
> <chrisi.schrefl@gmail.com> wrote:
> 
>> +       select HAVE_RUST if CPU_LITTLE_ENDIAN && CPU_32v7
> 
> Nothing in the patch series really explains this restriction, so it
> should be in the commit message. Arnd mentions some atomics
> etc, but we really need to know exactly why this is in the patch.

This should probably work with armv6 targets, for v5 or v4 Targets a 
different target would have to be specified in the KBUILD_RUSTFLAGS.

Rust also has some big endian arm targets.

> 
> I'm a bit surprised by this since the rustc LLVM backend nowadays
> support all old ARM ISAs. I would have expected:
> 
> select HAVE_RUST if AEABI
> 
> Ideally this should work on any ARM core, but it's fair to require
> EABI.
> 
> The big reason: I think we want to be able to use Rust in kernel
> core components sooner than ARMv5 goes away from the kernel.
> 
> If testing is the only issue, I can provide testing on ARMv4, v5,
> ARMv5 BE etc, just tell me how to test. (But I guess it's more than
> that...)

The main reason that I only did this for ARMv7 was that I'm not very
familiar with older arm versions and that I only have v7 hardware for
testing.

I currently don't have much time to work on this, but when/if it 
works in qemu I'll send you a message to test it on HW.

Cheers
Christian

Re: [PATCH v3] arm: rust: Enable Rust support for ARMv7

[Manish Shakya]

Tested with Beaglebone back with following configs:

# zcat /proc/config.gz | grep RUST
CONFIG_RUSTC_VERSION=108600
CONFIG_RUST_IS_AVAILABLE=y
CONFIG_RUSTC_LLVM_VERSION=190107
CONFIG_RUST=y
CONFIG_RUSTC_VERSION_TEXT="rustc 1.86.0 (05f9846f8 2025-03-31)"
CONFIG_HAVE_RUST=y
# CONFIG_RUST_FW_LOADER_ABSTRACTIONS is not set
CONFIG_TRUSTED_FOUNDATIONS=y
# CONFIG_BLK_DEV_RUST_NULL is not set
# CONFIG_RUST_PHYLIB_ABSTRACTIONS is not set
# CONFIG_HID_THRUSTMASTER is not set
# CONFIG_TRUSTED_KEYS is not set
CONFIG_SYSTEM_TRUSTED_KEYRING=y
CONFIG_SYSTEM_TRUSTED_KEYS=""
# CONFIG_SECONDARY_TRUSTED_KEYRING is not set
CONFIG_RUST_DEBUG_ASSERTIONS=y
CONFIG_RUST_OVERFLOW_CHECKS=y
CONFIG_RUST_BUILD_ASSERT_ALLOW=y

Re: [PATCH v3] arm: rust: Enable Rust support for ARMv7

[Miguel Ojeda]

On Sun, Apr 6, 2025 at 4:08 PM Manish Shakya <msh.shakya@gmail.com> wrote:
>
> CONFIG_RUST_DEBUG_ASSERTIONS=y

This is great for testing...

> CONFIG_RUST_BUILD_ASSERT_ALLOW=y

...but this one should really be disabled (both for testing and for
production use).

`RUST_BUILD_ASSERT_ALLOW` is really only there as a worst case
workaround (escape hatch) that nobody should ever hit, hopefully.

If you ever find you need to set it, then please report it -- thanks!

Cheers,
Miguel

Re: [PATCH v3] arm: rust: Enable Rust support for ARMv7

[Miguel Ojeda]

On Wed, Feb 5, 2025 at 2:15 PM Alice Ryhl <aliceryhl@google.com> wrote:
>
> Seems like we already have a warning for it:

Yeah, that is the "just Clippy" part, but other forms could perhaps do
more, e.g. imply `no_fp_fmt_parse` (in a stable way) and remove other
bits that may not be needed.

Cheers,
Miguel

Re: [PATCH v3] arm: rust: Enable Rust support for ARMv7

[Benno Lossin]

On Sun Apr 6, 2025 at 4:57 PM CEST, Miguel Ojeda wrote:
> On Sun, Apr 6, 2025 at 4:08 PM Manish Shakya <msh.shakya@gmail.com> wrote:
>>
>> CONFIG_RUST_DEBUG_ASSERTIONS=y
>
> This is great for testing...
>
>> CONFIG_RUST_BUILD_ASSERT_ALLOW=y
>
> ...but this one should really be disabled (both for testing and for
> production use).
>
> `RUST_BUILD_ASSERT_ALLOW` is really only there as a worst case
> workaround (escape hatch) that nobody should ever hit, hopefully.

Maybe we should rename it to something more discouraging then. Eg
CONFIG_RUST_BUILD_ASSERT_DISABLE.

---
Cheers,
Benno

Re: [PATCH v3] arm: rust: Enable Rust support for ARMv7

[Miguel Ojeda]

On Sun, Apr 6, 2025 at 11:17 PM Benno Lossin <benno.lossin@proton.me> wrote:
>
> Maybe we should rename it to something more discouraging then. Eg
> CONFIG_RUST_BUILD_ASSERT_DISABLE.

To clarify: it doesn't disable them, but rather converts them to runtime checks.

Perhaps it should be _ESCAPE_HATCH or _KEEP_DISABLED or _AT_RUNTIME or
similar -- though changing it now may be even more confusing.

The description already mentions it should not happen, and that is an
escape hatch, and the recommendation and the default is N. So if
someone enables it in production, they really went out of their way to
do so, and even then they are protected by the panics (that they
shouldn't hit at all).

Eventually, we may just want to remove it entirely if we never see a
case failing and/or if we get proper support for those from upstream
Rust for this.

Cheers,
Miguel

Re: [PATCH v3] arm: rust: Enable Rust support for ARMv7

[Manish Shakya]

I followed the Documentation/rust/testing.rs document to test more. It 
seems that only the KUnit test is possible, while the other two tests 
are not feasible in a cross-compilation setup. What other tests need to 
be performed?

The KUnit test passed.

[    1.162374] # rust_doctests_kernel: pass:128 fail:0 skip:0 total:128
[    1.162388] # Totals: pass:128 fail:0 skip:0 total:128
[    1.162401] ok 1 rust_doctests_kernel

Here is my current setup:
# zcat /proc/config.gz | grep RUST
CONFIG_RUSTC_VERSION=108600
CONFIG_RUST_IS_AVAILABLE=y
CONFIG_RUSTC_LLVM_VERSION=190107
CONFIG_RUST=y
CONFIG_RUSTC_VERSION_TEXT="rustc 1.86.0 (05f9846f8 2025-03-31)"
CONFIG_HAVE_RUST=y
# CONFIG_RUST_FW_LOADER_ABSTRACTIONS is not set
CONFIG_TRUSTED_FOUNDATIONS=y
# CONFIG_BLK_DEV_RUST_NULL is not set
# CONFIG_TRUSTED_KEYS is not set
CONFIG_SYSTEM_TRUSTED_KEYRING=y
CONFIG_SYSTEM_TRUSTED_KEYS=""
# CONFIG_SECONDARY_TRUSTED_KEYRING is not set
CONFIG_SAMPLES_RUST=y
CONFIG_SAMPLE_RUST_MINIMAL=y
CONFIG_SAMPLE_RUST_PRINT=y
CONFIG_SAMPLE_RUST_HOSTPROGS=y
CONFIG_RUST_DEBUG_ASSERTIONS=y
CONFIG_RUST_OVERFLOW_CHECKS=y
# CONFIG_RUST_BUILD_ASSERT_ALLOW is not set
CONFIG_RUST_KERNEL_DOCTESTS=y

# cat /proc/cpuinfo
processor       : 0
model name      : ARMv7 Processor rev 2 (v7l)
BogoMIPS        : 298.84
Features        : half thumb fastmult vfp edsp thumbee neon vfpv3 tls 
vfpd32
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x3
CPU part        : 0xc08
CPU revision    : 2

Hardware        : Generic AM33XX (Flattened Device Tree)
Revision        : 0000
Serial          : 4014BBBK0948

Re: [PATCH v3] arm: rust: Enable Rust support for ARMv7

[Miguel Ojeda]

On Mon, Apr 7, 2025 at 6:04 PM Benno Lossin <benno.lossin@proton.me> wrote:
>
> Maybe we should also hide it behind CONFIG_EXPERT?

Maybe -- it is already inside the "Kernel hacking" menu, but it could help.

> Yeah, the upstream support would be the best. Did we ever need to enable
> this option?

Not that I am aware of / recall. So far all the ones that we got a
report for were actually expected cases.

Cheers,
Miguel

Re: [PATCH v3] arm: rust: Enable Rust support for ARMv7

[Manish Shakya]

On 4/7/25 12:04 PM, Benno Lossin wrote:
> I suspect that most of the people sadly don't read the description.
>
I must admit I didn't read the description. I was trying to get as much 
as info. Since it was my first time building kernel with rust support.

Re: [PATCH v3] arm: rust: Enable Rust support for ARMv7

[Christian Schrefl]

On 21.03.25 8:24 AM, Linus Walleij wrote:
> Hi Christian,
> 
> thanks for your patch!
> 
> Sorry for being late to the show. I missed this very nice patch
> that was actually on my personal TODO but I have to much
> to do and also I'm not smart with Rust, but I'm a big supporter.
> 
> On Thu, Jan 23, 2025 at 11:40 PM Christian Schrefl
> <chrisi.schrefl@gmail.com> wrote:
> 
>> +       select HAVE_RUST if CPU_LITTLE_ENDIAN && CPU_32v7
> 
> Nothing in the patch series really explains this restriction, so it
> should be in the commit message. Arnd mentions some atomics
> etc, but we really need to know exactly why this is in the patch.
> 
> I'm a bit surprised by this since the rustc LLVM backend nowadays
> support all old ARM ISAs. I would have expected:
> 
> select HAVE_RUST if AEABI
> 
> Ideally this should work on any ARM core, but it's fair to require
> EABI.
> 
> The big reason: I think we want to be able to use Rust in kernel
> core components sooner than ARMv5 goes away from the kernel.
> 
> If testing is the only issue, I can provide testing on ARMv4, v5,
> ARMv5 BE etc, just tell me how to test. (But I guess it's more than
> that...)

I've done a quick test on armv5 with the `armv5te-none-eabi` rust 
target and it needs some atomics (`AtomicU64` type and for 
`AtomicBool` the `compare_exchange` and `compare_exchange` 
functions) to build:

```
  RUSTC L rust/kernel.o
error[E0432]: unresolved import `core::sync::atomic::AtomicU64`
  --> rust/kernel/block/mq/operations.rs:15:33
   |
15 | use core::{marker::PhantomData, sync::atomic::AtomicU64, sync::atomic::Ordering};
   |                                 ^^^^^^^^^^^^^^---------
   |                                 |             |
   |                                 |             help: a similar name exists in the module: `AtomicU8`
   |                                 no `AtomicU64` in `sync::atomic`

error[E0432]: unresolved import `core::sync::atomic::AtomicU64`
  --> rust/kernel/block/mq/request.rs:16:20
   |
16 |     sync::atomic::{AtomicU64, Ordering},
   |                    ^^^^^^^^^
   |                    |
   |                    no `AtomicU64` in `sync::atomic`
   |                    help: a similar name exists in the module: `AtomicU8`

error[E0599]: no method named `compare_exchange` found for struct `AtomicBool` in the current scope
   --> rust/kernel/list/arc.rs:518:14
    |
517 | /         self.inner
518 | |             .compare_exchange(false, true, Ordering::Acquire, Ordering::Relaxed)
    | |             -^^^^^^^^^^^^^^^^ method not found in `AtomicBool`
    | |_____________|
    |

error[E0599]: no method named `swap` found for struct `AtomicBool` in the current scope
   --> rust/kernel/revocable.rs:130:30
    |
130 |         if self.is_available.swap(false, Ordering::Relaxed) {
    |                              ^^^^ method not found in `AtomicBool`

error: aborting due to 4 previous errors

Some errors have detailed explanations: E0432, E0599.
For more information about an error, try `rustc --explain E0432`.
```

When gating all the modules that need these linking fails because
of missing __eabi__* intrinsics:

```
ld.lld: error: undefined symbol: __aeabi_memcpy
>>> referenced by kernel.2bb770ae1dba3d33-cgu.0
>>>               rust/kernel.o:(<kernel::str::RawFormatter as core::fmt::Write>::write_char) in archive vmlinux.a
>>> referenced by kernel.2bb770ae1dba3d33-cgu.0
>>>               rust/kernel.o:(<kernel::str::Formatter as core::fmt::Write>::write_char) in archive vmlinux.a
>>> referenced by kernel.2bb770ae1dba3d33-cgu.0
>>>               rust/kernel.o:(<kernel::page::Page>::read_raw) in archive vmlinux.a
>>> referenced 29 more times

ld.lld: error: undefined symbol: __aeabi_memclr8
>>> referenced by bindings.4cab29b7397d35cb-cgu.0
>>>               rust/bindings.o:(<bindings::bindings_raw::module as core::default::Default>::default) in archive vmlinux.a
>>> referenced by uapi.fe46408b8870a0f6-cgu.0
>>>               rust/uapi.o:(<uapi::module as core::default::Default>::default) in archive vmlinux.a
>>> referenced by uapi.fe46408b8870a0f6-cgu.0
>>>               rust/uapi.o:(<uapi::thread_info as core::default::Default>::default) in archive vmlinux.a
>>> referenced 86 more times

ld.lld: error: undefined symbol: __aeabi_memclr4
>>> referenced by bindings.4cab29b7397d35cb-cgu.0
>>>               rust/bindings.o:(<bindings::bindings_raw::fp_hard_struct as core::default::Default>::default) in archive vmlinux.a
>>> referenced by bindings.4cab29b7397d35cb-cgu.0
>>>               rust/bindings.o:(<bindings::bindings_raw::iwmmxt_struct as core::default::Default>::default) in archive vmlinux.a
>>> referenced by uapi.fe46408b8870a0f6-cgu.0
>>>               rust/uapi.o:(<uapi::fp_soft_struct as core::default::Default>::default) in archive vmlinux.a
>>> referenced 95 more times

ld.lld: error: undefined symbol: __aeabi_memset
>>> referenced by core.64aa0a46a0f8f964-cgu.0
>>>               rust/core.o:(<core::num::fmt::Part>::write) in archive vmlinux.a
>>> referenced by core.64aa0a46a0f8f964-cgu.0
>>>               rust/core.o:(core::fmt::num::fmt_u128) in archive vmlinux.a

ld.lld: error: undefined symbol: __aeabi_memcpy4
>>> referenced by kernel.2bb770ae1dba3d33-cgu.0
>>>               rust/kernel.o:(<kernel::of::DeviceId>::new) in archive vmlinux.a
>>> referenced by core.64aa0a46a0f8f964-cgu.0
>>>               rust/core.o:(<core::char::ToLowercase as core::fmt::Display>::fmt) in archive vmlinux.a

ld.lld: error: undefined symbol: __aeabi_memclr
>>> referenced by kernel.2bb770ae1dba3d33-cgu.0
>>>               rust/kernel.o:(<kernel::page::Page>::fill_zero_raw) in archive vmlinux.a
>>> referenced by uapi.fe46408b8870a0f6-cgu.0
>>>               rust/uapi.o:(<uapi::__kernel_sockaddr_storage__bindgen_ty_1__bindgen_ty_1 as core::default::Default>::default) in archive vmlinux.a
>>> referenced by uapi.fe46408b8870a0f6-cgu.0
>>>               rust/uapi.o:(<uapi::sockaddr__bindgen_ty_1 as core::default::Default>::default) in archive vmlinux.a
>>> referenced 16 more times

ld.lld: error: undefined symbol: __aeabi_memset4
>>> referenced by core.64aa0a46a0f8f964-cgu.0
>>>               rust/core.o:(core::fmt::num::fmt_u128) in archive vmlinux.a
make[2]: *** [scripts/Makefile.vmlinux:91: vmlinux] Error 1
make[1]: *** [/home/chrisi/Documents/code/rust-arm32/Makefile:1242: vmlinux] Error 2
make: *** [Makefile:248: __sub-make] Error 2
```

With define_panicking_intrinsics! for these an empty sample works
(not yet tested as module), but even printing a non formatted
string (with `pr_info!("Hi rust\n");`) fails because rust tries
to use __adddf3:

``
Hardware name: ARM-Versatile (Device Tree Support)
PC is at __rust__adddf3+0x0/0x4
LR is at _RNvXsg_NtCs3KHxpmQFgFb_6kernel3strNtB5_12RawFormatterNtNtCs8DPF7ip8WBQ_4core3fmt5Write9write_str+0x34/0x40
pc : [<c028950c>]    lr : [<c028b5ec>]    psr: 20000193
sp : c8811a78  ip : c8811ae8  fp : c058e44e
r10: 00000000  r9 : c058e450  r8 : c07ac118
r7 : 00000000  r6 : 00000000  r5 : c07ac120  r4 : c8811adc
r3 : c07ac120  r2 : 00000008  r1 : c0667f60  r0 : c07ac118
Flags: nzCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment none
```

I'm not sure how to proceed from here and I most likely won't
find time to continue working on this anytime soon.

My very hacky changes are available on Github at:
https://github.com/onestacked/linux/commit/edddb388267ab1afe5255bea4d84f96cbdb37978

Cheers,
Christian

Re: [PATCH v3] arm: rust: Enable Rust support for ARMv7

[Christian Schrefl]

On 21.03.25 8:24 AM, Linus Walleij wrote:
> Hi Christian,
>
> thanks for your patch!
>
> Sorry for being late to the show. I missed this very nice patch
> that was actually on my personal TODO but I have to much
> to do and also I'm not smart with Rust, but I'm a big supporter.
>
> On Thu, Jan 23, 2025 at 11:40 PM Christian Schrefl
> <chrisi.schrefl@gmail.com> wrote:
>
>> +       select HAVE_RUST if CPU_LITTLE_ENDIAN && CPU_32v7
>
> Nothing in the patch series really explains this restriction, so it
> should be in the commit message. Arnd mentions some atomics
> etc, but we really need to know exactly why this is in the patch.
>
> I'm a bit surprised by this since the rustc LLVM backend nowadays
> support all old ARM ISAs. I would have expected:
>
> select HAVE_RUST if AEABI
>
> Ideally this should work on any ARM core, but it's fair to require
> EABI.
>
> The big reason: I think we want to be able to use Rust in kernel
> core components sooner than ARMv5 goes away from the kernel.
>
> If testing is the only issue, I can provide testing on ARMv4, v5,
> ARMv5 BE etc, just tell me how to test. (But I guess it's more than
> that...)

I've done a quick test on armv5 with the `armv5te-none-eabi` rust 
target and it needs some atomics (`AtomicU64` type and for 
`AtomicBool` the `compare_exchange` and `compare_exchange` 
functions) to build:

```
  RUSTC L rust/kernel.o
error[E0432]: unresolved import `core::sync::atomic::AtomicU64`
  --> rust/kernel/block/mq/operations.rs:15:33
   |
15 | use core::{marker::PhantomData, sync::atomic::AtomicU64, sync::atomic::Ordering};
   |                                 ^^^^^^^^^^^^^^---------
   |                                 |             |
   |                                 |             help: a similar name exists in the module: `AtomicU8`
   |                                 no `AtomicU64` in `sync::atomic`

error[E0432]: unresolved import `core::sync::atomic::AtomicU64`
  --> rust/kernel/block/mq/request.rs:16:20
   |
16 |     sync::atomic::{AtomicU64, Ordering},
   |                    ^^^^^^^^^
   |                    |
   |                    no `AtomicU64` in `sync::atomic`
   |                    help: a similar name exists in the module: `AtomicU8`

error[E0599]: no method named `compare_exchange` found for struct `AtomicBool` in the current scope
   --> rust/kernel/list/arc.rs:518:14
    |
517 | /         self.inner
518 | |             .compare_exchange(false, true, Ordering::Acquire, Ordering::Relaxed)
    | |             -^^^^^^^^^^^^^^^^ method not found in `AtomicBool`
    | |_____________|
    |

error[E0599]: no method named `swap` found for struct `AtomicBool` in the current scope
   --> rust/kernel/revocable.rs:130:30
    |
130 |         if self.is_available.swap(false, Ordering::Relaxed) {
    |                              ^^^^ method not found in `AtomicBool`

error: aborting due to 4 previous errors

Some errors have detailed explanations: E0432, E0599.
For more information about an error, try `rustc --explain E0432`.
```

When gating all the modules that need these linking fails because
of missing __eabi__* intrinsics:

```
ld.lld: error: undefined symbol: __aeabi_memcpy
>>> referenced by kernel.2bb770ae1dba3d33-cgu.0
>>>               rust/kernel.o:(<kernel::str::RawFormatter as core::fmt::Write>::write_char) in archive vmlinux.a
>>> referenced by kernel.2bb770ae1dba3d33-cgu.0
>>>               rust/kernel.o:(<kernel::str::Formatter as core::fmt::Write>::write_char) in archive vmlinux.a
>>> referenced by kernel.2bb770ae1dba3d33-cgu.0
>>>               rust/kernel.o:(<kernel::page::Page>::read_raw) in archive vmlinux.a
>>> referenced 29 more times

ld.lld: error: undefined symbol: __aeabi_memclr8
>>> referenced by bindings.4cab29b7397d35cb-cgu.0
>>>               rust/bindings.o:(<bindings::bindings_raw::module as core::default::Default>::default) in archive vmlinux.a
>>> referenced by uapi.fe46408b8870a0f6-cgu.0
>>>               rust/uapi.o:(<uapi::module as core::default::Default>::default) in archive vmlinux.a
>>> referenced by uapi.fe46408b8870a0f6-cgu.0
>>>               rust/uapi.o:(<uapi::thread_info as core::default::Default>::default) in archive vmlinux.a
>>> referenced 86 more times

ld.lld: error: undefined symbol: __aeabi_memclr4
>>> referenced by bindings.4cab29b7397d35cb-cgu.0
>>>               rust/bindings.o:(<bindings::bindings_raw::fp_hard_struct as core::default::Default>::default) in archive vmlinux.a
>>> referenced by bindings.4cab29b7397d35cb-cgu.0
>>>               rust/bindings.o:(<bindings::bindings_raw::iwmmxt_struct as core::default::Default>::default) in archive vmlinux.a
>>> referenced by uapi.fe46408b8870a0f6-cgu.0
>>>               rust/uapi.o:(<uapi::fp_soft_struct as core::default::Default>::default) in archive vmlinux.a
>>> referenced 95 more times

ld.lld: error: undefined symbol: __aeabi_memset
>>> referenced by core.64aa0a46a0f8f964-cgu.0
>>>               rust/core.o:(<core::num::fmt::Part>::write) in archive vmlinux.a
>>> referenced by core.64aa0a46a0f8f964-cgu.0
>>>               rust/core.o:(core::fmt::num::fmt_u128) in archive vmlinux.a

ld.lld: error: undefined symbol: __aeabi_memcpy4
>>> referenced by kernel.2bb770ae1dba3d33-cgu.0
>>>               rust/kernel.o:(<kernel::of::DeviceId>::new) in archive vmlinux.a
>>> referenced by core.64aa0a46a0f8f964-cgu.0
>>>               rust/core.o:(<core::char::ToLowercase as core::fmt::Display>::fmt) in archive vmlinux.a

ld.lld: error: undefined symbol: __aeabi_memclr
>>> referenced by kernel.2bb770ae1dba3d33-cgu.0
>>>               rust/kernel.o:(<kernel::page::Page>::fill_zero_raw) in archive vmlinux.a
>>> referenced by uapi.fe46408b8870a0f6-cgu.0
>>>               rust/uapi.o:(<uapi::__kernel_sockaddr_storage__bindgen_ty_1__bindgen_ty_1 as core::default::Default>::default) in archive vmlinux.a
>>> referenced by uapi.fe46408b8870a0f6-cgu.0
>>>               rust/uapi.o:(<uapi::sockaddr__bindgen_ty_1 as core::default::Default>::default) in archive vmlinux.a
>>> referenced 16 more times

ld.lld: error: undefined symbol: __aeabi_memset4
>>> referenced by core.64aa0a46a0f8f964-cgu.0
>>>               rust/core.o:(core::fmt::num::fmt_u128) in archive vmlinux.a
make[2]: *** [scripts/Makefile.vmlinux:91: vmlinux] Error 1
make[1]: *** [/home/chrisi/Documents/code/rust-arm32/Makefile:1242: vmlinux] Error 2
make: *** [Makefile:248: __sub-make] Error 2
```

With define_panicking_intrinsics! for these an empty sample works
(not yet tested as module), but even printing a non formatted
string (with `pr_info!("Hi rust\n");`) fails because rust tries
to use __adddf3:

``
Hardware name: ARM-Versatile (Device Tree Support)
PC is at __rust__adddf3+0x0/0x4
LR is at _RNvXsg_NtCs3KHxpmQFgFb_6kernel3strNtB5_12RawFormatterNtNtCs8DPF7ip8WBQ_4core3fmt5Write9write_str+0x34/0x40
pc : [<c028950c>]    lr : [<c028b5ec>]    psr: 20000193
sp : c8811a78  ip : c8811ae8  fp : c058e44e
r10: 00000000  r9 : c058e450  r8 : c07ac118
r7 : 00000000  r6 : 00000000  r5 : c07ac120  r4 : c8811adc
r3 : c07ac120  r2 : 00000008  r1 : c0667f60  r0 : c07ac118
Flags: nzCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment none
```

I'm not sure how to proceed from here and I most likely won't
find time to continue working on this anytime soon.

My very hacky changes are available on Github at:
https://github.com/onestacked/linux/commit/edddb388267ab1afe5255bea4d84f96cbdb37978

Cheers,
Christian