Re: TLS relocations in PPC

[Alan Modra <amodra at bigpond dot net dot au>]

On Fri, Nov 13, 2009 at 10:16:56AM -0500, Michael Mrozek wrote:
> > > 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.

Yes, leaving the field as zero would work fine.  I wrote a patch some
time ago to do exactly that, but it caused some tests in the prelinker
testsuite related to prelink's undo option to fail.

> > > 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:
[snip]

You have found a bug in gas.  @tls is not valid with addi, but we
don't issue an error.

-- 
Alan Modra
Australia Development Lab, IBM