我正在修复DWARF调试信息解析器中的一个错误(第二个DWARF版本(。在这个过程中，我做出了以下奇怪的观察：
字节流是通过读取dll文件创建的(由GNAT使用ada文件创建(。在"a"的位置；DW_ TAG_ structure_type；在这个字节流中的debuginfo中，一个值为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)
有人知道这是什么吗；奇异字节"；都是关于？
不太熟悉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(编码标记+具有子条目标志(的流。