XCode 支持此构建设置的这 2 个值:
构建设置 > 构建选项 > 调试信息格式。
有人可以解释这些差异吗?
不同之处在于,对于带有 dSYM 文件的 DWARF,您的 Archive app.xcarchive(用于 adHoc 分发)还包含在崩溃报告中对代码进行反向符号化所需的 dSYM 文件。通常,.xcarchive 包含
dSyms
Products
info.plist
因此,如果您需要它在归档应用程序以进行分发的情况下对崩溃报告进行外部分析,您应该使用 DWARF 和 dSYM 文件。
一如既往地理解缩写有帮助!
DWARF是一种广泛使用的标准化调试数据格式:
DWARF 最初是与可执行和可链接格式(ELF) 一起设计的,尽管它独立于目标文件格式。这个名字是对“ELF”的中世纪幻想补充,没有官方意义。只有(矮人和精灵)都是神话生物
调试符号(dSYM):
默认情况下,应用程序的调试版本将调试符号存储在已编译的二进制文件中,而应用程序的发布版本将调试符号存储在伴随的 dSYM 文件中以减小二进制文件的大小。
调试符号文件和应用程序二进制文件通过构建 UUID 在每个构建的基础上绑定在一起。为您的应用程序的每个构建生成一个新的 UUID,并唯一标识该构建。即使使用相同的编译器设置从相同的源代码重建功能相同的可执行文件,它也将具有不同的构建 UUID。
例如,如果您有一个库 libfoo.dylib,则调试符号文件将为 libfoo.dylib.dSYM。
从这里
长话短说
DWARF只是一个调试文件
带有 dSYM 文件的 DWARF是一个调试文件和符号文件
专家提示:
在我们项目的 GitHub 存储库中,在发布部分,我们有这样的内容:
我们上传.ipa
anddysm
文件,所以如果从现在起 3 个月后,用户在我们的 10.16 版本中出现奇怪的崩溃,那么我们将转到此发布分支并使用此 dsym 运行它并尝试重现该问题。
DWARF和带有 dSYM 的DWARF都像在所有其他平台上一样创建 DWARF 调试信息,但它们在调试或符号化时访问调试信息的位置不同:
矮人表示调试信息保留在 .o 文件中,并且在构建过程中未链接此调试信息。每个 .o 文件都将包含未链接的 DWARF,并且调试器(LLDB、GDB)将在调试时即时链接调试信息。主可执行文件包含一个包含在符号表中的调试映射表,其中包含链接调试信息所需的一切。这些映射包含指向每个 .o 文件的 STABS 符号条目,并告诉调试器或链接器需要将所有内容链接到哪里(对于函数、全局变量和静态变量)。由于没有链接,调试信息的效率会降低,并且每个 .o 文件都可以包含在其他 .o 文件中也可以找到的类型定义,因此整体调试信息的大小会更大。这对于您在实现新功能或尝试追踪错误时的编辑/编译/调试周期通常最有用。好处是您不必在构建过程中链接调试信息。并非所有解析调试信息的工具都支持这种调试信息模式,因此如果系统上的本地崩溃报告在回溯中不包含源文件和行信息,您可能需要创建 dSYM 文件。需要解析调试信息的示例、ReportCrash 和 Instruments 等工具可能不支持 因此,如果您系统上的本地崩溃报告在回溯中不包含源文件和行信息,您可能需要创建 dSYM 文件。需要解析调试信息的示例、ReportCrash 和 Instruments 等工具可能不支持 因此,如果您系统上的本地崩溃报告在回溯中不包含源文件和行信息,您可能需要创建 dSYM 文件。需要解析调试信息的示例、ReportCrash 和 Instruments 等工具可能不支持矮人设置。
带有 dSYM 的 DWARF意味着在您构建可执行文件后,将使用名为dsymutil
. dsymutil
在链接您的可执行文件以解析主可执行文件中的调试映射并生成包含所有调试信息的 dSYM 文件后运行。如果您的项目中有大量代码,则链接调试信息可能会增加您的构建时间。所有 .o 文件中的 DWARF 调试信息都智能地链接到 dSYM 文件中。任何被死剥离的代码都将删除其调试信息,并且调试信息中的dsymutil
意志类型是唯一的,因此生成的 DWARF 更小更高效。在构建版本时使用此设置,或者如果您有一个构建机器正在缓存构建以供其他人下载。
为了找到可执行文件的 dSYM 文件,将主可执行文件中的 UUID 复制到 dSYM 文件中。先前的评论表明,即使使用相同的源代码和编译器,UUID 也会随着每次构建而改变,但事实并非如此。UUID 是二进制文件中不会因调试信息而改变的部分的 MD5 校验和。调试信息可以包含路径和其他数据,这些路径和其他数据会根据源所在的目录而改变。如果 UUID 只是整个二进制文件的 MD5 校验和,那么对于使用相同编译器构建的相同源,UUID 将是不同的。内置于 /tmp/myproj 与 /users/data/myproj。因此,即使项目构建在不同的目录中,如果重要位(__TEXT、__DATA 等)相同,Darwin 二进制文件中内置的 UUID 也会匹配。这允许 UUID 用于跨生成相同二进制文件的多个构建的唯一 dSYM 文件。如果使用 SDK 头文件或不同的编译器或链接器,UUID 很容易不同。
dSYM 文件的 Spotlight 导入器知道如何从 dSYM 文件中提取 UUID,即使 dSYM 文件不正确,调试器和其他工具(如示例、仪器、ReportCrash 等)也可以找到二进制文件的 dSYM 文件旁边的二进制。您可以通过运行查看二进制文件的 UUID dwarfdump
:
$ dwarfdump --uuid ~/a.out
UUID: E76A2647-AFB4-3950-943A-CB1D701B7C07 (x86_64) ~/a.out
然后您可以使用系统中的 Spotlight 窗口来搜索 dSYM 文件。还有一个用于聚光灯的命令行工具,称为“mdfind”,可以使用:
$ mdfind E76A2647-AFB4-3950-943A-CB1D701B7C07
/Users/admin/a.out.dSYM
总结一下:如果您有大型项目并希望避免在日常工作流程中链接 dSYM 文件所花费的时间,请使用DWARF进行编辑/编译/调试周期。如果您有较小的项目、进行发布构建或需要其他非调试器的 Apple 工具来解析您的调试信息,请始终使用DWARF 和 dSYM 。两种格式都包含相同类型的信息,可用于调试,但并非所有工具都可以加载DWARF格式,其中 DWARF 保留在 .o 文件中。
DWARF(使用属性记录格式进行调试)是许多编译器和调试器用来支持源代码级调试的调试文件格式。它是目标文件中调试信息的格式。程序的 DWARF 描述是一个树结构,其中每个节点都可以有子节点或兄弟节点。节点可能代表类型、变量或函数。
来源:https ://www.ibm.com/developerworks/aix/library/au-dwarf-debug-format/index.html
带有 dSYM 文件的 DWARF 存储应用程序的调试符号
像 crashlytics 这样的服务使用它来用适当的方法名称替换崩溃日志中的符号,这样它就可以阅读并且有意义。
从“项目编辑器帮助”:
调试信息格式 (DEBUG_INFORMATION_FORMAT)
要生成的调试信息的类型。
DWARF:目标文件和链接产品将使用 DWARF 作为调试信息格式。矮人
DWARF 与 dSYM 文件:目标文件和链接的产品将使用 DWARF 作为调试信息格式,Xcode 还将生成一个包含来自各个目标文件的调试信息的 dSYM 文件(除了不需要也不会创建 dSYM 文件对于静态库或目标文件产品)。dsym 侏儒