https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82005
--- Comment #17 from rguenther at suse dot de <rguenther at suse dot de> --- 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 > >--- Comment #16 from Iain Sandoe <iains at gcc dot gnu.org> --- >So.. trying to understand what we need to do to get this working on >Darwin. > >in the original .s we have ... > > .section __GNU_DWARF_LTO,__debug_info,regular,debug >Lsection__debug_info_lto: >Ldebug_info0: > .private_extern _pr82005_a.c.9d5291f5 > .globl _pr82005_a.c.9d5291f5 >_pr82005_a.c.9d5291f5: > .long 0x4dc # Length of Compilation Unit Info > .word 0x2 # DWARF version number > .set L$set$0,Ldebug_abbrev0-Lsection__debug_abbrev_lto > .long L$set$0 # Offset Into Abbrev. Section > .byte 0x8 # Pointer Size (in bytes) >>> start + 11 > .byte 0x1 # uleb128 0x1; (DIE (0xb) DW_TAG_compile_unit) > >... 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. > >in the lto .s we have > > .section __DWARF,__debug_info,regular,debug >Lsection__debug_info: >Ldebug_info0: > .long 0x16b # Length of Compilation Unit Info > .word 0x2 # DWARF version number > .set L$set$13,Ldebug_abbrev0-Lsection__debug_abbrev > .long L$set$13 # Offset Into Abbrev. Section > .byte 0x8 # Pointer Size (in bytes) ><snip> > .quad Letext0 # DW_AT_high_pc > .set L$set$14,Ldebug_line0-Lsection__debug_line > .long L$set$14 # DW_AT_stmt_list > .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). > >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 > >.. there will be one "copy-renamed" debug-only(+symtab) object for each >original TU ? Yes.
