DTPREL relocations in input files

["Joseph S. Myers" <joseph@xxxxxxxxxxxxxxxx>]

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?

-- 
Joseph S. Myers
joseph@xxxxxxxxxxxxxxxx