Hi Waldemar, On 2/7/20 1:51 PM, Waldemar Brodkorb wrote: 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