Analyzes DWARF debug information in compiled binaries. Use when inspecting .debug_* sections, DIE trees, or DW_TAG_/DW_AT_ entries with dwarfdump/llvm-dwarfdump or readelf, verifying debug info with llvm-dwarfdump --verify, answering DWARF standard questions, or writing code that parses DWARF (libdwarf, pyelftools, gimli).
インストールする前に、エージェントに与えられる指示の中身を確認できます。
Expertise for DWARF debug info: parsing and searching it, verifying its integrity, answering questions about the standard, and writing code that consumes it. Out of scope: runtime debugging (use gdb/lldb), reverse engineering beyond the DWARF sections (use Ghidra/IDA), and compiler-specific DWARF generation bugs.
When precision matters, look standard details up instead of answering from memory:
llvm/lib/DebugInfo/DWARF/ is a reliable reference implementation:
DWARFDie.cpp (DIE and attribute access), DWARFUnit.cpp (compilation units),
DWARFDebugLine.cpp (line tables), DWARFVerifier.cpp (validation).Prefer dwarfdump over readelf for DWARF-specific work. Two implementations
exist — libdwarf's dwarfdump and LLVM's llvm-dwarfdump — with different
options, and a bare dwarfdump command may be either: check dwarfdump --version
first. The options below are LLVM's.
On macOS, linked Mach-O executables do not carry DWARF: it stays in the .o
files until dsymutil collects it into a .dSYM bundle. Point dwarfdump at
the dSYM (or the object files), not the executable. pyelftools is ELF-only —
for Mach-O scripted work, stay with the LLVM tools.
--all: dump every DWARF section; --debug-info, --debug-line, etc. dump one--show-children [--recurse-depth=<n>]: include child DIEs when printing
selected entries — parameters, locals, and struct members are children of
function and type DIEs--show-parents [--parent-recurse-depth=<n>]: include parent DIEs--show-form: print attribute form types, for when encoding details matter--find=<name>: exact-name lookup via the accelerator tables — fast but not
exhaustive; fall back to --name when it misses--name=<pattern> [--ignore-case] [--regex]: exhaustive DIE-name search--lookup=<address>: find the DIE covering an address--verbose: print low-level encoding detailEscalate through these strategies as the query grows more complex:
--find, then --name; --lookup for addresses.float *): dump and
filter. grep -B pulls in the header line carrying each DIE's offset:
llvm-dwarfdump file | grep -B 5 "float \*" | grep DW_TAG_formal_parameter,
then print each DIE at its offset with --debug-info=<offset> --show-children
(--lookup takes a program address, not a DIE offset).pyelftools instead.llvm-dwarfdump --verify <binary>: structural checks (unit chains, DIE
relationships, address ranges). --error-display=<quiet|summary|details|full>
controls detail; --verify-json=<path> writes a machine-readable error
summary; --quiet for exit-code-only checks.llvm-dwarfdump --statistics <binary>: debug-info quality metrics as JSON —
compare across compiler versions or optimization levels to catch regressions.Verify after producing DWARF (compilers, binary rewriters), when a debugger misbehaves on a binary, and when developing DWARF tooling against known-good files.
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, so the pin is often readable right there; clang's producer
string carries no flags. Old versions remain common in the wild and 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.
For general ELF structure, or when dwarfdump is unavailable:
--debug-dump=<section>: dump a DWARF section (info, line, ...)--dwarf-depth=<n> / --dwarf-start=<n>: limit DIE depth / start offsetPrefer an existing library over parsing by hand:
| Library | Language | Notes |
|---|---|---|
libdwarf | C/C++ | github.com/davea42/libdwarf-code — low-level; used to implement dwarfdump |
pyelftools | Python | github.com/eliben/pyelftools — also parses ELF in general |
gimli | Rust | github.com/gimli-rs/gimli — pair with object to load container files |
debug/dwarf | Go | standard library |
LibObjectFile | .NET | github.com/xoofx/LibObjectFile — also handles ELF/PE object files |
Default to Python with pyelftools for one-off scripts unless the task dictates
otherwise.
DWARF-specific pitfalls to handle — and to check for when reviewing DWARF code:
DW_AT_name, DW_AT_type, ranges, etc.DW_AT_abstract_origin (inlined instances) or DW_AT_specification
(out-of-line definitions) — resolve the chain before concluding data is absent.DW_TAG_const_type,
DW_TAG_pointer_type, ...) wrap the underlying type; walk DW_AT_type links to
reach the base type.まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
Builds and runs code under AddressSanitizer to catch buffer overflows, use-after-free, and other memory errors during fuzzing or tests. Covers -fsanitize=address builds, ASAN_OPTIONS, reading the crash report, LeakSanitizer, and the overhead and platform trade-offs. Use when fuzzing C/C++ or Rust that has unsafe blocks or FFI, when debugging a memory corruption crash, or when reading an ASan stack trace.
日本語の概要は準備中です。原文の説明を表示しています。
Sets up and runs AFL++ for multi-core fuzzing of C/C++ projects built with afl-clang-fast or afl-gcc-fast. Covers instrumentation modes, parallel main and secondary campaigns, persistent mode, corpus minimization, and crash triage. Use when scaling fuzzing across cores, fuzzing a mature C/C++ codebase, reading the afl-fuzz status screen, or moving on after libFuzzer has plateaued.
日本語の概要は準備中です。原文の説明を表示しています。
Audits GitHub Actions workflows for security vulnerabilities in AI agent integrations including Claude Code Action, Gemini CLI, OpenAI Codex, and GitHub AI Inference. Detects attack vectors where attacker-controlled input reaches AI agents running in CI/CD pipelines, including env var intermediary patterns, direct expression injection, dangerous sandbox configurations, and wildcard user allowlists. Use when reviewing workflow files that invoke AI coding agents, auditing CI/CD pipeline security for prompt injection risks, or evaluating agentic action configurations.
日本語の概要は準備中です。原文の説明を表示しています。
Scans Algorand smart contracts for 11 common vulnerabilities including rekeying attacks, unchecked transaction fees, missing field validations, and access control issues. Use when auditing Algorand projects (TEAL/PyTeal).
日本語の概要は準備中です。原文の説明を表示しています。
Sets up and runs Atheris, the coverage-guided Python fuzzer built on libFuzzer. Covers TestOneInput harnesses, FuzzedDataProvider, instrumenting both pure Python and native C extensions, and running under AddressSanitizer. Use when fuzzing a Python package, hunting memory corruption in a Python C extension, or choosing between Atheris and Hypothesis for a Python target.
日本語の概要は準備中です。原文の説明を表示しています。
Augments Trailmark code graphs with external audit findings from SARIF static analysis results, weAudit annotation files, and version-gated Trailmark 0.4.x binary-analysis graph exports. Maps findings to graph nodes by file and line overlap, creates severity-based subgraphs, and enables cross-referencing findings with pre-analysis data (blast radius, taint, etc.). Use when projecting SARIF results onto a code graph, overlaying weAudit annotations, importing binary graph findings, cross-referencing Semgrep, CodeQL, or binary-analysis findings with call graph data, or visualizing audit findings in the context of code structure.
日本語の概要は準備中です。原文の説明を表示しています。