* ld: linking to GNU_UNIQUE symbol does not set ELFOSABI_GNU
@ 2013-01-24 11:31 Florian Weimer
2013-01-24 13:29 ` Alan Modra
0 siblings, 1 reply; 5+ messages in thread
From: Florian Weimer @ 2013-01-24 11:31 UTC (permalink / raw)
To: binutils
This code in bfd/elf64-x86-64.c seems to be wrong:
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;
The DYNAMIC requirement should only apply to the STT_GNU_IFUNC case.
For STB_GNU_UNIQUE, the binding type is propagated to the resulting
object (at least for DSOs).
I think this might be the appropriate fix:
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;
But the has_gnu_symbols flag should probably be set in a different
location because this code is replicated in many places.
--
Florian Weimer / Red Hat Product Security Team
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: ld: linking to GNU_UNIQUE symbol does not set ELFOSABI_GNU
2013-01-24 11:31 ld: linking to GNU_UNIQUE symbol does not set ELFOSABI_GNU Florian Weimer
@ 2013-01-24 13:29 ` Alan Modra
2013-01-25 15:02 ` Florian Weimer
0 siblings, 1 reply; 5+ messages in thread
From: Alan Modra @ 2013-01-24 13:29 UTC (permalink / raw)
To: Florian Weimer; +Cc: binutils
On Thu, Jan 24, 2013 at 12:31:37PM +0100, Florian Weimer wrote:
> I think this might be the appropriate fix:
>
> 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 would mark a binary that merely linked against a shared library
having gnu_unique symbols. The binary would not even have to
reference such symbols.
I'm not sure your premise is correct anyway. STB_GNU_UNIQUE seems to
be relevant to the definition of a symbol, not a reference. Which
leads me to think that ld probably should not give undefined symbols
an STB_GNU_UNIQUE binding.
--
Alan Modra
Australia Development Lab, IBM
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: ld: linking to GNU_UNIQUE symbol does not set ELFOSABI_GNU
2013-01-24 13:29 ` Alan Modra
@ 2013-01-25 15:02 ` Florian Weimer
2013-01-25 15:50 ` H.J. Lu
0 siblings, 1 reply; 5+ messages in thread
From: Florian Weimer @ 2013-01-25 15:02 UTC (permalink / raw)
To: binutils
On 01/24/2013 02:28 PM, Alan Modra wrote:
> On Thu, Jan 24, 2013 at 12:31:37PM +0100, Florian Weimer wrote:
>> I think this might be the appropriate fix:
>>
>> 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 would mark a binary that merely linked against a shared library
> having gnu_unique symbols. The binary would not even have to
> reference such symbols.
Oh, that would be wrong indeed.
> I'm not sure your premise is correct anyway. STB_GNU_UNIQUE seems to
> be relevant to the definition of a symbol, not a reference. Which
> leads me to think that ld probably should not give undefined symbols
> an STB_GNU_UNIQUE binding.
Sorry, I have no idea how to implement that. Should I file a bug so
that this issue isn't lost?
--
Florian Weimer / Red Hat Product Security Team
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: ld: linking to GNU_UNIQUE symbol does not set ELFOSABI_GNU
2013-01-25 15:02 ` Florian Weimer
@ 2013-01-25 15:50 ` H.J. Lu
2013-02-06 18:33 ` Florian Weimer
0 siblings, 1 reply; 5+ messages in thread
From: H.J. Lu @ 2013-01-25 15:50 UTC (permalink / raw)
To: Florian Weimer; +Cc: binutils
On Fri, Jan 25, 2013 at 7:02 AM, Florian Weimer <fweimer@redhat.com> wrote:
> On 01/24/2013 02:28 PM, Alan Modra wrote:
>>
>> On Thu, Jan 24, 2013 at 12:31:37PM +0100, Florian Weimer wrote:
>>>
>>> I think this might be the appropriate fix:
>>>
>>> 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 would mark a binary that merely linked against a shared library
>> having gnu_unique symbols. The binary would not even have to
>> reference such symbols.
>
>
> Oh, that would be wrong indeed.
>
>
>> I'm not sure your premise is correct anyway. STB_GNU_UNIQUE seems to
>> be relevant to the definition of a symbol, not a reference. Which
>> leads me to think that ld probably should not give undefined symbols
>> an STB_GNU_UNIQUE binding.
>
>
> Sorry, I have no idea how to implement that. Should I file a bug so that
> this issue isn't lost?
>
>
Please open a bug with a testcase.
--
H.J.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: ld: linking to GNU_UNIQUE symbol does not set ELFOSABI_GNU
2013-01-25 15:50 ` H.J. Lu
@ 2013-02-06 18:33 ` Florian Weimer
0 siblings, 0 replies; 5+ messages in thread
From: Florian Weimer @ 2013-02-06 18:33 UTC (permalink / raw)
To: H.J. Lu; +Cc: binutils
On 01/25/2013 04:49 PM, H.J. Lu wrote:
>>> I'm not sure your premise is correct anyway. STB_GNU_UNIQUE seems to
>>> be relevant to the definition of a symbol, not a reference. Which
>>> leads me to think that ld probably should not give undefined symbols
>>> an STB_GNU_UNIQUE binding.
>>
>>
>> Sorry, I have no idea how to implement that. Should I file a bug so that
>> this issue isn't lost?
> Please open a bug with a testcase.
Done: http://sourceware.org/bugzilla/show_bug.cgi?id=15107
--
Florian Weimer / Red Hat Product Security Team
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2013-02-06 18:33 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-01-24 11:31 ld: linking to GNU_UNIQUE symbol does not set ELFOSABI_GNU Florian Weimer
2013-01-24 13:29 ` Alan Modra
2013-01-25 15:02 ` Florian Weimer
2013-01-25 15:50 ` H.J. Lu
2013-02-06 18:33 ` Florian Weimer
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).