Re: Another MIPS multigot patch

[Richard Sandiford <rsandifo at redhat dot com>]

Daniel Jacobowitz <drow@mvista.com> writes:
> Considering that the relatively recent _bfd_elf_symbol_refs_local_p is
> not used from the MIPS code, I would have been amazed if it agreed on
> all counts.  Indeed it does not.  I did this:
>
> +      /* If this symbol got a global GOT entry, we might have to decay
> +        GOT_PAGE/GOT_OFST to GOT_DISP/addend.  We check whether we need
> +        to decay, because if we don't need to it's possible that no GOT
> +        entry was allocated in this input BFD's GOT for this reference
> +        (it might be in some other GOT, and out of range).  */
> +      if (h && (h->root.dynindx
> +               < mips_elf_get_global_gotsym_index (elf_hash_table (info)
> +                                                   ->dynobj)))
> +       BFD_ASSERT (_bfd_elf_symbol_refs_local_p (h, info, 1));
> +      local_p = local_p || _bfd_elf_symbol_refs_local_p (h, info, 1);
>
> and built world; the assertion failed a number of times.

Interesting.  I'll see if I can reproduce.

> I would prefer to investigate this problem separately from the original
> patch, which was needed for large applications to link on n64.  But if
> you prefer then we can keep digging - I don't have time to figure out
> what the problem with _xexit_cleanup is right now.  I have long
> suspected that MIPS's crazy unique GOT handling did not honor the
> symbol pre-emption rules properly.

Well, I'm not a maintainer of course, but I'd prefer it we keep them
together.  If we bolt a short-term fix onto the local_p condition, while
leaving stuff that _ought_ to be dead, then that's just going to increase
confusion in the long run.  It's the last thing this particular bit of
code needs...

Richard