This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: RFC: Add ___tls_get_addr
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Szabolcs Nagy <szabolcs dot nagy at arm dot com>
- Cc: nd <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, 6 Jul 2017 04:06:55 -0700
- Subject: Re: RFC: Add ___tls_get_addr
- Authentication-results: sourceware.org; auth=none
- References: <CAMe9rOrYdAh6kJUUTdyzWdwfhEWVuiHJVs5xhp4pVbeB6hEM1w@mail.gmail.com> <595D0B89.8040004@arm.com> <CAMe9rOo12ow=WPo4_01rrtq-WFnqKR_f1yXZq4=PXKBSjyV=Fg@mail.gmail.com> <595DEF7B.50203@arm.com>
On Thu, Jul 6, 2017 at 1:06 AM, Szabolcs Nagy <szabolcs.nagy@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.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.
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.