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

[Magnus Lindholm]

Hi Adhemerval,

On Thu, Sep 24, 2026 at 2:11 PM Adhemerval Zanella Netto
<adhemerval.zanella@linaro.org> wrote:
>
>
>
> 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.

Thanks for taking the time to lay that out, history included, that's a
good answer and I'll pursue it. The kernel trap is already posted (v3);
I'll work from there on getting v8 support into libgcc directly instead
of glibc's own atomic-machine.h, so it's picked up transparently through
the compiler builtins like every other target now.

I won't be pursuing this glibc series with that in mind. In the meantime
I'll carry it downstream, since as things stand a v8 sparc32 target
can't build a modern glibc at all, it at least gets a working modern
userland on real V8 hardware while the proper fix is in progress, for me
and anyone else still running one of these.

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

That sounds like a good idea on its own regardless of this series,
happy to look at it separately if useful.

Thanks again,
Magnus