On Thu, Jul 6, 2017 at 1:06 AM, Szabolcs Nagy <szabolcs.n...@arm.com> wrote: > 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.
Using ___tls_get_addr should be controlled by an option selected by compiler build time as well as run-time. > or users interposing __tls_get_addr (asan) need > to update their code. Yes. That is true. > 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) This happens every time when a new version of a function is added to glibc. musl has to deal with it. > i think introducing new libc<->compiler abi This is no different from adding a new version of a function to glibc. > should be done conservatively when it is really > necessary and from Rich's mail it seems there > is no need for new abi here. > See: https://sourceware.org/ml/libc-alpha/2017-07/msg00086.html -- H.J.