Re: binutils 2.19.92 linker broke with --as-needed flag

[David Daney <ddaney dot cavm at gmail dot com>]

On 03/28/2013 04:21 PM, Vincent Wen wrote:
> Eric,
>
> Thanks a lot for clarification!
>
> Alan,
>
> So I am testing the following patch per our discussion. Please let me
> know if anything missing.

It may be worth having Richard Sandiford look at this.  He has been 
doing most of the MIPS patch reviews of late...


David Daney


> Thanks,
>
> Vincent
>
> --- a/bfd/elfxx-mips.c    2013-02-10 16:50:56.000000000 -0800
> +++ b/bfd/elfxx-mips.c    2013-02-10 17:14:06.000000000 -0800
> @@ -4681,12 +4681,9 @@
>     h->non_elf = 0;
>     h->def_regular = 1;
>     h->type = STT_OBJECT;
> +  h->other = STV_HIDDEN;
>     elf_hash_table (info)->hgot = h;
>
> -  if (info->shared
> -      && ! bfd_elf_link_record_dynamic_symbol (info, h))
> -    return FALSE;
> -
>     amt = sizeof (struct mips_got_info);
>     g = bfd_alloc (abfd, amt);
>     if (g == NULL)
>
> On Thu, Mar 28, 2013 at 3:02 PM, Eric Christopher <echristo@gmail.com> wrote:
> > On Wed, Mar 27, 2013 at 7:36 PM, Alan Modra <amodra@gmail.com> wrote:
> > > On Wed, Mar 27, 2013 at 06:54:39PM -0700, Vincent Wen wrote:
> > > > Alan,
> > > >
> > > > Who is the MIPS maintainer?
> > >
> > > Theoretically Eric Christopher, but binutils/MAINTAINERS lists an
> > > old email address and it's been a while since we've seen him around
> > > here.  Eric, can you comment on the code below?
> >
> > Yeah, it's been a while. Sorry about that. I'll update everything at some point
> > though I'm no longer doing anything with MIPS (or mn10300) so while I can
> > pitch in on occasion I could also move myself to write-after-approval
> > if you'd like.
> >
> > > > On Wed, Mar 27, 2013 at 5:02 PM, Alan Modra <amodra@gmail.com> wrote:
> > > > > On Wed, Mar 27, 2013 at 10:24:51AM -0700, Vincent Wen wrote:
> > > > > > Alan,
> > > > > >
> > > > > > I'd like to know whether the patch for this issue is accepted or not?
> > > > >
> > > > > That really is up to one of the MIPS maintainers.  As I said in
> > > > > http://sourceware.org/ml/binutils/2013-02/msg00159.html the MIPS backend
> > > > > wants _GLOBAL_OFFSET_TABLE_ dynamic for some reason.
> > > > >
> > > > >    bh = NULL;
> > > > >    if (! (_bfd_generic_link_add_one_symbol
> > > > >           (info, abfd, "_GLOBAL_OFFSET_TABLE_", BSF_GLOBAL, s,
> > > > >            0, NULL, FALSE, get_elf_backend_data (abfd)->collect, &bh)))
> > > > >      return FALSE;
> > > > >
> > > > >    h = (struct elf_link_hash_entry *) bh;
> > > > >    h->non_elf = 0;
> > > > >    h->def_regular = 1;
> > > > >    h->type = STT_OBJECT;
> > > > >    elf_hash_table (info)->hgot = h;
> > > > >
> > > > >    if (info->shared
> > > > >        && ! bfd_elf_link_record_dynamic_symbol (info, h))
> > > > >      return FALSE;
> > > > >
> > > > > I think that is just plain wrong, but I don't know the history of this
> > > > > code.
> >
> > It's been that way since the original revision and that's a long long time
> > ago. :) I think I noticed it at one point and thought it odd, but I'm not sure
> > what it was actually for... some oddity on SGI machines that depended
> > upon a dynamic _GLOBAL_OFFSET_TABLE_ that only appeared if there
> > were entries? If there's anything weird the easiest assumption is "SGI
> > was weird".
> >
> > Sorry I couldn't be more help.
> >
> > -eric