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

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Thu, Jul 6, 2017 at 8:07 AM, Florian Weimer <fweimer@redhat.com> wrote:
> 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.
>

(c) doesn't fix the problem for unfixed GCC at all.  As far as unfixed GCC
is concerned, nothing is changed.  For fixed GCC, it is the same as without
the bug for [BZ #21609].  I think (c) is the least suitable option.

-- 
H.J.