https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82005
--- Comment #47 from Iain Sandoe <iains at gcc dot gnu.org> --- bah. - put in the change from comment #6 - modified lto-wrapper to - remove the debug object pre-link - append the debug objects to the final link. - faked a common symbol in the copied debug, so that ld64 actually emits the debug.temp.o into the linked objects table [in the exe]. Without this it just silently drops files which only contain debug, I guess on the basis that debug is always local so if there's no content, there can't be any debug (IMO this is prob. a tool bug, but academic at present, since it doesn't work even with the faked common symbol) (dsymutil uses the linked objects table - actually a bunch of stabs OSOs - to find the original objects which _it_ links the debug from) - ld64 completes without error, and the resulting object (for at least the trivial case in this pr) can be debugged. - but dsymutil barfs with "warning: could not find referenced DIE", so despite this, something remains broken. ... so, I could (presumably, probably) fix ld64 and/or dsymutil to work for this - but that would force Darwin to use customised "mach-o binutils" (not a Bad Thing IMO, but obviously we would be behind the vendor's tools, since they don't release the sources particularly often/quickly). However, it seems that many of the Darwin folks prefer to use the Xcode set .. so maybe have to think of an alternative. I wonder if the additional stuff added to simple-object would allow me to fake a "ld -r" for debug. will do some more analysis to see what ld has actually done with the relocs.
