c - GNU 链接器中的部分链接是什么？

Question

我能找到的最好的解释来自官方文档:

-r --relocateable Generate relocatable output--i.e., generate an output file that can in turn serve as input to ld. This is often called partial linking. As a side effect, in environments that support standard Unix magic numbers, this option also sets the output file's magic number to OMAGIC. If this option is not specified, an absolute file is produced. When linking C++ programs, this option will not resolve references to constructors; to do that, use -Ur. This option does the same thing as `-i'.

我特别想知道链接器输入中出现的符号会发生什么变化。举个例子，我有一个静态库 libstatic.a，它包含一个目标文件 component.o。现在，我想创建另一个静态库 libfinal.a，它将用作 libstatic.a 的接口(interface)。我使用这个命令来创建它:

ld -r -o libfinal.a wrapper.o -L。 -lstatic

其中wrapper.o提供专属API调用libstatic.a中定义的函数

libfinal.a 是否只是一个包含 wrapper.o 和 component.o 的组合存档或所有可能的引用- 在wrapper.o 和component.o 之间解析(链接)然后放入libfinal.a？

Edit_1:根据取得的进展更新问题:组件库libstatic.a的objdump(objdump -D libstatic.a)分别显示.text段对于每个功能(如预期)。而在通过部分链接(-r标志)创建的组合库 libfinal.a 中，只有一个 .text 部分.我想这意味着内部链接已经发生，而不仅仅是创建一个普通的存档。

Answer 1

最小可运行示例

在这里，我生成了一个最小示例，并以两种方式编译它以生成功能相同的可执行文件:

• 一个合并的 f12.c 文件，没有部分链接链接到 f12.o
• 两个单独的 f1.c 和 f2.c，它们首先部分链接到 f12_r.o

主.c

#include <assert.h>
#include <stdlib.h>

int f_1_2(void);
int f_2_1(void);

int main(void) {
    assert(f_1_2() + f_2_1() == 5);
    return EXIT_SUCCESS;
}

f1.c

#include "f1.h"

f2.c

#include "f2.h"

f12.c

#include "f1.h"
#include "f2.h"

f1.h

int f_2(void);

int f_1_2(void) {
    return f_2() + 1;
}

int f_1(void) {
    return 1;
}

f2.h

int f_1(void);

int f_2_1(void) {
    return f_1() + 1;
}

int f_2(void) {
    return 2;
}

运行.sh

#!/usr/bin/env bash
set -eux
cflags='-ggdb3 -std=c99 -O0 -fPIE -pie'
gcc $cflags -c -o f1.o f1.c
gcc $cflags -c -o f2.o f2.c
gcc $cflags -c -o f12.o f12.c
ld -o f12_r.o -r f1.o f2.o
gcc $cflags -c -o main.o main.c
gcc $cflags -o main.out f12.o main.o
gcc $cflags -o main_r.out f12_r.o main.o
./main.out
./main_r.out

GitHub upstream .

如果我们尝试同样的事情但没有 ld -r，那么我们会得到最后的警告:

+ ld -o f12_r.o f1.o f2.o
ld: warning: cannot find entry symbol _start; defaulting to 0000000000401000
+ gcc -ggdb3 -std=c99 -O0 -fPIE -pie -o main_r.out f12_r.o main.o
/usr/bin/ld: error in f12_r.o(.eh_frame); no .eh_frame_hdr table will be created

它们都没有使工具退出非 0，并且最终的可执行文件仍在运行，所以我不确定它有多糟糕。 TODO 明白。

二进制分析

如果您不熟悉重定位，请先阅读:What do linkers do?

关键问题是部分链接如何加速链接。我唯一能想到的就是解决跨预链接文件的引用。我现在专注于此。

但是，它并没有按照 Resolve relative relocations in partial link 中的要求那样做，所以我预计它不会显着加快链接速度。

我已经确认了这一点:

objdump -S f12.o
objdump -S f12_r.o

两者都产生相同的输出，其中包含:

int f_1_2(void) {
   0:   55                      push   %rbp
   1:   48 89 e5                mov    %rsp,%rbp
    return f_2() + 1;
   4:   e8 00 00 00 00          callq  9 <f_1_2+0x9>
   9:   83 c0 01                add    $0x1,%eax
}
   c:   5d                      pop    %rbp
   d:   c3                      retq

所以我们看到对 f_1_2 的调用在这两种情况下都还没有被解析，因为相对偏移地址仍然是 0: e8 00 00 00 00 (e8 是操作码)。

这也告诉我，GCC 不会在最终链接之前解析函数调用 TODO 理由，可能强制它解析？

基准

我在 Replacing ld with gold - any experience? 上对 LD 与 GOLD 进行了基准测试，所以我决定重新使用它来查看部分链接是否会导致任何链接加速。

我用 this script 生成了测试对象:

./generate-objects 100 1000 100

然后我从最极端的链接案例开始:预链接除主文件之外的所有内容，然后对最终链接进行基准测试:

mv main.o ..
ld -o partial.o -r *.o
time gcc               partial.o ../main.o
time gcc -fuse-ld=gold partial.o ../main.o

以秒为单位的挂钟时间结果如下:

          No partial link   Partial link
No Gold   6.15              5.756
Gold      4.06              4.457

因此:

• 时差存在，但不是很大
• 没有黄金，速度更快，但有黄金，它变得更慢!

因此，根据这个实验，部分链接似乎根本不会加快您的链接时间，我只建议您先尝试使用 GOLD。

如果您能提供一个具体示例，说明增量链接会显着加快速度，请告诉我。

案例研究:Linux 内核

Linux 内核是曾经使用增量链接的大型项目的一个例子，所以也许我们可以从中学到一些东西。

它已经转移到 ar T 精简存档，如 https://unix.stackexchange.com/questions/5518/what-is-the-difference-between-the-following-kernel-makefile-terms-vmlinux-vml/482978#482978 所示

初始提交和基本原理位于:a5967db9af51a84f5e181600954714a9e4c69f1f(包含在 v4.9 中)，其提交消息显示:

ld -r is an incremental link used to create built-in.o files in build
subdirectories. It produces relocatable object files containing all
its input files, and these are are then pulled together and relocated
in the final link. Aside from the bloat, this constrains the final
link relocations, which has bitten large powerpc builds with
unresolvable relocations in the final link.

Documentation/process/changes.rst 中也提到了这一点:

Binutils
--------

The build system has, as of 4.13, switched to using thin archives (`ar T`)
rather than incremental linking (`ld -r`) for built-in.a intermediate steps.
This requires binutils 2.20 or newer.

TODO:查明何时引入了增量链接，并查看是否有一个最小的测试用例，我们可以使用它来加快速度:https://unix.stackexchange.com/questions/491312/why-does-the-linux-kernel-build-system-use-incremental-linking-or-ar-t-thin-arch

在 Ubuntu 18.10、GCC 8.2.0、Lenovo ThinkPad P51 笔记本电脑、Intel Core i7-7820HQ CPU(4 核/8 线程)、2x Samsung M471A2K43BB1-CRC RAM (2x 16GiB)、Samsung MZVLB512HAJQ-000L7 SSD (3,000) 上测试兆/秒)。