bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug ld/26103] Assertion failure at ldlang.c:7269 when compiling with LT


From: amodra at gmail dot com
Subject: [Bug ld/26103] Assertion failure at ldlang.c:7269 when compiling with LTO on MinGW
Date: Sun, 14 Jun 2020 12:22:25 +0000

https://sourceware.org/bugzilla/show_bug.cgi?id=26103

Alan Modra <amodra at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2020-06-14
             Status|UNCONFIRMED                 |ASSIGNED
     Ever confirmed|0                           |1
           Assignee|unassigned at sourceware dot org   |amodra at gmail dot com

--- Comment #8 from Alan Modra <amodra at gmail dot com> ---
> I set the watchpoint on h->type for the weak symbol and it only gets set to 
> bfd_link_hash_undefined once

OK, so that would seem to mean we don't have the class of linker bug that
caused pr24567.

Next theory:  The .weak.* symbol (which isn't weak BTW) is defined in a
LINK_ONCE_DISCARD section, and the section is discarded due to some other copy
of the section being linked before ios.o is linked.  You can check that this
might be so by inspecting your ios.o with objdump -th to see whether the weak
symbol section (index 169 according to the dump you attached) is
LINK_ONCE_DISCARD.  That would make the .weak.* symbol bfd_link_hash_undefined,
cofflink.c:314.

Then, when the libstdc++ archive is searched again after loading the lto output
object file, ios.o is seen as defining this undefined symbol.  Oops, we load
ios.o again.

The good news is that I managed to create a relatively simple testcase that
doesn't require LTO, and that fails on ELF targets.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]