这个问题在这里已有答案:
C ++链接如何在实践中发挥作用?我正在寻找的是关于链接如何发生的详细解释,而不是链接的命令。
关于编译的问题已经有了类似的问题,并没有详细介绍:How does the compilation/linking process work?
编辑:我已将此答案移至副本:https://stackoverflow.com/a/33690144/895245
这个答案侧重于地址重定位,这是链接的关键功能之一。
将使用一个最小的例子来阐明这个概念。
摘要:重定位编辑目标文件的.text
部分进行翻译:
这必须由链接器完成,因为编译器一次只能看到一个输入文件,但我们必须立即知道所有目标文件以决定如何:
.text
和.data
部分先决条件:对:
链接与C或C ++无关:编译器只生成目标文件。然后链接器将它们作为输入,而不知道编译它们的语言。它可能也是Fortran。
因此,为了减少地壳,让我们研究一下NASM x86-64 ELF Linux hello world:
section .data
hello_world db "Hello world!", 10
section .text
global _start
_start:
; sys_write
mov rax, 1
mov rdi, 1
mov rsi, hello_world
mov rdx, 13
syscall
; sys_exit
mov rax, 60
mov rdi, 0
syscall
编译和汇编:
nasm -felf64 hello_world.asm # creates hello_world.o
ld -o hello_world.out hello_world.o # static ELF executable with no libraries
与NASM 2.10.09。
首先我们反编译对象文件的.text
部分:
objdump -d hello_world.o
这使:
0000000000000000 <_start>:
0: b8 01 00 00 00 mov $0x1,%eax
5: bf 01 00 00 00 mov $0x1,%edi
a: 48 be 00 00 00 00 00 movabs $0x0,%rsi
11: 00 00 00
14: ba 0d 00 00 00 mov $0xd,%edx
19: 0f 05 syscall
1b: b8 3c 00 00 00 mov $0x3c,%eax
20: bf 00 00 00 00 mov $0x0,%edi
25: 0f 05 syscall
关键的是:
a: 48 be 00 00 00 00 00 movabs $0x0,%rsi
11: 00 00 00
它应该将hello world字符串的地址移动到rsi
寄存器中,该寄存器将传递给write系统调用。
可是等等!当程序加载时,编译器怎么可能知道"Hello world!"
在内存中的哪个位置?
嗯,它不能,特别是在我们将一堆.o
文件与多个.data
部分链接在一起之后。
只有链接器可以这样做,因为只有他将拥有所有这些目标文件。
所以编译器只是:
0x0
这个“额外信息”包含在目标文件的.rela.text
部分中
.rela.text
代表“重新定位.text部分”。
使用单词重定位是因为链接器必须将对象的地址重定位到可执行文件中。
我们可以用以下方法拆卸.rela.text
部分:
readelf -r hello_world.o
其中包含;
Relocation section '.rela.text' at offset 0x340 contains 1 entries:
Offset Info Type Sym. Value Sym. Name + Addend
00000000000c 000200000001 R_X86_64_64 0000000000000000 .data + 0
本节的格式已修复,记录在:http://www.sco.com/developers/gabi/2003-12-17/ch4.reloc.html
每个条目告诉链接器一个需要重定位的地址,这里我们只有一个用于字符串。
简化一下,对于这个特定的行,我们有以下信息:
Offset = C
:这个条目改变的.text
的第一个字节是什么。
如果我们回头看反编译的文本,它正好位于关键的movabs $0x0,%rsi
内部,那些知道x86-64指令编码的人会注意到它编码指令的64位地址部分。Name = .data
:地址指向.data
部分Type = R_X86_64_64
,它指定了为翻译地址需要做些什么的计算。
该字段实际上取决于处理器,因此记录在AMD64 System V ABI extension第4.4节“重定位”中。
该文件说R_X86_64_64
做:
Field = word64
:8个字节,因此00 00 00 00 00 00 00 00
在地址0xC
Calculation = S + A
S
是重新安置地址的价值,因此00 00 00 00 00 00 00 00
A
是0
的加数。这是重定位条目的字段。
所以S + A == 0
和我们将被重新安置到.data
部分的第一个地址。现在让我们看一下为我们生成的可执行文件ld
的文本区域:
objdump -d hello_world.out
得到:
00000000004000b0 <_start>:
4000b0: b8 01 00 00 00 mov $0x1,%eax
4000b5: bf 01 00 00 00 mov $0x1,%edi
4000ba: 48 be d8 00 60 00 00 movabs $0x6000d8,%rsi
4000c1: 00 00 00
4000c4: ba 0d 00 00 00 mov $0xd,%edx
4000c9: 0f 05 syscall
4000cb: b8 3c 00 00 00 mov $0x3c,%eax
4000d0: bf 00 00 00 00 mov $0x0,%edi
4000d5: 0f 05 syscall
所以从目标文件中唯一改变的是关键线:
4000ba: 48 be d8 00 60 00 00 movabs $0x6000d8,%rsi
4000c1: 00 00 00
现在指向地址0x6000d8
(小端的d8 00 60 00 00 00 00 00
)而不是0x0
。
这是hello_world
字符串的正确位置吗?
要决定我们必须检查程序头,它告诉Linux在哪里加载每个部分。
我们用以下方法拆卸它们:
readelf -l hello_world.out
这使:
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
LOAD 0x0000000000000000 0x0000000000400000 0x0000000000400000
0x00000000000000d7 0x00000000000000d7 R E 200000
LOAD 0x00000000000000d8 0x00000000006000d8 0x00000000006000d8
0x000000000000000d 0x000000000000000d RW 200000
Section to Segment mapping:
Segment Sections...
00 .text
01 .data
这告诉我们.data
部分是第二部分,从VirtAddr
= 0x06000d8
开始。
数据部分唯一的问题是我们的hello world字符串。
实际上,可以说链接相对简单。
从最简单的意义上说,它只是将对象文件1捆绑在一起,因为它们已经包含了各自源代码中包含的每个函数/全局/数据的发出程序集。链接器在这里可能非常愚蠢,只需将所有内容视为符号(名称)及其定义(或内容)。
显然,链接器需要生成一个尊重某种格式的文件(一般在Unix上的ELF格式),并将各种类别的代码/数据分成文件的不同部分,但这只是调度。
我所知道的两个并发症是:
1:编译不同翻译单元的结果(粗略地说,预处理的源文件)
除了已经提到的“Linkers and Loaders”之外,如果你想知道真实和现代的链接器是如何工作的,你可以启动here。