[Bug testsuite/95577] Tcl error with testsuite/gcc.misc-tests/outputs.exp on darwin

["iains at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95577

--- Comment #4 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Alexandre Oliva from comment #3)
> Iain,
> 
> Do platforms that use dsymutil support -gsplit-dwarf?

None I am aware of - Darwin should reject -gsplit-dwarf with a diagnostic, so
that configuration should detect missing support correctly there.

> I'm thinking of bringing -g into the gsplit_dwarf variable, so it won't be
> enable without -gsplit-dwarf, and removing other explicit mentions of -g
> from outputs.exp.
> 
> Would this be enough to address the dsymutil left-overs?

I don't think so (hence the code to detect -g* and delete the .dSYM if one is
seen).

======

The motivation for Darwin's 'split' debug is actually different from the
-gsplit-dwarf (and it doesn't solve the object size problem that split dwarf
does).

For the record - the Darwin behaviour is like this;

[when debug is enabled] the static linker [ld64] embeds a list of contributing
object file paths into the executable.  It does not link or include any debug
in the exe (this saves time).

dsymutil [the debug linker] takes the executable, looks up the list of object
files and produces a linked debug object, this is placed into a Darwin file
package (a directory structure with some metadata embedded + the object).  This
is named <exe>.dSYM <= but it's a file package, so has to be deleted like a
directory.

On Darwin, debug consumers have two options;

1. Use the table in the exe to pull the debug data directly from the
contributing objects (i.e. never do an actual debug link but just dynamically
satisfy those symbols the user inspects).
  - LLDB and GDB both grok this (newer GDBs might have bit-rotted somewhat
since Adacore is no longer maintaining the Darwin binutils stuff and I am
totally out of cycles to contribute).

2. If the the debug linker has been run and the .dSYM is available, they can
use that.

1) is very efficient for large projects with many object files with long debug
link times, since that stage of linking can be omitted in the
compile/edit/debug loop.

-----

BUT, then there's one case where (1) doesn't work - which is when the user
does;

 gcc foo.c bar.o ..... -g -o x

because the object file created for any source on the command line is
ephemeral, and thus if it's put into the exe that doesn't help - because it
won't be available at debug time.

So Darwin's linker spec force dsymutil to be run for any compile line that
includes a source file, this is a very common circumstance in the test suite,
leading to many .dSYM files that need to be removed.

The patch fragment at comment #1 addresses this for these tests (and Dominque
has a larger patch [which I need to look at] to clean it up in more places in
the test suite).