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).
