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