前言

程序猿在编程的代码无非是由函数和各种变量，以及对这些变量的读、写。不管是变量还是函数，它们最终都要存储在内存里。为每个变量和函数正确地分配内存空间，记录它们的地址，并把这个地址复写回调用或引用它们的地方。

而负责将这些符号转换成地址就是由链接器完成的 ~~~

通常分成3种情况：

静态链接：

  • 生成二进制可执行文件的过程中。

动态链接：

  • 在二进制文件被加载进内存时。在二进制文件保留符号，在加载时再把符号解析成真实的内存地址
  • 在运行期间解析符号。这种情况会把符号的解析延迟到最后不得不做时才去做符号的解析

接下来，我将详细介绍这2种链接的具体工作原理。

前置知识

这部分主要记录ELF文件格式，已经会的可以直接跳到链接部分。

ELF：可执行和链接格式

ELF（Executable and Linkable Format）

ELF格式文件不仅用于可执行文件，还可以存储可重定位目标文件、动态库文件等。也就是说，ELF文件既要承载编译的输出(可重定位目标文件)，又要承载链接的输出(可执行文件)，因此其文件格式需要同时满足这两个功能。

image-20240416143913414

可重定位目标文件格式

可重定位目标文件格式

可重定位目标文件主要包含代码部分和数据部分，它可以与其他可重定位目标文件链接，从而创建可执行目标文件、共享库文件。

  • 可被链接（合并）生成可执行文件或共享目标文件；

  • 静态链接库文件由若干个可重定位目标文件组成；

  • 包含代码、数据（已初始化全局变量和局部静态变量.data和未初始化的全局变量和局部静态变量.bss）

  • 包含重定位信息（指出哪些符号引用处需要重定位）

  • 文件扩展名为.o（相当于Windows中的 .obj文件）

    格式如下：由ELF头，节，节头表组成。

（1）ELF头

readelf -h 命令对某个可重定位目标文件的 ELF 头进行解析

浅浅查看一下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
 penge@penge-virtual-machine  ~/Desktop/MordenCpp/tmp  readelf -h main.o
ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 
  Class:                             ELF64
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              REL (Relocatable file)
  Machine:                           Advanced Micro Devices X86-64
  Version:                           0x1
  Entry point address:               0x0
  Start of program headers:          0 (bytes into file)
  Start of section headers:          848 (bytes into file)
  Flags:                             0x0
  Size of this header:               64 (bytes)
  Size of program headers:           0 (bytes)
  Number of program headers:         0
  Size of section headers:           64 (bytes)
  Number of section headers:         13
  Section header string table index: 12

ELF 头位于目标文件的起始位置，包含文件结构说明信息。分32位版本和64位版本。

32位系统对应的数据结构，共占 52（0x34）字节：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
#define EI_NIDENT 16

typedef struct {
   unsigned char e_ident[EI_NIDENT]; // 开始的四个字节是魔数，后面的16个字节包含一些标识信息，如字节序、32/64位、版本号等
   Elf32_Half e_type;      // 目标文件类型（可重定位文件、可执行文件、共享库文件还是其他类型文件）
   Elf32_Half e_machine;   // 机器结构类型（如 IA-32、AMD 64等）
   Elf32_Word e_version;   // 目标文件版本
   Elf32_Addr e_entry;     // 指定系统将控制权转移到的起始虚拟地址（程序入口点），如果没有关联入口点则为0，比如可重定位文件就是0
   Elf32_Off e_phoff;
   Elf32_Off e_shoff;      // 节头表在文件中的偏移量（以字节为单位）
   Elf32_Word e_flags;
   Elf32_Half e_ehsize;    // ELF 头的大小（以字节为单位）
   Elf32_Half e_phentsize; 
   Elf32_Half e_phnum;
   Elf32_Half e_shentsize; // 节头表中一个表项的大小，所有表项大小相同
   Elf32_Half e_shnum;     // 节头表项的个数
   Elf32_Half e_shstrndx;
} Elf32_Ehdr;

  • 魔数：文件开头几个字节通常用来确定文件的类型或格式。

    • a.out的魔数：01H 07H
    • PE格式魔数：4DH 5AH
    • 加载或读取文件时，可用魔数确认文件类型是否正确

  • 仅 ELF 头在文件中具有固定位置，即总是在开头位置，其余部分的位置由 ELF 头和节头表指出。

  • 因为是可重定位文件，所以字段 e_entry 为0，无程序头表（Size of program headers = 0）。

（2）节

节是 ELF 文件中的主体信息，包含了链接过程所用的目标代码信息，包括指令、数据、符号表和重定位信息等。

节名 说明
.text 已编译程序的机器代码
.rodata 只读数据，如 printf 语句中的格式串、开关语句（switch-case）的跳转表等
.data 已初始化的全局变量
.bss 未初始化的全局和静态变量，以及所有被初始化为 0 的全局或静态变量。在目标文件中这个节不占据实际的空间，它仅仅是一个占位符，为了节省空间。在运行时，在内存中将这些变量初始化为 0。
.symtab 符号表（symbol table）,程序中定义的函数名和全局静态变量名都属于符号，与这些符号相关的信息保存在符号表中。每个可重定位目标文件都有一个 .symtab 节。和编译器中的符号表不同， .symtab 符号表不包含局部变量的条目。
.rel.text .text 节相关的重定位信息。当链接器合并目标文件时，.text 中的代码合并后部分位置的数据需要修改。一般而言，任何调用外部函数或者引用全局变量的指令都需要修改定位信息。另一方面，调用本地函数的指令则不需要修改。 TIP：可执行文件中并不需要重定位信息。
.rel.data .data 节相关的可重定位信息。一般而言，任何已初始化的全局变量，如果它的初始值是一个全局变量地址或者外部定义函数的地址，都需要被修改。
.debug 调试用符号表。其条目是程序中定义的全局变量和类型定义，程序中定义和引用的全局变量，以及原始的 C 源文件。
.line C 源程序中的行号和 .text 节中机器指令之间的映射。
.strtab 字符串表。包括 .symtab 节和 .debug 节中的符号以及节头表中的节名。字符串表就是以 null 结尾的字符序列。

