https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82005
--- Comment #41 from Eric Gallager <egallager at gcc dot gnu.org> --- (In reply to Iain Sandoe from comment #40) > Created attachment 44417 [details] > Patch series to enable copying of early debug data. > > > 1. Sorry about the long absence, equally long story... Welcome back; it's good to see you again! > > 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 Please submit to the gcc-patches mailing list for review then! > > - 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?
