On Sun, Nov 05, 2017 at 01:02:36PM -0800, Philip Guenther wrote: > Well, ld.so and libc _should_ currently support startup-time TLS using the > initial-exec and local-exec modules.
I can't see support for R_x_TPOFF64 relocations in ld.so(1) so I don't think initial-exec will work. But local-exec doesn't require any relocations by the dynamic linker so that should work. > The diff below fixes that, at least on amd64, by checking whether no > AUX_phdr value was found and, if so, trying to instead find them via the > ELF header referenced via the linker-provided __executable_start symbol. The patch fixed the segfaults I was seeing. However, initialized TLS data doesn't work in static executables: it appears as zero. $ cat test.s .globl foo .section .tdata,"awT",@nobits .align 4 .size foo, 4 foo: .int 42 .text .globl get_foo .type get_foo, @function get_foo: movl %fs:foo@tpoff, %eax ret $ cc -o test.o -c test.s $ cc -o test test.o main.c $ ./test 42 $ cc -static -o test test.o main.c $ ./test 0 PIE/no-PIE doesn't seem to make any difference to this. I don't actually need initialized TLS data for my use, which is statically linking Go binaries, so you've fixed my problem: thank you! I've run the complete Go test-suite with your patch applied and everything that I'd expect to pass does pass. This is on AMD64 only; I don't have access to any other architecture for testing. -- Charles