最可靠方式是调用libdwfl（elfutils），它自动处理DWARF各节交叉引用并兼容stripped二进制；需确保含.debug_line段或配置debuginfod，地址须为运行时虚拟地址，且注意优化导致的行号漂移与伪指令地址陷阱。
用 libdwfl 解析 DWARF 获取地址到行号映射最可靠
直接调用 libdwfl（来自 elfutils）是 Linux 下最稳定的方式，它自动处理 .debug_line、.debug_info、.debug_abbrev 等节的交叉引用，也兼容 stripped 二进制（只要保留了调试段或有 separate debug file）。别自己手撸 dwarf_nextcu + dwarf_srclines 组合——容易漏掉编译单元切换、line number program reset、prologue length 解析错误等问题。
关键前提：目标二进制必须含 .debug_line 段，或通过 debuginfod / build-id 找到外部调试文件。用 readelf -S binary | grep debug_line 快速确认。
-
dwfl_begin()后必须调用dwfl_report_elf()或dwfl_report_offline()，否则dwfl_getsrc() / dwfl_lineinfo()全部返回空 - 地址需是“运行时虚拟地址”（VMA），不是文件偏移；若查的是 core dump 或 perf record 地址，得先用
dwfl_addrmodule()定位模块，再用dwfl_module_relocate_address()转成模块内偏移 - 一个地址可能对应多行（如内联展开、模板实例化），
dwfl_lineinfo()默认只返回第一条；要全量，得循环调用dwfl_linesrc()+dwfl_lineaddr()配合dwfl_line_next()
gdb 的 Python API 可快速验证但不能用于生产反查
在调试现场用 gdb -batch -ex "info line *0x401234" binary 或 Python 脚本调用 gdb.find_pc_line() 很方便，但它依赖 gdb 正在加载的符号和调试信息状态，且无法嵌入到非交互式工具链中。尤其当二进制被 strip 且未配置 debuginfod-url 时，gdb 会静默失败，不报错也不返回行号。
-
gdb.find_pc_line(0x401234)返回的symtab字段可能为None，需显式判空，不能直接取.filename - gdb 内部用的是自己的 DWARF 解析器（
gdb/dwarf2read.c），与 libdwfl 行为不完全一致；比如对 GCC 的-grecord-gcc-switches生成的 DW_AT_GNU_dwo_id 处理逻辑不同 - 不要在子进程中反复 fork+exec gdb 来查地址——启动开销大，且并发高时易触发 gdb 的 symbol cache 锁竞争
注意编译器优化导致的行号漂移问题
即使 DWARF 解析完全正确，0x401234 查出来的行号也未必是程序员写的那行。GCC/Clang 在 -O2 及以上会重排指令、内联、循环展开，导致机器码地址落在某行的“逻辑中间”，甚至跨多行。DWARF 的 DW_LNS_set_prologue_end 和 DW_LNE_epilogue_begin 标记能缓解，但无法消除。
立即学习“C++免费学习笔记（深入）”；
- 用
objdump -l -d binary | grep -A5 '401234:'对照汇编，看该地址实际执行哪条指令，再结合gcc -g -O2 -S生成的 .s 文件人工比对 - 若需精准追踪，编译时加
-grecord-gcc-switches -gstrict-dwarf，避免 GCC 插入非标准扩展属性干扰解析 - Clang 的
-fdebug-info-for-profiling会增强行号映射粒度，但仅对采样分析友好，不提升单地址反查精度
常见错误：地址查不到行号却没报错
典型现象是 dwfl_lineinfo() 返回 0，但 dwfl_errno() 是 DWFL_E_NOERROR——这表示“地址有效但无源码映射”，不是解析失败。原因通常是：
- 该地址属于 PLT、.plt.sec、.init_array 等无源码区域，
dwfl_module_addrsym()可辅助判断是否为符号地址 - 调试信息中该地址落在
line number program的special op区间外，例如函数 prologue 中尚未设置is_stmt标志 - 使用了
-gsplit-dwarf，但dwfl未配置dwfl_standard_find_debuginfo回调去加载 .dwo 文件
真正难缠的是那些编译器生成的“伪指令地址”（如 call __stack_chk_fail 插桩点），它们有 DWARF 描述，但源码行号指向 __stack_chk_fail 的声明而非调用处——这时候得回溯 call 指令前一条的地址，再查行号。
