[Bug lto/48447] New: LTO link fails to link libgcc correctly when -nostdlib option is specified

[Bug lto/48447] New: LTO link fails to link libgcc correctly when -nostdlib option is specified

[patrick at motec dot com.au]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48447

           Summary: LTO link fails to link libgcc correctly when -nostdlib
                    option is specified
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: lto
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: patrick@motec.com.au


Created attachment 23879
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23879
Test cases

Not sure if this is a bug with gcc or binutils (ld) but I suspect gcc as test
case 2 succeeds.

Attached are 3 test cases which build a minimal project demonstrating the
following behaviours:

1. Link with LTO and -nostartfiles (succeeds)
2. Link without LTO and -nostdlib, libgcc is specified on the command line
(succeeds)
3. Link with LTO and -nostdlib, libgcc is specified on the command line (fails)

*** TEST 1: LTO with -nostartfiles
powerpc-eabispe-gcc -nostartfiles -flto -fuse-linker-plugin -Os -o test1 crt0.o
main.o -L.
*** TEST 2: no LTO with -nostdlib
powerpc-eabispe-gcc -nostdlib -Os -o test2 crt0.o main.o
/home/patrick/src/e7/toolchain/stage2/lib/gcc/powerpc-eabispe/4.6.0/libgcc.a
*** TEST 3: LTO with -nostdlib
powerpc-eabispe-gcc -nostdlib -flto -fuse-linker-plugin -Os -o test3 crt0.o
main.o
/home/patrick/src/e7/toolchain/stage2/lib/gcc/powerpc-eabispe/4.6.0/libgcc.a
/tmp/ccpXMwiG.ltrans0.ltrans.o: In function `foo.1466':
ccpXMwiG.ltrans0.o:(.text+0x84): undefined reference to `_rest32gpr_29_x'
collect2: ld returned 1 exit status
make: *** [test3] Error 1

Output of gcc -v

patrick@gtr:~/src/patrick/test$ powerpc-eabispe-gcc -v
Using built-in specs.
COLLECT_GCC=powerpc-eabispe-gcc
COLLECT_LTO_WRAPPER=/home/patrick/src/e7/toolchain/stage2/libexec/gcc/powerpc-eabispe/4.6.0/lto-wrapper
Target: powerpc-eabispe
Configured with: /home/patrick/src/e7/toolchain/src/gcc-4.6.0/configure
--prefix=/home/patrick/src/e7/toolchain/stage2 --build=x86_64-unknown-linux-gnu
--host=x86_64-unknown-linux-gnu --target=powerpc-eabispe
--enable-languages=c,c++ --with-sysroot=/home/patrick/src/e7/prex_sysroot
--disable-nls --disable-werror --with-newlib
--with-gmp=/home/patrick/src/e7/toolchain/stage2
--with-mpfr=/home/patrick/src/e7/toolchain/stage2 --disable-shared
--disable-debug --disable-libssp --with-cpu=8540
Thread model: single
gcc version 4.6.0 (GCC)

I have tried this with binutils 2.21 and the latest 2.21.51 development
snapshot.

Please let me know if there is any other information I can provide to assist in
working this out.

Thanks,

    Patrick

[Bug lto/48447] LTO link fails to link libgcc correctly when -nostdlib option is specified

[d.g.gorbachev at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48447

Dmitry Gorbachev <d.g.gorbachev at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |davek at gcc dot gnu.org

--- Comment #1 from Dmitry Gorbachev <d.g.gorbachev at gmail dot com> 2011-04-05 07:13:35 UTC ---
I believe it's a linker bug. I can reproduce it with analogous testcase on
i686-pc-linux-gnu. It fails only with BFD ld. Works with:
1) Gold;
2) BFD ld from Hongjiu Lu's lto-mixed branch
<http://git.kernel.org/?p=devel/binutils/hjl/x86.git;a=summary>;
3) BFD ld with Dave Korn's experimental patch
<http://sourceware.org/ml/binutils/2011-02/msg00337.html>.

[Bug lto/48447] LTO link fails to link libgcc correctly when -nostdlib option is specified

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48447

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2011.04.05 11:15:12
     Ever Confirmed|0                           |1

--- Comment #2 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-04-05 11:15:12 UTC ---
I think the references to the functions are introduced late, so the
archive re-scanning has to work.

[Bug lto/48447] LTO link fails to link libgcc correctly when -nostdlib option is specified

