采用并行 DWARF 链接器：dsymutil 的演进与挑战

背景

在 Apple 平台（macOS、iOS 等）的开发体验设计中，核心目标之一是尽可能缩短“编译-链接-调试”的周期。为了实现这一目标，调试信息的处理方式与传统的链接流程有所不同：链接器并不会将大量的 DWARF 调试信息直接链接到最终的二进制文件中，而是将其保留在目标文件（object files）中，并生成一个调试映射文件（debug map），告诉调试器去哪里查找这些信息。

在本地调试时，这种机制非常高效。然而，如果开发者需要将调试信息归档用于崩溃报告（crash reporting）或远程调试，就需要一种方法来生成一个自包含的调试信息包。这就是 dsymutil 工具存在的意义。

dsymutil 不仅仅是一个简单的 DWARF 拼接工具，它是一个利用“单一定义规则”（One Definition Rule, ODR）在编译单元之间去重类型的优化链接器。在 C++ 项目中，每个包含头文件的翻译单元都会拥有该头文件中定义类型的独立 DWARF 副本。dsymutil 能够识别等效类型并只保留一个规范副本（canonical copy）。对于大型 C++ 项目而言，这种去重能力至关重要，它决定了生成的 Mach-O 文件是否能控制在 4GB 的限制之内。

为了执行这些优化，dsymutil 需要解析并语义分析 DWARF，这也是耗时最多的部分。经典的 DWARF 链接算法在设计上是单线程的。由于大型项目的调试信息轻松达到数百 GB，为了避免一次性将所有数据加载到内存中，dsymutil 采用流式处理方式，一次处理一个编译单元。这一约束使得并行化核心链接循环变得非平凡。尽管多年来团队做出了增量改进（如并行处理不同架构、在独立线程上锁步运行分析和克隆阶段），但根本瓶颈依然存在：ODR 去重操作仍然发生在单线程上。

虽然 LLVM 中早已存在可以跨线程去重类型的并行 DWARF 链接器，但由于存在一些重大局限性，它一直未能达到生产就绪状态。

核心内容

资格化难题：二进制一致性 vs. 语义等价性

dsymutil 面临的最大挑战在于“资格化”（qualification），即如何验证新版本的正确性。在将 dsymutil 上游合并到 LLVM 以及重写克隆阶段时，团队采用的策略是生成“逐位相同”（bug-for-bug identical）的 DWARF 输出。这种二进制一致性使得开发者可以通过对两个 dSYM 文件运行 diff 命令来确信代码变更确实是“无功能变更”（NFC, No Functional Change）。

然而，并行链接器无法产生二进制相同的输出。由于编译单元是并发处理的，类型被遇到和去重的顺序发生了变化。虽然输出在语义上是相同的（或者应该是相同的），但 DWARF 的结构以及字节序列会有所不同。这意味着之前用于资格化 dsymutil 每次变更的二进制兼容性方法不再适用。

如果没有一种语义比较输出的方法，团队就无法确认并行链接器生成的 DWARF 的正确性。虽然在测试中检查小问题相对容易，但这无法扩展到中等规模的项目。真正棘手的问题往往只有在调试时，当调试器开始表现异常时才会暴露。因此，为了考虑在 dsymutil 中采用并行链接器，团队需要一种工具，能够具体地展示并行链接器输出与经典链接器输出之间的差异。

语义 DWARF 差异比较工具

DWARF 看起来像是一系列标签和属性的树，但实际上它是一个有向无环图（DAG）。属性可以引用图中其他部分的 DIE（Debug Information Entry，调试信息条目）。例如，变量引用其类型，类型引用其成员的类型，子程序引用其参数类型，依此类推。比较两个 DWARF 输出意味着在两个图之间匹配节点，并验证它们的属性及可达子图是否等价。

仅仅通过比较 dwarfdump 的文本输出是无法做到这一点的。因为偏移量不同，DIE 的顺序可能不同，交叉引用指向的位置也不同。更不用说对于任何现实世界的项目，dwarfdump 的输出量之大，使得大多数工具难以处理。正确的做法是以稳定的标识符（如链接名称、声明坐标和类型签名）为锚点，然后从那里遍历图，在结构上比较属性和子节点。

