Re: TLS issue on aarch64

[Phillip Berndt <phillip.berndt@googlemail.com>]

Regarding the interaction with dynamic TLS:

I can't get dynamically linked programs to work at all with musl 1.1.19.
The third stage of the dynamic linker initializes the thread pointer
with the built-in TLS before doing anything else. But again, the pointer
doesn't end up where it's supposed to:

(gdb) p &builtin_tls.pt
$2 = (struct __pthread *) 0x5555642828 <builtin_tls+8>

(gdb) p __pthread_self()
$5 = (struct __pthread *) 0x5555642810 <buf+16>

Since this is the wrong address, the pthread structure isn't actually
zero-initialized, which for me means that the cancel state is non-zero,
which means that the linker exits at the first syscall (because
__syscall_cp_c() does that for canceled pthreads).

I've got a musl 1.1.18 dynamic linker flying around that at least doesn't
fail to start programs. Your discussion of dynamically linked objects got me
interested, so I wanted to see what happens if I run a program using TLS in
the main program, TLS from a statically linked library, TLS from a
dynamically linked library, and TLS from a shared library opened by
dlopen(), all at the same time. Here's what happens:

[           main] 0x0x415ff0: 0
[      SO_dlopen] 0x0x415ff0: 0
[      SO_linked] 0x0x415ff0: 0
[         static] 0x0x416ff0: 0

..note that all four variables have differently named symbols, they should
not end up at the same location. All should be page-aligned and have
non-zero values.

From what I can see, Szabolcs's patch still does the right thing for
statically linked applications. Those can't use dlopen() anyway.

Would it hence be an option to proceed with his patch, and fix dynamically
linked programs in the next step?

- Phillip