Re: Fix MIPS multi-GOT -Bsymbolic link failure

[Richard Sandiford <rdsandiford at googlemail dot com>]

Daniel Jacobowitz <dan@codesourcery.com> writes:
> On Thu, Aug 26, 2010 at 10:58:20PM +0100, Richard Sandiford wrote:
>> > _bfd_mips_elf_finish_dynamic_symbol iterates over global GOT entries,
>> > and ends up calling mips_elf_create_dynamic_relocation with a NULL sec
>> > value, while the code in mips_elf_create_dynamic_relocation checks
>> > SYMBOL_REFERENCES_LOCAL and on that basis reaches code requiring a
>> > non-NULL sec.  In turn the link fails with "final link failed: Bad
>> > value".  This patch arranges for NULL sec to go through the global
>> > rather than the local case.
>> 
>> I'm not sure this will correctly preserve the -Bsymbolic semantics.
>> We really don't want the relocation to be against a global symbol,
>> since the ABI requires any global symbols involved in relocations
>> to have a global GOT entry, which in turn means we'll end up using
>> the usual -Bdynamic value of the symbol.
>
> That should work out fine.  Yes, we'll get a global symbol in the
> relocation - but the library will have DT_SYMBOLIC or DF_SYMBOLIC set,
> and so the library's view of the symbol will resolve locally.

Er, yes indeed. :-(  What was I thinking?

With lapses like that, perhaps I shouldn't be reviewing this thing at all,
but it seems odd that we should generate global relocations for secondary
GOT entries but local relocations for every other (non-GOT) reference.
Passing the correct section from _bfd_mips_elf_finish_dynamic_symbol
might be better, although a little more work.

I now agree that the patch is correct though.  If you're happy with
it too, let's put it in.

I might experiment with adding the equivalent of:

      BFD_ASSERT (htab->got_info->global_gotsym != NULL
		  && h->root.dynindx >= htab->got_info->global_gotsym->dynindx);

after:

  if (h != NULL && (sec == NULL || ! SYMBOL_REFERENCES_LOCAL (info, &h->root)))
    {

which would give me a bit more confidence that we don't try to create
invalid relocs by mistake in future.  (I might also experiment with
generating local GOT entries in this case, as mentioned before.)

Richard