On 15/02/24 09:13, H.J. Lu wrote:
> On Thu, Feb 15, 2024 at 4:12 AM H.J. Lu <hjl.to...@gmail.com> wrote:
>>
>> On Thu, Feb 15, 2024 at 3:49 AM Adhemerval Zanella Netto
>> <adhemerval.zane...@linaro.org> wrote:
>>>
>>>
>>>
>>> On 15/02/24 08:47, H.J. Lu wrote:
>>>> On Thu, Feb 15, 2024 at 12:01 AM Maxim Kuvyrkov
>>>> <maxim.kuvyr...@linaro.org> wrote:
>>>>>
>>>>>> On Feb 15, 2024, at 03:54, H.J. Lu <hjl.to...@gmail.com> wrote:
>>>>>>
>>>>>> FAIL: elf/tst-gnu2-tls2
>>>>>>
>>>>>> indicates that your _dl_tlsdesc_dynamic may not preserve all caller-saved
>>>>>> registers.  Please find out how the test fails.
>>>>>
>>>>> Hi H.J.,
>>>>>
>>>>> See below.
>>>>>
>>>>> ...
>>>>>> FAIL: 1 regressions
>>>>>>
>>>>>> regressions.sum:
>>>>>>                === glibc tests ===
>>>>>>
>>>>>> Running glibc:elf ...
>>>>>> FAIL: elf/tst-gnu2-tls2
>>>>>>
>>>>>>
>>>>>> You can find the failure logs in *.log.1.xz files in
>>>>>> - 
>>>>>> https://ci.linaro.org/job/tcwg_glibc_check--master-arm-precommit/1460/artifact/artifacts/artifacts.precommit/00-sumfiles/
>>>>>
>>>>> tests.log.1.xz contains output of failed tests --
>>>>> https://ci.linaro.org/job/tcwg_glibc_check--master-arm-precommit/1460/artifact/artifacts/artifacts.precommit/00-sumfiles/tests.log.1.xz
>>>>> ===
>>>>> FAIL: elf/tst-gnu2-tls2
>>>>> original exit status 1
>>>>> open tst-gnu2-tls2mod0.so
>>>>> open tst-gnu2-tls2mod1.so
>>>>> open tst-gnu2-tls2mod2.so
>>>>> close tst-gnu2-tls2mod0.so
>>>>> close tst-gnu2-tls2mod1.so
>>>>> open tst-gnu2-tls2mod0.so
>>>>> open tst-gnu2-tls2mod1.so
>>>>> Didn't expect signal from child: got `Segmentation fault'
>>>>> ===
>>>>>
>>>>> Let me know if you need any help investigating this.
>>>>>
>>>>
>>>> I don't have access to aarch64 machine which can build glibc.
>>>> Please configure glibc with --enable-hardcoded-path-in-tests
>>>> and run elf/tst-gnu2-tls2 under GDB to find out what is going
>>>> on.
>>>>
>>>
>>> I will check this out H.J.
>>
>> Does your _dl_tlsdesc_dynamic save ALL caller-saved registers,
>> except for the return value register?  I saw
>>
>>         stp      x5,  x6, [sp, #16*1]
>>         stp      x7,  x8, [sp, #16*2]
>>         stp      x9, x10, [sp, #16*3]
>>         stp     x11, x12, [sp, #16*4]
>>         stp     x13, x14, [sp, #16*5]
>>         stp     x15, x16, [sp, #16*6]
>>         stp     x17, x18, [sp, #16*7]
>>
>> Do you need to save x1 to x4?
>>
>> --
>> H.J.
> 
> If your processor is also impacted, please add it to
> 
> https://sourceware.org/bugzilla/show_bug.cgi?id=31372
> 

Hi H.J.

The issues is not really on aarch64, but rather arm 32 bits.  And it is
seems to be a real one on arm _dl_tlsdesc_dynamic implementation, that 
fail to save/restore r12 that is used by gcc as a scratch register.

I have added 3 more fixes on top on your patches [1].  First one is a 
small fix for the -mtls-dialect=gnu2 configure test that fail when
-mtp=soft is used (used by default arm-linux-gnueabihf cross compiler
produced by build-many-glibcs.py).

Second is the arm fix for BZ 31372 regression.  However, I am not sure 
if this suffice, since similar to others ABIs, arm also support vector 
extensions (VFP, VFP3, and neon).  I think we will eventually need to 
do something similar to what you did for x86 and provided either
multiple _dl_tlsdesc_dynamic or handle the vector register save/restore
using hwcap feature check (or we can also eventually just remove the
slow patch and get over this whole save/restore vector extensions).

This is not an issue now on arm32 because gnu2 is not default and I 
don't think gcc will flip the switch in near future.

The last patch enables TLS descriptor tests on aarch64 as well, since 
it uses a different name of gnu2.  I think RISC-V will use the same 
naming as aarch64, so it would make easier to enable such tests 
on this abi as well.

[1] https://github.com/zatrazz/glibc/commits/azanella/tls-descriptor-fixes-arm/

_______________________________________________
linaro-toolchain mailing list -- linaro-toolchain@lists.linaro.org
To unsubscribe send an email to linaro-toolchain-le...@lists.linaro.org

Reply via email to