http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46749
--- Comment #22 from Iain Sandoe <iains at gcc dot gnu.org> 2010-12-02 10:10:06 UTC --- (In reply to comment #21) > 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? At install-time dsymutil is run and the relevant xxx.dSYM is installed along with the objects, where required. AFAICS, this is already handled within auto* & gcc (the gcc libraries appear to build dSYMs). > Can we just disable this for the testsuite? well, one possibility to resolve this, is to disable the 'automatic' running of dsymutil - add a '-syms' flag, and require that the user adds that flag along with the debug ones. In which case, it would be automatically absent from the test-suite. It's a bit of a cop-out and I don't know if it would be acceptable to Darwin maintainers .. but it's a thought. The problem showing in this PR would still arise for a user invoking such a flag along with flto -- so we need to fix it at some stage (but I wouldn't say it was in any way critical).
