http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46749
--- Comment #21 from rguenther at suse dot de <rguenther at suse dot de> 2010-12-02 09:50:48 UTC --- On Thu, 2 Dec 2010, iains at gcc dot gnu.org wrote: > 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 Huh, but what do you do at make install time? Copy the object files? Extract the debug info and put it into the binary again? Have a special dsymutil make install hook? Can we just disable this for the testsuite? Richard.
