This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: ld fix for STB_GNU_UNIQUE PR10549
- From: Mark Wielaard <mjw at redhat dot com>
- To: Alan Modra <amodra at gmail dot com>
- Cc: binutils at sourceware dot org, Nick Clifton <nickc at redhat dot com>, Ulrich Drepper <drepper at gmail dot com>
- Date: Sat, 9 Apr 2011 17:24:41 -0400 (EDT)
- Subject: Re: ld fix for STB_GNU_UNIQUE PR10549
> 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