mal*_*lex 34
不同之处在于,对于带有dSYM文件的DWARF,Archive app.xcarchive(用于adHoc分发)还包含在崩溃报告中反向符号化代码所需的dSYM文件.通常,.xcarchive包含
dSyms
Products
info.plist
Run Code Online (Sandbox Code Playgroud)
因此,如果您需要在归档应用程序以进行分发时对崩溃报告进行外部分析,则应将DWARF与dSYM文件一起使用.
Hon*_*ney 13
一如既往地了解缩写帮助!
DWARF是一种广泛使用的标准化调试数据格式:
DWARF最初是与可执行和可链接格式(ELF)一起设计的,尽管它独立于目标文件格式.这个名字是对"ELF"的中世纪幻想补充,没有官方意义.只有(矮人和精灵)都是神话中的生物
调试符号(dSYM):
默认情况下,应用程序的调试版本将调试符号存储在已编译的二进制文件中,而应用程序的发布版本将调试符号存储在随附的dSYM文件中以减小二进制文件大小.
调试符号文件和应用程序二进制文件通过构建UUID在每个构建基础上绑定在一起.为应用程序的每个构建生成一个新的UUID,并唯一标识该构建.即使从相同的源代码重建功能相同的可执行文件,使用相同的编译器设置,它也将具有不同的构建UUID.
例如,如果您有一个库libfoo.dylib,则调试符号文件将是libfoo.dylib.dSYM.
从这里开始
长话短说
DWARF只是一个调试文件
带有dSYM文件的DWARF是一个调试文件以及符号化文件
小智 10
这两个矮和矮跟的dSYM创建像其他所有平台上DWARF调试信息,但他们在其中调试信息调试或symbolicating时访问不同:
矮人意味着调试信息保留在 .o 文件中,并且在构建过程中不会链接此调试信息。每个 .o 文件将包含未链接的 DWARF,调试器(LLDB、GDB)将在调试时即时链接调试信息。主可执行文件包含一个包含在符号表中的调试映射,该映射包含链接调试信息所需的一切。映射包含指向每个 .o 文件的 STABS 符号条目,并告诉调试器或链接器所有需要链接的位置(对于函数、全局变量和静态变量)。调试信息由于没有链接而效率较低,并且每个 .o 文件可以包含在其他 .o 文件中也可以找到的类型定义,因此整体调试信息大小会更大。这对于您在实现新功能或尝试跟踪错误时的编辑/编译/调试周期通常最有用。好处是您不必在构建过程中链接调试信息。并非所有解析调试信息的工具都支持这种调试信息模式,因此如果系统上的本地崩溃报告不包含回溯中的源文件和行信息,您可能需要创建 dSYM 文件。需要解析调试信息的示例、ReportCrash 和 Instruments 等工具可能不支持 因此,如果系统上的本地崩溃报告不包含回溯中的源文件和行信息,则您可能需要创建 dSYM 文件。需要解析调试信息的示例、ReportCrash 和 Instruments 等工具可能不支持 因此,如果系统上的本地崩溃报告不包含回溯中的源文件和行信息,则您可能需要创建 dSYM 文件。需要解析调试信息的示例、ReportCrash 和 Instruments 等工具可能不支持矮人设定。
带有 dSYM 的 DWARF意味着在您构建可执行文件后,dSYM 调试信息文件将使用名为dsymutil. dsymutil在您的可执行文件被链接以解析主可执行文件中的调试映射并生成包含所有调试信息的 dSYM 文件后运行。如果您的项目中有大量代码,链接调试信息会增加您的构建时间。所有 .o 文件中的 DWARF 调试信息都智能地链接到 dSYM 文件中。任何被彻底剥离的代码都将删除其调试信息,并且调试信息中的dsymutil将是唯一类型,因此生成的 DWARF 更小且更高效。在构建您的版本时使用此设置,或者如果您有一台缓存构建供其他人下载的构建机器。
为了找到可执行文件的 dSYM 文件,主可执行文件中的 UUID 被复制到 dSYM 文件中。之前的评论表明,即使使用相同的源代码和编译器,UUID 也会随着每次构建而改变,但事实并非如此。UUID 是二进制文件中不因调试信息而改变的部分的 MD5 校验和。调试信息可以包含路径和其他数据,这些数据会根据源所在的目录而变化。如果 UUID 只是整个二进制文件的 MD5 校验和,那么对于使用相同编译器构建的相同源,如果 UUID 是不同的,则 UUID 将不同内置 /tmp/myproj 与 /users/data/myproj。因此,即使项目构建在不同的目录中,如果重要位(__TEXT、__DATA 等)相同,Darwin 二进制文件中内置的 UUID 也会匹配。这允许将 UUID 用于跨多个生成相同二进制文件的构建的唯一 dSYM 文件。如果使用 SDK 头文件或不同的编译器或链接器,则 UUID 很容易不同。
dSYM 文件的 Spotlight 导入器知道如何从 dSYM 文件中提取 UUID,以便调试器和其他工具(如示例、仪器、ReportCrash 等)能够找到二进制文件的 dSYM 文件,即使 dSYM 文件不正确旁边的二进制。您可以通过运行dwarfdump以下命令查看二进制文件的 UUID :
$ dwarfdump --uuid ~/a.out
UUID: E76A2647-AFB4-3950-943A-CB1D701B7C07 (x86_64) ~/a.out
Run Code Online (Sandbox Code Playgroud)
然后您可以使用系统中的 Spotlight 窗口来搜索 dSYM 文件。还有一个名为“mdfind”的聚光灯命令行工具可以使用:
$ mdfind E76A2647-AFB4-3950-943A-CB1D701B7C07
/Users/admin/a.out.dSYM
Run Code Online (Sandbox Code Playgroud)
所以总结一下:如果您有大型项目并希望避免在日常工作流程中链接 dSYM 文件所需的时间,请使用DWARF进行编辑/编译/调试循环。如果您有较小的项目、进行发布版本或需要其他非调试器的 Apple 工具来解析您的调试信息,请始终将DWARF 与 dSYM 结合使用。两种格式都包含相同类型的信息并可用于调试,但并非所有工具都可以加载DWARF格式,其中 DWARF 保留在 .o 文件中。
| 归档时间: |
|
| 查看次数: |
13924 次 |
| 最近记录: |