https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82005
--- Comment #42 from Richard Biener <rguenth 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.
>
First thanks for continuing to look into this (and sorry for the late
response).
> 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
That's something I considered. The scheme would basically be:
- at dwarf2out_early_finish time when we write-out LTO debug assembly
"switch" to an alternate asm_out_file and output the debug info there
with "real" section names
- given tooling cannot deal with a -c compile producing multiple .o files
as output the options are
* assemble the debug to a temporary .o file and include that wrapped
in a LTO section with the main .o output
* include the assembly in a LTO section with the main .o output
- at WPA time we have to somehow "offload" the early debug again. The
"simple" option is to produce a set of non-LTRANS-IL but "final"
object files, one per original compile unit. That works with both
object code and assembly. The alternative is to "link" the early
debug into a single "LTRANS" object, we'd have to re-write the
offloaded assembly, renaming all local labels (at least)
but neither of the above would solve out issue here - the early debug
would be still separate from the LTRANS object debug that refers to
it symbolically.
DWARF has some machinery to have "references" without locations but only
for type DIEs by using CRCs as references (and hoping for no collisions).
A new DWARF extension could do sth similar for CU references and
references relative to such imported CUs. Doesn't solve things for
old tools and darwin tools would have to support this extension.
> - 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?
The issue is that we'd have to distribute _all_ early debug to _each_
LTRANS unit with late debug. That's N-fold duplication that I wanted
to avoid... but yes, with the assembly scheme from above you could
"prepend" each LTRANS unit with the "merged" early debug assembly.
(at least N is limited by --param lto-partitions which defaults to 32...)
Note that doing the assembling of the early debug during compile-time
and then have the linker at the final link pick up that debug from the
original objects as would have been my prefered way would be still the
best for compile-time and disk-space usage. But of course it wouldn't
work for DARWIN w/o assembler changes to support this kind of relocations.
So maybe for darwin the only practical way into the future is to have
that DWARF extension? The DWARF standard suggests that the linker should
be able to handle the kind of relocations we currently use though. Not
sure if maybe .debug_addr / DW_FORM_addrx* from split-dwarf can help
here but my understanding is that darwin doesn't support split-dwarf.
