Re: [AArch64][TLSLE][3/3] Implement local executable mode for all memory model

[Jiong Wang <jiong dot wang at arm dot com>]

Christophe Lyon writes:

> On 27 August 2015 at 12:03, Jiong Wang <jiong.wang@arm.com> wrote:
>>
>> Jiong Wang writes:
>>>>>
>>>>> Those relocation types required by tls-size 12 & 24 are supported by
>>>>> binutils-2.25 already, and you have passed compilation and failed at
>>>>> exectuion, so there do have something wrong I guess.
>>>>>
>>>>> Either the generated instruction sequence or the bare-metal environment.
>>>>>
>>>>> One thing strange to me is those testcases are guarded by:
>>>>>
>>>>>   /* { dg-require-effective-target tls_native } */
>>>>>
>>>>> while for bare-metal environment, normally you don't have tls_native
>>>>> support right? then these testcases should have been marked as
>>>>> unsupported otherwise they will generate native tls instruction
>>>>> sequences while the bare-metal runtime environment may don't support
>>>>> initialize tp register etc, thus caused the exectuion error.
>>>>>
>>>>> Could you please double check this? thanks
>>>>>
>>>>
>>>> Well, the "tls_native" check passes (there is no "emutls" string in
>>>> the generated assembly).
>>>> This BTW, does not involve the binutils, since it only check the
>>>> assembly output.
>>>>
>>>> Could it be a configure error instead? (where GCC wouldn't notice that
>>>> it shouldn't generate such relocations)
>>>
>>> to me, it's more like this. native tls is enabled on a no such support
>>> platform.
>>>
>>> I am trying to setup a bare-metal environment for reproducing. I was
>>> testing on linux environment.
>>
>> Finished test on my local aarch64-none-elf bare-metal. they are marked
>> as unsupported correctly. gcc is doing correct configuration on my
>> environment. looks like somehow gcc is doing wrong tls enable on your
>> bare-metal platform.
>>
> I checked libgcc's configure output and it answers "no" to the
> question "whether the thread-local storage support is from emutls"
>
> What is the result in your case?
>
> And before that 'assembler supports thread-local storage' is yes, too.

configure:4849: checking whether the target assembler supports thread-local storage
...
configure:4867: result: yes

configure:4877: checking whether the thread-local storage support is from emutls
...
configure:4898: result: yes

That's my log which means native tls disabled as we are using emutls. A
double check shows my bare-metal environment is passing --disable-tls
explicitly when configuring gcc.

A further look at the gcc code shows gcc decides whether to use native
tls or emultls based on targetm.have_tls which is assigned to the value
HAVE_AS_TLS.

And HAVE_AS_TLS is defined during configure by simply assemble a .s
includs some simple instruction sequences contains tls specific
stuff.

So gcc is making the decision purely on static check, this make sense to
me, as it's hard or impossible to make runtime check because you only
have binutils that time as toolchain build steps is normally
binutils->gcc->libc->g++.

I think you need to pass "--disable-tls" to your bare-metal gcc
configuration, as gcc do needs user's help here as it doesn't understand
runtime features.

Above solution is only wrong if your bare-metal do support "tp" based
native tls mechanism which I think largely not.


>
>> UNSUPPORTED: gcc.target/aarch64/tlsdesc_hoist.c
>> UNSUPPORTED: gcc.target/aarch64/tlsle12_1.c
>> UNSUPPORTED: gcc.target/aarch64/tlsle24_1.c
>> UNSUPPORTED: gcc.target/aarch64/tlsle32_1.c
>> --
>> Regards,
>> Jiong
>>

-- 
Regards,
Jiong