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?
.. 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?
(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 ?