[d.g.gorbachev at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48447

--- Comment #3 from Dmitry Gorbachev <d.g.gorbachev at gmail dot com> 2011-04-05 12:42:52 UTC ---
For now, option -Wl,-plugin-opt=-pass-through=$(LIBGCC) can be manually added
to the command line (as discussed in PR42690).

[Bug lto/48447] LTO link fails to link libgcc correctly when -nostdlib option is specified

[patrick at motec dot com.au]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48447

--- Comment #4 from Patrick Oppenlander <patrick at motec dot com.au> 2011-04-06 22:47:12 UTC ---
(In reply to comment #3)
> For now, option -Wl,-plugin-opt=-pass-through=$(LIBGCC) can be manually added
> to the command line (as discussed in PR42690).

That does seem to work for now.

Does that mean this is a duplicate?

[Bug lto/48447] LTO link fails to link libgcc correctly when -nostdlib option is specified

[davek at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48447

--- Comment #5 from Dave Korn <davek at gcc dot gnu.org> 2011-04-07 15:49:29 UTC ---
Well, this is basically a weakness in the pass-through solution implemented for
PR 42690; it only knows about the compilers stdlibs, and doesn't process any
user-specified libs on the command line.  In the general case that's how things
ought to be: LTRANS only generates new references to builtins/libcalls, not any
of the user's code.  However when you use -nostdlib and pass libgcc as if it
were a user library, as in case 3, the pass-through mechanism doesn't know that
it's actually a compiler runtime rather than user library and doesn't pass it
through.

The correct fix is going to be in the linker, not the compiler, by implementing
a second library scan pass and obsoleting the pass-through mechanism.  I've got
a revised version of that experimental patch that I'll attach to this PR for
reference.

[Bug lto/48447] LTO link fails to link libgcc correctly when -nostdlib option is specified

[davek at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48447

--- Comment #6 from Dave Korn <davek at gcc dot gnu.org> 2011-04-07 15:51:30 UTC ---
Created attachment 23913
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23913
WIP patch

Work in progress: see comment at start of do_rescan_work() re DT_NEEDED libs,
but should be worth trying.

[Bug lto/48447] LTO link fails to link libgcc correctly when -nostdlib option is specified

[d.g.gorbachev at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48447

--- Comment #7 from Dmitry Gorbachev <d.g.gorbachev at gmail dot com> 2011-04-07 18:18:00 UTC ---
LD with patch from comment 6 fails on testcase from PR ld/12277.

[Bug lto/48447] LTO link fails to link libgcc correctly when -nostdlib option is specified

[patrick at motec dot com.au]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48447

--- Comment #8 from Patrick Oppenlander <patrick at motec dot com.au> 2011-04-07 22:15:56 UTC ---
> The correct fix is going to be in the linker, not the compiler, by implementing
> a second library scan pass and obsoleting the pass-through mechanism.  I've got
> a revised version of that experimental patch that I'll attach to this PR for
> reference.

How does this affect circular dependencies between user supplied libraries. ld
used to resolve these ok, and from the outside it seems like a similar problem.

[Bug lto/48447] LTO link fails to link libgcc correctly when -nostdlib option is specified

[davek at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48447

--- Comment #9 from Dave Korn <davek at gcc dot gnu.org> 2011-04-07 22:22:51 UTC ---
(In reply to comment #8)
> > The correct fix is going to be in the linker, not the compiler, by implementing
> > a second library scan pass and obsoleting the pass-through mechanism.  I've got
> > a revised version of that experimental patch that I'll attach to this PR for
> > reference.
> 
> How does this affect circular dependencies between user supplied libraries. ld
> used to resolve these ok, and from the outside it seems like a similar problem.

It doesn't affect them at all.

This problem only arises because the LTRANS phase (when the plugin invokes
lto-wrapper to recompile all the IR files that it has claimed) sometimes
creates new undefined references that weren't in the LTO symbol tables in the
original IR.  However, it is guaranteed that these references are only ever
going to be to functions that the compiler knows about itself as builtins, so
will only ever result in references to the various compiler language runtimes
and the core system libraries; for user-supplied functions.

LTO creates symbol tables in the IR files that drive the linker's initial
symbol resolution process, and these symbol tables will contain explicit
references to any external functions that aren't part of the language and
compiler runtimes; it however deliberately omits references to compiler
builtins, since they may well be optimised out during LTRANS.

So, everything related to user-supplied functions should behave identically
regardless of LTO, either with or without this extra patch to cause GCC to
rescan the libraries.

[Bug lto/48447] LTO link fails to link libgcc correctly when -nostdlib option is specified

[patrick at motec dot com.au]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48447

--- Comment #10 from Patrick Oppenlander <patrick at motec dot com.au> 2011-04-07 22:50:25 UTC ---
Ok, thanks for explaining that.

Another problem I've run into here is that I also need to pass through ecrtn.o
with -Wl,-plugin-opt=-pass-through to make sure it gets linked last, otherwise
it's symbols end up in the wrong place.