https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102772
--- Comment #21 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot
Uni-Bielefeld.DE> ---
> --- Comment #19 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> If it is the linker, you can always objdump -dr the binary to see what is in
> there after linking. s@ntpoff in my understanding is a relocation that should
> supply at link time the offset from the TLS base and at least on the GCC side
> it can appear anywhere where 32-bit immediate appears in an instruction (or in
> data section too), not necessarily in addl imm, %eax instruction.
The linker isn't a factor here: both ld and gld 2.38 produce the same
result:
08048890 <_Z3foov>:
8048890: 65 a1 00 00 00 00 mov %gs:0x0,%eax
8048896: 05 d0 ff ff ff add $0xffffffd0,%eax
804889b: c3 ret
> Perhaps also try to have 2 different functions, one with
> movl %gs:0, %eax
> addl $s@ntpoff, %eax
> ret
> and another with
> pushl %ebx
> movl %gs:0, %ebx
> addl $s@ntpoff, %ebx
> popl %ebx
> ret
> and see what they do at runtime (if they both print the same address in each
> thread or not).
They don't at all: I've also added in the thread id. I get
foo foob
$ ./ta48-ebx
id = 3 fdf80a90 8066638
[...]
id = 1 fe682a90 0
id = 46 fbf66290 8067b0c
[...]
id = 41 fbf63a90 80678a0
All other threads are similarly off: not 16-byte aligned and completely
different from the %eax results.
To verify, I've run the test under dbx (gdb currently lacks TLS support
on Solaris) and print &s in the initial thread: the result matches the
foo value above for id = 1, which suggests they are consistent.
