Re: bug: GOLD handling of Sparc PLTREL

[David Miller <davem at davemloft dot net>]

From: Ian Lance Taylor <iant@google.com>
Date: Tue, 09 Feb 2010 07:04:13 -0800

> David Miller <davem@davemloft.net> writes:
> 
>> It is a problem, GLIBC has code which does the following when the
>> macro ELF_MACHINE_PLTREL_OVERLAP is defined:
> 
> Yes, but to be pedantically clear, the problem there is not that
> .rela.dyn and .rela.plt are separate.  The problem is that the DT_RELA
> dynamic tag does not include the PLT relocations.

Correct.

>>> I see a few calls to add_local_relative and add_global_relative that
>>> are not passing down elfcpp::R_SPARC_RELATIVE as the reloc type.  That
>>> is rather suspicious and seems like it could cause this sort of
>>> problem.
>>
>> It has nothing to do with these crashes.
> 
> It is a problem, though, because it will cause DT_RELACOUNT to be
> incorrect.

Ok.  I do remember there was a reason I gave non-R_SPARC_RELATIVE
relocations to that function.  I needed the calculations it
performed, even for non-R_SPARC_RELATIVE relocs.

I'll look into this, it probably explains some of the failures
I still get (about 12) after fixing the pltrel-overlap issue.

>> I'm playing around with the following patch to fix this:
> 
> Looks like a reasonable approach.  I prefer boolean variables to have
> names which read correctly with if, so perhaps dynrel_includes_plt
> instead of of pltrel_overlap.  Also no need to duplicate the entire
> union in Output_data_dynamic.
> 
> Another approach would be to in fact put the PLT into the .rela.dyn
> output section.  That could be done by just changing the call to
> layout->add_output_section_data to use .rela.dyn in both SHT_RELA
> calls in sparc.cc.

Thanks for the suggestions, I'll work on finalizing this fix
and will post a new version.