9

Are these two commands on linux:

objcopy --only-keep-debug foo foo.dbg
objcopy --add-gnu-debuglink=foo.dbg foo

equivalent to below on mac 

dsymutil <binary> -o <binary>.dSYM

Equivalent in the sense that,

  1. It creates a standalone debug info file.
  2. It create a link between the executable and debug info file.

Then for stripping

is the commands on linux:

objcopy --strip-debug foo

OR

strip -g <binary>

equivalent to below on mac 

strip -S <binary>
Abhishek Jain
  • 9,614
  • 5
  • 26
  • 40

1 Answers1

6

The --only-keep-debug part of the objcopy does functionally the same thing as dsymutil.

There isn't any tool to record the binary location in the dSYM. Rather the dSYM & the binary share a common UUID, and clients that want to find symbol files use the DebugSymbols framework, which uses various tricks (e.g. a Spotlight importer, search paths, a "dSYM finding external script", etc) to find the separate debug file. So there isn't a need for an equivalent to --add-gnu-debuglink.

The mac version of strip -S does strip debug information the same way that the binutils version does. The difference is that strip -S on OS X won't actually decrease the size of the binary much. On OS X, the debug information is always kept out of the executable - residing either in the .o files or in the dSYM. The executable only has a small "debug map" that tells lldb or dsymutil how to link the dwarf from the .o files. strip -S only has to remove the debug map.

Jim Ingham
  • 25,260
  • 2
  • 55
  • 63
  • 1. How does the linking happens on Mac OSX between dSYM and the binary? 2. Does that mean .o files also needs to be passed to dsymutil? – Abhishek Jain Oct 23 '15 at 18:26
  • No, dsymutil reads the "debug map" from the executable, which lists the location of all the .o files. This does mean you have to have the .o files in their original location and not have stripped the binary you want to run dsymutil on. That seems an acceptable trade-off for the convenience of not having to figure out what .o files to run dsymutil on... – Jim Ingham Oct 26 '15 at 19:31
  • I guess I just answered #2. As for #1. In short "by running dsymutil on the binary". Since the binary knows where the .o files are (from the debug map) you only need to provide dsymutil the path to the binary, it will do everything else. If you want details on how dsymutil works, note that in Xcode 7.0 we switched from an internal version of dsymutil to one implemented in the llvm source base. So you can read the sources in llvm/tools/dsymutil to get the complete story. – Jim Ingham Oct 27 '15 at 18:01
  • Ok. i built a binary, then created standalone symbol dSYM and then stripped the map from the binary. Then i ran the binary and it got crashed and core got dumped. Now while analyzing the core in lldb using target create --core core/path binary/path. The dSYM being next to binary, lldb was able to pick up symbols. BUT when i move dSYM somewhere else, 1. It could not show me any source but just function names, from where is the function name information coming? – Abhishek Jain Oct 28 '15 at 04:45
  • 2. if i bring back the dSYM next to binary and do core analysis using lldb, now also it does not pick symbols from dSYM. The GetNumCompileUnits return 0 nor image list shows the dSYM. What could be the issue? I also used --symfile in target create, but that also did not help. – Abhishek Jain Oct 28 '15 at 04:45
  • If the binary and the dSYM are not next to one another, lldb will use Spotlight to find the dSYM. However, Spotlight doesn't index everywhere (not in /tmp, not in build directories, and other places.) In this case, you can always use the "add-dsym" command to tell lldb explicitly where the dSYM is. – Jim Ingham Oct 28 '15 at 23:20
  • For #2, I would need more info to know what was going wrong, but again, the add-dsym command should always work provided the UUID's of the dSYM and the binary match. If add-dsym fails then there must be a mismatch here. – Jim Ingham Oct 28 '15 at 23:22