https://sourceware.org/bugzilla/show_bug.cgi?id=23600
H.J. Lu changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://sourceware.org/bugzilla/show_bug.cgi?id=23600
--- Comment #7 from cvs-commit at gcc dot gnu.org ---
The master branch has been updated by H.J. Lu :
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=b986869b6605e45044626c5b3111390ac4e70b82
commit b986869b6605e45044626c5b3111390a
https://sourceware.org/bugzilla/show_bug.cgi?id=23600
--- Comment #6 from Mike Hommey ---
It works, and it still detects cases where the IR file doesn't have the right
architecture:
$ clang -flto -o main.o -c main.c
$ clang -flto -o main main.ld
$ clang -m32 -flto -o main main.ld
/tmp/bin/ld: i3
https://sourceware.org/bugzilla/show_bug.cgi?id=23600
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://sourceware.org/bugzilla/show_bug.cgi?id=23600
--- Comment #4 from Mike Hommey ---
AFAICT, bfd/plugin.c is never setting the arch_info, so that would likely be
the problem.
--
You are receiving this mail because:
You are on the CC list for the bug.
___
https://sourceware.org/bugzilla/show_bug.cgi?id=23600
--- Comment #3 from Mike Hommey ---
So the difference when linking a non LTO object file with the same linker
script is that after the call to bfd_check_format, check->arch_info is
bfd_x86_64_arch (it is bfd_default_arch_struct before the call
https://sourceware.org/bugzilla/show_bug.cgi?id=23600
--- Comment #2 from Mike Hommey ---
(entry->the_bfd->arch_info is also bfd_default_arch_struct when not using the
linker script)
--
You are receiving this mail because:
You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=23600
--- Comment #1 from Mike Hommey ---
In ldfile_try_open_bfd, we end up in the error case presumably because:
(rr) print check->filename
$2 = 0x5582b37b57e0 "main.o"
(rr) print check->arch_info
$3 = (const struct bfd_arch_info *) 0x5582b3286fe0
