[Bug debug/61352] gcc 4.9.0 fails to execute dsymutil when linking executables on darwin

[iains at gcc dot gnu.org]

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+