Bug 23600 - Link failure when using clang LTO + linker script with INPUTs
Summary: Link failure when using clang LTO + linker script with INPUTs
Alias: None
Product: binutils
Classification: Unclassified
Component: ld (show other bugs)
Version: 2.32
: P2 normal
Target Milestone: 2.32
Assignee: Not yet assigned to anyone
Depends on:
Reported: 2018-08-31 00:25 UTC by Mike Hommey
Modified: 2018-09-01 02:59 UTC (History)
0 users

See Also:
Last reconfirmed: 2018-08-31 00:00:00


Note You need to log in before you can comment on or make changes to this bug.
Description Mike Hommey 2018-08-31 00:25:57 UTC
$ cat <<EOF > main.c
int main() { return 0; }
$ clang -flto -o main.o -c main.c
$ cat <<EOF > main.ld
$ clang -flto -o main main.ld
/usr/bin/ld: skipping incompatible main.o when searching for main.o
/usr/bin/ld: cannot find main.o
clang: error: linker command failed with exit code 1 (use -v to see invocation)

This works with gold.
Comment 1 Mike Hommey 2018-08-31 00:48:02 UTC
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 <bfd_default_arch_struct>
(rr) print link_info.output_bfd->arch_info
$4 = (const struct bfd_arch_info *) 0x5582b328fa60 <bfd_x86_64_arch>

This probably only happens because INPUT makes ld lookup in search directories, and find an appropriate input for the given output, while an explicit path on the command line just doesn't do such lookup and never cares to check the arch_info is compatible.
Comment 2 Mike Hommey 2018-08-31 00:49:32 UTC
(entry->the_bfd->arch_info is also bfd_default_arch_struct when not using the linker script)
Comment 3 Mike Hommey 2018-08-31 01:01:12 UTC
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).
Comment 4 Mike Hommey 2018-08-31 02:07:46 UTC
AFAICT, bfd/plugin.c is never setting the arch_info, so that would likely be the problem.
Comment 5 H.J. Lu 2018-08-31 15:43:21 UTC
Please try

Comment 6 Mike Hommey 2018-08-31 23:41:49 UTC
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: i386:x86-64 architecture of input file `/tmp/lto-llvm-9bef61.o' is incompatible with i386 output
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Comment 7 cvs-commit@gcc.gnu.org 2018-09-01 02:58:48 UTC
The master branch has been updated by H.J. Lu <hjl@sourceware.org>:


commit b986869b6605e45044626c5b3111390ac4e70b82
Author: H.J. Lu <hjl.tools@gmail.com>
Date:   Fri Aug 31 19:56:25 2018 -0700

    Allow an IR object with unknown architecture
    An IR object may have an unknown architecture.  But it is compatible
    with other architecture.
    	PR ld/23600
    	* archures.c (bfd_arch_get_compatible): Allow an IR object with
    	unknown architecture.
Comment 8 H.J. Lu 2018-09-01 02:59:57 UTC
Fixed for 2.32.