Just to be clear what’s going on here…
On Darwin systems, the linker does not ever insert DWARF debug information into a binary. Instead it uses one of two modes:
- Debug in .o file: leave the DWARF in the .o files and write a “debug map” into the binary that tells lldb where the .o files are and how the linker mapped symbols from .o to binary
- Create a dSYM (using dsymutil) which does the same linking job lldb does and produces a stand alone debug file.
The problem with the “one step” build process is that when you don’t specify a .o output, clang creates a temporary one that it deletes when the linking is done. That rules out method 1 above, so clang makes a dSYM in that case before deleting the temporary .o file. TTTT, I’ve never ensured this happens the same way with .s file but it would be surprising if it didn’t.
The dSYM should be equivalent to the .o files & debug map, if that’s not true that’s a bug in dsymutil (why Adrian was asking for info about the dSYM…)
It’s also curious that anything works on deleting the dSYM, since that implies that the .o files are still hanging around somewhere, which is unexpected.
You can view the debug map (which we cannily reused STABS entries for) by doing:
$ nm -ap <path_to_binary> | grep " OSO"
that will list all the debug files the debug map was told about. If you look at the N_FUN entries you’ll also see all the functions we were told about, etc…
You can see whether lldb read in any .o files for debugging purposes by issuing:
(lldb) image list -g
All the .o files will be at the bottom. There’s a bug in this listing (just in the listing, not the search) - we don’t list .o files we found in .a files, but I don’t think that’s relevant in your case.
Jim