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

[Moritz Sichert via Phabricator via llvm-commits]

MoritzS added a comment.

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

> In D109293#2985202 <https://reviews.llvm.org/D109293#2985202>, @lhames wrote:
>
>> In D109293#2984957 <https://reviews.llvm.org/D109293#2984957>, @MoritzS wrote:
>>
>>> 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.
>>
>> Is that compatible with adding extra code at runtime? I suspect we'll need to go the other way: convert things to function calls by default, but make it possible to use direct models where they're safe. That's speculation having not read the TLS spec though.
>
> That depends on how the allocation of TLS sections is implemented, but in general you are right, I didn't think about that.
>
> The problem I faced when implementing the TLS relocations is that we can't chose which types of TLS relocations the object files we try to link use. This means that we need to implement the GOTTPOFF/TPOFF relocations that do not go through the indirection of __tls_get_addr. They just resolve to an offset that will be added to the value stored in %fs:0. This is usually set initially by ld.so when a process starts by using arch_prctl(ARCH_SET_FS), or for newer CPUS by using the wrfsbase instruction. This means that we can't easily extend the storage of the process that runs the runtime linker to add new TLS sections since messing with the fs register will very likely lead to unexpected results. There are several possible solutions for that with different disadvantages:
>
> 1. Don't allow GOTTPOFF/TPOFF relocations at all. This means that we will not be able to link many pre-compiled static libraries.
> 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.
> 3. Rewrite the relocated code so that it does not use the fs register. On Linux we could probably replace all references to fs by gs and then manually set the gs register? I'm not sure if this can break code if we change instructions that did not originally have a relocation.
>
> I implemented 2. in llvm-rtdyld. Since this is mainly used for testing, the size of the pre-allocated TLS section is only 16 B. In a "real" program you could easily allocate an entire page without noticing any runtime overhead. This is more than enough to link an entire static glibc, for example.

The point I wanted to make here is that if we go for 2. (or 3.), we might as well convert all TLSGD/LD relocations to TPOFF. We would implement all the logic for the TPOFF relocations anyway and if we assume that the pre-allocated TLS storage is large enough to link all object files, this will lead to less runtime overhead to access TLS variables.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109293