From joseph at codesourcery.com Wed Jun 6 21:17:24 2007 From: joseph at codesourcery.com (Joseph S. Myers) Date: Wed, 6 Jun 2007 21:17:24 +0000 (UTC) Subject: DTPREL relocations in input files Message-ID: 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 , 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 .) 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 at codesourcery.com From nigel at mips.com Thu Jun 7 15:40:32 2007 From: nigel at mips.com (Nigel Stephens) Date: Thu, 07 Jun 2007 16:40:32 +0100 Subject: [mips-tls] DTPREL relocations in input files In-Reply-To: References: Message-ID: <466826F0.6020706@mips.com> 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 > , 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 > .) > > 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 From dan at codesourcery.com Thu Jun 7 18:03:49 2007 From: dan at codesourcery.com (Daniel Jacobowitz) Date: Thu, 7 Jun 2007 14:03:49 -0400 Subject: [mips-tls] DTPREL relocations in input files In-Reply-To: <466826F0.6020706@mips.com> References: <466826F0.6020706@mips.com> Message-ID: <20070607180348.GV8705@caradoc.them.org> On Thu, Jun 07, 2007 at 04:40:32PM +0100, Nigel Stephens wrote: > 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? For ARM, we're going to use R_ARM_TLS_LDO32 in the object file. This is only ever present in objects and used for the local dynamic model; it's equivalent to the combined R_MIPS_DTPREL_LO16 and R_MIPS_DTPREL_HI16. The dynamic relocation used for local dynamic is R_ARM_TLS_DTPOFF32, equivalent to R_MIPS_TLS_DTPREL32. Most architectures seem to have separate relocations, but I don't know why. -- Daniel Jacobowitz CodeSourcery