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

[Florian Weimer <fweimer at redhat dot com>]

On 07/06/2017 06:08 PM, Carlos O'Donell wrote:
> 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.

Easier said than done when the guilty party has moved on and no longer
supports the buggy releases.

> 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.

But that's *never* been a goal with the way we maintain glibc.  We are
quite eager to break this in many other contexts.

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

I still think (c) is superior to the ___tls_get_addr (three _) solution.
 The three _s probably have to be made known to the sanitizers and to
valgrind, too.

> 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).

Would you please expand on that?  For RPM-based distributions, the new
___tls_get_addr (3 _) symbol would also add a GLIBC_2.26 or GLIBC_2.27
dependency, causing the same issue as any other versioned symbol.

> 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.

Surely you mean (a) here?  No new symbol for 2.26?

Thanks,
Florian