This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] x86-64: Align the stack in __tls_get_addr [BZ #21609]
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