libdwarf 是解析 DWARF 最稳定的选择，封装节定位、LEB128 解码、DIE 遍历等细节，需正确调用 dwarf_init、dwarf_next_cu_header_c 等核心函数，避免手动 mmap .debug_info；须检查调试信息存在性、CU 类型、地址属性（优先 DW_AT_ranges）、类型引用链及构建配置（如 -gstrict-dwarf）。
用 libdwarf 读取 .debug_info 节最直接
libdwarf 是目前 C++ 生产环境中解析 DWARF 最稳定的选择，比手撕 ELF + 解码 DWARF 更靠谱。它封装了节定位、LEB128 解码、DIE 遍历等底层细节，你只需关注 dwarf_init、dwarf_next_cu_header_c、dwarf_siblingof 这几个核心函数。
常见错误是直接 mmap .debug_info 段然后硬解——DWARF 各版本（v2/v3/v4/v5）的 header 结构、属性编码规则差异很大，手动处理极易崩溃或漏字段。libdwarf 内部会根据 .debug_abbrev 和 .debug_str 自动关联缩写表和字符串池，跳过这步基本等于重写半个 dwarf-dump。
实操建议：
- 链接时加
-ldwarf -lelf（Linux），macOS 上需用brew install dwarves或自己编译 libdwarf - 初始化必须检查
dwarf_open返回值，某些 stripped 二进制可能缺失.debug_info但保留.debug_line，此时dwarf_init会失败而非静默跳过 - 遍历 CU（Compilation Unit）前先调用
dwarf_get_die_infotypes确认是否含 DW_TAG_compile_unit，避免把 .debug_types 当主 CU 处理
提取函数名和地址范围得靠 DW_AT_low_pc / DW_AT_high_pc
DWARF 中函数符号不存于 .symtab，而是嵌套在 DW_TAG_subprogram DIE 里，靠 DW_AT_name + 地址属性定位。但注意：DW_AT_low_pc 不一定等于函数入口地址——它可能是优化后内联展开的起始偏移，也可能是被 DW_AT_ranges 替代的旧式单区间表示。
立即学习“C++免费学习笔记（深入）”；
实操建议：
- 优先检查是否存在
DW_AT_ranges属性，有则用dwarf_get_ranges解析，它支持不连续代码块（如死代码剥离后的空洞） -
DW_AT_low_pc值是相对text段基址的偏移，需结合readelf -S查出.text的sh_addr才能还原真实地址 -
DW_AT_name可能为空（C++ 模板实例化或匿名命名空间函数），此时要 fallback 到DW_AT_MIPS_linkage_name或DW_AT_specification回溯声明点
解析 C++ 类型信息时小心模板和 typedef 链
libdwarf 不自动展开类型别名或模板参数，DW_TAG_typedef 和 DW_TAG_template_type_param 都是独立 DIE，需要手动 dwarf_attr + dwarf_formref 跳转。比如 std::vector<int> 在 DWARF v4 里通常拆成 DW_TAG_class_type → DW_TAG_template_type_param → DW_TAG_base_type 三级引用。
实操建议：
- 不要依赖
DW_AT_name直接拼接类型名，std::basic_string<char>可能被记为string或完整 mangled 名，应优先读DW_AT_type引用再递归解析 - 遇到
DW_TAG_structure_type且无DW_AT_name，大概率是匿名 struct 或 lambda 捕获类，需检查DW_AT_decl_file+DW_AT_decl_line定位源码上下文 - libdwarf v20191107+ 支持
dwarf_get_die_type_name辅助函数，但它不处理模板特化，仍需自己 walkDW_TAG_template_value_param
调试信息缺失时先确认 build 配置和 strip 行为
很多“解析不到函数”问题其实和 libdwarf 无关：GCC/Clang 默认只在 -g 下生成 DWARF，而 -g1 会删掉 .debug_info 里的局部变量和内联信息；strip --strip-debug 会清空所有 .debug_* 节，但保留 .symtab；strip -g 才真正删调试段。运行 file binary 和 readelf -S binary | grep debug 是最快验证手段。
实操建议：
- 构建时显式加
-gstrict-dwarf -gdwarf-4，避免 GCC 自动降级到 v2（某些旧版 binutils 不兼容 v5） - Android NDK r21+ 默认用 DWARF v5，但 libdwarf 主干尚未完全支持
.debug_sup（supplementary object），解析时需禁用该特性或降级到 v4 - 如果目标文件是 PIE 可执行体，
DW_AT_low_pc值是 load-time 相对地址，需配合/proc/pid/maps计算实际运行地址，不能直接当绝对地址用
真正麻烦的是跨工具链场景：LLVM-generated DWARF 和 GCC-generated DWARF 在 DW_AT_location 表达式语义上存在细微差异，比如寄存器编号映射或 stack value 计算顺序。这时候光看 spec 不够，得用 dwarfdump --debug-info 对比原始输出，再反推 libdwarf 的 attr 解析逻辑是否匹配。
