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 04:26 PM, Florian Weimer wrote:
> On 07/06/2017 06:08 PM, Carlos O'Donell wrote:
>> 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 do not mean to set precedent for other technical discussions, and I am
talking specifically about the problem of __tls_get_addr.

I think that symbol versioning is a good solution to this problem, but it's
the simplest solution, and if we can do better, then we should.
 
>> 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.

That is a good 'Con' against (b). Is it true? We should have someone like
Mark Wielaard comment on this?

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

My comment above was only to say that distributions rebuild packages for many
reasons, and after that rebuild is complete the package may fail to compile,
or operate correctly at runtime because of a semantic change we made using
symbol versioning. That is OK though, we allowed existing users to continue
to user their packages for as long as they wanted, and that is the ABI guarantee
we give. I do not want to remove value from symbol versioning, or header changes,
all things which we are allowed to do.

I want us to do better than symbol versioning, if we can, and if the cost/reward
is in favour of doing that.

When comparing (b) to (c) from a distro perspective we see:

(b) New ___tls_get_addr (3x_) API.
    Pro: Link failures if you get the coordination wrong.
    Con: Need to coordinate a glibc/gcc release in the distro.

(c) New symbol version.
    Pro: No need to coordinate a glibc/gcc release in the distro.
    Con: Can create broken packages depending on which glibc/gcc
         combination is in the buildroot, or was used by the user.

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

Sorry, yes (a). No new symbol for 2.26, which is what HJ checked in.

In closing I would like to point out that it is not as cut-and-dry as we make
it out to be and that choosing between (a), (b), and (c) should be done with
due consideration.

Thankfully we can always revisit an optimization given our choice with (a).

For example we should probably look at TLSDESC again for x86_64.

-- 
Cheers,
Carlos.