DWARF debug information: Additional byte generated in element inside debug_info

Question

I am fixing a bug in a parser for DWARF debug information (2nd DWARF version). In the process I made the following strange observation:

A bytestream was created by reading a dll file (created with ada files by GNAT). At the position of a "DW_TAG_structure_type" in debug_info inside this bytestream an additional byte with the value 1 has crept into the byte stream. Thereby all values in the FileInputStream are shifted by 1 byte.

This is how the original DIE in .debug_info looks like:

 <1><3aa824>: Abbrev Number: 129 (DW_TAG_structure_type)
    <3aa826>   DW_AT_byte_size   : 44   
    <3aa827>   DW_AT_decl_file   : 11   
    <3aa828>   DW_AT_decl_line   : 380  
    <3aa82a>   DW_AT_artificial  : 1    
    <3aa82b>   DW_AT_sibling     : <0x3aa888>

This is the corresponding scheme for the DIE in .debug_abbrev:

129      DW_TAG_structure_type    [has children]
    DW_AT_byte_size    DW_FORM_data1
    DW_AT_decl_file    DW_FORM_data1
    DW_AT_decl_line    DW_FORM_data2
    DW_AT_artificial   DW_FORM_flag
    DW_AT_sibling      DW_FORM_ref4
    DW_AT value: 0     DW_FORM value: 0

However, when I display the bytestream at this point, these values are shown:

Abbrev Number  >>Strange Byte<<  DW_AT_byte_size  DW_AT_decl_file
     81               01                2C              0B         ...
    (129)             ??               (44)            (11)

Does anyone know what this "Strange Byte" is all about?

Answer 1

Not really familiar with DWARF, but the DWARF 2.0 specification reads (section 7.5.3):

Following the tag encoding is a 1-byte value that determines whether a debugging information entry using this abbreviation has child entries or not. If the value is DW_CHILDREN_yes, the next physically succeeding entry of any debugging information entry using this abbreviation is the first child of the prior entry. If the 1-byte value following the abbreviation’s tag encoding is DW_CHILDREN_no, the next physically succeeding entry of any debugging information entry using this abbreviation is a sibling of the prior entry. [...]

Finally, the child encoding is followed by a series of attribute specifications. [...]

So, could this "strange byte" represent DW_CHILDREN_yes?

I'm also a little bit puzzled by the value 0x81 (129). The specification states that the tag encoding for DW_TAG_structure_type is 0x13 (which should fit in a byte), and the previous quote suggests that the tag encoding is followed by a byte that is not part of the tag encoding itself (if I understand correctly). So I would expect a stream of 0x13 0x01 (encoded tag + has child entries flag).