"H.J. Lu" <hjl.to...@gmail.com> writes: > On Tue, Jul 15, 2025 at 8:47 AM 'Florian Weimer' via X86-64 System V > Application Binary Interface <x86-64-...@googlegroups.com> wrote: >> >> * H. J. Lu: >> >> > 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. >> >> (Such a linker requirement could be enforced by requiring that the >> linker recognizes a command option specific to GLIBC_ABI_GNU2_TLS, and >> that current linkers treat as an error.) >> >> Would such an unconditional requirement be acceptable to GCC 16? I >> don't think so. So we'd still have to design a configure option for it. >> And that requires further compiler changes. It's also not entirely >> clear how this would interact with -fuse-ld. >> >> I just don't think option (b) is trivial from a compiler perspective. >> > > It depends on what we want. If we want 100% guarantee of glibc run-time > GNU2 TLS bug-free, GCC can pass -z gnu2-tls to linker whenever GNU2 TLS > is used with glibc. It is an error if the linker doesn't support -z > gnu2-tls. We > can provide a GCC option to disable -z gnu2-tls.
Agreed. For DT_RELR, we were pretty worried. If we're worried about GNU2 TLS descriptors to the same substantial level, we can and should add the marker because users will distribute binaries either way even if it is not the default. If we're not worried, great, we can pick a compromise option like enabling purely based on build-time bfd version. But if we do (e)/(f), wouldn't we have the same problem, and have to introduce a dependency again? I am really leaning towards (d).
