Go语言链接器大修

之前有帖子说到 [《Google抛弃C语言，采用Go语言重写Go编译器》](http://studygolang.com/topics/471)，这里说到的是链接器。同样，有部分功能会使用 Go 语言编写。 ### 摘要 ### 在构建和运行一个标准的 Go 程序时，链接器是最慢的一部分。为了解决这个问题，我们计划将链接器拆分到两部分。其中的一部分可能会用 Go 来编写。 ### 背景 ### 链接器总是 Plan 9 工具链中最慢的部分之一，而现在它是 Go 工具链中最慢的部分了。Ken Thompson 在关于工具链的概述中进行了总结： 新的编译器编译迅速、加载缓慢，生成中等质量的目标代码。编译器与移植性相关，对于不同的计算机需要若干星期的工作来构建对应的编译器。对于 Plan 9 来说，需要若干有特定功能、且使用自己的目标格式的编译器，这一项目不可或缺。对于我们来说，编译器必须可以自由的伴随 Plan 9 发行。 在回顾中带来了两个问题。首先是必须对编译器和加载器进行简化。Plan 9 运行在多种处理器上，而这些编译通常会并行完成。不幸的是，在加载进行之前，所有的编译都必须完成。加载是单线程的。在这个模型下，任何用于加载的编译结果的变化都会显著的增加实际时间。着对于那些经常编译和加载的库来说同样如此。未来，我们可能尝试将一些加载工作放到编译器完成。 这篇文档编写于上世纪 90 年代初期。现在就是未来。 ### 建议规划 ### 当前的链接器执行两个独立的任务。首先，它伴随定位表，将伪指令输入流翻译为可执行代码和数据块。然后，它删除无用代码，合并其他到单一的镜像中、重新处理定位，并且生成一些例如运行时符号表这样的完整程序数据结构。 第一部分可以分解到一个库（liblink）中，这样就可以同汇编器与编译器联合。那些 6a、6c 或 6g 等等输出的目标文件可以由 liblink 输出，且包含可执行代码、数据块与定位表，即当前链接器的第一个中间产物。 第二部分可以由移除 liblink 之后的链接器处理。剩下的程序可以读取新的目标文件并完成链接。这个链接器只有很少的代码，大部分是与架构无关的。这使得将其合并为一个与平台无关的程序，然后像“go tool ld”这样调用成为可能。甚至使用 Go 来编写它，使其在大型链接的时候更加容易并行化。（参阅下面的章节了解如何开始。） 一开始，我们将集中精力使新剥离的部分能用于 C 代码。一旦所有修改完成，就开始 Go 的探索。 为了避免影响可用性，生成的目标文件将保持已有的扩展名 .5、.6、.8。可能在 Go 1.3 中，新的链接器可以包含叫做 5l、6l 和 8l 的过渡性程序。这些过渡程序将在 Go 1.4 中移除。 ### 目标文件 ### 新的拆分需要新的目标文件格式。当前的目标文件包含伪指令流，但是新的目标文件将包含可执行代码以及伴随定位表的数据块。 一个自然的问题是应当使用已有的目标文件格式吗，例如 ELF。首先，我们将使用定制的格式。为了构建像运行时符号表这样的运行时数据结构，需要定制一个 Go 的链接器，因此即使使用 ELF 目标文件，也无法重用标准的 ELF 链接器。ELF 文件也包含了大量超过 Go 定制的链接器所需要的通用语义和 ELF 语义。一个定制的，不那么通用的目标文件格式可以让生成与使用更加简单。另一方面，ELF 可以由如 readelf、objdump 等等的标准工具处理。不过，一旦尘埃落定，当我们知道到底这个格式需要什么的时候，还是值得确认一下使用 ELF 能否满足需求。 新的目标文件的细节还未完成。这个章节的剩余部分列出了一些设计的思路。 显然，这个文件越简单越好。除了一些例外，链接器的工作都应当在中间库中完成。可能会神奇地包含栈划分代码，这使得目标文件是操作系统依赖的，虽然它们在包中已经是基于依赖操作系统的 Go 代码了。同时软件的浮点工作也在中间库中完成，使得 ARM 目标文件是特定的 GOARM（当前在链接器运行之前，没有任何东西特定是 GOARM 的）。 我们需要确保目标文件是可以通过 mmap 使用的。这可以降低复制带来的 I/O。这需要修改 Go 的运行时对于非 nil 的地址产生 SIGSEGV 时，产生一个 panic 而不是崩溃掉。 纯 Go 包由 Go 编译器在一个 Go 代码文件完整的集合上一次产生一个目标文件。接下来这个目标文件被封装到一个打包文件中。我们可以整理这个单一的目标文件也是一个合法的打包文件，那么通常情况下就无需封装的步骤。 ### 启动 ### 如果新的 Go 链接器是用 Go 编写的，就有一个启动问题：如何链接这个链接器？这里有两个方案。 第一个方案是维护一个 CL 启动列表。队列中的第一个 CL 应当包含当前的链接器，由 C 编写。每个步骤都是一个 CL，包含了新的链接器用来链接下一个。队列的最后一个二进制结果就可以用于下载了。队列不能太长，并且能贴合里程碑。例如，可以让 Go 1.3 的链接器可以由 Go 1.2 的程序进行编译，Go 1.4 的链接器可以由 Go 1.3 的程序进行编译，等等。队列的记录确保了如果需要，可以重新启动，不过也得提供对付信任依赖问题的机制。另一个启动的方法是使用 gccgo，然后使用它来编译 Go 1.3 链接器。 第二个方案是在用 Go 写了一个更好的链接器之后，也仍然维护 C 的版本，并且保持大多数功能对等。用 C 编写的版本只需要保持足够的功能来链接 Go 编写的这个。它需要加载一些目标文件，合并它们，然后输出可执行文件。无需 cgo 支持、无需外部链接、无需共享库、无需高性能。只需要一些朴素的代码（可能只有几千行代码）并且不需要经常修改。C 版本会在 make.bash 的时候构建和使用，但不会被安装。这个方案对于其他从 Go 源码构建的开发者来说更加容易。 我们选择哪个方案并不重要，无论怎样都至少会有一个可用的方案。事情继续推进，我们就可以决定。 原文：[Go 1.3 Linker Overhaul](https://docs.google.com/document/d/1xN-g6qjjWflecSP08LNgh2uFsKjWb-rR9KA11ip_DIE/edit#) 译文来源：mikespook 的 blog，[GO 1.3 链接器大修](http://mikespook.com/2013/12/%E7%BF%BB%E8%AF%91-go-1-3-%E9%93%BE%E6%8E%A5%E5%99%A8%E5%A4%A7%E4%BF%AE/)