sparc TPOFF handling in GOLD

sparc TPOFF handling in GOLD

[David Miller]

Ian, I figured out why I was using the relative reloc
emitters for relocations other than R_SPARC_RELATIVE.

It seems to be for an issue with TPOFF{32,64} handling.

For example, when we have an IE TLS relocation for a local symbol, the
TPOFF{32,64} relocation pointing to the GOT entry needs to have an
addend with value:

	value - tls_segment()->vaddr();

This is needed because the dynamic linker sets the relocation using:

	*reloc_addr = sym->st_value - sym_map->l_tls_offset
		+ reloc->r_addend;

Compare to i386 which, lacking addends, goes:

	*reloc_addr += map->l_tls_offset - sym->st_value;

x86_64 uses addends and seems to compute the TPOFF64 relocation
similar to sparc, so I wonder how it is working there?

Anyways, way back when writing the Sparc GOLD backend I couldn't
figure out any way to get that TPOFF{32,64} addend set correctly other
than to use the relative reloc trick since that triggers the logic in
Output_reloc::write() which goes:

  addend = this->rel_.symbol_value(addend);

But now that we emit DT_RELACOUNT in the dynamic section, this trick
no longer works.

Maybe I'm missing something obvious here that can be used to make this
work?  Perhaps I need to use a target specific relocation?

Thanks!

Re: sparc TPOFF handling in GOLD

[David Miller]

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"

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 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.

What do you think?

Re: sparc TPOFF handling in GOLD

[Ian Lance Taylor]

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

Re: sparc TPOFF handling in GOLD

[David Miller]

From: Ian Lance Taylor <iant@google.com>
Date: Wed, 10 Feb 2010 12:54:00 -0800

> 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?

Only for local symbols.

> That doesn't seem to be
> what bfd/elfxx-sparc.c does for this case.

Yes it does:

	      indx = h && h->dynindx != -1 ? h->dynindx : 0;
	      if (r_type == R_SPARC_TLS_IE_HI22
		  || r_type == R_SPARC_TLS_IE_LO10)
		dr_type = SPARC_ELF_TPOFF_RELOC (htab);
	      else
		dr_type = SPARC_ELF_DTPMOD_RELOC (htab);

> 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?

Yep, that sounds about right.

> 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?

Currently, I'm pretty sure the IE TLS relocs only get imporperly
computed for local symbols.

But look at that GOLD sparc ->add_*_relative() patch I put in
yesterday.  All of those cases needed this behavior, although
I think the section cases is OK.

Re: sparc TPOFF handling in GOLD

[David Miller]

From: David Miller <davem@davemloft.net>
Date: Wed, 10 Feb 2010 13:00:28 -0800 (PST)

> From: Ian Lance Taylor <iant@google.com>
> Date: Wed, 10 Feb 2010 12:54:00 -0800
> 
>> 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?
> 
> Yep, that sounds about right.

Actually, I stand corrected.  It's the lack of ability to control the
addend _and_ the symbol index.

For local symbol IE relocations we definitely want the TPOFF{32,64} to
be output with a zero symbol index and relative addend calculations.

As we've been discussing, there is currently no easy way to do this
from a GOLD target.

Re: sparc TPOFF handling in GOLD

[Ian Lance Taylor]

David Miller <davem@davemloft.net> writes:

> From: David Miller <davem@davemloft.net>
> Date: Wed, 10 Feb 2010 13:00:28 -0800 (PST)
>
>> From: Ian Lance Taylor <iant@google.com>
>> Date: Wed, 10 Feb 2010 12:54:00 -0800
>> 
>>> 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?
>> 
>> Yep, that sounds about right.
>
> Actually, I stand corrected.  It's the lack of ability to control the
> addend _and_ the symbol index.
>
> For local symbol IE relocations we definitely want the TPOFF{32,64} to
> be output with a zero symbol index and relative addend calculations.
>
> As we've been discussing, there is currently no easy way to do this
> from a GOLD target.

That sounds basically right to me.  Probably we should split
is_relative_ into two fields: one which says that the reloc should use
a symbol index of 0 and the symbol value as the addend, and one which
says that the reloc should be sorted and counted as a RELATIVE reloc.
Then most of the Output_reloc constructors get a new parameter.  Hmmm.

Then I guess that rather than using the
Output_data_got::add_local_with_rela helper function, that code will
have to be done manually in sparc.cc.  That is, assign the GOT offset
and create the reloc, as in, e.g., x86_64.cc handling of
R_X86_64_GOTPC32_TLSDESC for a local symbol.

Ian

Re: sparc TPOFF handling in GOLD

[David Miller]

From: Ian Lance Taylor <iant@google.com>
Date: Wed, 10 Feb 2010 13:34:17 -0800

> That sounds basically right to me.  Probably we should split
> is_relative_ into two fields: one which says that the reloc should use
> a symbol index of 0 and the symbol value as the addend, and one which
> says that the reloc should be sorted and counted as a RELATIVE reloc.
> Then most of the Output_reloc constructors get a new parameter.  Hmmm.

Yeah, I have a patch half-written which does this.

> Then I guess that rather than using the
> Output_data_got::add_local_with_rela helper function, that code will
> have to be done manually in sparc.cc.  That is, assign the GOT offset
> and create the reloc, as in, e.g., x86_64.cc handling of
> R_X86_64_GOTPC32_TLSDESC for a local symbol.

Right.  That's what the sparc.cc code was doing before when
it was mis-using the ->add_*_relative() with non-R_SPARC_RELATIVE
relocations.