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
