[Bug target/82005] [8 regression] early lto debug creates invalid assembly on Darwin

["rguenther at suse dot de" <gcc-bugzilla at gcc dot gnu dot org>]

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-bugzilla@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.