[Bug ld/26150] Assertion failure at ldlang.c:7269 when using inline assembly, -flto and --start-group
https://sourceware.org/bugzilla/show_bug.cgi?id=26150 Alan Modra changed: What|Removed |Added Status|ASSIGNED|RESOLVED Target Milestone|--- |2.35 Resolution|--- |FIXED --- Comment #13 from Alan Modra --- Should now be fixed. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26150] Assertion failure at ldlang.c:7269 when using inline assembly, -flto and --start-group
https://sourceware.org/bugzilla/show_bug.cgi?id=26150 --- Comment #12 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Alan Modra : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=9221725d1f6e3f5dd0c0143ee750460619c582f2 commit 9221725d1f6e3f5dd0c0143ee750460619c582f2 Author: Alan Modra Date: Tue Jun 23 23:50:56 2020 +0930 PR26150, Assertion when asm() defines global symbols, -flto and --start-group If an archive map contains symbols that aren't actually defined by the indexed element for any reason, then loading that element will leave the symbol undefined (or common). This leads to the possibility of the element being loaded again should the archive be searched again due to the action of --start-group/--end-group. The testcase triggering this problem was an archive containing fat lto objects, with the archive map incorrectly created by ar rather than gcc-ar. PR 26150 * ldlang.c (ldlang_add_file): Assert that we aren't adding the current end of link.next list again too. * ldmain.c (add_archive_element): Don't load archive elements again that have already been loaded. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26150] Assertion failure at ldlang.c:7269 when using inline assembly, -flto and --start-group
https://sourceware.org/bugzilla/show_bug.cgi?id=26150 --- Comment #11 from Pekka Seppänen --- Oh my... I completely forgot the --plugin part and how it participates with ar. This is my bad, sorry :( Indeed the resulting (thin) archive is a bit different whether or not --plugin is there, namely how archive0__object1 is mapped in this case. So, in a sense that assertation is simply a red herring. There could be yet another way of triggering this same problem, again, due to not properly using --plugin when creating an archive with object files compiled using -flto and inline assembly. I originally stubled upon this as I have a few locations that require naked functions when forwarding calls between different rings. For AArch64 GCC does unfortunately support those, so I simply had a similar inline shims; Those do not actually reference any symbols but are referenced within the same library. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26150] Assertion failure at ldlang.c:7269 when using inline assembly, -flto and --start-group
https://sourceware.org/bugzilla/show_bug.cgi?id=26150 Alan Modra changed: What|Removed |Added Summary|Assertion failure at|Assertion failure at |ldlang.c:7269 when using|ldlang.c:7269 when using |inline assembly, -flto and |inline assembly, -flto and |--no-whole-archive |--start-group Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Assignee|unassigned at sourceware dot org |amodra at gmail dot com Last reconfirmed||2020-06-23 -- You are receiving this mail because: You are on the CC list for the bug.
