6

I'm using CMake on MacOS to generate Makefiles for my C++ project. When I build a target (say, test/AsyncTest), I get that target, plus a test/AsyncTest.dSYM/ directory that contains the following:

test/AsyncTest.dSYM/Contents/Resources/DWARF/AsyncTest
test/AsyncTest.dSYM/Contents/Info.plist

I'm guessing this is debug information (based on the ".dSYM" and the "DWARF" clues), but I haven't found a tool that lets me inspect the AsyncTest file. dwarfdump doesn't recognize it.

So, what exactly is this file? Is there a tool I can use to dump the symbolic information (assuming that's what it is)? Why is CMake generating it when I didn't ask it to? And can I not generate it (since the resulting file is huuuuge)?

Eric Niebler
  • 5,927
  • 2
  • 29
  • 43
  • 2
    I think https://stackoverflow.com/questions/22460058/how-is-a-dsym-file-created answers the 'what' question – Oleg Bogdanov Aug 01 '18 at 02:35
  • 1
    Also https://stackoverflow.com/questions/10044697/where-how-does-apples-gcc-store-dwarf-inside-an-executable#12827463 has good insights from Apple dev – Oleg Bogdanov Aug 01 '18 at 02:36

2 Answers2

9

macOS / OS X / Darwin / Mach-O objects has a "separated debug" scheme by default.

when an exe is linked, the static linker (ld64) does not include the debug data in the exe.

However, the static linker records (in the exe symbol table) the names of the object files that it linked

A second tool (debug linker, named dsymutil) consumes the exe file table and the original objects and links the debug - producing a standard mach-o package structure containing the linked debug. [by default name.dSYM] where "name" is the name of the exe.

LLDB and some versions of GDB can consume this package to provide the debug data they need.

to look at the content :

The Xcode “dwarfdump” utility can understand the package (dwarfdump name.dSYM).

The actual content: name.dSYM/Contents/Resources/DWARF/name should also be dumpable by:

  • llvm-dwarfdump
  • BINUTILS objdump (if that’s been built for the appropriate darwin target).
iains
  • 106
  • 2
  • Thanks, llvm-dwarfdump is the magic sauce I was looking for. The vanilla gnu dwarfdump doesn't recognize the format of these DWARF files, but llvm-dwarfdump does. – Eric Niebler Aug 01 '18 at 22:36
-1

I don't know exactly what's in there, but it's defiantly debug-related, and not cmake's fault: "c++ -g test.cpp -o test" generates it too.

The only way to turn it off that I know of is to not compile in debug mode: pass -DCMAKE_BUILD_TYPE=Release to cmake.

crmoore
  • 399
  • 3
  • 7