http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46749
--- Comment #20 from Iain Sandoe <iains at gcc dot gnu.org> 2010-12-02 09:09:49 UTC --- (In reply to comment #19) > On Wed, 1 Dec 2010, iains at gcc dot gnu.org wrote: > > yeah - it's on my TODO (pr43751). > > FWIW, some time ago, I did enquire about the difficulty of adding an > > intentional additional post-link phase, with the feedback that it was prob. > > not > > easy. > > I thought about adding it to the collect-ld script instead. > > Why do we want it only if there is a .c source available? That doesn't > make sense to me ... but i have no idea what dsymutil is supoosed to do, > so ... _any_ source, in fact -- hence PR43751 (because we don't even try to notice Fortran at present). ---- OK. Without wishing to start any debate on whether the approach is "good" or "bad". The idea is that one saves time in the compile/debug loop by _not_ linking the debug - and leaving it in the object files. This is fine until the c/l is of the form " gcc some-source.ext -o exe " because then the object is temporary and deleted, thus not available for debugging. So, dsymtuil (which is a stand-alone debug-linker - used, in general, for the packaging phase of a project) is invoked for such command lines. It grabs the debug from the files that will be deleted during the build. this is quite helpful: http://wiki.dwarfstd.org/index.php?title=Apple's_%22Lazy%22_DWARF_Scheme
