https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82005
--- Comment #40 from Iain Sandoe <iains at gcc dot gnu.org> --- Created attachment 44417 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44417&action=edit Patch series to enable copying of early debug data. 1. Sorry about the long absence, equally long story... 2. The patches are *not* a fix for the problem, but might allow investigation of more possibilities. - 2.1) Small patch to lto-wrapper to make the debug data temp files easier to identify and to save them with -save-temps. - 2.2) Patch to simple object to allow the callback that identifies LTO debug sections to be specific to the file format handler. - 2.3) Patch to copy the LTO debug data in mach-o simple-object. This turns out to be quite heavy lifting despite the conceptual simplicity - since there was no support for symbols in the existing impl. of mach-o simple object. Anyway, it's functional. - 2.4) patch for lto-wrapper to allow mach-o LTO debug sections to be detected. 3. You can back out the change to darwin.c that disables debug for LTO, but the end result will still be the same (undefined symbols in a subtraction). * 3.1 this is not solved by any copying or linking, since it's an assembler diagnostic. * 3.2 The debug sections are not individually 0-based so we can't assume that. * 3.3 In a single mach-o object file, the assembler is able to elide the inter-section debug relocations, since the order of (and offsets between) the debug sections is known at assembly time. Thus a 'normal' mach-o object does not have inter-section relocs for the debug data. The debug linker (dsymutil) handles this. * 3.4 FWIW, the static linker produces a "0" output for linking objects which only contain debug data. I guess this could be regarded as a tool bug (since it *should* reference the original object files with stabs symbols, but doesn't). However, given 3.1 it's probably not worth getting too excited about. * 3.5 Alternative to messing with ld64 might be to patch dsymutil to provide the debug link equivalent of "-r" (still doesn't solve 3.1) 4. Where from here? - the patches are probably useful in their own right, even tho they don't solve the problem - maybe we can in some way regenerate relevant asm source from the copied debug data and find some way to include it in the LTO output files - we seem to be jumping through quite a few hoops here, presumably because it's too complex to emit the relevant data as markup into the LTO stream directly?
