[PATCH 0/2] sparc32: restore baseline-V8 glibc builds that need an out-of-line compare-and-swap

[Adhemerval Zanella Netto]

On 24/09/26 08:40, Magnus Lindholm wrote:
> Hi Florian,
> 
> On Thu, Sep 24, 2026 at 11:10 AM Florian Weimer <fweimer@redhat.com> wrote:
>>
>> * Magnus Lindholm:
>>
>>> The SPARC V8 baseline has no compare-and-swap instruction.  GCC lowers
>>> __atomic_compare_exchange and the read-modify-write builtins it cannot
>>> inline to calls into libatomic.  glibc cannot link against libatomic,
>>> which is itself built against glibc, so any of glibc's own code the
>>> compiler happens to lower this way has been unbuildable for this
>>> target since libatomic became the compiler's only fallback in 2019.
>>
>> Shouldn't this be fixed in GCC?  If kernel assists are transparent to
>> userspace (and are address-independent etc.), GCC should report these
>> atomics as lock-free, and put hte out-of-line implementations into
>> libgcc instead of libatomic.
>>
>> Thanks,
>> Florian
>>
> 
> Fair question, and there's real precedent for it: ARM carried its own
> internal kernel-assisted CAS (__kuser_cmpxchg) for pre-ARMv6 hardware for
> about two decades, entirely inside glibc, before GCC's own codegen took
> it over directly in 2021 (commit f9646d1, BZ #24774) and glibc dropped
> its copy for good.
> 
> The difference here is that ARM's kernel helper has been an unconditional
> part of the ABI since ARM Linux's first release, present on every kernel
> a binary could run on, so GCC can just always inline the call, no runtime
> check needed. The sparc32 trap doesn't have that history: it's posted
> 
> https://lore.kernel.org/sparclinux/20260923201830.865553-1-linmag7@gmail.com/
> 
> but not landed, and its ABI details, the memory-ordering contract in
> particular, are still moving during review. That's not about a legacy
> install base to stay compatible with,  sparc32 doesn't boot mainline at
> all yet without the other prerequisite series, it's that until the trap
> is actually upstream and stable as part of the ABI, its presence is a
> runtime fact glibc has to check via AT_HWCAP, not something GCC can fold
> into a compile-time lock-free guarantee the way it could for ARM's
> always-present helper.
> 
> If that kernel series ends up designed so the trap is unconditionally
> safe to call, the kernel choosing internally whether to satisfy it via
> real casa or software emulation, the way ARM's kuser page does, then I
> agree the ARM path becomes available here too. If anything I'd expect
> that to be the natural order: ARM's own mechanism lived as a glibc-
> internal stopgap for about two decades before GCC could safely absorb it
> in 2021, and a compiler can hardly bake in support for a mechanism
> nothing has used yet. I'd rather not gate glibc's ability to build for
> this target on that kernel design settling and landing first, but it's
> the right longer-term target and this series doesn't foreclose it.

Sorry, I don't want to re-instate arch-specific atomics after we spent
a lot of cycles removing them and making sure that libgcc works correctly
by proving the required lock-free primitives. keeping them was a PITA,
where we have wrapper over wrappers.

We had this on glibc because atomics pre-C11 was a complete mess: each
ABI having slight different semantics, kernel support was incomplete in
some cases (we even had to add runtime checks for these cases, check
47c5adebd2c8, f5c77f78ec03, 2e4cf7789725, and 8e3c00db16fc), and for 
some ABI the atomic support was absent.

We are now requiring the ABI to proper support C11 semantic, and only
through compiler builtins.  So the way to re-enable v8 support is to
first get the support on kernel, then add the support on libgcc, and 
finally on glibc transparently through GCC atomic builtins.

We might also want a configure check to double-check compiler is not
linking against libatomic.