https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61352
--- Comment #14 from Iain Sandoe <iains at gcc dot gnu.org> --- (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+
