矮小调试信息:在debug_info内部的元素中生成的附加字节

Question

我正在修复解析器中的一个bug，以获取矮人调试信息(第二个侏儒版本)。在这个过程中，我做了以下奇怪的观察：

字节流是通过读取dll文件(由GNAT用ada文件创建)创建的。在这个字节流中的"DW_TAG_structure_type“位于debug_info中的位置，一个值为1的额外字节悄悄地进入了字节流。因此，FileInputStream中的所有值都被移动1字节。

.debug_info中的原始死模是这样的：

 <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中相应的模具方案：

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)

有人知道这个“奇怪的拜特”是怎么回事吗？

Answer 1

虽然不太熟悉矮人，但侏儒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流(编码标记+有子条目标志)。