[llvm-dev] [LLD][ELF] Symbol/Relocation manipulation.

[Sid Manning via llvm-dev]

Fangrui,

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
>
>to
>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
>guess.
>
>Thanks,

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...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191230/02a2f0cf/attachment.html>