团队原型化了一个语义差异比较工具，并在 clang 上运行，比较经典链接器和并行链接器的输出。在大约 500 万个 DIE 中，该工具识别出了约 5 万个差异。虽然团队尚未验证所有结果，且该工具本身远未达到生产就绪状态，但它足以让团队具体了解两个链接器在何处产生分歧。

确定性（Determinism）问题

阻碍采用并行链接器的最大障碍是其非确定性。对于任何严肃的构建工具来说，可重现构建（reproducible builds）是不可或缺的。如果没有它，开发者将失去缓存、二分查找（bisect）和验证工件的能力。

这种非确定性源于并行链接器在 ODR 去重期间选择规范 DIE 的方式。当多个编译单元定义相同的类型时，线程会竞争以获取规范副本。先到达的线程获胜。由于线程调度在每次运行之间可能不同，不同的运行可能会选择不同的规范 DIE。

解决方案是根据编译单元在链接顺序中的位置为其分配优先级。当线程想要注册一个规范 DIE 时，只有当其优先级严格高于当前优先级时（即它在输入中出现在更早的位置），它才会覆盖当前的规范 DIE。这保证了无论调度如何，都会选择相同的规范 DIE，同时保留了并行性。

切换默认值的策略

差异比较工具只是资格化策略的一部分，而非全部。它只能告诉我们两个链接器是否达成一致，而不能告诉我们哪一个才是正确的。此外，它也是流程中最难自动化的部分。为了切换默认值，团队需要一套全面的资格化策略来确保正确性。

切换默认值的步骤包括：

1. 运行现有测试套件：使用 --linker=parallel 标志运行 dsymutil 现有的测试套件。这些测试涵盖了特定的 DWARF 构造和边缘情况。任何通过经典链接器的测试也应通过并行链接器。使所有测试通过，或理解未通过的原因，是切换默认值的前提。
2. 运行 LLDB 测试套件：针对由并行链接器生成的 dSYM 运行 LLDB 测试套件。LLDB 的测试涵盖了广泛的调试场景。默认情况下，它会运行每个测试的多个变体：一次使用目标文件中的 DWARF，一次使用 dSYM。这将帮助团队识别经典链接器与并行链接器之间，以及目标文件中的 DWARF 与并行链接器生成的 dSYM 之间的回归问题。
3. 手动检查大型项目：使用差异比较工具，手动检查经典链接器和并行链接器为越来越大的项目生成的 dSYM 之间的差异。

这项工作仍在持续跟踪和进行中。

性能表现

为了提供背景参考：在 clang 上运行 dsymutil，经典链接器大约需要 3 分钟，而并行链接器仅需约 40 秒。速度提升一直是预期的结果，并行链接器的设计初衷就是更快。上述工作的核心目的是建立信心，以确保能够真正投入使用。

在 Apple 平台上，clang 默认传递 -fno-limit-debug-info 标志，这意味着每个编译单元都会获得完整的类型定义，而不是对其他地方定义的类型的前向声明。拥有完整的类型信息意味着我们不必解析所有输入 DWARF，这提高了调试器的性能和可靠性，但也增加了 dsymutil 需要处理的 DWARF 量。

关键要点

• 并行化的必要性：经典 dsymutil 受限于单线程 ODR 去重，无法充分利用多核资源，导致处理大型 C++ 项目时耗时过长。
• 二进制一致性失效：并行处理导致类型去重顺序变化，使得输出 DWARF 的二进制字节序列与经典链接器不同，传统的 diff 验证方法失效。
• 语义差异工具：团队开发了基于稳定标识符（链接名、坐标、类型签名）的语义 DWARF 差异比较工具，以在图结构层面验证两个链接器输出的等价性。
• 确定性修复：通过基于链接顺序的优先级机制解决并行链接器的