https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91376
--- Comment #9 from Martin Liška <marxin at gcc dot gnu.org> ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #8)
> > --- 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.
I thought you see the failure for all tests. Then one could use nm to identify
if LTO plugin is properly loaded.
> 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]
Can you please send me the *.o files so that I can investigate them?
>
> 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.
That's strange! The test-case is not special to me.
