Hi Waldemar,
On 2/7/20 1:51 PM, Waldemar Brodkorb wrote:
> Hi,
> Vladimir Murzin wrote,
>
>> Hi Waldemar,
>>
>> On 2/7/20 1:40 PM, Waldemar Brodkorb wrote:
>>> Hi Vladimir,
>>>
>>> thanks, all four patches applied and pushed.
>>> Reduces the failure count for aarch64 testing to 3 from
>>> 34.
>>
>> Great!
>>
>> May I know which are failing test so I might have a look when I
>> get enough bandwidth?
>
> These are the open failures:
>
> .... tst-tls17^MFAIL tst-tls17 got 1 expected 0
> Didn't expect signal from child: got `Segmentation fault'
> .... tst-tls18^MFAIL tst-tls18 got 1 expected 0
> Didn't expect signal from child: got `Segmentation fault'
> .... tst-res^MFAIL tst-res got 139 expected 0
> Segmentation fault
>
>
I got some time to look into it. I took tst-tls17 and this is how it fails
(gdb) disassemble
Dump of assembler code for function tlsmod17a0:
0x0000fffff7f1a710 <+0>: stp x29, x30, [sp, #-16]!
0x0000fffff7f1a714 <+4>: mrs x2, tpidr_el0
0x0000fffff7f1a718 <+8>: adrp x0, 0xfffff7f2b000
0x0000fffff7f1a71c <+12>: ldr x1, [x0, #32]
0x0000fffff7f1a720 <+16>: add x0, x0, #0x20
0x0000fffff7f1a724 <+20>: blr x1
0x0000fffff7f1a728 <+24>: mov x29, sp
0x0000fffff7f1a72c <+28>: add x2, x2, x0
0x0000fffff7f1a730 <+32>: cbz x2, 0xfffff7f1a744 <tlsmod17a0+52>
=> 0x0000fffff7f1a734 <+36>: ldr w1, [x2]
0x0000fffff7f1a738 <+40>: mov w0, #0x0 // #0
0x0000fffff7f1a73c <+44>: cmp w1, #0x4
0x0000fffff7f1a740 <+48>: b.eq 0xfffff7f1a758 <tlsmod17a0+72> //
b.none
0x0000fffff7f1a744 <+52>: adrp x0, 0xfffff7f1a000
0x0000fffff7f1a748 <+56>: mov w1, #0x0 // #0
0x0000fffff7f1a74c <+60>: add x0, x0, #0x770
0x0000fffff7f1a750 <+64>: bl 0xfffff7f1a5a0 <printf@plt>
0x0000fffff7f1a754 <+68>: mov w0, #0x1 // #1
0x0000fffff7f1a758 <+72>: ldp x29, x30, [sp], #16
0x0000fffff7f1a75c <+76>: ret
End of assembler dump.
(gdb) i r x2
x2 0x1ffffeff14c18 562949684022296
As you can see address stored in x2 is odd. It seems that is due to how x0 was
computed:
(gdb) x/2xg 0xfffff7f2b000+32
0xfffff7f2b020: 0x0000fffff7fed028 0x0000fffff7f1a558
(gdb) disassemble 0x0000fffff7fed028
Dump of assembler code for function _dl_tlsdesc_return:
0x0000fffff7fed028 <+0>: ldr x0, [x0, #8]
0x0000fffff7fed02c <+4>: ret
End of assembler dump.
since _dl_tlsdesc_return() takes tlsdesc I started looking how that was filled.
In this
particular case it comes from _dl_do_lazy_reloc():
v0
value=0x0 size=0x4 info=0x16 other=0x0
shndx=0xe
0x407 offset=0x11020 addend=0x0
patched_lazy: 0x0 ==> 0xffffa8dc7028 @ 0xffffa8d05020
yet value stored in arg member of tlsdesc is bogus due to
case R_AARCH64_TLSDESC:
{
struct tlsdesc volatile *td =
(struct tlsdesc volatile *)reloc_addr;
td->arg = (void*)rpnt;
td->entry = _dl_tlsdesc_return;
}
break;
i.e. it holds address of Elf64_Rela object. In contrast glibc holds relatively
small number
(0xed or so).
Next I started wondering how to fix that and hit [1] - it seems that uClibc
also affected,
yet next I hit [2] and now I dunno if it worth fixing... It looks like the
proper fix would
be disable lazy tlsdesc, but I'm not familiar enough with the code to do it on
my own.
[1] https://sourceware.org/legacy-ml/libc-alpha/2015-04/msg00266.html
[2] https://sourceware.org/legacy-ml/libc-alpha/2017-10/msg01117.html
Cheers
Vladimir
_______________________________________________
devel mailing list
[email protected]
https://mailman.uclibc-ng.org/cgi-bin/mailman/listinfo/devel
