On Tue, Jul 15, 2025 at 7:55 AM Florian Weimer <fwei...@redhat.com> wrote: > > * Adhemerval Zanella Netto: > > >> (b) Introduce binary markup to indicate that binaries may need the glibc > >> fix, and that glibc has the fix. > >> > >> [PATCH] x86-64: Add GLIBC_ABI_GNU2_TLS [BZ #33129] > >> > >> <https://inbox.sourceware.org/libc-alpha/20250704205341.155335-1-hjl.to...@gmail.com/> > >> > >> This requires changes to all linkers, GCC and glibc. > > >> I'm personally leaning towards (d) or (a) for GCC 16. I dislike (b). > >> And (e) is unrealistic in the short term. > > > > We did something similar to (b) for DT_RELR, so it is not > > unprecedented. > > But DT_RELR was a new feature. We expected wide-spread, > hard-to-diagnose breakage if it were rolled out without proper markup. > The TLSDESC bug was only found by massive, systematic testing, using a > huge codebase. Not being default option contributed to the bug staying > hidden for so long, but the overall triggering conditions also seem to > be complicated to meet. This s really different from DT_RELR without > markup, I think. > > We could treat TLSDESC without clobbers more like DT_RELR, but in my > opinion that requires revisting the question of whose ABI was right. > The (b) approach expresses that callee-saved vector registers are a new > feature, and that without it, GCC should generate code that assumes > vector registers are clobbered across TLSDESC. But we sort of decided > against this approach when we said this was a glibc bug and not a GCC > bug. > > > The (b) might generate some attrition when users try to deploy binaries > > built with recent gcc on older systems; even though running with the new > > TLS variant is subject to breakage. Either users will fallback to use > > the old tls dialect or employ some hacks like remove the > > GLIBC_ABI_GNU2_TLS mark (and yeah, there are multiple cases like this, > > like Firefox with DT_RELR). But at least the toolchain does provide > > a way to work around it. > > > > As H.J has noted, GLIBC_ABI_GNU2_TLS only requires glibc and linker > > issues. This does not help when recent gcc are used with old binutils, > > but I take this is not really a common setup. > > For (b), GCC would still need to know when it is safe to rely on > callee-saved vector registers for TLSDESC, no? If the linker is too > old, it won't know about the need to generate the ABI marker. >
Compilers will never know since the build-time glibc is independent of the run-time glibc. If compilers want to be 100% sure that the run-time is GNU2 TLS bug-free, they can require linkers which generate the GLIBC_ABI_GNU2_TLS dependency. -- H.J.