（3）节头表

节头表（Section Header Table）由若干表项组成，每个表项描述相应的一个节的节名、在文件中的偏移、大小、访问属性、对齐方式等，目标文件中的每个节都有一个表项与之对应。

  • 除ELF头之外，节头表是ELF可重定位目标文件中最重要的部分内容。

以下是 32 位系统对应的数据结构（每个表项占40B）：

1
2
3
4
5
6
7
8
9
10
11
12
13
typedef struct {
   Elf32_Word sh_name;  // 节名字符串在.strtab中的偏移
   Elf32_Word sh_type;  // 节类型：无效/代码或数据/符号/字符串/…
   Elf32_Word sh_flags; // 节标志：该节在虚拟空间中的访问属性
   Elf32_Addr sh_addr;  // 虚拟地址：若可被加载，则对应虚拟地址
   Elf32_Off sh_offset; // 在文件中的偏移地址，对.bss节而言则无意义
   Elf32_Word sh_size;  // 节在文件中所占的长度
   Elf32_Word sh_link;  // sh_link和sh_info用于与链接相关的节（如.rel.text节、.rel.data节、.symtab节等）
   Elf32_Word sh_info;
   Elf32_Word sh_addralign;   // 节的对齐要求
   Elf32_Word sh_entsize;     // 节中每个表项的长度，0表示无固定长度表项
} Elf32_Shdr;

  • 比较特殊的一个地方：.bss 在文件中不占用空间，但节头表记录了 .bss 节的长度为 0x0c = 12，因此需要在主存中给 .bss 节分配 12 字节空间。

整体就是通过 ELF 头连接了节头表，再通过节头表把每一个节连接起来了。

可执行目标文件格式

image-20240415164614632

与可重定文件稍有不同：

  • ELF头中字段 e_entry 给出执行程序时第一条指令的地址，而在可重定位文件中，此字段为0；
  • 多一个程序头表，也称段头表（segment header table），是一个结构数组，用来说明段信息；
  • 多一个.init节，用于定义_init函数，该函数用来进行可执行目标文件开始执行时的初始化工作；
  • 少两个.rel节（无需重定位）。

在可执行文件中，ELF 头、程序头表、.init 节、.fini 节、.text 节和 .rodata 节合起来可构成一个只读代码段；.data 节和 .bss 节合起来可构成一个可读写数据段。显然，在可执行文件启动执行时，这两个段必须装入内存，因而称为可装入段。

静态链接

认知

先对链接器的的两步链接有个整体的认识：

第一步是，链接器需要对编译器生成的多个目标（.o) 文件进行合并，采取的策略是相似段的合并，最终生成共享文件 (.so) 或者可执行文件。这个阶段中，链接器对输入的各个目标文件进行扫描，获取各个段的大小，并且同时会收集所有的符号定义以及引用信息，构建一个全局的符号表。当链接器构造好了最终的文件布局以及虚拟内存布局后，我们根据符号表，也就能确定了每个符号的虚拟地址了。

第二步是，链接器会对整个文件再进行第二遍扫描，这一阶段，会利用第一遍扫描得到的符号表信息，依次对文件中每个符号引用的地方进行地址替换。也就是对符号的解析以及重定位过程。

简单来讲就是进行两遍扫描：【重点中的重点】第一遍扫描完成文件合并、虚拟内存布局的分配以及符号信息收集；第二遍扫描则是完成了符号的重定位过程。

接下来，我将分类讨论各种符号的处理方式。

在实操之前，先说总结：

  1. 静态函数不需要重定位因为和执行单元代码都在.text段，相对位置在编译的时候就能确定了，因为链接器合并中间文件时相对位置不会变。
  2. 静态变量需要重定位，因为和编译单元代码段.text分属不同的section，在.data，链接器合并文件时会重新排布，所以需要重定位。
  3. 全局变量/函数，外部变量/函数都是需要被重定位的，大致方法就是：编译器先用0占位符号、链接重定位表找符号、定位符号地址、然后在当前代码段计算RIP相对偏移位置填上。

实操

开始实操

工具：readelf 查看 elf 文件 和 objdump 查看反汇编。

  • objdump：对二进制文件进行反汇编
  • readelf ：解析二进制文件信息

例子：

example.c

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
// example.c
extern int extern_var;
int global_var = 1;
static int static_var = 2;
 
extern int extern_func();
int global_func() {
    return 10;
}
 
static int static_func() {
    return 20;
}
 
int main() {
    int var0 = extern_var;
    int var1 = global_var;
    int var2 = static_var;
    int var3 = extern_func();
    int var4 = global_func();
    int var5 = static_func();
    return var0 + var1 + var2 + var3 + var4 + var5;
}

external.c

1
2
3
4
5
// external.c
int extern_var = 3;
int extern_func() {
    return 30;
}
1
2
3
⚙ penge@penge-virtual-machine  ~/Desktop/MordenCpp/tmp1  gcc example.c -c -o example.o -fno-PIC -g
⚙ penge@penge-virtual-machine  ~/Desktop/MordenCpp/tmp1  gcc external.c -c -o external.o -fno-PIC -g
⚙ penge@penge-virtual-machine  ~/Desktop/MordenCpp/tmp1  gcc external.o example.o -o a.out -no-pie
  • -fno-PIC ：告诉编译器不要生成 PIC 的代码。
  • PIC（Position-Independent Code，位置无关代码）是一种编程技术，主要用于创建共享库（shared libraries），使其能够在内存中的任何位置加载和执行，而不需要在加载时进行重新定位（relocation）。

我们将两个.o 文件链接生成可执行文件

