[PATCH] [BZ #20309] X86-64: Properly align stack in _dl_tlsdesc_dynamic

[H.J. Lu]

On Mon, Jul 11, 2016 at 9:53 AM, Szabolcs Nagy <szabolcs.nagy@arm.com> wrote:
> On 11/07/16 16:55, H.J. Lu wrote:
>> On Wed, Jun 29, 2016 at 6:24 AM, H.J. Lu <hongjiu.lu@intel.com> wrote:
>>> Since _dl_tlsdesc_dynamic is called via PLT, we need to add 8 bytes
>>> for for push in the PLT entry to align the stack.
>>>
>>> Tested on i686 and x86-64.  OK for trunk?
>>
>> If there is no objection by the end of today, I will check it tomorrow.
> ...
>>> +AC_CACHE_CHECK([for -mtls-dialect=gnu2], libc_cv_mtls_dialect_gnu2,
>>> +[dnl
>>> +cat > conftest.c <<EOF
>>> +__thread int i;
>>> +void foo (void)
>>> +{
>>> +  i = 10;
>>> +}
>>> +EOF
>>> +if AC_TRY_COMMAND([${CC-cc} $CFLAGS $CPPFLAGS -S -fPIC -mtls-dialect=gnu2
>>> +                  conftest.c 1>&AS_MESSAGE_LOG_FD])
>>> +then
>>> +  libc_cv_mtls_dialect_gnu2=yes
>>> +else
>>> +  libc_cv_mtls_dialect_gnu2=no
>>> +fi
>>> +rm -f conftest*])
>>> +AC_SUBST(libc_cv_mtls_dialect_gnu2)
>>> +LIBC_CONFIG_VAR([have-mtls-dialect-gnu2], [$libc_cv_mtls_dialect_gnu2])
>>> +
>
> on aarch64 the flag is -mtls-dialect=desc
> (it's the default dialect though)
>
>>> --- a/elf/Makefile
>>> +++ b/elf/Makefile
>>> @@ -224,6 +224,13 @@ modules-names = testobj1 testobj2 testobj3 testobj4 testobj5 testobj6 \
>>>                 tst-tlsalign-lib tst-nodelete-opened-lib tst-nodelete2mod \
>>>                 tst-audit11mod1 tst-audit11mod2 tst-auditmod11 \
>>>                 tst-audit12mod1 tst-audit12mod2 tst-audit12mod3 tst-auditmod12
>>> +ifeq (yes,$(have-mtls-dialect-gnu2))
>>> +tests += tst-gnu2-tls1
>>> +modules-names += tst-gnu2-tls1mod
>>> +$(objpfx)tst-gnu2-tls1: $(objpfx)tst-gnu2-tls1mod.so
>>> +tst-gnu2-tls1mod.so-no-z-defs = yes
>>> +CFLAGS-tst-gnu2-tls1mod.c += -mtls-dialect=gnu2
>>> +endif
>
> so this new test won't run on aarch64.
>
> i don't object to the patch, but i think
> testing with different tls-dialects may
> eventually need a better approach.
>

I can move -mtls-dialect=gnu2 test to sysdep/x86 if it is x86 specific.
Or we can leave it as is and adapt it to different targets later.

-- 
H.J.