Date: Thu, 31 May 2018 17:22:57 +0200 From: Phillip Berndt <phillip.berndt@...glemail.com> To: musl@...ts.openwall.com Subject: Re: TLS issue on aarch64 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
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.