Implement __sync builtins for thumbv6-none-eabi #1050

taiki-e · 2025-12-27T06:47:35Z

This is a PR for thumbv6-none-eabi (bere-metal Armv6k in Thumb mode) which proposed to be added by rust-lang/rust#150138.

Armv6k supports atomic instructions, but they are unavailable in Thumb mode unless Thumb-2 instructions available (v6t2).

Using Thumb interworking (can be used via #[instruction_set]) allows us to use these instructions even from Thumb mode without Thumb-2 instructions, but LLVM does not implement that processing (as of LLVM 21), so this PR implements it in compiler-builtins.

The code around __sync builtins is basically copied from arm_linux.rs which uses kernel_user_helpers for atomic implementation.
The atomic implementation is a port of my atomic-maybe-uninit inline assembly code.

This PR has been tested on QEMU 10.2.0 using patched compiler-builtins and core that applied the changes in this PR and rust-lang/rust#150138 and the portable-atomic no-std test suite (can be run with ./tools/no-std.sh thumbv6-none-eabi on that repo) which tests wrappers around core::sync::atomic. (Note that the target-spec used in test sets max-atomic-width to 32 and atomic_cas to true, unlike the current rust-lang/rust#150138.) The original atomic-maybe-uninit implementation has been tested on real Arm hardware.

(Note that Armv6k also supports 64-bit atomic instructions, but they are skipped here. This is because there is no corresponding code in arm_linux.rs (since the kernel requirements increased in 1.64, it may be possible to implement 64-bit atomics there as well. see also taiki-e/portable-atomic#82), the code becomes more complex than for 32-bit and smaller atomics.)

cc @thejpster (target maintainer)

I'll undraft this PR once the target maintainer approved this approach.

rust-lang/compiler-builtins#1050

taiki-e · 2025-12-27T06:54:16Z

compiler-builtins/src/thumbv6k.rs

+    };
+}
+
+atomic_rmw!(@old __sync_fetch_and_add_1, u8, |a: u8, b: u8| a.wrapping_add(b));


The macro calls from here to L319 are the same as in arm_linux.rs (the definitions of the called macros are different), so I think it would be preferable to extract them into a separate file.

Done in af8d4af.

rust-lang/compiler-builtins#1050

thejpster · 2025-12-27T20:35:50Z

compiler-builtins/src/thumbv6k.rs

+        "mcr p15, #0, {zero}, c7, c10, #5"
+    };
+}
+macro_rules! asm_use_dmb {


I think this macro is just an asm block, but with macro expansion (and an extra {zero} register which I guess is useful somewhere). But it could probably do with a comment to explain all that because it's really non-obvious. Especially as this macro doesn't have anything to do with dmb (other than it's written as a macro that needs to be expanded).

This was originally a helper for writing code that required no changes other than using the Data Memory Barrier (DMB instruction or equivalent instructions).

In this PR, it is indeed unclear, so it can be deleted.

Removed asm_use_dmb! macro and renamed dmb! macro to cp15_barrier! (to more clearly reflect what it does) in a1a5401.

thejpster · 2025-12-28T12:56:31Z

This looks OK to me, but it's a bit beyond my Arm experience.

tgross35

Looks pretty good to me, thanks for the patch. This should wait until one of the compiler leads approves the target PR, though.

tgross35 · 2026-01-04T10:24:47Z

compiler-builtins/src/sync_builtins.rs

Nit: could you name this arm_thumb_sync_builtins or similar?

Actually, I think we may as well group this by functionality like we have for other areas, something like:

src/sync/ arm_linux.rs thumbv6k.rs arm_thumb_shared.rs // this file

I'll move the aarch64 builtins there too.

tgross35 · 2026-01-04T10:30:48Z

compiler-builtins/src/thumbv6k.rs

+        // FIXME(safety): preconditions review needed
+        let curval = unsafe { T::load_relaxed(ptr) };
+        let newval = f(curval);
+        // FIXME(safety): preconditions review needed
+        if unsafe { T::cmpxchg(ptr, curval, newval) } == curval {


Would you mind filling these in? Most of them are probably just related to pointer validity.

tgross35 · 2026-01-04T10:49:24Z

compiler-builtins/src/thumbv6k.rs

+                        dst = in(reg) dst,
+                        // Note: this cast must be a zero-extend since loaded value
+                        // which compared to it is zero-extended.
+                        old = in(reg) old as u32,


u32::from(old), since this should never truncate

tgross35 · 2026-01-04T10:50:00Z

compiler-builtins/src/thumbv6k.rs

+                            concat!("ldrex", $suffix, " {out}, [{dst}]"),      // atomic { out = *dst; EXCLUSIVE = dst }
+                            "cmp {out}, {old}",                                // if out == old { Z = 1 } else { Z = 0 }
+                            "bne 3f",                                          // if Z == 0 { jump 'cmp-fail }
+                            cp15_barrier!(),                                            // fence
+                        "2:", // 'retry:
+                            concat!("strex", $suffix, " {r}, {new}, [{dst}]"), // atomic { if EXCLUSIVE == dst { *dst = new; r = 0 } else { r = 1 }; EXCLUSIVE = None }
+                            "cmp {r}, #0",                                     // if r == 0 { Z = 1 } else { Z = 0 }
+                            "beq 3f",                                          // if Z == 1 { jump 'success }
+                            concat!("ldrex", $suffix, " {out}, [{dst}]"),      // atomic { out = *dst; EXCLUSIVE = dst }
+                            "cmp {out}, {old}",                                // if out == old { Z = 1 } else { Z = 0 }
+                            "beq 2b",                                          // if Z == 1 { jump 'retry }


For my own understanding: why is the barrier needed between the first ldrex/strex, but not between subsequent l/s pairs?

tgross35 · 2026-01-04T11:01:14Z

compiler-builtins/src/thumbv6k.rs

+                // SAFETY: the caller must uphold the safety contract.
+                // casts are okay because $ty and $base implement the same layout.
+                unsafe { <$base as Atomic>::load_relaxed(src.cast::<$base>()) as Self }
+            }
+            #[inline]
+            unsafe fn cmpxchg(dst: *mut Self, old: Self, new: Self) -> Self {
+                // SAFETY: the caller must uphold the safety contract.
+                // casts are okay because $ty and $base implement the same layout.
+                unsafe {
+                    <$base as Atomic>::cmpxchg(dst.cast::<$base>(), old as $base, new as $base)
+                        as Self
+                }


.cast_{un,}signed() is stable now and would make the as casts more clear

tgross35 · 2026-01-04T11:02:15Z

compiler-builtins/src/thumbv6k.rs

+#[rustfmt::skip]
+macro_rules! atomic {


I don't think rustfmt does any changes here

tgross35 · 2026-01-04T11:25:57Z

This PR has been tested on QEMU 10.2.0 using patched compiler-builtins and core that applied the changes in this PR and rust-lang/rust#150138 and the portable-atomic no-std test suite (can be run with ./tools/no-std.sh thumbv6-none-eabi on that repo) which tests wrappers around core::sync::atomic.

If you get the chance at some point, I would be rather interested in having some of your atomic test suite here. Especially the part you mention since we don't have any no-std tests set up.

(Note that Armv6k also supports 64-bit atomic instructions, but they are skipped here. This is because there is no corresponding code in arm_linux.rs (since the kernel requirements increased in 1.64, it may be possible to implement 64-bit atomics there as well. see also taiki-e/portable-atomic#82), the code becomes more complex than for 32-bit and smaller atomics.)

Assuming this would allow us to set target_has_atomic = "64", I think that would be worth it. Just not pressing, of course.

taiki-e added a commit to taiki-e/portable-atomic that referenced this pull request Dec 27, 2025

Remove thumbv6-none-eabi from no_atomic list

513d461

rust-lang/compiler-builtins#1050

taiki-e mentioned this pull request Dec 27, 2025

Add new Tier 3 targets for ARMv6 rust-lang/rust#150138

Open

taiki-e commented Dec 27, 2025

View reviewed changes

taiki-e force-pushed the thumbv6k branch from 82a177a to 3e39c7e Compare December 27, 2025 07:04

taiki-e added a commit to taiki-e/portable-atomic that referenced this pull request Dec 27, 2025

Remove thumbv6-none-eabi from no_atomic list

d7c7d90

rust-lang/compiler-builtins#1050

thejpster reviewed Dec 27, 2025

View reviewed changes

taiki-e added 3 commits December 28, 2025 22:00

Implement __sync builtins for thumbv6-none-eabi

363382c

Separate __sync builtins definitions into its own file

c93feea

Remove asm_use_dmb helper, rename dmb macro to cp15_barrier

f989e56

taiki-e force-pushed the thumbv6k branch from a1a5401 to f989e56 Compare December 28, 2025 13:00

taiki-e marked this pull request as ready for review December 28, 2025 13:00

tgross35 reviewed Jan 4, 2026

View reviewed changes

		#[rustfmt::skip]
		macro_rules! atomic {

Implement __sync builtins for thumbv6-none-eabi #1050

Are you sure you want to change the base?

Implement __sync builtins for thumbv6-none-eabi #1050

Uh oh!

Conversation

taiki-e commented Dec 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

thejpster commented Dec 28, 2025

Uh oh!

tgross35 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tgross35 Jan 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tgross35 commented Jan 4, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

taiki-e commented Dec 27, 2025 •

edited

Loading

tgross35 Jan 4, 2026 •

edited

Loading