1
gcc external.o example.o -o a.out -no-pie
  • -no-pie 表示关闭 pie 的模式。gcc 会默认打开 pie 模式，也就意味着系统 loader 对加载可执行文件时的起始地址，会随机加载。关闭 pie 之后，在 Linux 64 位的系统下，默认的加载起始地址是 0x400000。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
 penge@penge-virtual-machine  ~/Desktop/MordenCpp/tmp1  objdump -S example.o

example.o:     file format elf64-x86-64


Disassembly of section .text:

0000000000000000 <global_func>:
extern int extern_var;
int global_var = 1;
static int static_var = 2;
extern int extern_func();
int global_func()
{
   0:	f3 0f 1e fa          	endbr64 
   4:	55                   	push   %rbp
   5:	48 89 e5             	mov    %rsp,%rbp
    return 10;
   8:	b8 0a 00 00 00       	mov    $0xa,%eax
}
   d:	5d                   	pop    %rbp
   e:	c3                   	retq   

000000000000000f <static_func>:
static int static_func()
{
   f:	f3 0f 1e fa          	endbr64 
  13:	55                   	push   %rbp
  14:	48 89 e5             	mov    %rsp,%rbp
    return 20;
  17:	b8 14 00 00 00       	mov    $0x14,%eax
}
  1c:	5d                   	pop    %rbp
  1d:	c3                   	retq   

000000000000001e <main>:
int main()
{
  1e:	f3 0f 1e fa          	endbr64 
  22:	55                   	push   %rbp
  23:	48 89 e5             	mov    %rsp,%rbp
  26:	48 83 ec 20          	sub    $0x20,%rsp
    int var0 = extern_var;
  2a:	8b 05 00 00 00 00    	mov    0x0(%rip),%eax        # 30 <main+0x12>
  30:	89 45 e8             	mov    %eax,-0x18(%rbp)
    int var1 = global_var;
  33:	8b 05 00 00 00 00    	mov    0x0(%rip),%eax        # 39 <main+0x1b>
  39:	89 45 ec             	mov    %eax,-0x14(%rbp)
    int var2 = static_var;
  3c:	8b 05 00 00 00 00    	mov    0x0(%rip),%eax        # 42 <main+0x24>
  42:	89 45 f0             	mov    %eax,-0x10(%rbp)
    int var3 = extern_func();
  45:	b8 00 00 00 00       	mov    $0x0,%eax
  4a:	e8 00 00 00 00       	callq  4f <main+0x31>
  4f:	89 45 f4             	mov    %eax,-0xc(%rbp)
    int var4 = global_func();
  52:	b8 00 00 00 00       	mov    $0x0,%eax
  57:	e8 00 00 00 00       	callq  5c <main+0x3e>
  5c:	89 45 f8             	mov    %eax,-0x8(%rbp)
    int var5 = static_func();
  5f:	b8 00 00 00 00       	mov    $0x0,%eax
  64:	e8 a6 ff ff ff       	callq  f <static_func>
  69:	89 45 fc             	mov    %eax,-0x4(%rbp)
    return var0 + var1 + var2 + var3 + var4 + var5;
  6c:	8b 55 e8             	mov    -0x18(%rbp),%edx
  6f:	8b 45 ec             	mov    -0x14(%rbp),%eax
  72:	01 c2                	add    %eax,%edx
  74:	8b 45 f0             	mov    -0x10(%rbp),%eax
  77:	01 c2                	add    %eax,%edx
  79:	8b 45 f4             	mov    -0xc(%rbp),%eax
  7c:	01 c2                	add    %eax,%edx
  7e:	8b 45 f8             	mov    -0x8(%rbp),%eax
  81:	01 c2                	add    %eax,%edx
  83:	8b 45 fc             	mov    -0x4(%rbp),%eax
  86:	01 d0                	add    %edx,%eax
}
  88:	c9                   	leaveq 
  89:	c3                   	retq

各种符号的处理方式

局部变量

从反汇编的结果里，我们可以看到，局部变量在程序中的地址，都是基于 %rbp的偏移这种形式，rbp 寄存器存放的是当前函数栈帧的基地址。这些局部变量的内存分配与释放，都是在运行时通过 %rbp 的改变来进行的，因此，局部变量的内存地址不需要链接器来操心。

静态函数

它是唯一不需要重定位的类型。

1
2
3
 int var5 = static_func();
5f:	b8 00 00 00 00       	mov    $0x0,%eax
64:	e8 a6 ff ff ff       	callq  f <static_func>

e8是callq指令的编码，后边 4个字节就对应被调函数的地址。

如果采用小端的字节序数值来表示0x ff ff ff a6也就是对应十进制的-90。

此时，当 CPU执行到 callq这条指令时，rip 寄存器的值指向的是下一条指令的内存地址，也就是 5d这条指令的内存地址，通过计算0x69 – 90可以得到 0xf。从反汇编中可以得到，0xf 刚好是 static_fun 的地址。

image-20240419135448453

同一个编译单元内部，static_func 与 main 函数的相对位置是固定不变的，即便链接的过程中会对不同.o 文件中的代码段进行合并，但是同一个.o 文件内部不同函数之间的位置也会保持不变，因此，我们在编译的时候，就能确定对静态函数调用的偏移。也就是说，静态函数的调用地址在编译阶段就可以确定下来。

外部变量，全局变量以及静态变量

从反汇编结果中看到，前三条语句对 extern_var、global_var 和 static_var 的访问，都生成了一条 mov 0x0(%rip)，%eax 的指令。这是因为在这个时候，编译器还无法确定这三个变量的地址，因此，先通过 0 来进行占位，以后链接器会将真正的地址回填在这里。

extern_func 和 global_func 的调用

call 指令同样是通过 0 来进行占位，和全局变量的处理方式一样。

处理占位符【核心】

由于在无法确定变量的真实地址时，编译器先通过 0 来进行占位。所以，我们这里继续观察链接器对 extern_var，static_var，global_var，global_func 以及 extern_func 的重定位过程。我们来查看占位符是如何处理的。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
penge@penge-virtual-machine  ~/Desktop/MordenCpp/tmp1  readelf -S example.o

