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

[Florian Weimer <fweimer at redhat dot com>]

On 07/06/2017 04:52 PM, Carlos O'Donell wrote:

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

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.

I think (c) is better than (b).  But (c) vs (a) is a tough call.

Thanks,
Florian