MacOS下调试信息格式区分_dwarf dsym 区别 mac

一直没弄明白DWARF和符号文件的区别，恰好在StackOverflow找到了详细的分析。DWARF是调试信息的格式，在开发阶段（未配置生成信息格式为dSYM的情况下）调试信息是在目标文件中的，调试时根据二进制执行文件中的映射表在目标文件中加载调试信息。但产品发布的时候目标文件作为中间会遗失，所以就要把这些调试信息从目标文件中剥离集成为单独的调试文件，即dSYM文件，在生成dSYM文件时会打入可执行文件一致的uuid，每次编译都会有不同的uuid，文件符号的匹配校验也是根据该uuid，所以对于面临发布的产品一定要有独立的dSYM文件，否则就会出现dump文件无法符号文件做分析的尴尬。

原文链接：

ios - What's the difference between DWARF and DWARF with dSYM file? - Stack Overflow

Both DWARF and DWARF with dSYM create DWARF debug information like on all other platforms, but they differ on where the debug information will be accessed when debugging or symbolicating:

DWARF means that the debug information is left in .o files and this debug information is not linked during the build process. Each .o file will contain unlinked DWARF and the debugger (LLDB, GDB) will link the debug information on the fly when debugging. The main executable contains a debug map contained in the symbol table which has everything that is needed to link the debug information. The maps contains STABS symbol entries that points to each .o file and tells the debugger or linker where everything needs to be linked (for functions, globals and static variables). The debug information will be less efficient since it is not linked, and each .o file can contain type definitions that are also found in other .o files, so the overall debug information size will be bigger. This is often most useful for the edit/compile/debug cycles that you while implementing new features or trying to track down bugs. The benefit is you do not have to link the debug information during your build process. Not all tools that parse debug information support this mode of debug information, so you might want create dSYM files if local crash reports on your system do not contain source file and line information in the backtraces. Tools like sample, ReportCrash, and Instruments that need to parse debug information might not support the DWARF setting.

DWARF with dSYM means that after you build your executable, a dSYM debug information file will be linked using a tool named dsymutil. dsymutil gets run after your executable is linked to parse the debug map in the main executable and produce a dSYM file with all of the debug information. Linking the debug information can add to your build times if you have a lot of code in your project. The DWARF debug information in all of the .o files is intelligently linked into the dSYM file. Any code that was dead stripped will have its debug information removed, and the dsymutil will unique types within the debug information, so the resulting DWARF is much smaller and more efficient. Use this setting when building your releases or if you have a build machine that is caching builds for others to download.

In order find the dSYM file for an executable, the UUID from the main executable is copied into the dSYM file. A previous comment suggested that the UUID changes with each build even if the same source code and compiler was used, but this is not true. The UUID is a MD5 checksum of the parts of the binary that do not change due to debug information. Debug information can contain paths and other data that change depending on what directory the sources exist in. If the UUID was simply a MD5 checksum of the entire binary, then the UUID would be different for the same sources built with the same compiler if one was built in /tmp/myproj vs /users/data/myproj. So the UUID built into Darwin binaries will match if the important bits (__TEXT, __DATA, etc) are the same even if the project is built in different directories. This allows the UUID to be used to unique dSYM files across multiple builds that produce the same binary. If SDK header files or different compilers or linkers are used, the UUID can easily differ.

There is Spotlight importer for dSYM files knows how to extract the UUID from the dSYM file to make it possible for debuggers and other tools like sample, Instruments, ReportCrash and more to find the dSYM file for a binary even if the dSYM file is not right next to the binary. You can see the UUID of your binary by running dwarfdump:

$ dwarfdump --uuid ~/a.out
UUID: E76A2647-AFB4-3950-943A-CB1D701B7C07 (x86_64) ~/a.out

Then you can use the Spotlight window in your system to search for the dSYM file. There is also a command line tool for spotlight called "mdfind" that can be used:

$ mdfind E76A2647-AFB4-3950-943A-CB1D701B7C07
/Users/admin/a.out.dSYM

So to sum up: use DWARF for edit/compile/debug cycles if you have large projects and want to avoid the time it takes to link a dSYM file during your daily workflow. Use DWARF with dSYM all the time if you have smaller projects, doing release builds, or need other Apple tools that are not debuggers to be able to parse your debug information. Both formats contain the same kind of information and can be used for debugging, but not all tools can load the DWARF format where the DWARF is left in the .o files.