[PATCH] [BZ #19679] [x86_64] Set DL_RUNIME_UNALIGNED_VEC_SIZE to 8

[H.J. Lu]

On Sat, Feb 20, 2016 at 4:05 AM, Florian Weimer <fweimer@redhat.com> wrote:
> On 02/20/2016 10:16 AM, Markus Trippelsdorf wrote:
>> On 2016.02.20 at 09:38 +0100, Florian Weimer wrote:
>>> On 02/20/2016 12:49 AM, H.J. Lu wrote:
>>>> +#ifndef DL_RUNTIME_UNALIGNED_VEC_SIZE
>>>> +/* The maximum size in bytes of unaligned vector load and store in the
>>>> +   dynamic linker.  Since SSE optimized memory/string functions with
>>>> +   aligned SSE register load and store are used in the dynamic linker,
>>>> +   we must set this to 8 so that _dl_runtime_resolve_sse will align the
>>>> +   stack before calling _dl_fixup.  */
>>>> +# define DL_RUNTIME_UNALIGNED_VEC_SIZE 8
>>>
>>> The comment doesn't really explain the situation.  If all programs
>>> actually fallowed the psABI, we wouldn't need this.
>>>
>>> I think it's easier at this point to change the psABI to say that
>>> __tls_getaddr can be called with an 8-byte-aligned stack.
>>
>> I think this would be an overreaction.
>
> I don't know.  If glibc will keep this compatibility code indefinitely,
> it's easy for other toolchains to make the same mistake.
>

On one hand, we are realigning stack in glibc anyway, may be forever,
and compiler doesn't need to keep stack aligned to 16 bytes when calling
__tls_getaddr.  Also we realign stack in AVX and AVX512 machines
anyway and TLS isn't completely specified in the x86-64 psABI.

On the other hand, it is odd to change psABI after 10 years just because
one compiler has a bug in its TLS implementation.

If we change the x86-64 psABI for this, I will update i386 psABI specify
that __tls_getaddr has 4-byte incoming stack alignment.

FYI, I am backporting it to 2.23 branch.

-- 
H.J.