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

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,


-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20191227/7baa9cd2/attachment.html>

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.

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>