DWARF 和带有 dSYM 文件的 DWARF 有什么区别？答案

【问题标题】：What's the difference between DWARF and DWARF with dSYM file?DWARF 和带有 dSYM 文件的 DWARF 有什么区别？
【发布时间】：2014-04-27 16:40:32
【问题描述】：

XCode 支持此构建设置的这 2 个值：

构建设置 > 构建选项 > 调试信息格式。

谁能解释一下区别？

【问题讨论】：

标签： ios xcode dwarf

【解决方案1】：

不同之处在于，对于带有 dSYM 文件的 DWARF，您的 Archive app.xcarchive（用于 adHoc 分发）还包含在崩溃报告中对代码进行反向符号化所需的 dSYM 文件。一般来说，.xcarchive 包含

dSyms
Products
info.plist

因此，如果您需要它在归档应用程序以进行分发的情况下对崩溃报告进行外部分析，您应该使用 DWARF 和 dSYM 文件。

【讨论】：

【解决方案2】：

一如既往地理解缩写有帮助！

DWARF 是一种广泛使用的标准化调试数据格式：

DWARF 最初是与Executable and Linkable Format (ELF) 一起设计的，尽管它独立于目标文件格式。这个名字是对“ELF”没有官方意义的中世纪幻想补充。只是（矮人和精灵）都是神话生物

Debug Symbol (dSYM)：

默认情况下，应用程序的调试版本将调试符号存储在编译后的二进制文件中，而应用程序的发布版本将调试符号存储在配套的 dSYM 文件中以减小二进制文件大小。

调试符号文件和应用程序二进制文件通过构建 UUID 在每个构建的基础上绑定在一起。为您的应用程序的每个构建生成一个新的 UUID，并唯一标识该构建。即使功能相同的可执行文件从相同的源代码重建，使用相同的编译器设置，它也会有不同的构建 UUID。

例如，如果你有一个库 libfoo.dylib，调试符号文件将是 libfoo.dylib.dSYM。

_来自here

长话短说

DWARF只是一个调试文件
DWARF with dSYM File是一个调试文件和符号文件

专业提示：

在我们项目的 GitHub 存储库中，在发布部分，我们有这样的内容：

我们上传了 .ipa 和 dysm 文件，所以如果从现在起 3 个月后，用户在我们的 10.16 版本中出现了奇怪的崩溃，那么我们将转到这个发布分支并使用这个 dsym 运行它并尝试重现问题。

【讨论】：

为什么开发人员更喜欢 DWARF 而不是带 dsym 的 DWARF？性能对构建有影响吗？
dSYM 允许您将应用程序进程附加到 Xcode 并对其进行调试。想象一下，如果您打算制作一个安全的银行应用程序。您不想让其他人调试您的代码。拥有 dSYMS 可以让其他人（黑客）更轻松地符号化您的崩溃报告。

【解决方案3】：

DWARF 和 DWARF with dSYM 都像在所有其他平台上一样创建 DWARF 调试信息，但它们在调试或符号化时访问调试信息的位置不同：

DWARF 表示调试信息保留在 .o 文件中，并且在构建过程中不会链接此调试信息。每个 .o 文件都将包含未链接的 DWARF，并且调试器（LLDB、GDB）将在调试时即时链接调试信息。主可执行文件包含一个包含在符号表中的调试映射表，其中包含链接调试信息所需的一切。这些映射包含指向每个 .o 文件的 STABS 符号条目，并告诉调试器或链接器需要将所有内容链接到哪里（对于函数、全局变量和静态变量）。由于没有链接，调试信息的效率会降低，并且每个 .o 文件都可以包含在其他 .o 文件中也可以找到的类型定义，因此整体调试信息的大小会更大。这对于您在实现新功能或尝试追踪错误时的编辑/编译/调试周期通常最有用。好处是您不必在构建过程中链接调试信息。并非所有解析调试信息的工具都支持这种调试信息模式，因此如果您系统上的本地崩溃报告在回溯中不包含源文件和行信息，您可能需要创建 dSYM 文件。需要解析调试信息的示例、ReportCrash 和 Instruments 等工具可能不支持 DWARF 设置。

DWARF with dSYM 意味着在您构建可执行文件后，将使用名为 dsymutil 的工具链接 dSYM 调试信息文件。 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，以使调试器和其他工具（例如 sample、Instruments、ReportCrash 等）能够找到二进制文件的 dSYM 文件，即使是 dSYM 文件不在二进制旁边。您可以通过运行dwarfdump 来查看二进制文件的 UUID：

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

然后您可以使用系统中的 Spotlight 窗口来搜索 dSYM 文件。还有一个用于 Spotlight 的命令行工具，叫做“mdfind”，可以使用：

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

总结一下：如果您有大型项目并希望避免在日常工作流程中链接 dSYM 文件所花费的时间，请使用 DWARF 进行编辑/编译/调试周期。如果您有较小的项目、进行发布构建或需要其他非调试器的 Apple 工具来解析您的调试信息，请始终使用 DWARF 和 dSYM。两种格式都包含相同类型的信息，可用于调试，但并非所有工具都可以加载 DWARF 格式，其中 DWARF 保留在 .o 文件中。

【讨论】：

【解决方案4】：

DWARF（使用属性记录格式进行调试）是许多编译器和调试器用来支持源代码级调试的调试文件格式。它是目标文件中调试信息的格式。程序的 DWARF 描述是一个树结构，其中每个节点都可以有子节点或兄弟节点。节点可能代表类型、变量或函数。

来源：https://www.ibm.com/developerworks/aix/library/au-dwarf-debug-format/index.html

带有 dSYM 文件的 DWARF 存储您应用的调试符号

诸如 crashlytics 之类的服务使用它来将崩溃日志中的符号替换为适当的方法名称，使其可读且有意义。

来源：What's the dSYM and how to use it? (iOS SDK)

【讨论】：

【解决方案5】：

来自“项目编辑器帮助”：

调试信息格式（DEBUG_INFORMATION_FORMAT）

要生成的调试信息的类型。

DWARF：目标文件和链接产品将使用 DWARF 作为调试信息格式。矮人

带有 dSYM 文件的 DWARF：目标文件和链接的产品将使用 DWARF 作为调试信息格式，Xcode 还将生成一个包含来自各个目标文件的调试信息的 dSYM 文件（除了不需要 dSYM 文件并将不是为静态库或目标文件产品创建的）。 dsym 小矮人

【讨论】：