There are 21 section headers, starting at offset 0xb50:

Section Headers:
  [Nr] Name              Type             Address           Offset
       Size              EntSize          Flags  Link  Info  Align
  [ 0]                   NULL             0000000000000000  00000000
       0000000000000000  0000000000000000           0     0     0
  [ 1] .text             PROGBITS         0000000000000000  00000040
       000000000000008a  0000000000000000  AX       0     0     1
  [ 2] .rela.text        RELA             0000000000000000  00000760
       0000000000000078  0000000000000018   I      18     1     8
  [ 3] .data             PROGBITS         0000000000000000  000000cc
       0000000000000008  0000000000000000  WA       0     0     4
  [ 4] .bss              NOBITS           0000000000000000  000000d4
       0000000000000000  0000000000000000  WA       0     0     1
  [ 5] .debug_info       PROGBITS         0000000000000000  000000d4
       0000000000000126  0000000000000000           0     0     1
  [ 6] .rela.debug_info  RELA             0000000000000000  000007d8
       0000000000000228  0000000000000018   I      18     5     8
  [ 7] .debug_abbrev     PROGBITS         0000000000000000  000001fa
       00000000000000a4  0000000000000000           0     0     1
  [ 8] .debug_aranges    PROGBITS         0000000000000000  0000029e
       0000000000000030  0000000000000000           0     0     1
  [ 9] .rela.debug_arang RELA             0000000000000000  00000a00
       0000000000000030  0000000000000018   I      18     8     8
  [10] .debug_line       PROGBITS         0000000000000000  000002ce
       0000000000000067  0000000000000000           0     0     1
  [11] .rela.debug_line  RELA             0000000000000000  00000a30
       0000000000000018  0000000000000018   I      18    10     8
  [12] .debug_str        PROGBITS         0000000000000000  00000335
       000000000000011f  0000000000000001  MS       0     0     1
  [13] .comment          PROGBITS         0000000000000000  00000454
       0000000000000024  0000000000000001  MS       0     0     1
  [14] .note.GNU-stack   PROGBITS         0000000000000000  00000478
       0000000000000000  0000000000000000           0     0     1
  [15] .note.gnu.propert NOTE             0000000000000000  00000478
       0000000000000020  0000000000000000   A       0     0     8
  [16] .eh_frame         PROGBITS         0000000000000000  00000498
       0000000000000078  0000000000000000   A       0     0     8
  [17] .rela.eh_frame    RELA             0000000000000000  00000a48
       0000000000000048  0000000000000018   I      18    16     8
  [18] .symtab           SYMTAB           0000000000000000  00000510
       00000000000001f8  0000000000000018          19    16     8
  [19] .strtab           STRTAB           0000000000000000  00000708
       0000000000000055  0000000000000000           0     0     1
  [20] .shstrtab         STRTAB           0000000000000000  00000a90
       00000000000000bb  0000000000000000           0     0     1

其中的 readelf -S选项是打印出二进制文件中所有 section-header的信息。我们可以看到 example.o里总共包含了 12 个 section，重点看.rela.text 段。

从 section-header的信息里可以看到，.rela.text 段的类型是 RELA 类型，也就是重定位表。

链接器在处理目标文件的时候，需要对目标文件里代码段和数据段引用到的符号进行重定位，而这些重定位的信息都记录在对应的重定位表里。

一般来说，重定位表的名字都是以 .rela 开头，比如 .rela.text 就是对 .text 段的重定位表，.rela.data 是对 .data 段的重定位表。

1
2
3
4
5
6
7
8
9
 penge@penge-virtual-machine  ~/Desktop/MordenCpp/tmp1  readelf -r example.o 

Relocation section '.rela.text' at offset 0x760 contains 5 entries:
  Offset          Info           Type           Sym. Value    Sym. Name + Addend
00000000002c  001300000002 R_X86_64_PC32     0000000000000000 extern_var - 4
000000000035  001000000002 R_X86_64_PC32     0000000000000000 global_var - 4
00000000003e  000300000002 R_X86_64_PC32     0000000000000000 .data + 0
00000000004b  001400000004 R_X86_64_PLT32    0000000000000000 extern_func - 4
000000000058  001100000004 R_X86_64_PLT32    0000000000000000 global_func - 4

.rela.text 的重定位表里存放了text段中需要进行重定位的每一处信息。所以，每个重定位项都会包含需要重定位的偏移、重定位类型和重定位符号。

1
2
3
4
5
typedef struct {
    Elf64_Addr›   r_offset; /* 重定位表项的偏移地址 */
    Elf64_Xword›  r_info;   /* 重定位的类型以及重定位符号的索引 */
    Elf64_Sxword› r_addend; /* 重定位过程中需要的辅助信息 */
} Elf64_Rela;

其中，r_info 的高 32bit 存放的是重定位符号在符号表的索引，r_info 的低 32bit 存放的是重定位的类型的索引。符号表就是.symtab 段，可以把它看成是一个字典，这个字典以整数为 key ，以符号名为 value。

查看重定位表中的四项，它们的类型都是 R_X86_64_PC32。这种类型的重定位计算方式为：S + A – P。

  • S 表示完成链接后该符号的实际地址。在链接器将多个中间文件的段合并以后，每个符号就按先后顺序依次都会分配到一个地址，这就是它的最终地址 S。
  • A 表示 Addend 的值，它代表了占位符的长度。
  • P 表示要进行重定位位置的地址或偏移，可以通过 r_offset 的值获取到，这是引用符号的地方，也就是我们要回填地址的地方，简单说，它就是我们上文提到的用 0 填充的占位符的地址。

这里 S 与 P 所表示的地址都是文件合并之后最终的虚拟地址。

以extern_var为例进制演算：【下面的例子的地址和上面程序无关】

