* 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. Thanks, Florian