https://sourceware.org/bugzilla/show_bug.cgi?id=26150
Bug ID: 26150
Summary: Assertion failure at ldlang.c:7269 when using inline
assembly, -flto and --no-whole-archive
Product: binutils
Version: 2.35 (HEAD)
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: pexu at sourceware dot mail.kapsi.fi
Target Milestone: ---
Target: aarch64-none-elf
Hi.
Hitting this assert on ldlang.c.
7269 ASSERT (entry->the_bfd->link.next == NULL);
I'm aware of https://sourceware.org/bugzilla/show_bug.cgi?id=26103, but this is
not related to link-once sections. Using binutils and GCC built from the
latest development tree.
I was able to able to narrow this issue down to inline assembly which
references an external object that resides inside the same library. An another
function must also reference that same object. Consider the following case
(header files omitted and assembly abbreviated):
libarchive0.a:
archive0__object0.c:
int archive0__object0(void) { return 42; }
archive0__object1.c:
__asm__("archive0__object1:" ";"
"b archive0__object0"); /* branch to archive0__object0 */
archive0__object2.c:
int archive0__object2(void) { return archive0__object0(); }
If archive0__object0 is referenced outside this library, everything works out
fine. However, if archive0__object0 is not referenced but archive0__object1
and archive0__object2 are, ld will trip the assertation.
Using -Wl,--trace I see a following pattern happening, I was lazy and simply
printf'd anything ldlang_add_entry was given. Basically two distinct
lang_input_statement_type objects reference the same bfd object; At some point
its link.next is set to a non-zero value (which seems to be valid value).
I will attach a brief test case; I only tried aarch64-none-elf, my apologies
for that.
.\libarchive0.a
@ add_archive_element: name=archive0__object1, abfd=@<location A>.
ldlang_add_entry(input=@<location B>
@<location B>: struct type: lang_input_statement_type
filename: .\archive0__object1.o
the_bfd: @<location C>
@<location C>: struct type: bfd
filename: .\archive0__object1.o (symbol from plugin)
usrdata: 0000000000000000
next: 0000000000000000
.\archive0__object1.o
.\archive0__object2.o
.\archive0__object0.o
.\libarchive0.a
@ add_archive_element: name=archive0__object1, abfd=@<location A>.
ldlang_add_entry(input=@<location D>)
@<location D>: struct type: lang_input_statement_type
filename: .\archive0__object1.o
the_bfd: @<location C>
@<location C>: struct type: bfd
filename: .\archive0__object1.o (symbol from plugin)
usrdata: <location A>
next: <location E>
@<location E>: struct type: bfd
filename: .\archive0__object2.o (symbol from plugin)
--
You are receiving this mail because:
You are on the CC list for the bug.
