[Bug lto/48447] LTO link fails to link libgcc correctly when -nostdlib option is specified
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
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
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
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
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
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.
[Bug lto/48447] LTO link fails to link libgcc correctly when -nostdlib option is specified
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
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
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
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).
