[llvm-dev] [LLD][ELF] Symbol/Relocation manipulation.
Sid Manning via llvm-dev
llvm-dev at lists.llvm.org
Mon Dec 30 11:40:52 PST 2019
Thanks for the info. I had made a change to llvm to emit the call to __tls_get_addr but wanted to see if lld could accommodate the current baseline. I will revisit the llvm change.
From: Fangrui Song <maskray at google.com>
Sent: Friday, December 27, 2019 11:48 AM
To: Sid Manning <sidneym at quicinc.com>
Cc: ruiu at google.com <ruiu at google.com>; llvm-dev <llvm-dev at lists.llvm.org>
Subject: [EXT] Re: [LLD][ELF] Symbol/Relocation manipulation.
On 2019-12-27, Sid Manning wrote:
>I'd like to convert the following
>call A at GDPLT //R_HEX_GD_PLT_B22_PCREL
>call __tls_get_addr //R_HEX_B22_PCREL
>"A" is a TLS variable and preceding code has prepared for the call.
>When the R_HEX_GD_PLT_B22_PCREL is found it will initially point to the TLS
>variable so at that point I'd like to define a __tls_get_addr symbol and update
>the relocation's type and symbol to point to it.
>Is there an existing mechanism to do this? It would happen during relaxation I
For newer psABI, it is recommended implementing TLSDESC directly. It is
strictly superior to the traditional General Dynamic and Local Dynamic
TLS models. This applies to RISC-V
https://github.com/riscv/riscv-elf-psabi-doc/issues/94 as well, which
seems to copy from ARM or MIPS.
If you have to implement the traditional General Dynamic and Local Dynamic TLS models (__tls_get_addr):
call A at GDPLT //R_HEX_GD_PLT_B22_PCREL
call __tls_get_addr //R_HEX_B22_PCREL
IMO the generated assembly should mention __tls_get_addr directly, i.e.
the assembler should create an undefined symbol __tls_get_addr and
create call-typed relocations which reference it.
The linker should not be responsible for synthesizing a symbol called
__tls_get_addr. No existing architecture (AFAIK) does this.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev