[Bug ld/26150] New: Assertion failure at ldlang.c:7269 when using inline assembly, -flto and --no-whole-archive

[pexu at sourceware dot mail.kapsi.fi]

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.