[PATCH] D109293: [JITLink][WIP] Add initial native TLS support to ELFNix platform

Fangrui Song via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Sep 7 13:46:41 PDT 2021


MaskRay added a comment.

I am well familiar with the TLS implementations in ld.lld and musl and somewhat familiar with FreeBSD rtld and glibc ld.so.
I have been consulted by ghc on its FreeBSD support.

I appreciate if folks who want to add the LLVM JIT ELF support keep me in the loop.
I currently know nearly nothing about JIT but am happy to allocate some time to study.

In D109293#2984957 <https://reviews.llvm.org/D109293#2984957>, @MoritzS wrote:

> In D109293#2984338 <https://reviews.llvm.org/D109293#2984338>, @lhames wrote:
>
>>> To allocate the TLS descriptor in GOT, I need to get the edge kind information in PerGraphGOTAndPLTStubBuilder, So I add a Edge::Kind K argument in some functions in PerGraphGOTAndPLTStubBuilder.h. If it is not
>>> suitable, I can think further to solve this problem.
>>
>> Is there a good reason to put these in the GOT? I would create and manage a different section for these, rather than re-using the GOT.
>
> The ELF TLS spec actually describes using the GOT for that. Each TLSGD relocation is usually converted into two adjacent GOT entries with the DTPMOD64 and DTPOFF64 relocations. I think the practical reason for that is that a TLSGD relocation is 32-bit PC-relative, so using an address of the GOT will guarantee that the 32 bit offset can represent the address.

It doesn't need to be the `.got` section. It can be any section, but ld.so is the one responsible for filling DTPMOD64/DTPOFF64 values.

> In general I would suggest not trying to resolve a TLSGD/LD relocation at all but instead converting it to a GOTTPOFF relocation. Then, no runtime function to implement __tls_get_addr is needed. You can find the detailed description of how to do this in Section 5.5 of the ELF TLS spec (https://akkadia.org/drepper/tls.pdf).
>
> I implemented this for RuntimeDyld (D105466 <https://reviews.llvm.org/D105466>) so you can take a look there. Let me know where I can help!

While the psABI documents of x86-32/x86-64/ppc32/ppc64 have defined TLS optimizations, many (arm/aarch64/riscv/...) don't.
So converting to GOTPTOFF is not always feasible.

> 2. Allow all TLS relocations. Since we can't add new TLS storage at runtime, define a global thread-local variable which will then be used by the linker to resolve GOTTPOFF/TPOFF relocations.

I agree that reserving static TLS blocks is the most plausible approach (before looking at an implementation).


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D109293/new/

https://reviews.llvm.org/D109293



More information about the llvm-commits mailing list