This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: PR12760 plugin vs. warning syms
On Mon, May 16, 2011 at 7:12 AM, Alan Modra <amodra@gmail.com> wrote:
> On Mon, May 16, 2011 at 05:48:42AM -0700, H.J. Lu wrote:
>> On Mon, May 16, 2011 at 1:29 AM, Alan Modra <amodra@gmail.com> wrote:
>> > On Sun, May 15, 2011 at 06:37:58PM -0700, H.J. Lu wrote:
>> >> We must call bfd_link_repair_undef_list when we change symbol
>> >> type to bfd_link_hash_undefweak. ?Otherwise, assert may fail in:
>> >>
>> >> void
>> >> bfd_link_add_undef (struct bfd_link_hash_table *table,
>> >> ? ? ? ? ? ? ? ? ? ? struct bfd_link_hash_entry *h)
>> >> {
>> >> ? BFD_ASSERT (h->u.undef.next == NULL);
>> >
>> > How could that happen? ?We know the new symbol is a definition.
>> >
>>
>> After we turned a definition into an undefweak, we may see a reference in
>> LTO output, which will call bfd_link_add_undef.
>
> No, because the undefweak doesn't last. ?When plugin_notice returns to
> _bfd_generic_link_add_one_symbol we'll turn it into a defined,
> defweak, or common.
>
If linker sees undefined reference from an LTO output first, linker
will turn undefweak into undefined, which will trigger the assert.
Also, there are
/* The undefs list was designed so that in normal use we don't need to
remove entries. However, if symbols on the list are changed from
bfd_link_hash_undefined to either bfd_link_hash_undefweak or
bfd_link_hash_new for some reason, then they must be removed from the
list. Failure to do so might result in the linker attempting to add
the symbol to the list again at a later stage. */
void
bfd_link_repair_undef_list (struct bfd_link_hash_table *table)
--
H.J.