https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91376
--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot
Uni-Bielefeld.DE> ---
> --- Comment #7 from Martin Liška <marxin at gcc dot gnu.org> ---
> (In reply to Martin Liška from comment #6)
>> Good, then let me take a look.
>
> So I've just tested current master of binutils and I can see:
>
> marxin@marxinbox:/tmp> gcc --version
> gcc (GCC) 10.0.0 20190806 (experimental)
> Copyright (C) 2019 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions. There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> marxin@marxinbox:/tmp> gcc -c -flto main.c
>
> $ nm main.o
> nm: main.o: plugin needed to handle lto object
> 0000000000000001 C __gnu_lto_slim
>
> The issue here is that the installed nm can't load plugin from bfd-plugins:
>
> $ strace -f -s512 nm main.o 2>&1 | grep plugin
> openat(AT_FDCWD, "/home/marxin/bin/binutils/bin/../bin/../lib/bfd-plugins",
> O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 4
> stat("/home/marxin/bin/binutils/bin/../bin/../lib/bfd-plugins/..",
> {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
> stat("/home/marxin/bin/binutils/bin/../bin/../lib/bfd-plugins/.",
> {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
> write(2, "main.o: plugin needed to handle lto object", 42main.o: plugin needed
> to handle lto object) = 42
>
> $ nm --plugin /dev/shm/objdir/lto-plugin/.libs/liblto_plugin.so.0.0.0 main.o
> 00000000 T main
>
> So the question is if you have a LTO plugin accessible for the built gold or
> nm?
I don't see how nm would come into play here. For one, I've only
installed gas and gld from binutils trunk under non-standard names
(gas-2.32.51 and gld-2.32.51) and use them via --with-as and --with-ld.
The failing testcases boils down to (run in gcc/testsuite/g++):
#!/bin/sh
COLLECT_GCC=../../xg++ \
COLLECT_GCC_OPTIONS= \
COLLECT_LTO_WRAPPER=../../lto-wrapper \
COMPILER_PATH=../.. \
\
/vol/gcc/bin/gld-2.32.51 \
-plugin ../../liblto_plugin.so \
-plugin-opt=../../lto-wrapper \
-plugin-opt=-fresolution=cp_lto_pr90990_0.res \
-plugin-opt=-v \
-plugin-opt=-save-temps \
-o g++-dg-lto-pr90990-01.exe -r cp_lto_pr90990_0.o
$ gld.cmd
../../lto-wrapper -fresolution=cp_lto_pr90990_0.res -flinker-output=rel
cp_lto_pr90990_0.o
/vol/gcc/bin/gld-2.32.51: /var/tmp//ccKkavFd.lto.o: plugin needed to handle lto
object
[Leaving g++-dg-lto-pr90990-01.exe.lto_wrapper_args]
[Leaving /var/tmp//ccKkavFd.lto.o]
When I run this under truss (Solaris equivalent of strace), I find just
the following calls to execve:
12815: execve("../../lto-wrapper", 0xFEFFD6F4, 0xFEFFD844) argc = 2
12815: argv: ../../lto-wrapper
12815: @g++-dg-lto-pr90990-01.exe.lto_wrapper_args
12817: execve("../../xg++", 0xFEFFD5A4, 0xFEFFD990) argc = 2
12817: argv: ../../xg++ @/var/tmp//ccxh7UCb
12819: execve("../../lto1", 0x08189FD0, 0x08187784) argc = 19
12819: argv: ../../lto1 -quiet -dumpbase cp_lto_pr90990_0.o
12819: -mtune=generic -march=pentium4 -auxbase-strip
12819: /var/tmp//ccKkavFd.lto.o -O0 -fno-openmp -fno-openacc
12819: -fno-pie -fno-diagnostics-show-caret
12819: -fno-diagnostics-show-line-numbers
12819: -fresolution=cp_lto_pr90990_0.res -flinker-output=rel
12819: @/var/tmp//ccsvXE.b -o /var/tmp//ccM632hc.s
12821: execve("/vol/gcc/bin/gas-2.32.51", 0x08189FD0, 0x08187784) argc = 7
12821: argv: /vol/gcc/bin/gas-2.32.51 -Qy -s --32 -o
12821: /var/tmp//ccKkavFd.lto.o /var/tmp//ccM632hc.s
There's no nm anywhere in sight. Besides, I find it very strange that
out of hundreds if not thousends of LTO tests during this bootstrap,
only a single one shows this error. If there were a fundamental
problem, I'd expect a way larger number here.
