DSYMUTIL(1)

πŸ“¦
version 11.1.0 Β· 2 versions
, in fedora 43, fedora 44

πŸ’– DSYMUTIL πŸ’–

okay bestie, welcome to dsymutil, the LLVM girlie whose whole job is manipulating archived DWARF debug symbol files. Yes, that's a mouthful. No, we're not scared of it. She eats debug info for breakfast. ✨


🌸 SYNOPSIS 🌸

dsymutil [options] executable

πŸ¦‹ DESCRIPTION πŸ¦‹

So here's the tea: dsymutil links up all the DWARF debug information hanging out inside the object files for an executable β€” and she does it by using the debug symbols information that's chilling in that executable's symbol table. She's basically the group chat organizer of debug data. 🫢

By default? The linked debug information gets dropped into a .dSYM bundle with the same name as the executable. Cute, predictable, iconic. πŸ’…


✨ OPTIONS ✨

  • --accelerator=<accelerator type> β€” pick which type of accelerator table you want. The valid options are 'Apple', 'Dwarf' and 'Default'. That's it, that's the menu. πŸ’œ
  • --arch <arch> β€” only link DWARF debug information for the CPU architecture types you name. Architectures get specified by name. Heads up: when you use this, if any architectures can't be properly linked, you get an error back. You can specify this option multiple times β€” once for each architecture you want. By default all CPU architectures get linked, and any 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 that contain the debug information) in YAML format, then exits. No DWARF link will take place. It's giving "just show me the receipts". πŸ™ˆ
  • --flat, -f β€” produces a flat dSYM file. A .dwarf extension gets appended to the executable name unless the output file is specified using the -o option. πŸ“
  • --gen-reproducer β€” generate a reproducer consisting of the input object files. Very "here's a copy of my homework so you can reproduce the bug". πŸ“‹
  • --help, -h β€” print this help output. The classic. πŸ’–
  • --minimize, -z β€” when used when 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 used together with the --update option, it will cause redundant accelerator tables to be removed. Two jobs, one flag, main character energy. πŸ‘‘
  • --no-odr β€” do not use ODR (One Definition Rule) for uniquing C++ types. 🚫
  • --no-output β€” does the link in memory, but does not emit the result file. All vibes, no evidence. πŸ’€
  • --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. Parallelism slay. πŸ”₯
  • --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; it helps dsymutil 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. Warning girlies, this one's for you. ⚠️
  • --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 β€” prints 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. It's a leaderboard. πŸ†
  • --symbol-map <bcsymbolmap> β€” update the existing dSYMs inplace using the symbol map specified. 🧚
  • -s, --symtab β€” dumps the symbol table found in executable or object file(s) and exits. Peek inside, then dip. πŸ‘€
  • -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 to contain 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. Tell me everything, bestie. πŸ—£οΈ
  • --verify β€” run the DWARF verifier on the linked DWARF debug info. Fact-check the fact-check. βœ…
  • -v, --version β€” display the version of the tool. πŸ’–
  • -y β€” treat executable as a YAML debug-map rather than an executable. Plot twist. πŸŒ€

πŸ”₯ EXIT STATUS πŸ”₯

dsymutil returns 0 if the DWARF debug information was linked successfully. Otherwise, she returns 1. That's the whole vibe check. πŸ’€


πŸ‘‘ SEE ALSO πŸ‘‘


πŸ’œ AUTHOR πŸ’œ

Maintained by the LLVM Team (https://llvm.org/). They're the parents, we're just living in their house. 🏠


2003-2024, LLVM Project


and that's the whole page, bestie πŸŽ€ this was DSYMUTIL(1), page 11, dated 2024-07-18 β€” now go link some DWARF and slay πŸ’–βœ¨

πŸ“¦ where this page comes from