On 17/05/2019 14:51, Tom Horsley wrote: > I'm trying (for reason too complex to go into) to > locate the TLS offset of the tcache_shutting_down > variable from malloc in the ubuntu provided > glibc on aarch64 ubuntu 18.04. > > Various "normal" TLS variables appear to operate > much like x86_64 with a GOT table entry where the > TLS offset of the variable gets stashed.
this is more of a glibc question than a gcc one (i.e. libc-help list would be better). tls in glibc uses the initial-exec tls access model, (tls object is at a fixed offset from tp across threads), that requires a GOT entry for the offset which is set up via a R_*_TPREL dynamic reloc at startup time. (note: if a symbol is internal to the module its TPREL reloc is not tied to a symbol, it only has an addend for the offset within the module) > But in the ubuntu glibc there is no GOT entry for > that variable, and disassembly of the code shows > that it seems to "just know" the offset to use. i see adrp+ldr sequences that access GOT entries. e.g. in the objdump of libc.so.6: 00000000000771d0 <__libc_malloc@@GLIBC_2.17>: ... 77400: f00006c0 adrp x0, 152000 <sys_sigabbrev@@GLIBC_2.17+0x278> 77404: f9470c00 ldr x0, [x0, #3608] 77408: d53bd041 mrs x1, tpidr_el0 you can verify that 0x152000 + 3608 == 0x152e18 is indeed a GOT entry (falls into .got) and there is a 0000000000152e18 R_AARCH64_TLS_TPREL64 *ABS*+0x0000000000000010 dynamic relocation for that entry as expected. (but i don't know which symbol this entry is for, only that the symbol must be a local tls sym) > Is there some kind of magic TLS optimization that > can happen for certain variables on aarch64? I'm trying > to understand how it could know the offset like > it appears to do in the code. there is no magic.