1
2
3
4
5
6
00000000004004ad <main>:
  4004ad:       55                      push   %rbp
  4004ae:       48 89 e5                mov    %rsp,%rbp
  4004b1:       48 83 ec 20             sub    $0x20,%rsp
  4004b5:       8b 05 75 0b 20 00       mov    0x200b75(%rip),%eax        # 601030 <extern_var>
  4004bb:       89 45 e8                mov    %eax,-0x18(%rbp)

  • S 是其最终符号的真实地址，如上汇编里边的注释所示 也就是上面注释的 0x601030 这个地址；

  • A 是 Addend 的值，可以从重定位表里查到是 -4，对于 A 的具体含义我还会进一步解释；

  • P 是重定位 offset 的地址，这里是 0x4004b7。

根据公式，我们算出重定位处需要填写的值应该是 0x601030 + (-4) – 0x4004b7 = 0x200b75，也就是最终可执行文件中这条 mov 指令里的值。

现在，我们从我们再从 CPU 的角度验证取值关系。从上面 main 函数的反编译的结果可以看到，我们最终对 extern_var 的访问生成的汇编是：

1
mov    0x200b75(%rip), %eax

这是一条 PC 相对偏移的寻址方式。当 CPU 执行到这条指令的时候，%rip 的值存放的是下一条指令的地址，也就是 0x4004bb。这时候可以算出 0x4004bb + 0x200b75 = 0x601030，刚好是 extern_var 的实际地址。

经过正面分析这个重定位的值的作用后，这里我们再来理解一下 S+A-P 这个公式的作用。链接器有了整体的虚拟内存布局后，知道的信息是：需要重定位符号的地址 S 的值是 (0x601030)，以及需要重定位的位置地址 P 的值是 (0x4004b7)。

其实，到这里不照本宣科的想一下更加比较容易的想·懂。

静态变量

static_var 的最终地址就是本编译单元的.data 段的最终地址。

动态链接

回顾下静态链接的过程：源文件经过编译生成可重定位文件（.o文件），再经过静态链接生成可执行的ELF文件，最终运行时，通过页加载和页错误的方式，保证进程的正常运行。

假如像printf，scanf，strlen等基础函数，每个应用中都会使用到，那么不同的程序中一定会包含它们的指令部分。这就导致这些程序在磁盘保存时，都有这些基础函数的副本。运行时，也会将这些副本加载到对应进程的虚拟空间内存中去。这就导致了浪费磁盘和内存。

那么，接下来就要引出下面的主角了，动态链接。

而动态链接的重定位的时机又可以分成：加载期间或者运行期间。

加载期间

简单介绍下：我们希望将常用的公共的函数都放到一个文件中，在整个系统里只会被加载到内存中一次，无论有多少个进程使用它，这个文件在内存中只有一个副本，这种文件就是动态链接库文件。

动态链接库文件

  • Linux：共享目标文件 (share object, so)
  • Window：动态链接库文件 (dynamic linking library, dll)

我们先看个超级简单的例子

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
//main.c
extern void func(int i);

int main()
{
    func(5);
    return 0;
}

//func.c
#include<stdio.h>
void func(int i)
{
    printf("input i = %d\n",i);
    return;
}
1
2
gcc -shared -fPIC -o libfunc.so fun.c
gcc main.c -o main -L./ -lfunc

  • -L： 指定了查找链接库的路径 (或者可以通过设置环境变量 LIBRARY_PATH 来追加路径)。 -L. 就是告诉链接器需要到当前目录下查找共享文件。

  • -l ：指定了具体链接库的名称，需要注意的是，gcc 在处理链接库名称时，会自动加上 lib的前缀和.so的后缀，所以，gcc 命令选项写的 -lfunc，就是告诉链接器查找libfunc.so这个共享目标文件。

运行指令

1
2
3
export LD_LIBRARY_PATH=./
./main
input i = 5

通过命令的指令我们浅浅的猜测一下，编译参数中 -lfunc存在的目的 ？

因为libfunc.so的符号表中有func，当链接器发现该符号存在于.so中，则将其作为动态符号处理。这也说明了，为什么静态链接阶段，我们还需要动态库的原因。静态链接阶段，动态库的作用就是用于区别符号的类型。

在多进程共享动态库的时候，因为代码段是不可写的，所以进程间共享不存在问题，而数据段可写，系统必须保证一个进程写了共享库的数据段，另外一个进程看不到。因此，不同的库在不同的进程加载地址可能是不同的。

下面通过简单的实践查看一下

1
2
3
4
5
6
7
#include <stdio.h>

int main(){
    printf("Hello World");
    getchar();
    return 0;
}

运行下面的指令

1
gcc example.c   -no-pie -o main
  • -no-pie 是禁止生成地址无关的可执行文件，方便查看进程的内存布局。

分别在终端启动2个程序，通过下面的命令查看进程pid，具体实践如下：

1
2
3
4
5
6
 ✘ penge@penge-virtual-machine  ~/Desktop/MordenCpp  ps aux | grep main

penge      13319  0.1  2.4 962872 95600 ?        Sl   15:38   0:02 /home/penge/.vscode-server/cli/servers/Stable-e170252f762678dec6ca2cc69aba1570769a5d39/server/node /home/penge/.vscode-server/cli/servers/Stable-e170252f762678dec6ca2cc69aba1570769a5d39/server/out/server-main.js --connection-token=remotessh --accept-server-license-terms --start-server --enable-remote-auto-shutdown --socket-path=/tmp/code-5e7b9f0b-d52b-4755-9d41-32cabc4825ca
penge      14196  0.0  0.0   2496   516 pts/2    S+   16:11   0:00 ./main
penge      14241  0.0  0.0   2496   580 pts/4    S+   16:11   0:00 ./main
penge      14405  0.0  0.0  12116  2728 pts/0    S+   16:13   0:00 grep --color=auto --exclude-dir=.bzr --exclude-dir=CVS --exclude-dir=.git --exclude-dir=.hg --exclude-dir=.svn --exclude-dir=.idea --exclude-dir=.tox mai

