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 10:35 AM, Florian Weimer wrote:
> On 07/06/2017 04:30 PM, Carlos O'Donell wrote:
> 
>>> I'm not sure if the second patch is actually needed, and if the new
>>> symbol is the right way to do it. It penalizes those who use modern and
>>> fixed compilers by making their lives more complicated, while we should
>>> do it the other way round (those who use unfixed compilers should
>>> suffer, at least if the choice is between the two outcomes).
>>
>> Isn't the "suffering" just that you cannot build a compiler that is both
>> compatible with the old glibc (performance loss) and new glibc (fastest
>> performance)?
> 
> No, there is also the programmer inconvenience that they'd have to deal
> with yet another -m flag.
> 
> If it's unconditional, you wouldn't be able to use the new GCC with the
> alternate symbol enabled for glibc development (stable branch
> maintenance, to be specific).
> 
> It's that kind of complexity I'm objecting to.

The complexity is a consequence of the bug and our desire to attain optimal
performance for __tls_get_addr calls, which are integral to __thread usage.

Objecting abstractly to the complexity does not take into account the entire
set of consequences surrounding this problem. The objections must be balanced
against the gains being sought here, and the performance our users want.

As far as I understand it there are two paths we could take:

(a) __tls_get_addr aligns the stack for you if required, with a fast and
    slow path, everyone pays the small cost to check fir misalignment, and
    only the broken old binaries are forced to realign. This change works
    for old and new binaries without any need to coordinate between the
    compiler and the runtime.

    Pro: No gcc/glibc coordination (no additional flags).
    Con: All applications pay a small cost to check.

(b) We add a ___tls_get_addr which assumes alignment of the stack and a
    newly configured gcc that notices the system glibc provides this symbol
    automatically defaults to building with this option enabled.
    One of:
    (b.1) A configure option to disable the use of the new ___tls_get_addr.
    or
    (b.2) A new machine option -m<disable tls align>/-m<enable tls align>
    option is used to control this feature.
    Both b.1 and b.2 change the ABI.

    Pro: Fastest solution. Only old applications pay the check+align cost.
    Con: All application developers must ensure gcc/glibc coordination.
    When building a new gcc with a new glibc, the resulting compiler defaults
    to the new ABI, and if you need to build an old glibc you must add to
    your CFLAGS the right -m<disable tls align>.

So the question becomes:

How many users build their gcc/glibc and need to handle the coordination?

Are we asking all future users to pay a cost to simplify developer workflow?

As much as I don't like the complexity, I see the inherent value to our users
in what HJ is proposing.

-- 
Cheers,
Carlos.