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

[Arnd Bergmann]

On Sat, Oct 3, 2026, at 19:07, Karl Mehltretter wrote:
> On Sat, Oct 03, 2026 at 12:45:07PM +0100, Arnd Bergmann wrote:
>>
>> > Kernels that also contain ARMv4 or ARMv4T CPUs are built for the
>> > lowest architecture and stay excluded. CPU_32v5 also covers the ARMv5T
>> > ARM1020. C code is already built with -march=armv5te there, so Rust
>> > matches.
>> 
>> None of this makes sense to me: The target should not control
>> the instruction set, that is what the -march= flag is needed for.
>> Does that not get passed for Rust?
>
> No. arch/arm/Makefile only passes --target=arm-unknown-linux-gnueabi,
> no CPU or feature flags. That target has "+v6" built in, so Rust code
> in an ARMv7 kernel is built as ARMv6 today.

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?

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.

> I tried the generic target with CPU flags (libcore for versatile on
> v7.3-rc1, rustc 1.99.0, CPU arch from the build attributes of core.o):
>
>   --target=arm-unknown-linux-gnueabi
>       ARMv6, uses uxtb/uxth/sxth/rev
>   --target=arm-unknown-linux-gnueabi -Ctarget-cpu=arm926ej-s
>       still ARMv6
>   --target=arm-unknown-linux-gnueabi -Ctarget-cpu=arm926ej-s

Ok, so I guess this is more like -mtune= in clang and gcc?

>  -Ctarget-feature=-v6
>      ARMv5TE, but every rustc call warns
>      "unstable feature specified for `-Ctarget-feature`: `v6`"
...
> So -Ctarget-cpu can add features but does not remove the +v6. The
> generic target also declares 64-bit atomics, armv5te and armv4t only
> 32 bit. Below ARMv6 I only see the separate targets.

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.

>> I don't see what part of rust would depend on ARMv5 instructions,
>> it should just work on ARMv4T as well, though ARMv4 may be
>> trickier because missing bx instructions etc.
>
> Agreed. !CPU_32v4T only came from the armv5te target, which emits clz
> and blx. With the armv4t target it can go. ARMv4 has no rustc target.

Ok, makes sense.

>> This looks wrong, the choice between armv5 and armv7 should work
>> the same way as the choice between armv6 and armv7/v8, if I read
>> the rustc docs correctly, this should be using the target-cpu=
>> argument on the generic arm-unknown-linux-gnueabi target.
>
> There is no choice between ARMv6 and ARMv7 today. Both get the generic
> target without flags and so ARMv6 code. And target-cpu= on the generic
> target does not get below ARMv6, see the table above. That is why I
> used a separate target for ARMv5.
>
> For a v2 of this I would
>
> - pick the rustc target next to the -march lines: armv4t for
>   CPU_32v4T, armv5te for CPU_32v5, the generic one from ARMv6K upwards
> - select HAVE_RUST for everything except CPU_32v4 and plain CPU_V6

I would leave out CPU_V7M as well, it's not worth trying to
support, and likely going away soon. It's probably not supported
by rust either, as this requires building with -march=armv7 or
-march=armv7-m and is definitely incompatible with -march=armv7-a
and -march=armv6k.

> - make arch-support.rst say the same
>
> I have this running in QEMU on v7.3-rc1 with
> - sx1 (OMAP310, ARM925T, ARMv4T), omap1_defconfig
> - versatilepb (ARM926EJ-S), versatile_defconfig
> - raspi0 (ARM1176), bcm2835_defconfig without ARCH_MULTI_V7
>
> Would that be ok for you?

Yes, sounds fine to me, though I would still hope to get native
ARMv7-A support in place of "build for v6 and hope for the best"
approach eventually. 

      Arnd