On 27 August 2015 at 10:35, Jiong Wang <jiong.w...@arm.com> wrote:
>
> Christophe Lyon writes:
>
>> On 19 August 2015 at 16:21, Jiong Wang <jiong.w...@arm.com> wrote:
>>>
>>> Marcus Shawcroft writes:
>>>
>>>> On 21 May 2015 at 17:49, Jiong Wang <jiong.w...@arm.com> wrote:
>>>>
>>>>> 2015-05-14 Jiong Wang <jiong.w...@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
>
