readelf 怎么从 DWARF 行号表找到源码位置映射

当日志或崩溃信息只给出一个机器地址时，先别急着打开调试器。只要 ELF 仍保留 DWARF 的行号信息，就可以用 readelf --debug-dump=decodedline 读取地址、源文件和行号之间的静态映射。这个命令的关键不是“把地址翻译成任何源码”，而是读取编译阶段已经写入 .debug_line 的对应关系。

官方地址：https://sourceware.org/binutils/docs/binutils/readelf.html

最小用法是 readelf --debug-dump=decodedline --wide ./app，短写法是 readelf -wL --wide ./app。如果没有行号信息，反复更换输出参数也不会凭空得到源码位置。

先把 ELF 输入和调试信息分开看

这次排查的入口是一个 ELF 文件，而不是源代码目录。先确认文件类型，再检查它是否留下调试段：

# 先确认目标是 ELF，再查看是否存在行号调试段
file ./app
readelf --section-headers ./app | grep -E '\.debug_line|\.zdebug_line' || true

# 生成带 DWARF 行号信息的示例文件；-g 负责保留调试信息
cc -g -O0 -o app sample.c

这里的 -g 只是示例构建条件，不代表所有发行包都会保留调试信息。生产环境常见的情况是主程序被剥离，但调试信息被放在独立文件中；因此“程序能运行”和“readelf 能显示源码行”是两件事。

readelf --debug-dump=decodedline 到底读出了什么

GNU Binutils 文档把 --debug-dump=decodedline 定义为显示解释后的 .debug_line 内容，-wL 是对应的简写。实际阅读时，把输出看成一组行记录：地址是机器代码位置，文件和行号是编译器写入的源码位置，列号与 is_stmt、basic_block 等状态则提供更细的边界提示。

# 只读取解释后的 DWARF 行号表，并让长路径尽量保持在一行
readelf --debug-dump=decodedline --wide ./app

# 需要脚本处理时使用短选项；输出仍然是静态行号映射
readelf -wL --wide ./app

示意输出可能包含类似下面的列：

CU: sample.c:
File name                            Line number    Starting address
sample.c                                      4              0x1129
sample.c                                      5              0x1134

不要把上面的地址当成“函数入口”或把每一行都当成唯一指令。优化、内联、宏和编译器生成的多个地址都可能让一段源码对应多条记录；decodedline回答的是“这个地址在行号表中对应哪里”，不是完整的反汇编结果。

把地址、文件和行号组成一个可执行判断

如果外部日志给了地址 0x1129，就先在 decodedline 输出中找同一地址或覆盖它的记录，再读取同一条记录的文件名和行号。最稳妥的判断顺序是：

这也是自动化流水线里应该设置的门禁：先判断字段是否存在，再把地址和源码位置存入诊断结果，最后才决定是否需要源代码或独立调试文件。不要把“路径打不开”与“地址没有映射”混为一谈。

空输出时按门禁顺序排查

decodedline 没有有效记录时，优先检查输入状态，而不是连续尝试一串无关选项。先看 section 表里是否有 .debug_line 或压缩形式，再确认构建是否使用了 -g，最后检查是否存在可跟随的独立调试信息。readelf 对压缩调试段可以在显示时临时解压，但它不能恢复已被删除的段。

# 只跟随已有的独立调试信息链接，避免把“没有链接”误判成参数错误
readelf --debug-dump=decodedline --follow-links ./app

# 若需要明确禁止跟随链接，可用 no-follow-links 对比主文件本身
readelf --debug-dump=decodedline --no-follow-links ./app

如果主文件已经被剥离，第一条命令仍然可能没有行号记录；这时应回到构建产物管理，找到与该 ELF 匹配的调试文件。若记录里的源文件路径与当前工作区不同，映射本身仍可能有价值，只是不能直接用这个路径打开文件。

一份简短的使用边界

• 能解决：从 ELF 的 DWARF 行号表读取地址到文件、行号的静态对应关系。
• 不能替代：反汇编、符号解析、调试器断点和运行时调用栈采集。
• 排查优先级：先看调试段，再看独立调试链接，最后处理源码路径迁移。

常见问题

为什么 readelf -wL 没有输出？通常是 ELF 没有保留 .debug_line，或者调试信息在独立文件中而当前输入没有可用链接；先检查 section 表。

行号能看到，但源码文件不存在怎么办？这只说明编译时记录的路径当前不可用，不等于地址映射无效。找到匹配源码或用构建系统保存的路径映射继续定位即可。

为什么同一个源码行出现多个地址？一行源码可能生成多条机器指令，优化和编译器布局都会影响记录数量；应把它当作地址集合，而不是一对一关系。