This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: [PATCH] .symver x, x@foo (take 2)
On Thu, Feb 13, 2003 at 11:16:50AM +0100, Jakub Jelinek wrote:
> On Thu, Feb 13, 2003 at 01:03:28PM +1030, Alan Modra wrote:
> > On Tue, Feb 11, 2003 at 09:31:08AM +0100, Jakub Jelinek wrote:
> > > + (*bed->elf_backend_hide_symbol) (info, hi, TRUE);
> > > + hi->root.type = bfd_link_hash_indirect;
> > > + hi->root.u.i.link = (struct bfd_link_hash_entry *) h;
> > > + (*bed->elf_backend_copy_indirect_symbol) (bed, h, hi);
> > > + hi->elf_link_hash_flags = 0;
> >
> > Why clear elf_link_hash_flags?
>
> Will recheck on all arches if this is still necessary, libvers24a.so built
> fine without it on IA-32.
Ok, succeeded on i386/alpha/ia64/ppc/s390/s390x/x86_64. That part can be
taken out.
> > > + sym_hash = elf_sym_hashes (abfd);
> > > + if (sym_hash)
> > > + for (symidx = 0; symidx < extsymcount; ++symidx)
> > > + if (sym_hash[symidx] == hi)
> > > + {
> > > + sym_hash[symidx] = h;
> > > + break;
> > > + }
> >
> > I can't say I like this either. Is it really necessary to tweak sym
> > hashes? Won't later uses of the sym hash follow indirect links anyway?
>
> This is necessary for libvers24c.so (ie. if .symver x, x@foo and relocations
> against x happen to be in the same input file (whether same assembly or ld
> -r).
> Normally, elf_link_add_object_symbols already follows indirect links
> when assigning to sym_hashes[x], so none of the check_relocs etc. routines
> bother to check that.
Jakub