Re: ld fix for STB_GNU_UNIQUE PR10549

[Alan Modra <amodra at gmail dot com>]

On Sat, Apr 09, 2011 at 05:24:41PM -0400, Mark Wielaard wrote:
> > On Thu, Apr 07, 2011 at 10:01:01PM +0200, Mark Wielaard wrote:
> > > @@ -15229,9 +15229,10 @@ elf32_arm_add_symbol_hook (bfd *abfd,
> > > struct bfd_link_info *info,
> > >  			   Elf_Internal_Sym *sym, const char **namep,
> > >  			   flagword *flagsp, asection **secp, bfd_vma *valp)
> > >  {
> > > - if ((abfd->flags & DYNAMIC) == 0
> > > - && ELF_ST_TYPE (sym->st_info) == STT_GNU_IFUNC)
> > > - elf_tdata (info->output_bfd)->has_ifunc_symbols = TRUE;
> > > + if (((abfd->flags & DYNAMIC) == 0
> > > + && ELF_ST_TYPE (sym->st_info) == STT_GNU_IFUNC)
> > > + || ELF_ST_BIND (sym->st_info) == STB_GNU_UNIQUE)
> > > + elf_tdata (info->output_bfd)->has_gnu_symbols = TRUE;
> > 
> > This looks odd. Why should an STB_GNU_UNIQUE symbol in a dynamic
> > object, perhaps not even referenced, result in the current linker
> > output being marked with has_gnu_symbols?
> 
> I did that deliberately thinking that, unlike the IFUNC case,
> when a program links against something that uses UNIQUE
> semantics it will need/depend on that. Do you think it should
> only be done for symbols coming from non-dynamic objects
> (making it identical to the IFUNC case)?

Yes, because as I said, a symbol in a shared library may not even be
referenced by the executable or shared library being produced by the
linker.  The output file may not even mark the shared library as
DT_NEEDED.

Ulrich's reply didn't exactly answer my question, but does point out
another deficiency in ld.  We ought to only accept STB_GNU_UNIQUE in
object files that are ELFOSABI_LINUX.

-- 
Alan Modra
Australia Development Lab, IBM