https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82005
--- Comment #50 from Iain Sandoe <iains at gcc dot gnu.org> --- (In reply to rguent...@suse.de from comment #49) > On Wed, 1 Aug 2018, iains at gcc dot gnu.org wrote: > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82005 > > > > --- Comment #48 from Iain Sandoe <iains at gcc dot gnu.org> --- > > the relocations look reasonable and dwarfdump of the individual objects > > (.debug.temp.o and the .ltrans0.ltans.o) also. > > > > So, it looks like dsymutil isn't somehow consuming this so some debugging is > > needed there. > > But the interesting piece then is to somehow preserve the ltrans > objects since that is needed when the debug is not linked into > the executable? Or is dsymutil extracting the debug from objects > and stores it somewhere more persistent? when an exe is linked, the static linker (ld64) does not include the debug data in the exe. However, it records (in the exe symbol table) the names of the object files that it linked dsymutil consumes the exe file table and the link line objects and links the debug - producing a standard Darwin/OS X package structure containing the linked debug. [by default name.dSYM] where "name" is the name of the exe. So, yes that's moved it to a persistent place. So case #1. - the link line objects are all temporaries (no save-temps). - in this case they must not be deleted until dsymutil has run, and AFAICS the collect2 driver deals with that already. - my local patches remove the pre-link of the debug objects and emit those onto the final link line (so it doesn't look any different from 'normal'). case #2 - with save temps, these objects need to be preserved - this isn't working with my current patch-set, it says [Leaving ... ] but the ltrans0.ltran.o and the debug.temp.o files are removed unless I put -Wl,-debug on the c/l. .. also on the TODO to figure that out.
