placid chat Asked: 2019-10-09 03:33:24 +0800 CST2019-10-09 03:33:24 +0800 CST 2019-10-09 03:33:24 +0800 CST 什么是黄金链接器? 772 以前有人用过gold链接器吗?为了链接一个相当大的项目,我不得不使用它而不是 GNU ld,它抛出了一些错误并且无法链接。 链接器如何gold能够链接ld失败的大型项目?某处是否存在某种记忆技巧? linux 4 个回答 Voted Best Answer Stephen Kitt 2019-10-09T03:54:49+08:002019-10-09T03:54:49+08:00 该gold链接器被设计为特定于 ELF 的链接器,旨在生成比 BFD ld(“传统”GNU binutils 链接器)更易于维护和更快的链接器。作为副作用,它确实能够使用比 BFD 更少的内存来链接非常大的程序ld,这可能是因为要处理的抽象层更少,并且因为链接器的数据结构更直接地映射到 ELF 格式。 我不确定是否有很多文档专门解决了两个链接器之间的设计差异以及它们对内存使用的影响。各种 GNU 链接器的作者 Ian Lance Taylor 有一系列关于链接器的非常有趣的文章,其中解释了导致gold. 他写道_ 我现在正在使用的链接器,称为黄金,将是我的第三个。它是专门的 ELF 链接器。再一次,目标是速度,在这种情况下比我的第二个链接器更快。多年来,通过添加对 ELF 和共享库的支持,该链接器已显着减慢速度。这种支持是修补的,而不是设计的。 (第二个链接器是 BFD ld。) suspectus 2019-10-09T03:55:58+08:002019-10-09T03:55:58+08:00 编写黄金链接器是为了使链接过程大大加快。根据黄金作者伊恩·兰斯·泰勒(Ian Lance Taylor )的说法 目前,与现有链接器相比,黄金只有一个显着优势:它更快。在大型 C++ 程序上,我测得它的运行速度快了五倍。 他正在将黄金链接器的性能与传统的 GNU 链接器进行比较。gold(与 GNU 链接器不同)不使用 BFD 库来处理目标文件。 gold 的限制是(不像 GNU 链接器可以处理许多目标文件类型)它只能链接 ELF 格式的目标文件。 关于您在使用 GNU 链接器时遇到的问题,这里是Michael Adam对 SO 上类似问题的一个有趣回答: 黄金链接器甚至在我们的代码中发现了一些依赖问题,因为它在某些细节方面似乎比经典链接器更正确。参见,例如这个 Samba 提交。 Ciro Santilli OurBigBook.com 2019-10-10T10:27:29+08:002019-10-10T10:27:29+08:00 gold与ld基准 我在以下位置发布了 ld 与黄金的具体综合基准:https ://stackoverflow.com/questions/3476093/replacing-ld-with-gold-any-experience/53921263#53921263 结果总结:黄金比 ld 快 2 倍到 3 倍。 对于具有失控模板和代码生成的复杂 C++ 项目,这种时间增益可能会改变游戏规则,因为链接步骤涉及项目中的所有文件,并且与编译不同,它必须始终完成,即使您更改只是一个 .cpp 文件。 所以缓慢的链接时间使得开发周期难以忍受,这可能是谷歌投入资源的主要原因。试想一下,每次微不足道的文件更改等待 10 秒而不是 30 秒的收益。 综合基准的时间收益也与我在一个复杂的现实世界项目(gem5)中获得的实际收益一致,正如该答案中所提到的那样。 Syfer Polski 2019-10-10T12:05:19+08:002019-10-10T12:05:19+08:00 现代 GNU/Linux 系统上提供了三个链接器: ld,由 GNU binutils 维护, gold,由 GNU binutils 维护,“仍在 beta 测试中”, lld,作为 LLVM 项目的一部分开发。 有关速度基准,请参阅:https ://www.phoronix.com/scan.php?page=article&item=lld4-linux-tests&num= 2 TL、DR:lld最快,其次是gold,其次是ld 有消息称,黄金项目一直停滞不前,Fedora 中的包结构反映了这一点。
该
gold
链接器被设计为特定于 ELF 的链接器,旨在生成比 BFDld
(“传统”GNU binutils 链接器)更易于维护和更快的链接器。作为副作用,它确实能够使用比 BFD 更少的内存来链接非常大的程序ld
,这可能是因为要处理的抽象层更少,并且因为链接器的数据结构更直接地映射到 ELF 格式。我不确定是否有很多文档专门解决了两个链接器之间的设计差异以及它们对内存使用的影响。各种 GNU 链接器的作者 Ian Lance Taylor 有一系列关于链接器的非常有趣的文章,其中解释了导致
gold
. 他写道_(第二个链接器是 BFD
ld
。)编写黄金链接器是为了使链接过程大大加快。根据黄金作者伊恩·兰斯·泰勒(Ian Lance Taylor )的说法
他正在将黄金链接器的性能与传统的 GNU 链接器进行比较。gold(与 GNU 链接器不同)不使用 BFD 库来处理目标文件。
gold 的限制是(不像 GNU 链接器可以处理许多目标文件类型)它只能链接 ELF 格式的目标文件。
关于您在使用 GNU 链接器时遇到的问题,这里是Michael Adam对 SO 上类似问题的一个有趣回答:
gold
与ld
基准我在以下位置发布了 ld 与黄金的具体综合基准:https ://stackoverflow.com/questions/3476093/replacing-ld-with-gold-any-experience/53921263#53921263
结果总结:黄金比 ld 快 2 倍到 3 倍。
对于具有失控模板和代码生成的复杂 C++ 项目,这种时间增益可能会改变游戏规则,因为链接步骤涉及项目中的所有文件,并且与编译不同,它必须始终完成,即使您更改只是一个 .cpp 文件。
所以缓慢的链接时间使得开发周期难以忍受,这可能是谷歌投入资源的主要原因。试想一下,每次微不足道的文件更改等待 10 秒而不是 30 秒的收益。
综合基准的时间收益也与我在一个复杂的现实世界项目(gem5)中获得的实际收益一致,正如该答案中所提到的那样。
现代 GNU/Linux 系统上提供了三个链接器:
有关速度基准,请参阅:https ://www.phoronix.com/scan.php?page=article&item=lld4-linux-tests&num= 2 TL、DR:
lld
最快,其次是gold
,其次是ld
有消息称,黄金项目一直停滞不前,Fedora 中的包结构反映了这一点。