[PATCH] D53906: [ELF] Allow configuring the TLS layout for an Android executable

[Ryan Prichard via Phabricator via llvm-commits]

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