This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: RFC: Add ___tls_get_addr
- From: Szabolcs Nagy <szabolcs dot nagy at arm dot com>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>
- Cc: nd at arm dot com, "x86-64-abi at googlegroups dot com" <x86-64-abi at googlegroups dot com>, GNU C Library <libc-alpha at sourceware dot org>, GCC Development <gcc at gcc dot gnu dot org>
- Date: Thu, 06 Jul 2017 09:06:19 +0100
- Subject: Re: RFC: Add ___tls_get_addr
- Authentication-results: sourceware.org; auth=none
- Authentication-results: gcc.gnu.org; dkim=none (message not signed) header.d=none;gcc.gnu.org; dmarc=none action=none header.from=arm.com;
- Nodisclaimer: True
- References: <CAMe9rOrYdAh6kJUUTdyzWdwfhEWVuiHJVs5xhp4pVbeB6hEM1w@mail.gmail.com> <595D0B89.8040004@arm.com> <CAMe9rOo12ow=WPo4_01rrtq-WFnqKR_f1yXZq4=PXKBSjyV=Fg@mail.gmail.com>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
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.