On 27 August 2015 at 15:35, Jiong Wang <jiong.w...@arm.com> wrote:
>
> Christophe Lyon writes:
>
>> On 27 August 2015 at 12:03, Jiong Wang <jiong.w...@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.
>
Thanks for looking at that. Indeed, I do not pass --disable-tls, I relied on
configure to do-the-right-thing.
I'll make that change.
> Above solution is only wrong if your bare-metal do support "tp" based
> native tls mechanism which I think largely not.
I'm using the classical newlib.
>
>>
>>> 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
>
