libdwarf 是最稳定、文档清晰的 c/c++ dwarf 解析库，读取 .debug_line 行表需正确初始化、定位 cu、循环遍历行记录，并注意 dwarf5 的目录/文件索引机制。
用 libdwarf 读取 DWARF 行表（.debug_line）
libdwarf 是目前最稳定、文档相对清晰的 C/C++ DWARF 解析库，比直接解析 ELF + .debug_line 段安全得多。行表的核心是把机器指令地址映射回源码文件名、行号、列号，调试器断点和单步依赖它。
常见错误是没正确初始化 dwarf_init 或忽略 DW_DLC_READ 标志，导致后续调用返回 DW_DLV_NO_ENTRY；另一个坑是误以为 dwarf_srclines 一次就能拿到全部行记录——实际它只返回一个 Dwarf_Lines 句柄，需配合 dwarf_lineinfo 循环遍历。
- 确保 ELF 文件编译时带
-g且未 strip：readelf -S binary | grep debug_line应有输出 - 调用
dwarf_srclines前必须先用dwarf_get_die_list或dwarf_next_cu_header定位到 CU（Compilation Unit），否则行表可能为空 - 每条行记录的
dwarf_lineno返回的是“逻辑行号”，不是物理文件行号（宏展开、#line指令会影响它） - 列号（
dwarf_linecol）常为 0，因多数编译器不写入精确列信息；若需定位表达式，应结合.debug_ranges或.debug_aranges
从 DIE 中提取局部变量名与类型（DW_TAG_variable / DW_TAG_formal_parameter）
DWARF 变量信息分散在多个属性中，不能只看 DW_AT_name：它可能缺失（如优化后的匿名寄存器变量），或指向编译器生成的内部符号（如 .LFB123）。真正可靠的是 DW_AT_location + DW_AT_type 组合。
典型错误是直接对 DW_AT_type 的 offset 做裸偏移解引用——必须用 dwarf_offdie 转成有效 DIE，再递归解析类型定义（DW_TAG_base_type、DW_TAG_pointer_type 等）。
-
DW_AT_location的值可能是DW_FORM_block（位置描述符字节码），需用dwarf_get_location解析，而非当成地址直接读 - 结构体成员变量通常嵌套在
DW_TAG_structure_type下，其DW_AT_data_member_location是相对于结构体起始的字节偏移，不是绝对地址 - 模板实例化变量（如
std::vector<int>::size</int>）的DW_AT_name可能含空格或括号，需完整提取，不能简单按空格切分 - 优化级别 ≥ -O2 时，
DW_TAG_variable可能被完全删除，仅剩DW_TAG_lexical_block内的DW_TAG_GNU_call_site类似信息
处理 DWARF5 新特性：.debug_line 的目录/文件索引与增量更新
DWARF5 行表引入了目录索引（include_directories）和文件索引（file_names）表，不再像 DWARF4 那样把完整路径硬编码进每条记录。若用旧版 libdwarf（dwarf_lineno 可能返回 0，dwarf_srcfiles 返回空数组。
关键点在于：DWARF5 行表头部的 directory_entry_format 和 file_name_entry_format 字段决定了如何解释后续数据块，不能跳过解析。
- 检查
dwarf_get_version返回值是否 ≥ 5，再决定是否启用DW_DLC_USE_DWARF5初始化标志 -
dwarf_srcfiles在 DWARF5 下返回的是“索引数组”，需用dwarf_filesrc传入索引查具体路径，而非直接当字符串数组用 - 增量编译（如 LTO 或 split DWARF）会导致
.debug_line.dwo单独存在，主 ELF 中只有DW_AT_stmt_list指向外部段，此时必须用dwarf_set_alt_dwarf加载对应 dwo 文件 - Clang 默认生成 DWARF5（除非加
-gdwarf-4），GCC 12+ 也默认 DWARF5，生产环境务必验证 libdwarf 版本兼容性
避免 segfault 的底层细节：DIE 生命周期与内存管理
libdwarf 的 DIE（Debugging Information Entry）是轻量句柄，背后指向内部缓冲区。常见 crash 来自：在 dwarf_finish 后继续使用之前获取的 Dwarf_Die，或对同一个 Dwarf_Debug 并发调用不同线程的 dwarf_offdie。
没有显式“释放 DIE”的 API，所有 DIE 生效范围严格绑定于其所属的 Dwarf_Debug 实例生命周期。一旦 dwarf_finish，所有相关指针立即失效。
- 不要缓存
Dwarf_Die指针跨函数调用，尤其不要存在全局 map 或 vector 中 - 若需长期持有变量信息，应提前用
dwarf_diename、dwarf_attr+dwarf_formstring提取字符串副本，或用dwarf_offdie重新定位 - 多线程解析不同 ELF 文件时，每个线程必须创建独立的
Dwarf_Debug，libdwarf 不保证线程安全 -
DW_DLC_STREAM_REWIND标志看似能重用Dwarf_Debug，但实际会清空内部缓存，反复初始化开销大，不如为每个文件新建实例
真正难的不是读出变量名或行号，而是理解 DWARF 是一种“描述性语言”而非“数据序列”：同一语义（比如一个 int 局部变量）在不同编译器、不同优化等级、不同 DWARF 版本下，可能由完全不同的 DIE 结构树表达。硬编码假设任何字段必存在，几乎必然失败。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
