This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: Add ___tls_get_addr


On 05/07/17 17:18, H.J. Lu wrote:
> On Wed, Jul 5, 2017 at 8:53 AM, Szabolcs Nagy <szabolcs.nagy@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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]