Re: sparc TPOFF handling in GOLD

[Ian Lance Taylor <iant at google dot com>]

David Miller <davem@davemloft.net> writes:

> From: David Miller <davem@davemloft.net>
> Date: Tue, 09 Feb 2010 23:37:01 -0800 (PST)
>
>> Maybe I'm missing something obvious here that can be used to make this
>> work?  Perhaps I need to use a target specific relocation?
>
> Ian, in thinking about this more, I think there is a reasonable
> need for being able to emit relocations that:
>
> 1) Behave like ->add_*_relative() wrt. setting the symbol index
>    and computing the RELA addend.
>
> 2) But does not influence reloc sorting or the incrementing
>    of RELACOUNT.
>
> This could be simply implemented using two boolean states
> instead of one in Output_reloc, then adding a variant of
> the ->add_*_relative() methods which takes an extra boolean
> to indicate "this is a relative reloc but not R_${TGT}_RELATIVE"

I'm curious about the symbol index: is a SPARC TPOFFnn reloc really
supposed to always have a zero symbol index?  That doesn't seem to be
what bfd/elfxx-sparc.c does for this case.

A RELATIVE reloc is special in a few ways, but they boil down to the
fact that the relocation computation performed by the dynamic linker
does not involve the symbol in any way.

> Another approach could be to make the elfcpp::R_${TGT}_RELATIVE
> value available in the target info, and compare that, but I
> think that's ugly.

I agree.

> I considered using a target specific relocation for this, but it's
> such a waste to have to store away the necessary information that the
> Output_reloc::write() method already has readily available.

I haven't yet looked into how x86_64 works, but it seems to me that
the problem kind of boils down the fact that there is no way to
control the addend when using add_local_with_rela.  Does that sound
right to you?

Looking at elfxx-sparc.c, for a global symbol the relocation does not
have any addend.  Does your current gold have a problem with global
symbols, or only with local symbols?

Ian