DSYMUTIL(1)

πŸ“¦
version 12.0.1 Β· 4 versions
, in fedora 43, fedora 44

πŸ’– DSYMUTIL(1) β€” the LLVM one, bestie πŸ’–

okay so this is dsymutil, and it lives in the LLVM manual, section 1. pull up a chair 🫢


✨ NAME ✨

dsymutil β€” manipulate archived DWARF debug symbol files


🌸 SYNOPSIS 🌸

dsymutil [options] executable

πŸ¦‹ DESCRIPTION πŸ¦‹

so here's the tea: dsymutil links the DWARF debug info it finds in the object files for an executable β€” that's the executable in the synopsis, bestie, it's literally the star of the show πŸ‘‘ β€” and it does that using debug symbols information contained in its symbol table.

by default, the linked debug information gets dropped into a .dSYM bundle with the same name as the executable. cute, consistent, iconic. ✨


πŸ’… OPTIONS πŸ’…

  • --accelerator=<accelerator type> β€” pick which type of accelerator table you want. the valid options are 'Apple', 'Dwarf' and 'Default'.
  • --arch <arch> β€” only link DWARF debug info for the CPU architecture types you name. architectures can be specified by name. if you use this option and any architectures can't be properly linked, an error gets returned, no cap. you can pass this option multiple times, once for each desired architecture. by default, all CPU architectures get linked, and any architecture that can't be properly linked will make dsymutil return an error.
  • --dump-debug-map β€” dumps the executable's debug-map (that's the list of the object files containing the debug information) in YAML format and then exits. no DWARF linking will take place, she's just here to spill the map πŸ“
  • --flat, -f β€” produce a flat dSYM file. a .dwarf extension gets appended to the executable name β€” unless you specified the output file with the -o option, in which case that's what you get.
  • --gen-reproducer β€” generate a reproducer consisting of the input object files.
  • --help, -h β€” print this help output.
  • --minimize, -z β€” when you're creating a dSYM file, this one suppresses the emission of the .debug_inlines, .debug_pubnames, and .debug_pubtypes sections, because dsymutil currently has better equivalents: .apple_names and .apple_types. and when you use it together with the --update option, it causes redundant accelerator tables to be removed. two-for-one πŸ’…
  • --no-odr β€” don't use ODR (One Definition Rule) for uniquing C++ types.
  • --no-output β€” do the link in memory, but don't emit the result file. all vibes, no file.
  • --no-swiftmodule-timestamp β€” don't check the timestamp for swiftmodule files.
  • --num-threads <threads>, -j <threads> β€” specifies the maximum number (n) of simultaneous threads to use when linking multiple architectures.
  • --object-prefix-map <prefix=remapped> β€” remap object file paths (but no source paths) before processing. use this for Clang objects where the module cache location was remapped using -fdebug-prefix-map, so dsymutil can find the Clang module cache. 🧚
  • --oso-prepend-path <path> β€” specifies a path to prepend to all debug symbol object file paths.
  • --out <filename>, -o <filename> β€” specifies an alternate path to place the dSYM bundle. the default dSYM bundle path is created by appending .dSYM to the executable name.
  • --papertrail β€” when you're running dsymutil as part of your build system, it can be desirable for warnings to be part of the end product rather than just being emitted to the output stream. when enabled, warnings are embedded in the linked DWARF debug information. paper trail but make it debug info 🌈
  • --remarks-output-format <format> β€” specify the format to be used when serializing the linked remarks.
  • --remarks-prepend-path <path> β€” specify a directory to prepend the paths of the external remark files.
  • --statistics β€” print statistics about the contribution of each object file to the linked debug info. this prints a table after linking with the object file name, the size of the debug info in the object file (in bytes) and the size contributed (in bytes) to the linked dSYM. the table is sorted by the output size, listing the object files with the largest contribution first. leaderboard behavior fr fr πŸ“Š
  • --symbol-map <bcsymbolmap> β€” update the existing dSYMs inplace using the symbol map specified.
  • -s, --symtab β€” dumps the symbol table found in the executable or object file(s) and exits.
  • -S β€” output textual assembly instead of a binary dSYM companion file.
  • --toolchain <toolchain> β€” embed the toolchain in the dSYM bundle's property list.
  • -u, --update β€” update an existing dSYM file so it contains the latest accelerator tables and other DWARF optimizations. this option will rebuild the .apple_names and .apple_types hashed accelerator tables. glow-up for your dSYM ✨
  • --use-reproducer <path> β€” use the object files from the given reproducer path.
  • --verbose β€” display verbose information when linking.
  • --verify β€” run the DWARF verifier on the linked DWARF debug info.
  • -v, --version β€” display the version of the tool.
  • -y β€” treat the executable as a YAML debug-map rather than an executable.

πŸŽ€ EXIT STATUS πŸŽ€

dsymutil returns 0 if the DWARF debug information was linked successfully. otherwise, it returns 1.

so: 0 = slay, 1 = not slay. that's the whole vibe check. πŸ’€

πŸ”₯ SEE ALSO πŸ”₯

llvm-dwarfdump(1)


πŸ‘‘ AUTHOR πŸ‘‘

maintained by the LLVM Team (https://llvm.org/). they're the moment, honestly.


2003-2024, LLVM Project


and that's the whole page, bestie 🫢 this is dsymutil(1) from LLVM, page 12, dated 2024-07-18. go forth and link your DWARF, periodt. πŸ’–πŸ¦‹βœ¨

πŸ“¦ where this page comes from