Re: [mips-tls] DTPREL relocations in input files

[Nigel Stephens <nigel@xxxxxxxx>]

Joseph S. Myers wrote:
> The MIPS TLS specification has R_MIPS_TLS_DTPREL32 and R_MIPS_TLS_DTPREL64 
> as relocations generated by the static linker and resolved by the dynamic 
> linker.  (For those of you reading the document at 
> <http://www.linux-mips.org/wiki/NPTL>, what appear there as 
> R_MIPS_TLS_DTPOFF32 and R_MIPS_TLS_DTPOFF64 got renamed as part of merging 
> the changes into FSF binutils, and the document hasn't been updated since 
> then; see notes on changes at 
> <http://gcc.gnu.org/ml/gcc-patches/2005-03/msg00959.html>.)
>
> While there are DTP-relative relocations R_MIPS_TLS_DTPREL_HI16 and 
> R_MIPS_TLS_DTPREL_LO16, used together to generate an offset for a 
> thread-local variable, there is no single relocation representing the 
> offset.  This causes problems generating debug information for such a 
> variable; instead of
>
>   DW_OP_addr %dtprel(variable)
>   DW_OP_GNU_push_tls_address
>
> much more complicated code is needed to describe the offset
>
>   DW_OP_addr %dtprel_hi(variable)
>   DW_OP_addr %dtprel_lo(variable)
>   DW_OP_const1u 16
>   DW_OP_shl
>   DW_OP_const1u 16
>   DW_OP_shra
>   DW_OP_swap
>   DW_OP_const1u 16
>   DW_OP_shl
>   DW_OP_plus
>   DW_OP_GNU_push_tls_address
>
> (for 32-bit, similar for 64-bit) - this does work and allow the debugger 
> to use the variables, but is not very efficient.  It seems reasonable to 
> allow R_MIPS_TLS_DTPREL32 and R_MIPS_TLS_DTPREL64 as static relocations in 
> linker input files as well as dynamic relocations for the dynamic linker: 
> when found in input files, the linker would resolve them in the obvious 
> way to the offset for the TLS variable in the TLS area for the current 
> module.  (The debug information is only generated for the object where the 
> TLS variable is defined, so this is effectively the LD model and acts like 
> a combinarion of the _HI16 and _LO16 relocations used for that model.)  
> Does anyone see problems with using these relocations this way, or think 
> we should allocate two new relocations for this purpose instead?
>   

Seems reasonable to reuse R_MIPS_TLS_DTPREL32 and R_MIPS_TLS_DTPREL64,
since AFAICS those relocs are currently generated only by the linker and
otherwise shouldn't be seen in a linker input file. What do other
architectures do here?


Nigel