查看进程内存：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
 penge@penge-virtual-machine  ~/Desktop/MordenCpp  cat /proc/14241/maps
00400000-00401000 r--p 00000000 08:05 1090886                            /home/penge/Desktop/MordenCpp/tmp1/main
00401000-00402000 r-xp 00001000 08:05 1090886                            /home/penge/Desktop/MordenCpp/tmp1/main
00402000-00403000 r--p 00002000 08:05 1090886                            /home/penge/Desktop/MordenCpp/tmp1/main
00403000-00404000 r--p 00002000 08:05 1090886                            /home/penge/Desktop/MordenCpp/tmp1/main
00404000-00405000 rw-p 00003000 08:05 1090886                            /home/penge/Desktop/MordenCpp/tmp1/main
01932000-01953000 rw-p 00000000 00:00 0                                  [heap]
7f8c910fc000-7f8c9111e000 r--p 00000000 08:05 2232266                    /usr/lib/x86_64-linux-gnu/libc-2.31.so
7f8c9111e000-7f8c91296000 r-xp 00022000 08:05 2232266                    /usr/lib/x86_64-linux-gnu/libc-2.31.so
7f8c91296000-7f8c912e4000 r--p 0019a000 08:05 2232266                    /usr/lib/x86_64-linux-gnu/libc-2.31.so
7f8c912e4000-7f8c912e8000 r--p 001e7000 08:05 2232266                    /usr/lib/x86_64-linux-gnu/libc-2.31.so
7f8c912e8000-7f8c912ea000 rw-p 001eb000 08:05 2232266                    /usr/lib/x86_64-linux-gnu/libc-2.31.so
7f8c912ea000-7f8c912f0000 rw-p 00000000 00:00 0 
7f8c91308000-7f8c91309000 r--p 00000000 08:05 2232260                    /usr/lib/x86_64-linux-gnu/ld-2.31.so
7f8c91309000-7f8c9132c000 r-xp 00001000 08:05 2232260                    /usr/lib/x86_64-linux-gnu/ld-2.31.so
7f8c9132c000-7f8c91334000 r--p 00024000 08:05 2232260                    /usr/lib/x86_64-linux-gnu/ld-2.31.so
7f8c91335000-7f8c91336000 r--p 0002c000 08:05 2232260                    /usr/lib/x86_64-linux-gnu/ld-2.31.so
7f8c91336000-7f8c91337000 rw-p 0002d000 08:05 2232260                    /usr/lib/x86_64-linux-gnu/ld-2.31.so
7f8c91337000-7f8c91338000 rw-p 00000000 00:00 0 
7ffd5dcfd000-7ffd5dd1e000 rw-p 00000000 00:00 0                          [stack]
7ffd5ddd5000-7ffd5ddd9000 r--p 00000000 00:00 0                          [vvar]
7ffd5ddd9000-7ffd5dddb000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 --xp 00000000 00:00 0                  [vsyscall]
 penge@penge-virtual-machine  ~/Desktop/MordenCpp  cat /proc/14196/maps
00400000-00401000 r--p 00000000 08:05 1090886                            /home/penge/Desktop/MordenCpp/tmp1/main
00401000-00402000 r-xp 00001000 08:05 1090886                            /home/penge/Desktop/MordenCpp/tmp1/main
00402000-00403000 r--p 00002000 08:05 1090886                            /home/penge/Desktop/MordenCpp/tmp1/main
00403000-00404000 r--p 00002000 08:05 1090886                            /home/penge/Desktop/MordenCpp/tmp1/main
00404000-00405000 rw-p 00003000 08:05 1090886                            /home/penge/Desktop/MordenCpp/tmp1/main
01584000-015a5000 rw-p 00000000 00:00 0                                  [heap]
7f9f9f286000-7f9f9f2a8000 r--p 00000000 08:05 2232266                    /usr/lib/x86_64-linux-gnu/libc-2.31.so
7f9f9f2a8000-7f9f9f420000 r-xp 00022000 08:05 2232266                    /usr/lib/x86_64-linux-gnu/libc-2.31.so
7f9f9f420000-7f9f9f46e000 r--p 0019a000 08:05 2232266                    /usr/lib/x86_64-linux-gnu/libc-2.31.so
7f9f9f46e000-7f9f9f472000 r--p 001e7000 08:05 2232266                    /usr/lib/x86_64-linux-gnu/libc-2.31.so
7f9f9f472000-7f9f9f474000 rw-p 001eb000 08:05 2232266                    /usr/lib/x86_64-linux-gnu/libc-2.31.so
7f9f9f474000-7f9f9f47a000 rw-p 00000000 00:00 0 
7f9f9f492000-7f9f9f493000 r--p 00000000 08:05 2232260                    /usr/lib/x86_64-linux-gnu/ld-2.31.so
7f9f9f493000-7f9f9f4b6000 r-xp 00001000 08:05 2232260                    /usr/lib/x86_64-linux-gnu/ld-2.31.so
7f9f9f4b6000-7f9f9f4be000 r--p 00024000 08:05 2232260                    /usr/lib/x86_64-linux-gnu/ld-2.31.so
7f9f9f4bf000-7f9f9f4c0000 r--p 0002c000 08:05 2232260                    /usr/lib/x86_64-linux-gnu/ld-2.31.so
7f9f9f4c0000-7f9f9f4c1000 rw-p 0002d000 08:05 2232260                    /usr/lib/x86_64-linux-gnu/ld-2.31.so
7f9f9f4c1000-7f9f9f4c2000 rw-p 00000000 00:00 0 
7ffd481b7000-7ffd481d8000 rw-p 00000000 00:00 0                          [stack]
7ffd481f7000-7ffd481fb000 r--p 00000000 00:00 0                          [vvar]
7ffd481fb000-7ffd481fd000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 --xp 00000000 00:00 0                  [vsyscall]

可以看出同样的/usr/lib/x86_64-linux-gnu/libc-2.31.so但是空间是不一样的。

