[Bug target/82005] Early lto debug not implemented on Darwin

[egallager at gcc dot gnu.org]

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?