dwarf-expert

DWARF expert

Contract

Inputs

• A binary, object file, or dSYM bundle to inspect (required for query, search, and verification work; not required for pure standard-explanation questions).
• The query surface: a DIE name or address to look up, an attribute or type predicate to filter, a structural query, an integrity-verification request, a DWARF-standard question, or a parser-development request.
• Optional: target DWARF version, compiler, or optimization level when relevant to verification or quality comparison.

Procedure

1. Identify the tool implementation and platform before running anything. Run dwarfdump --version first: a bare dwarfdump may be libdwarf's or LLVM's, and the options below are LLVM's. On macOS, linked Mach-O executables do not carry DWARF; it stays in .o files until dsymutil collects it into a .dSYM bundle; point the tool at the dSYM or object files, not the executable. pyelftools is ELF-only, so for Mach-O scripted work stay with the LLVM tools. Done when: the tool implementation and platform are identified.
2. Prefer dwarfdump over readelf for DWARF-specific work. Use readelf --debug-dump=<section> (with --dwarf-depth=<n> / --dwarf-start=<n> to limit depth or start offset) only for general ELF structure or when dwarfdump is unavailable. Done when: the appropriate tool is selected for the query type.
3. For a name or address match, escalate: try --find=<name> (accelerator-table exact lookup, fast but not exhaustive) first, fall back to --name=<pattern> (--ignore-case, --regex available) for exhaustive DIE-name search, and use --lookup=<address> to find the DIE covering a program address. Done when: the name or address is found or the escalation ladder is exhausted with a not-found report.
4. For an attribute or type query (e.g. all parameters of type float *), dump and filter: grep -B 1 <pattern> pulls in the header line carrying each DIE's offset, then print each DIE at its offset with --debug-info=<offset> --show-children (--lookup takes a program address, not a DIE offset). Use --show-children / --show-parents (with --recurse-depth / --parent-recurse-depth) to include child or parent DIEs, and --show-form when attribute encoding details matter. Done when: every matching DIE is printed with its offset and the requested children/parents/forms.
5. For a multi-attribute or structural query where grep pipelines turn brittle, write a Python script using pyelftools only if the user has explicitly requested a script or parser; otherwise, continue dumping and filtering and report the findings without creating code. Done when: the structural query is resolved, either with a pyelftools script (if requested) or a terminal report.
6. For integrity verification, run llvm-dwarfdump --verify <binary> for structural checks (unit chains, DIE relationships, address ranges); control detail with --error-display=<quiet|summary|details|full>, write a machine-readable summary with --verify-json=<path>, and use --quiet for exit-code-only checks. Run llvm-dwarfdump --statistics <binary> for debug-info quality metrics as JSON to compare across compiler versions or optimization levels. Verify after producing DWARF (compilers, binary rewriters), when a debugger misbehaves on a binary, and when developing DWARF tooling against known-good files. Done when: the --verify exit code and error detail are reported, and --statistics JSON is produced when quality comparison was requested.
7. When a current-generation compiler emitted an old DWARF version, the build explicitly passed -gdwarf-N; modern gcc and clang default to v4/v5, so check the build system rather than assuming a toolchain default. GCC embeds its flags in DW_AT_producer (the pin is often readable there); clang's producer string carries no flags. Old versions read the same way apart from surface forms: in v2 output, member offsets appear as location expressions (DW_OP_plus_uconst) and linkage names as DW_AT_MIPS_linkage_name. Done when: the DWARF version is confirmed from the build system or producer string.
8. For a DWARF-standard question where precision matters, look the detail up instead of answering from memory, escalating through authoritative sources: dwarfstd.org (the official specification; web-search specific sections), LLVM's llvm/lib/DebugInfo/DWARF/ (DWARFDie.cpp, DWARFUnit.cpp, DWARFDebugLine.cpp, DWARFVerifier.cpp as a reference implementation), and libdwarf at github.com/davea42/libdwarf-code (the reference C implementation). Done when: the question is answered with a citation naming which source answered it.
9. For an explicitly requested parser, prefer an existing library over parsing by hand: libdwarf (C/C++, low-level, used to implement dwarfdump), pyelftools (Python, also parses ELF), gimli paired with object (Rust, to load container files), debug/dwarf (Go standard library), or LibObjectFile (.NET, also handles ELF/PE). Default to Python with pyelftools for one-off scripts unless the task dictates otherwise. Done when: the parser is implemented using a named library.
10. In every search, verification, and parser, handle the DWARF-specific pitfalls: attributes are optional (a DIE may omit DW_AT_name, DW_AT_type, ranges); attribute indirection resolves through DW_AT_abstract_origin (inlined instances) and DW_AT_specification (out-of-line definitions) before concluding data is absent; and type chains walk DW_AT_type links through qualifiers and modifiers (DW_TAG_const_type, DW_TAG_pointer_type, ...) to reach the base type. Done when: optional attributes, abstract-origin/specification indirection, and wrapped type chains are handled in every search, verification, and parser.