https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82005
--- Comment #18 from Iain Sandoe <iains at gcc dot gnu.org> --- 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). 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). > >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. > >.. there will be one "copy-renamed" debug-only(+symtab) object for each > >original TU ? > > Yes. ..anyway, now I'm clearer about what needs doing.
