clang编译文件.debug_line段出现大量行号0的原因及对应编译选项查询

问题现象 #

近期使用clang编译的文件中，出现了大量地址对应的行号为0的情况，llvm-dwarfdump的输出结果如下：

Address            Line   Column File   ISA Discriminator Flags
------------------ ------ ------ ------ --- ------------- -------------
0x0000000000000000    287      0      4   0             0  is_stmt
0x0000000000000030    287      0      4   0             0  is_stmt prologue_end
**0x0000000000000034      0      0      4   0             0**
0x0000000000000038    293      2      4   0             0  is_stmt
**0x0000000000000060      0      2      4   0             0**
0x0000000000000064    300      6      4   0             0  is_stmt
0x000000000000006c    295     38      4   0             0  is_stmt
0x0000000000000070    297     14      4   0             0  is_stmt
0x0000000000000074    300      6      4   0             0  is_stmt
0x0000000000000078    300      6      4   0             0
0x000000000000007c      0      6      4   0             0
0x0000000000000080    301      3      4   0             0  is_stmt
0x0000000000000088      0      0      4   0             0
0x000000000000008c    301      3      4   0             0
0x0000000000000090    306     26      4   0             0  is_stmt
0x00000000000000a0    306     40      4   0             0
0x00000000000000a8    270     11      4   0             0  is_stmt
0x00000000000000ac    273     15      4   0             0  is_stmt
0x00000000000000b0    271     32      4   0             0  is_stmt
0x00000000000000b4    273     43      4   0             0  is_stmt

原因说明 #

该现象主要由**-O1及更高等级的编译优化选项**（包括-O2/-O3/-Os/-Oz）触发。
DWARF调试信息规范中，行号0专门用于标记无法对应到用户编写的源代码行的指令地址，这些指令都是编译器在优化过程中自动生成的，常见场景包括：

• 指令重排、寄存器分配优化后产生的零散无对应行的指令
• 优化后的函数序言、尾声代码
• 内联函数插入的桥接指令、跳转桩代码
• 循环展开、指令向量化生成的额外运行逻辑
  如果同时开启了-g1（等价于-gline-tables-only）选项，仅保留最基础的行号表调试信息，会进一步放大该现象：没有更细粒度的调试信息辅助关联生成代码到原代码位置，编译器会直接将这类地址标记为行号0。

解决方案 #

如果需要消除这类行号0的记录，可以选择以下任意一种调整方式：

• 把优化等级降低到-O0，关闭所有编译优化
• 改用-g2或者-g3选项生成更完整的调试信息，部分原本标记为行号0的地址会被重新关联到对应的源码行

内容的提问来源于stack exchange，提问作者joey jiao