C ++链接如何在实践中发挥作用?我正在寻找的是关于如何链接发生的详细解释,而不是哪些命令进行链接。
关于编译的问题已经有了类似的问题,但没有详细说明:How does the compilation/linking process work?
答案 0 :(得分:48)
编辑:我已将此答案移至副本: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
寄存器中,该寄存器将传递给写入系统调用。
但是等等!当程序加载时,编译器如何知道"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
在重新定位的地址 value ,因此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 :(得分:9)
实际上,人们可以说链接相对简单。
从最简单的意义上说,它只是将目标文件 1 捆绑在一起,因为那些已包含各自源中包含的每个函数/全局/数据的发出程序集。链接器在这里可能非常愚蠢,只需将所有内容视为符号(名称)及其定义(或内容)。
显然,链接器需要生成一个尊重某种格式的文件(一般在Unix上的ELF格式),并将各种类别的代码/数据分成文件的不同部分,但这只是调度。
我所知道的两个并发症是:
需要对符号进行重复删除:某些符号存在于多个目标文件中,只有一个符号应该在创建的结果库/可执行文件中出现;链接器作业只包含其中一个定义
链接时优化:在这种情况下,目标文件不包含发出的程序集,而是包含中间表示,链接器将所有目标文件合并在一起,应用优化传递(例如内联),将其编译为装配,最后发出结果。
1 :编译不同翻译单元的结果(粗略地说,是预处理的源文件)
答案 2 :(得分:7)
除了已经提到的“Linkers and Loaders”之外,如果您想知道真实和现代链接器的工作原理,您可以启动here。