Re: [PATCH 2/2] ARM: rust: Enable Rust support for ARMv5TE

[Karl Mehltretter]

On Sat, Oct 03, 2026 at 10:54:28PM +0100, Arnd Bergmann wrote:
> How do you build ARMv7-A rust code in user space? If the default is
> ARMv6, doesn't that rule out things like thumb2, vfpv3 and sensible
> (inlined) atomics?

With another target, armv7-unknown-linux-gnueabi (soft-float ABI, no
NEON). The kernel never used it. It fits the same scheme

  rust-target-$(CONFIG_CPU_32v7)   :=armv7-unknown-linux-gnueabi
  rust-target-$(CONFIG_CPU_32v6)   :=arm-unknown-linux-gnueabi

A v6K+v7 kernel stays ARMv6 like its C code. My planned v2 has this as
last patch. It changes the Rust code of all ARMv7-only kernels from
ARMv6 to ARMv7.

> In the kernel, we don't normally allow neon code, but it sounds like
> we may need to make rust depend on !CONFIG_THUMB2_KERNEL, as that
> may be problematic when linking with v6 code.

You are right, for modules. Built-in Rust code works on a Thumb-2
kernel (Pi 400 and QEMU). Rust modules do not load

  rust_minimal: section 8 reloc 24 sym 'rust_helper_krealloc_node_align': unsupported interworking call (ARM -> Thumb)

Same on v7.3-rc1. rustc has no Thumb-2 target with the soft-float ABI.
!THUMB2_KERNEL would also remove the built-in case, so v2 leaves it
alone.

I have a first module loader patch instead. bl to a Thumb function
becomes blx, other branches go through a PLT veneer. Rust modules then
load on a Thumb-2 kernel in QEMU. I would send it separately after more
testing. Or do you prefer !(THUMB2_KERNEL && MODULES) for now?

> >   --target=arm-unknown-linux-gnueabi -Ctarget-cpu=arm926ej-s
> 
> Ok, so I guess this is more like -mtune= in clang and gcc?

More like -mcpu. 
It adds features but does not override the +v6 of the target.

> Maybe this should be "+v7-a" instead of "-v6" to allow allow the
> compiler to use all ARMv7-A features instead? It would be surprising
> if they added 32-bit Arm support to Rust without a way to target what
> is in almost every single chip and Linux distro today.

rustc does not know +v7-a. +v7 works but warns about an unstable
feature. The separate target avoids that.

On the CP15 barriers. With the generic target a fence(SeqCst) from
core::sync::atomic becomes

  mcr p15, #0, r0, c7, c10, #5

and with the armv7 target dmb ish. No kernel Rust code does that today,
the Rust objects I looked at have no CP15 access and no swp. But
nothing prevents it.

> I would leave out CPU_V7M as well, it's not worth trying to

It is left out already. HAVE_RUST needs CPU_32v6K, CPU_32v5 or
CPU_32v4T.

Thanks
Karl