0

我正在修复 DWARF 调试信息（第二个 DWARF 版本）解析器中的错误。在这个过程中，我做了以下奇怪的观察：

通过读取 dll 文件（由 GNAT 使用 ada 文件创建）来创建字节流。在此字节流内的 debug_info 中的“DW_TAG_structure_type”位置，一个值为 1 的附加字节已潜入字节流。因此 FileInputStream 中的所有值都移动了 1 个字节。

这是 .debug_info 中原始 DIE 的样子：

 <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>

这是 .debug_abbrev 中 DIE 的对应方案：

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

但是，当我此时显示字节流时，会显示这些值：

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

有谁知道这个“奇怪的字节”是什么意思？

4

1 回答 1

0

不太熟悉 DWARF，但DWARF 2.0 规范中写道（第 7.5.3 节）：

标记编码之后是一个 1 字节的值，用于确定使用此缩写的调试信息条目是否具有子条目。如果值为DW_CHILDREN_yes，则使用此缩写的任何调试信息条目的下一个物理后续条目是先前条目的第一个子条目。如果缩写标记编码之后的 1 字节值是DW_CHILDREN_no，则使用此缩写的任何调试信息条目的下一个物理后续条目是先前条目的兄弟。[...]

最后，子编码之后是一系列属性规范。[...]

那么，这个“奇怪的字节”可以代表DW_CHILDREN_yes吗？

0x81我也对这个值（129）有点困惑。规范声明标签编码DW_TAG_structure_type是0x13（应该适合一个字节），并且前面的引用表明标签编码后面跟着一个不属于标签编码本身的字节（如果我理解正确的话）。所以我希望有一个0x13 0x01（编码标签+有子条目标志）流。

于 2022-01-26T21:34:09.097 回答