https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82005
--- Comment #19 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to Iain Sandoe from comment #18) > So .. just some notes on thoughts so far, not much conclusion yet. > > (In reply to rguent...@suse.de from comment #17) > > On September 16, 2017 2:37:02 PM GMT+02:00, "iains at gcc dot gnu.org" > > <gcc-bugzi...@gcc.gnu.org> wrote: > > >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82005 > > > > > > >... and we expect to copy that into a new file, with the > > >"__GNU_DWARF_LTO" > > >renamed to __DWARF so that the content will get linked into the final > > >debug. > > So far, we've concentrated discussion on this copying, and from what I've > looked at it's not too hard (as I read the comments, simple-object doesn't > currently emit symbol tables for Mach-O, but it's likely we want to build a > very basic one - containing one symbol - the identifier for this set of > debug). There shouldn't be any relocs in these sections, since another > Mach-O debug opt is to elid all relocs that are just file-relative offsets > (that's what all the .set xxx-yyy is about in the Mach-O debug). > > .byte 0x2 # uleb128 0x2; (DIE (0x13b) DW_TAG_imported_unit) > > > .quad _pr82005_a.c.9d5291f5-Lsection__debug_info+11 # DW_AT_import > > > > > >^^ so is intended to resolve to the address marked "start + 11" above? > > > > Yes. > > > > >.. and it's expected that the static linker will resolve that while > > >linking the > > >debug sections between different files, including the copy-renamed > > >dwarf data > > >from the original? > > > > Yes. > > > >(this is going to be "fun", I suspect). > > So, that's where things start to get more interesting, the debug data for > Mach-O has a number of optimisatios we need work around. > > Mach-O's static linker doesn't link the debug; rather it notes what object > files contain the debug and adds information to the exe's (or dylib's) > symbol table about these. > > then: > > (optionally) dsymutil uses that information to pick up the objects and > _does_ link the debug into a single object > > debug consumers can use the linked debug object from dsymutil (if it's > available) _or_ they can look at the objects table in the exe and read the > debug from the original objects (which means that they link those on the > fly). > > So, it'e not so much the linker (ld64) that needs attention here, but more > whether the other consumers will deal with out-of-line DIEs (I assume GDB > will, and therefore the issues will be with dsymutil and possibly LLDB). Note that the file we do actually end up linking in the end is temporary, we'll remove it after the link. The early-debug information stays in the original object files but only in the DEBUG_LTO segment. If we need to patch more than GCC then a final solution should see to elide the copying of the early debug alltogether. > most likely ld64 will be OK with the changed files... > ... but it's quite likely that dsymutil will not be expecting this .. so we > might have to patch it. > > symbol subtractors with an undefined symbol are not allowed, as you've > found; However, AFAIR debug sections are 0-based, so we should be OK with > Sym+0ffset (although this needs to be checked). Yeah, see my hacks posted in this bug that tried to do that. > > >At this stage, presumably, we have a single LTO TU and if there were > > >some way > > >to reconstruct the (copied renamed) DWARF (re-written as source) in > > >that file > > >that would avoid the undefined syms > > this seems quite horrible to implement - although possibly achievable with > .include in asm. what if we'd do partial links of the temporary debug object into each of the ltrans objects? I would expect that ld -r _has_ to link the debug data? We'd end up with quite some duplicated debug that way of course but it might make the rest of the toolchain happy? I wonder how Darwin handles split-debug (not implemented AFAICS) or -feliminate-dwarf2-dups (removed from trunk). Both generate relocations to "external" debug in some way. > > >.. there will be one "copy-renamed" debug-only(+symtab) object for each > > >original TU ? > > > > Yes. > > ..anyway, now I'm clearer about what needs doing. Thanks.
