This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]