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

[Christophe Lyon <christophe dot lyon at linaro dot org>]

On 27 August 2015 at 10:35, Jiong Wang <jiong.wang@arm.com> wrote:
>
> Christophe Lyon writes:
>
>> On 19 August 2015 at 16:21, Jiong Wang <jiong.wang@arm.com> wrote:
>>>
>>> Marcus Shawcroft writes:
>>>
>>>> On 21 May 2015 at 17:49, Jiong Wang <jiong.wang@arm.com> wrote:
>>>>
>>>>> 2015-05-14  Jiong Wang  <jiong.wang@arm.com>
>>>>> gcc/
>>>>>   * config/aarch64/aarch64.c (aarch64_print_operand): Support tls_size.
>>>>>   * config/aarch64/aarch64.md (tlsle): Choose proper instruction
>>>>>   sequences.
>>>>>   (tlsle_<mode>): New define_insn.
>>>>>   (tlsle_movsym_<mode>): Ditto.
>>>>>   * config/aarch64/constraints.md (Uta): New constraint.
>>>>>   (Utb): Ditto.
>>>>>   (Utc): Ditto.
>>>>>   (Utd): Ditto.
>>>>>
>>>>> gcc/testsuite/
>>>>>   * gcc.target/aarch64/tlsle.c: New test source.
>>>>>   * gcc.target/aarch64/tlsle12.c: New testcase.
>>>>>   * gcc.target/aarch64/tlsle24.c: New testcase.
>>>>>   * gcc.target/aarch64/tlsle32.c: New testcase.
>>>>>
>>>>
>>>>
>>>>   case SYMBOL_TLSLE:
>>>> -  asm_fprintf (asm_out_file, ":tprel_lo12_nc:");
>>>> +  if (aarch64_tls_size <= 12)
>>>> +    /* Make sure TLS offset fit into 12bit.  */
>>>> +    asm_fprintf (asm_out_file, ":tprel_lo12:");
>>>> +  else
>>>> +    asm_fprintf (asm_out_file, ":tprel_lo12_nc:");
>>>>    break;
>>>>
>>>> Use the existing classify_symbol mechanism we use throughout the
>>>> aarch64 backend.  Specifically rename SYMBOL_TLSLE as SYMBOL_TLSLE24
>>>> and introduce the 3 missing flavours then use the symbol
>>>> classification to control behaviour such as this modifier selection.
>>>
>>> Done.
>>>
>>> classified TLS symbol into the following sub-types according to the value of tls size.
>>>
>>>  SYMBOL_TLSLE12
>>>  SYMBOL_TLSLE24
>>>  SYMBOL_TLSLE32
>>>  SYMBOL_TLSLE48
>>>
>>> And On AArch64, instruction sequence for TLS LE under -mtls-size=32 will
>>> utilize the relocation modifier "tprel_g0_nc" together with MOVK, it's
>>> only supported in binutils since 2015-03-04 as PR gas/17843. So I
>>> adjusted tlsle32.c to make it robust by detecting whether there is such
>>> binutils support.
>>>
>>
>> Hi,
>>
>> I'm (still) using binutils-2.25, and I can see that 2 of these new
>> tests (tlsle12_1.c and tlsle24_1.c) fail at execution time on
>> aarch64*-none-elf targets.
>
> Christophe,
>
> 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)
I can see it uses tprel_hi12 and tprel_lo12_nc.


> Regards,
> Jiong
>