因此这时候就有了地址无关代码。

PIC

百度百科：在计算机领域中，地址无关代码 (position-independent code，PIC)，又称地址无关可执行文件 (position-independent executable，PIE) ，是指可在主存储器中任意位置正确地运行，而不受其绝对地址影响的一种机器码。

再介绍PIC之前，先说说之前不同的库在不同的进程加载地址可能是不同的导致的问题吧。

问题

image-20240419135438733

如上图所示，如果两个进程共享了libc.so和libd.so两个动态库，而且 libc 中会调用 libd 中定义的 foo 方法。

进程 1 将 foo 方法映射到自己的虚拟地址 0x1000 处，而调用 foo 方法的指令被映射到 0x2000 处，那么 call 指令如果采用依赖 rip 寄存器的相对寻址的办法，这个偏移量应该填 -0x1000。进程 2 将 foo 方法映射到自己虚拟地址 0x2000 处，调用 foo 方法的指令被映射到 0x5000 处，那么 call 指令的参数就应该填 -0x3000。这就产生了冲突。

因此需要地址无关代码技术。

在计算机科学领域，有一句名言：“计算机领域的所有问题都可以使用新加一层抽象来解决”。

那么有了这句话的引导，要实现代码段的地址无关代码，思路是通过添加一个中间层，使得对全局符号的访问由直接访问变成间接访问。

我们可以引入一个固定地址，让引用者与这个固定地址之间的相对偏移是固定的，然后这个地址处再填入 foo 函数真正的地址。当然，这个地方必然位于数据段中，是每个进程私有的，这样才能做到在不同的进程里，可以访问不同的虚拟地址。这个新引入的固定地址就是全局偏移表 (Global Offset Table, GOT)。

GOT 的工作原理如下

image-20240419135432310

在上图中，call指令处被填入了 0x3000，这是因为进程 1 的 GOT 与 call 指令之间的偏移是 0x5000-0x2000=0x3000，同时进程 2 的 GOT 与 call指令之间的偏移是 0x8000-0x5000=0x3000。所以对于这一段共享代码，不管是进程 1 执行还是进程 2 执行，它们都能跳到自己的GOT 表里。

然后，进程 1 通过访问自己的 GOT 表，查到 foo 函数的地址是 0x1000，它就能真正地调用到 foo 函数了。进程 2 访问自己的 GOT 表，查到 foo 函数的地址是 0x2000，它也能顺利地调用 foo 函数。这样我们就通过引入了 GOT 这个间接层，解决了 call 指令和 foo 函数定义之间的偏移不固定的问题。

这种技术就是地址无关代码 (Position Independent Code, PIC)。

精髓：【GOT表是在.so中的】

这个验证也比较简单，可以尝试自己通过程序验证下。

因此，共享库的好处也呼之欲出了。

静态库 VS 动态库

  • 静态库是在编译阶段就和可执行文件打包链接在一起的，它可以看成是中间文件的简单集合，保留了符号，只有在静态链接的过程，才会真正地做地址分配和重定位。
  • 动态库在编译阶段，它的代码并不会被合并进可执行文件中，在运行时才会被加载进内存，它被加载进内存的地址是不固定的，所以每次加载完成以后，才能为它的符号分配真实的内存地址，然后再把地址回填到引用它的GOT中。动态库的一个优点是可以在多个进程间共享，从而可以减少内存的重复。

进一步理解：

基本概念

  1. 全局偏移表（GOT）：GOT是一种数据结构，用于存储在位置无关代码（PIC）中需要动态链接的全局变量和函数的实际地址。
    • 在位置无关代码中，访问全局变量和函数时，不是直接使用绝对地址，而是通过GOT的偏移量来访问。
  2. 位置无关代码（PIC）：
    • PIC使得共享库可以在内存中的任何位置加载和执行，不需要在加载时进行重新定位（relocation）。

GOT的工作原理

  1. 编译时：
    • 编译器生成位置无关代码（PIC），并将需要动态链接的全局变量和函数的引用转换为对GOT的间接访问。
    • 例如，引用函数foo时，代码中会生成对GOT中某个偏移量的访问，例如GOT[foo]。
  2. 加载时：
    • 动态链接器（dynamic linker）在加载共享库时，会将实际的函数地址填入GOT中相应的位置。
    • 这样，程序执行时，通过GOT的偏移量访问全局变量和函数，实际访问的是动态链接器填入的地址。

GOT为什么可以保证多个进程的.so库地址到GOT表的相对地址相同

  1. 相对位置固定：
    • 在生成共享库时，编译器确保GOT的位置相对于共享库的基地址是固定的。
    • 例如，假设共享库的基地址是0x1000，GOT的偏移量是0x200，那么GOT的地址就是0x1000 + 0x200 = 0x1200。
  2. 基地址无关：
    • 当共享库被加载到内存中时，实际的基地址可能不同，但GOT的相对偏移量是固定的。
    • 例如，一个进程加载共享库到地址0x5000，那么GOT的地址是0x5000 + 0x200 = 0x5200；另一个进程加载到地址0x8000，GOT的地址是0x8000 + 0x200 = 0x8200。
  3. 通过GOT访问：
    • 程序访问全局变量和函数时，是通过GOT的偏移量进行的。
    • 例如，访问函数foo时，代码会访问GOT[foo]，无论共享库被加载到哪里，这个偏移量都是GOT基地址 + foo的偏移量。

运行期间

动态链接过程的基本原理：动态链接通过GOT 表加一层间接跳转的方式，解决了代码中 call 指令对绝对地址的依赖，从而实现了PIC的能力。

动态链接存在的问题：

  1. 每次对全局符号的访问都要转换为对 GOT 表的访问，然后进行间接寻址，这必然要比直接的地址访问速度慢很多。
  2. 动态链接和静态链接的区别是将链接中重定位的过程推迟到程序加载时进行。因此在程序启动的时候，动态链接器需要对整个进程中依赖的 so 进行加载和链接，也就是对进程中所有 GOT 表中的符号进行解析重定位。

