[PATCH] D53906: [ELF] Allow configuring the TLS layout for an Android executable
Ryan Prichard via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Tue Oct 30 17:19:23 PDT 2018
rprichard added a comment.
Yeah, I also need to modify libc and the loader. The problem is that, with the TLS local-exec (LE) access model used in executables, the static linker writes a thread-pointer-relative offset into an executable's text section, which the loader can't relocate. With the next-most efficient model, initial-exec (IE), the linker stores TLS offsets in the GOT, which the loader does relocate. (Disabling LE in the compiler+linker in favor of IE is another way of resolving this ABI conflict, but IIRC, it was also problematic. e.g. We can't do LD->LE relaxation anymore.)
e.g.: Suppose I compile for Android with the stack protection enabled, and with emutls disabled: https://godbolt.org/z/Jq38rr
The function's assembly is:
mrs x8, TPIDR_EL0
ldr x9, [x8, #40]
add x10, x8, :tprel_hi12:var1
add x10, x10, :tprel_lo12_nc:var1
str x9, [sp, #8]
strb wzr, [x10, x0]
ldr x8, [x8, #40]
ldr x9, [sp, #8]
cmp x8, x9
b.ne .LBB0_2
.Ltmp1:
ldp x29, x30, [sp, #16]
add sp, sp, #32
ret
The two `[x8, #40]` accesses are reading the stack protector cookie from TLS memory, but the function is also writing to TLS memory, and on arm64, lld would normally allocate the first TLS section at TP+16. If var1 is allocated at TP+16, it will overlap with the cookie at TP+40.
Repository:
rLLD LLVM Linker
https://reviews.llvm.org/D53906
More information about the llvm-commits
mailing list