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