ld fix for STB_GNU_UNIQUE PR10549

[Mark Wielaard]

> 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)?

Thanks,

Mark