延迟绑定技术

为了避免在加载时就把 GOT 表中的符号全部解析并重定位，那么就采取懒操作，把要做的事情推迟到必须做的时刻。简单来说，将函数地址的重定位工作一直推迟到第一次访问的时候再进行，这就是延迟绑定 (Lazy binding) 的技术。这样对于整个程序运行过程中没有访问到的全局函数，可以避免对这类符号的重定位工作，提高程序性能。

延迟绑定的实现使用了两个特殊的数据结构

  • 全局偏移表（Global Offset Table，GOT）
  • 过程链接表（Procedure Linkage Table，PLT）

大致的实现思路是我们把 GOT 中的待解析符号的地方都填成动态符号解析的函数，当 CPU 执行到这个函数的时候，就会跳转进去解析符号，然后把 GOT 表的这一项填成符号的真正的地址。

接下来，我们来看看下面的例子：

过程链接表（Procedure Linkage Table， PLT)，将动态解析符号的过程做成了三级跳。

image-20240419135425681

仔细查看，会发现上面的这张图多了.plt段。

在代码段里，main 函数对 B 函数的调用转成了对"B@plt"的调用，"B@plt"函数只有三条指令

  • 第一条指令 jmp *(GOT[3]) 是一个间接跳转，跳转的目标是 GOT 表偏移为 0x18 的位置，这个位置应该放的是 B 函数的真实地址，但是第一次访问时，里面肯定是为空的，因为在加载时，并没有进行重定位。因此现在填入的是指向了 B@plt + 0x6 的位置，这是为了传递参数给 _dl_runtime_resolve 函数。
  • B@plt+0x6 的位置其实就是 B@plt 函数的第二条指令，它的作用是将函数参数入栈。
  • 接着执行第三条指令 jmp .plt 再准备第二个参数。

3级跳分析：

  • 序号①箭头的位置，也就是第一级跳转，它的目的是把参数 0 入栈。由于 GOT 表的 0x0，0x8，0x10 的位置都被占用了，所以参数 0 代表的就是 0x18 位置，这就是 B 函数的真实地址应该存放的地方。

  • 序号②箭头的位置，发生了第二级跳转，这一次是为了把动态库的 ID 号压栈传参。

  • 序号③箭头的位置，继续进行第三级跳转，这一次跳转才真正地调用到了 _dl_runtime_resolve【动态解析符号的函数 _dl_runtime_resolve 依赖两个参数，一个是当前动态库的 ID，另一个是要解析的符号在 GOT 表中的序号】。调用完这个方法以后，B 函数的真实地址就会被填入 GOT 表中了。

image-20240419135418296

最后，总结一下 GOT 表中的各个表项的含义。

  • GOT.PLT[0]位置被加载器保留，它里面存放的是.dynamic 段的地址，这里我们不用关心。
  • GOT.PLT[1]位置存放的是当前 so 的 ID，这个 ID 是加载器在加载当前动态库文件的时候分配的。
  • GOT.PLT[2]位置存放的是动态链接函数的入口地址，一般是动态链接器中的 _dl_runtime_resovle 函数。这个函数的作用是找到需要查找的符号地址，并最终回填到 GOT.PLT 表的对应位置。

然后再回顾一下延迟绑定的整个过程。

  1. 当 demo 函数想要调用 global_func 的时候，程序调用先进入 global_func@plt 中；
  2. 在 global_func@plt 中，会先执行 jmpq *GOT.PLT[3] ，此时 GOT.PLT[3] 里存放的是 global_func@plt 项中的第二条指令，因此控制流继续返回到 global_func@plt 中进行执行；
  3. 接下会把数值 0x0 进行压栈，这个数值代表了 global_func 的 ID。然后 jmp 到 PLT[0] 的表项中进行执行；
  4. 在 PLT[0] 中，继续将 GOT.PLT[1] 的值也就是库文件的 ID 进行压栈，然后通过 GOT.PLT[2] 跳转到 _dl_runtime_resolve 函数中；
  5. dl_runtime_resolve 则根据存在栈上的函数 ID 和 so 的 ID 进行全局搜索，找到对应的函数地址之后就可以将其重新填充到 GOT.PLT[3] 中，这个时候延迟加载的整个过程就完成了；
  6. 当下一次调用 global_func 的时候，CPU 就可以通过 global_func@plt 中第一条指令 jmpq *GOT.PLT[3] 直接跳转到 global_func 的真实地址中。

Loader加载机制

一个完全静态链接的可执行文件则不需要动态链接器的辅助，所以内核加载完之后可以直接跳转到用户代码的入口中进行执行。而动态链接的可执行文件 a.out需要链接器。

Linux环境下：动态链接器名为ld.so，又因为它还负责加载动态库文件，所以我们有时也叫它 loader，或者加载器。

ld-linux.so完成4个工作：

  • 启动动态链接器
  • 根据可执行文件的动态链接信息，寻找并加载可执行文件依赖的.so文件
  • 对符号进行解析和重定位
  • 依次执行各个 so 的 init 函数

image-20240419140052826

总结

  • 重定位的概念：编译器在把源代码翻译成汇编指令的过程中，由于不知道其他编译单元的符号的真实地址，在引用这些符号的时候只能使用占位符（通常是 0）来代替。这些占位符由链接器填充。当链接器把所有的符号的位置都确定好以后，再把真实地址回填到占位符里。
  • 重定位的时机：编译期重定位，加载期和运行时重定位。
  • 负责动态链接的是ld-linux.so，它被称为动态链接器，但因为它还负责加载文件工作，所以也被人称为加载器或者 loader。它的工作流程主要有启动，加载，重定位和 init 四个步骤。

参考资料

  • 《程序员的自我修养》
  • 《CSAPP》
  • 《LINUX GNU C 程序观察 (罗秋明) 》
  • 《高级C/C++编译技术》
  • 极客时间