Re: [PATCH] x86-64: Align the stack in __tls_get_addr [BZ #21609]

[Carlos O'Donell <carlos at redhat dot com>]

On 07/06/2017 11:15 AM, Florian Weimer wrote:
> On 07/06/2017 05:11 PM, H.J. Lu wrote:
> 
>>> There's also this option:
>>>
>>> (c) glibc provides __tls_get_addr (two leading underscores)
>>>     under a new symbol version.
>>>
>>>     Pro: No GCC changes required for upstream maintained versions.
>>>     No problems for glibc development, no new -m flag.
>>>     As fast as (b) after relinking against a newer glibc.
>>>     Breakage with older/unfixed GCC is detectable during development
>>>     (unlike the reason for the workaround, which would have needed
>>>     clairvoyance on the developer's part).
>>>
>>>     Con: Relinking code compiled with the old, unfixed GCC against the
>>>     new glibc still produces broken binaries.
>>>
>>
>> (c) doesn't fix the problem for unfixed GCC at all.  As far as unfixed GCC
>> is concerned, nothing is changed.
> 
> It fixes existing binaries by addressing the implied ABI breakage by the
> glibc update.
> 
> It's my strong belief that compiler bugs should be fixed in the
> compiler, not in glibc.

The GNU C Library is part of the GNU Toolchain and the implementation.

We should work together to offer the best solution to our users.

In the case of (a), and (b) (assuming you don't downgrade your glibc, which
is dangerous for other reasons) it works even if the packages are rebuilt,
and that's an important "Pro" benefit.

I'd say choosing between (a) and (b) is what's really up for discussion.

Yes (c) is a simple option, but in the end, given how distributions operate,
symbol versioning should be our last choice (one which we don't have to make
in this case).

I think we've pretty much agreed that (b) is going to be the solution for
glibc 2.26, and HJ has checked in changes to that effect. Future optimizations
about ___tls_get_addr can be discussed later.

-- 
Cheers,
Carlos.