LLVM-DWARFDUMP(1)

โœจ LLVM-DWARFDUMP โœจ

okay bestie, gather round, because this is the llvm-dwarfdump page from the LLVM fam and it's about to be your new fave ๐Ÿซถ it dumps and verifies DWARF debug information, and honestly? iconic.


๐Ÿ’– NAME ๐Ÿ’–

llvm-dwarfdump โ€” dump and verify DWARF debug information. that's it. that's the whole job. and she does it beautifully ๐Ÿ’…


๐ŸŒธ SYNOPSIS ๐ŸŒธ

llvm-dwarfdump [options] [filename ...]

๐Ÿฆ‹ DESCRIPTION ๐Ÿฆ‹

so llvm-dwarfdump parses the DWARF sections hiding inside object files, archives, and .dSYM bundles, then prints their contents in a form that actual humans can read. main character behavior, truly. ๐ŸŽ€

and here's the tea: by default she only prints the .debug_info section. that's it. just that one. if you want more, you gotta ask โ€” either by naming specific section options or by hitting --all. no cap.

if you don't give her any input file at all, she'll just use a.out instead. and if you pass - as the input file? she reads the input straight from her standard input stream. flexible queen. โœจ


๐Ÿ’… OPTIONS ๐Ÿ’…

  • -a, --all โ€” dump every supported DWARF section. go big or go home.
  • --arch=<arch> โ€” dump DWARF debug info for the CPU architecture you name. you can specify architectures by name or by number (yes, either works, she's not picky). you can pass this option multiple times โ€” once per architecture you're obsessed with. by default, all CPU architectures get printed. ๐Ÿ’–
  • -c, --show-children โ€” show a debug info entry's children when you're selectively printing with the =<offset> argument of --debug-info, or with options like --find or --name. bring the whole family.
  • --color โ€” use colors in the output. aesthetics matter. ๐ŸŒˆ
  • --error-display=<value> โ€” sets how much detail and summary to show when verifying. this one implies --verify. the supported values are:
    • quiet โ€” only shows whether errors happened. that's all.
    • summary โ€” shows only a summary of the errors found.
    • details โ€” shows each error in detail, but no summary.
    • full โ€” shows each error and a summary. this is the [default].
  • -f <name>, --find=<name> โ€” search for the exact text <name> in the accelerator tables and print the matching debug info entries. heads up: if there are no accelerator tables, or your DIE's name just isn't in them, try the slower but way more complete --name option instead. she'll get there eventually, promise. ๐Ÿ˜ญ
  • -F, --show-form โ€” show DWARF form types after the DWARF attribute types. little extra detail, chef's kiss.
  • -h, --help โ€” show help and usage for this command. classic.
  • --help-list โ€” show help and usage, but without grouping the options into categories. flat list, no frills.
  • -i, --ignore-case โ€” ignore case distinctions when you're using --name. she's chill like that.
  • -n <name>, --name=<name> โ€” find and print all debug info entries whose name (that's the DW_AT_name/DW_AT_linkage_name attribute) matches <name>. ๐Ÿ”ฅ
  • --lookup=<address> โ€” look up <address> in the debug information and print out the file, function, block, and line table details. full detective mode.
  • -o <path> โ€” redirect output to the file specified by <path>, where - means the standard output stream. your output, your rules.
  • -p, --show-parents โ€” show a debug info entry's parents when selectively printing with the =<offset> argument of --debug-info, or with options like --find or --name. ancestry dot com but for DIEs.
  • --parent-recurse-depth=<N> โ€” when displaying debug info entry parents, only go to a maximum depth of <N>. gotta draw the line somewhere.
  • --quiet โ€” use this with --verify to not emit to STDOUT. silent but deadly. ๐Ÿ’€
  • -r <N>, --recurse-depth=<N> โ€” when displaying debug info entries, only show children to a maximum depth of <N>. don't go too deep bestie.
  • --show-section-sizes โ€” show the sizes of all the debug sections, expressed in bytes. ๐Ÿ“
  • --show-sources โ€” print all source files mentioned in the debug information. absolute paths are given whenever possible. she tries her best.
  • --statistics โ€” collect debug info quality metrics and print the results as machine-readable single-line JSON output. the format is described down in the FORMAT OF STATISTICS OUTPUT section, keep scrolling.
  • --summarize-types โ€” abbreviate the description of type unit entries. short and sweet.
  • -t, --filter-child-tag โ€” only dump children whose DWARF tag is one of the specified tags. example usage:
llvm-dwarfdump -t DW_TAG_structure_type -t DW_TAG_member -c
  • -x, --regex โ€” treat any <name> strings as regular expressions when searching with --name. and if --ignore-case is also specified, the regular expression becomes case-insensitive. regex girlies rise up ๐Ÿงš
  • -u, --uuid โ€” show the UUID for each architecture.
  • --diff โ€” dump the output in a format that's friendlier for comparing DWARF output from two different files. side by side, cutie.
  • -v, --verbose โ€” display verbose information when dumping. this can help you debug DWARF issues. when things get weird, she gets chatty.
  • --verify โ€” verify the structure of the DWARF information by verifying the compile unit chains, DIE relationships graph, address ranges, and more. she checks everything. ๐Ÿ‘‘
  • --verify-json=<path> โ€” output a JSON-formatted error summary to the file specified by <path>. implies --verify. the output format is described below in FORMAT OF VERIFY JSON OUTPUT.
  • --version โ€” display the version of the tool. know your queen's era.
  • --debug-abbrev, --debug-addr, --debug-aranges, --debug-cu-index, --debug-frame [=<offset>], --debug-gnu-pubnames, --debug-gnu-pubtypes, --debug-info [=<offset>], --debug-line [=<offset>], --debug-line-str, --debug-loc [=<offset>], --debug-loclists [=<offset>], --debug-macro, --debug-names, --debug-pubnames, --debug-pubtypes, --debug-ranges, --debug-rnglists, --debug-str, --debug-str-offsets, --debug-tu-index, --debug-types [=<offset>], --eh-frame [=<offset>], --gdb-index, --apple-names, --apple-types, --apple-namespaces, --apple-objc โ€” dump the specified DWARF section by name. remember, only the .debug_info section is shown by default. some of these entries let you add an =<offset> so you can hand her the optional offset of the exact entry to dump within that section. when you give an offset, only the entry at that offset gets dumped โ€” otherwise she dumps the entire section. all of it. no notes. โœจ

and some extra tea: the --debug-macro option prints both the .debug_macro and the .debug_macinfo sections. also, --debug-frame and --eh-frame are aliases โ€” in cases where both sections are present, one command outputs both. two for one, we love a deal. ๐ŸŽ€

  • @<FILE> โ€” read command-line options from <FILE>. yes, a whole file of options. iconic.

๐ŸŒŸ FORMAT OF STATISTICS OUTPUT ๐ŸŒŸ

the --statistics option generates single-line JSON output representing quality metrics of the processed debug info. these metrics are useful for comparing changes between two compilers โ€” especially for judging the effect that a change to the compiler has on the debug info quality. ngl, that's a glow-up report.

the output is formatted as key-value pairs. the first pair contains a version number. the following naming scheme is used for the keys:

  • variables ==> local variables and parameters
  • local vars ==> local variables
  • params ==> formal parameters

for aggregated values, the following keys are used:

  • sum_of_all_variables(...) ==> the sum applied to all variables
  • #bytes ==> the number of bytes
  • #variables - entry values ... ==> the number of variables excluding the entry values etc.

๐Ÿ”ฎ FORMAT OF VERIFY JSON OUTPUT ๐Ÿ”ฎ

the format of the JSON output created by the --verify-json is:

{
  "error-categories": {
    "<first category description>": {"count": 1234},
    "<next category description>": {"count": 4321}
  },
  "error-count": 5555
}

and the following is generated if there are no errors reported:

{
  "error-categories": {},
  "error-count": 0
}

clean sheet energy, we love to see it. ๐Ÿซถ


๐Ÿ’œ EXIT STATUS ๐Ÿ’œ

llvm-dwarfdump returns 0 if the input files were parsed and dumped successfully. otherwise? she returns 1. that's the vibe check, fr fr.


โญ SEE ALSO โญ


๐ŸŽ€ Author ๐ŸŽ€

maintained by the LLVM Team (https://llvm.org/). they're doing amazing sweetie.


2003-2026, LLVM Project


and that's the whole page bestie, version 22, dated 2026-07-16, from the LLVM-DWARFDUMP(1) manual โ€” go dump something and slay ๐Ÿ’…โœจ

๐Ÿ“ฆ where this page comes from