On 05/07/17 17:18, H.J. Lu wrote: > On Wed, Jul 5, 2017 at 8:53 AM, Szabolcs Nagy <szabolcs.n...@arm.com> wrote: >> On 05/07/17 16:38, H.J. Lu wrote: >>> On x86-64, __tls_get_addr has to realigns stack so that binaries compiled by >>> GCCs older than GCC 4.9.4: >>> >>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58066 >>> >>> continue to work even if vector instructions are used by functions called >>> from __tls_get_addr, which assumes 16-byte stack alignment as specified >>> by x86-64 psABI. >>> >>> We are considering to add an alternative interface, ___tls_get_addr, to >>> glibc, which doesn't realign stack. Compilers, which properly align stack >>> for TLS, call generate call to ___tls_get_addr, instead of __tls_get_addr, >>> if ___tls_get_addr is available. >>> >>> Any comments? >>> >>> >> >> what happens when new compiler generating the new symbol >> is used with old glibc? >> > > Compiler shouldn't do that. >
i don't see how can the compiler not do that e.g. somebody building an old glibc from source with new compiler, then runs the tests, all tls tests would fail because the compiler generated the new symbol. or users interposing __tls_get_addr (asan) need to update their code. or there are cases when libraries built against one libc is used with another (e.g. musl can mostly use a libstdc++ compiled against glibc on x86_64) i think introducing new libc<->compiler abi should be done conservatively when it is really necessary and from Rich's mail it seems there is no need for new abi here.
