[Bug binutils/27387] [readelf] Support -ggdb3 -gsplit-dwarf output

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=27387

--- Comment #14 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Nick Clifton from comment #13)
> Hi Tom,
> 
> > >         .section        .debug_macro.dwo,"e",@progbits
> > >         .value  0x4     # DWARF macro version number
> 
> I think that this may be a clue.  It looks like the assembler is creating
> version 4 .debug_macro.dwo sections, but the DWARF-5 standard only defines
> version 5 sections.  Ie, the assembler is for a proposed GNU extension to
> DWARF, rather than for an official DWARF-5 version.
> 
> I think that this matters because of the following bytes:
> 
> [This is from the second .debug_macro.dwo section in hello.s, as this
> is simpler):
> 
>       .value  0x4     <= version
>       .byte   0       <= flags
>       .byte   0x5
>       .uleb128 0x13
>       .uleb128 0x2a4
> 
> According to my reading of section 6.3.1 there ought to be *two* bytes
> following the flags, and before the first LEB128 value:
> 
>   "The table starts with a 1-byte count of the defined opcodes, 
>    followed by an entry for each of those opcodes. Each entry 
>    starts with a 1-byte unsigned opcode number ..."
> 
> And then only one LEB128 value for each entry:
> 
>    "... followed by unsigned LEB128 encoded number of operands
>     and for each operand there is a single unsigned byte 
>     describing the form in which the operand is encoded."
> 

Um, let's regenerate with -dA:
...
        .section       
.debug_macro.dwo,"G",@progbits,wm4.stdcpredef.h.19.006d14bbbe0dc07ba9\
b1ce3fdc8e40d3,comdat
.Ldebug_macro1:
        .value  0x4     # DWARF macro version number
        .byte   0       # Flags: 32-bit
        .byte   0x5     # Define macro strp
        .uleb128 0x13   # At line number 19
        .uleb128 0x2a4  # The macro: "_STDC_PREDEF_H 1"
...

So, I think the header stops after flags, and the actual contents starts at
.byte 0x5, which is described by the standard like so:
...
 Each macro unit starts with a header and is followed by a series of macro
information entries or file inclusion entries. Each entry consists of an opcode
followed by zero or more operands. Each macro unit ends with an entry
containing an opcode of 0.
...
So, the opcode is 0x5 (DW_MACRO_define_strp), and the two .uleb128 are the
operands of.

I think what is throwing your parsing off is that you're using the description
of the opcode_operands_table to parse the macro information entries.  But
there's no opcode_operands_table, because the corresponding flag
opcode_operands_table_flag is 0.

-- 
You are receiving this mail because:
You are on the CC list for the bug.