[Bug debug/61352] gcc 4.9.0 fails to execute dsymutil when linking executables on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61352
Iain Sandoe changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED |---
--- Comment #16 from Iain Sandoe ---
At present, we are calling dsymutil unconditionally, e.g. for:
gcc foo.o -g -o foo.exe
... which should not invoke dsymutil - it should only run:
(a) if there's a source file on the command line
(b) it we are doing LTO && a recompile of LTO code from objects takes place.
--- trunk/gcc/collect2.c2014/05/29 22:16:02 211066
+++ trunk/gcc/collect2.c2014/05/29 23:20:39 211067
@@ -848,6 +848,8 @@
fork_execute ("ld", lto_ld_argv);
post_ld_pass (false);
}
+ else
+post_ld_pass (true);
I think there's a paste-o here and this ^ and this should be "post_ld_pass
(false)"
}
/* Main program. */
[Bug debug/61352] gcc 4.9.0 fails to execute dsymutil when linking executables on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61352 --- Comment #15 from Iain Sandoe --- Created attachment 35512 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35512&action=edit Disable dsymutil when -save-temps is on the command line. … something like this…
[Bug debug/61352] gcc 4.9.0 fails to execute dsymutil when linking executables on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61352 --- Comment #14 from Iain Sandoe --- (In reply to Joel Brobecker from comment #13) > Sorry guys, but dsymutil is not working very well. I have a couple of > examples where, either dsymutil is excluding some DIEs from the DWARF image, > or where dsymutil actually segfaults. I think we all see this to some degree-or-other... >There is also the fact that dsymutil > doesn't know about recent DWARF enhancements, and doesn't work well when > compiling code with -gno-strict-dwarf. I think that's pretty much "not supported" with dsymutil; even the LLVM project makes concessions to the need to support older DWARF output for OS X… I'd also wonder if it's 100% safe w.r.t ld64, and other items from the DWARFutils package (although objdump & friends are pretty good for mach-o, they are not a standard build for most folks). however >Since we do not control dsymutil and its quality level (or lack thereof), Yeah .. 'tis the one thing we can't fix at present... … (let's cross fingers for llvm-dsymutil maturing quickly). > GDB should be able to use the debug info from the object files without > requiring the use of dsymutil. >I suggest the best course of action is > trying to figure out why GDB doesn't pick the debugging info up from the .o > files, and then fix that. That's a good idea. My experience is that it's quite variable, sometimes using GDB on the *.o works better … sometimes the .dSYM works better. > In the meantime, I suggest we revert this change, or else make it optional > at the very least. case 1. gcc foo.o bar.o baz.o … <= should *not* invoke dsymutil - should work "as expected" with the .o files. case 2. gcc foo.o bar.o bad.c <= should invoke dsymutil. In this case, you don't have baz.o, since it's a temporary file - so you can't use it for debug (hence the secondary purpose of dsymutil). You'd need 'save-temps' on the c/l to ensure this... So we we could try amending the link spec to suppress the call of dsymutil if "save-temps" is on the c/l? I'm kinda in favour of this, since we *don't* have control over dsymutil and it won't be fixed for darwin < bleeding edge even if a radar is filed - I assume radar(s) have been filed for the issues? > PS: Our experiments are on Darwin 13.4 and 14.3. It's much the same across the board Darwin9+
[Bug debug/61352] gcc 4.9.0 fails to execute dsymutil when linking executables on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61352 Joel Brobecker changed: What|Removed |Added CC||brobecker at gnat dot com --- Comment #13 from Joel Brobecker --- Sorry guys, but dsymutil is not working very well. I have a couple of examples where, either dsymutil is excluding some DIEs from the DWARF image, or where dsymutil actually segfaults. There is also the fact that dsymutil doesn't know about recent DWARF enhancements, and doesn't work well when compiling code with -gno-strict-dwarf. GDB should be able to use the debug info from the object files without requiring the use of dsymutil. Since we do not control dsymutil and its quality level (or lack thereof), I suggest the best course of action is trying to figure out why GDB doesn't pick the debugging info up from the .o files, and then fix that. In the meantime, I suggest we revert this change, or else make it optional at the very least. PS: Our experiments are on Darwin 13.4 and 14.3.
[Bug debug/61352] gcc 4.9.0 fails to execute dsymutil when linking executables on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61352 --- Comment #12 from mrs at gcc dot gnu.org --- Author: mrs Date: Wed May 6 00:33:49 2015 New Revision: 222835 URL: https://gcc.gnu.org/viewcvs?rev=222835&root=gcc&view=rev Log: 2015-05-05 Jack Howarth Backport from mainline 2014-05-29 Mike Stump PR debug/61352 * collect2.c (maybe_run_lto_and_relink): Be sure to always run post ld passes when lto is used. Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/collect2.c
[Bug debug/61352] gcc 4.9.0 fails to execute dsymutil when linking executables on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61352 --- Comment #11 from Jack Howarth --- fix confirmed when applied to gcc 4.9.0.
[Bug debug/61352] gcc 4.9.0 fails to execute dsymutil when linking executables on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61352 --- Comment #10 from Jack Howarth --- (In reply to Jack Howarth from comment #9) > (In reply to m...@gcc.gnu.org from comment #8) > > Ok, should work now. Richard turned on lto processing in collect2, and we > > need to run the post ld pass even when doing lto. > > Don't forget that we need this in gcc 4.9.1 as well. Also, shouldn't we add a simple darwin-specific test case for this PR to make sure that this one doesn't happen again.
[Bug debug/61352] gcc 4.9.0 fails to execute dsymutil when linking executables on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61352 --- Comment #9 from Jack Howarth --- (In reply to m...@gcc.gnu.org from comment #8) > Ok, should work now. Richard turned on lto processing in collect2, and we > need to run the post ld pass even when doing lto. Don't forget that we need this in gcc 4.9.1 as well.
[Bug debug/61352] gcc 4.9.0 fails to execute dsymutil when linking executables on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61352 mrs at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||mrs at gcc dot gnu.org Resolution|--- |FIXED --- Comment #8 from mrs at gcc dot gnu.org --- Ok, should work now. Richard turned on lto processing in collect2, and we need to run the post ld pass even when doing lto.
[Bug debug/61352] gcc 4.9.0 fails to execute dsymutil when linking executables on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61352 --- Comment #7 from mrs at gcc dot gnu.org --- Author: mrs Date: Thu May 29 23:20:39 2014 New Revision: 211067 URL: http://gcc.gnu.org/viewcvs?rev=211067&root=gcc&view=rev Log: PR debug/61352 * collect2.c (maybe_run_lto_and_relink): Be sure to always run post ld passes when lto is used. Modified: trunk/gcc/ChangeLog trunk/gcc/collect2.c
[Bug debug/61352] gcc 4.9.0 fails to execute dsymutil when linking executables on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61352 --- Comment #6 from Dominique d'Humieres --- r208320 (2014-03-04) generates the *.dSYM folder, r208478 (2014-03-11) does not.
[Bug debug/61352] gcc 4.9.0 fails to execute dsymutil when linking executables on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61352 Iain Sandoe changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-05-29 Ever confirmed|0 |1 --- Comment #5 from Iain Sandoe --- it looks suspiciously like collect2 has started running /usr/bin/nm -n .o in the place it used to run dsymutil, even when LTO is not engaged. Will take a look tomorrow.
