TLS relocations in PPC

[Michael Mrozek]

The two docs you linked to are great, thanks.

> > I'm not sure if this is the right place to ask. I'm trying
> > For example, if I assemble "li 0, foo@l+8", it encodes as
> > 0x38000008 with an R_PPC_ADDR16_LO reloc on foo with an
> > addend of 8. I don't really understand why it encodes the 8
> > in the instruction if PPC uses RELA relocations and it's
> > just going to be overwritten later (i.e. 0x38000000 should
> > work the same I would think), but I've been ignoring that.
> > However, "li 0, foo@tls+8" encodes as 0x38000002. Where did
> > the 2 come from? It seems to encode the @tls field as a 2 no
> > matter what, which makes me think maybe the encoding of the
> > field is important even if it's going to be rewritten by a
> > relocation later. Does it mean anything, or is it just a
> > side-effect of some other processing?
> 
> I think the "2" is in a register field, not part of the immediate
> operand field. Register r2 is the thread pointer, so the instruction
> is actually loading an offset relative to the contents of tp. The
> resulting effective address will be the address of the thread-local
> variable.

It shouldn't be; addi's structure is:

|    15   |    D    |    A    |             SIMM              | 
 0       5 6      10 11     15 16                           31

li rD, value -> addi rD, 0, value; so the last bytes where the 02 shows up are the end of the SIMM (value) field. More importantly, maybe I don't understand RELA relocs, so somebody tell me I'm stupid if I'm getting this wrong. I thought REL relocs stored their offset in the field itself, and RELA stored it in an addend and ignored the field. PPCs are RELA, so the value in the field shouldn't matter. I've even tried hacking object files and zeroing bytes that I think should be overwritten by a relocation, and it doesn't seem to change the run of the binary at all, except for these 2s caused by @tls (making one a 0 broke gcc with an internal error in ppc_elf_relocate_section).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20091113/3f82ce4a/attachment.sig>