macos - Apples GCC 在哪里/如何在可执行文件中存储 DWARF

Question

Apples GCC 在哪里/如何在可执行文件中存储 DWARF？

我通过 gcc -gdwarf-2 编译了一个二进制文件(苹果海湾合作委员会)。然而，objdump -g也不是 objdump -h确实向我展示了任何调试信息。

此外，libbfd 没有找到任何调试信息。 (我在 binutils-mailinglist 上询问了它 here 。)

但是，我可以通过 dsymutil 提取调试信息(变成一个 dSYM)。 libbfd 也能够读取这些调试信息。

Answer 1

在 Mac OS X 上，决定使用链接器 id链接程序时不处理所有调试信息。调试信息经常是10x程序可执行文件的大小，因此让链接器处理所有调试信息并将其包含在可执行二进制文件中是对链接时间的严重损害。对于迭代开发——编译、链接、编译、链接、调试、编译链接——这是一个真正的成功。

相反，编译器生成 DWARF .s 文件中的调试信息，汇编器将其输出到 .o 文件中，链接器在可执行二进制文件中包含一个“调试映射”，它告诉调试信息用户所有符号在链接过程中重新定位的位置。

消费者(进行 .o 文件调试)从可执行文件加载调试映射，并根据需要处理 .o 文件中的所有 DWARF，根据调试映射的说明重新映射符号。
dsymutil可以被认为是调试信息链接器。它执行相同的过程——读取调试映射，从 .o 文件加载 DWARF，重新定位所有地址——然后在最终链接地址处输出所有 DWARF 的单个二进制文件。这是 dSYM 包。

一旦你有了一个 dSYM 包，你就拥有了任何 dwarf 读取工具(可以处理 Mach-O 二进制文件)可以处理的普通旧标准 DWARF。

还有一个额外的改进使所有这些工作，Mach-O 二进制文件中包含的 UUID。每次链接器创建二进制文件时，它都会在 LC_UUID 加载命令(v. otool -hlv 或 dwarfdump --uuid )中发出一个 128 位 UUID。这唯一标识该二进制文件。当dsymutil创建 dSYM，它包含该 UUID。如果 dSYM 和可执行文件具有匹配的 UUID，调试器只会将它们关联起来——没有狡猾的文件 mod 时间戳或类似的东西。

我们还可以使用 UUID 来定位二进制文​​件的 dSYM。它们出现在崩溃报告中，我们包含一个 Spotlight 导入器，您可以使用它来搜索它们，例如
mdfind "com_apple_xcode_dsym_uuids == E21A4165-29D5-35DC-D08D-368476F85EE1"如果 dSYM 位于 Spotlight 索引位置。您甚至可以为您的公司拥有一个 dSYM 存储库，以及一个可以在给定 UUID 的情况下检索正确 dSYM 的程序 - 可能是一个小的 mysql 数据库或类似的东西 - 这样您就可以在随机可执行文件上运行调试器，然后立即进行所有调试该可执行文件的信息。您可以使用 UUID 做一些非常巧妙的事情。

但无论如何，要回答您的原始问题:未剥离的二进制文件具有调试映射，.o 文件具有 DWARF，以及何时 dsymutil运行这些组合以创建 dSYM 包。

如果您想查看调试映射条目，请执行 nm -pa executable他们都在那里。它们采用旧刺的形式nlist记录 - 链接器已经知道如何处理 stabs，因此使用它们是最容易的 - 但是你会很容易地看到它是如何工作的，如果你不确定，可以引用一些 stabs 文档。