目录
目标文件
编译和链接这两个步骤，在Windows下被我们的IDE封装的很完美，我们⼀般都是⼀键构建⾮常⽅便，但⼀旦遇到错误的时候呢，尤其是链接相关的错误，很多⼈就束⼿⽆策了。在Linux下，我们之前也学习过如何通过gcc编译器来完成这⼀系列操作。
先来回顾下什么是编译呢？编译的过程其实就是将我们程序的源代码翻译成CPU能够直接运⾏的机器
代码。
⽐如：在⼀个源⽂件 hello.c ⾥便简单输出"hello world!"，并且调⽤⼀个run函数，⽽这个函数被定义在另⼀个原⽂件 code.c 中。这⾥我们就可以调⽤ gcc -c 来分别编译这两个原⽂件。
可以看到，在编译之后会⽣成两个扩展名为 .o 的⽂件，它们被称作⽬标⽂件（可重定位目标文件）。要注意的是如果我们修改了⼀个原⽂件，那么只需要单独编译它这⼀个，⽽不需要浪费时间重新编译整个⼯程。⽬标⽂件是⼀个⼆进制的⽂件，⽂件的格式是 ELF ，是对⼆进制代码的⼀种封装。
file name //用于辨别文件类型
ELF文件
要理解编译链接的细节，我们不得不了解⼀下ELF⽂件。其实有以下四种⽂件其实都是ELF⽂件：
- 可重定位⽂件（Relocatable File） ：即 xxx.o ⽂件。包含适合于与其他⽬标⽂件链接来创建可执⾏⽂件或者共享⽬标⽂件(动态库)的代码和数据。
- 可执⾏⽂件（Executable File） ：即可执⾏程序。
- 共享⽬标⽂件（Shared Object File） ：即 xxx.so⽂件。
- 内核转储(core dumps) ，存放当前进程的执⾏上下⽂，⽤于dump信号触发。
⼀个ELF文件由以下四部分组成：
- ELF头(ELF header) ：描述⽂件的主要特性。其位于⽂件的开始位置，它的主要⽬的是定位⽂
件的其他部分。 - 程序头表(Program header table) ：列举了所有有效的段(segments)和他们的属性。表⾥
记着每个段的开始的位置和位移（offset）、⻓度，毕竟这些段，都是紧密的放在⼆进制⽂件中，
需要段表的描述信息，才能把他们每个段分割开。 - 节头表(Section header table) ：包含对节(sections)的描述。
- 节（Section ）：ELF⽂件中的基本组成单位，包含了特定类型的数据。ELF⽂件的各种信息和
数据都存储在不同的节中，如代码节存储了可执⾏代码，数据节存储了全局变量和静态数据等。
最常见的节：
代码节（.text）：⽤于保存机器指令，是程序的主要执⾏部分。
数据节（.data）：保存已初始化的全局变量和局部静态变量。
ELF从形成到加载轮廓
ELF形成可执行
step-1：将多份 C/C++ 源代码，翻译成为⽬标 .o ⽂件
step-2：将多份 .o ⽂件section进⾏合并
注意：
实际合并是在链接时进⾏的，但是并不是这么简单的合并，也会涉及对库合并。链接就是把
.o目标文件，可执行程序和共享文件中的section进行合并。
readelf命令
readelf 是 Linux 系统中用于分析 ELF（Executable and Linkable Format）格式文件的命令行工具，常用于查看可执行文件、动态库、目标文件等的内部结构信息。
常用选项:
-h或--file-header:显示 ELF 文件的头部信息，包括文件类型、机器架构、程序入口地址等。
-S或--section-headers:显示节头表信息，包括节名、节类型、大小、偏移、属性等。
-l或--program-headers:显示程序头信息，包括节区段的大小、偏移、虚拟地址等。
-s或--symbols:显示符号表信息，包括符号名称、类型、绑定属性、大小、值等。
-r或--relocs:显示重定位表信息，包括重定位节、符号、类型等。
-a或--all:显示所有信息，相当于同时使用 -h、-l、-S、-s、-r、-d 等选项。
ELF可执行文件加载
- ⼀个ELF会有多种不同的Section，在加载到内存的时候，也会进⾏Section合并，形成segment。
- 合并原则：相同属性，⽐如：可读，可写，可执⾏，需要加载时申请空间等。
- 这样，即便是不同的Section，在加载到内存中，可能会以segment的形式，加载到⼀起。
- 很显然，这个合并⼯作也已经在形成ELF的时候，合并⽅式已经确定了，具体合并原则被记录在了ELF的 程序头表(Program header table) 中。
//查看可执⾏程序的section
readelf -S a.out
There are 29 section headers, starting at offset 0x1968:
Section Headers:
[Nr] Name Type Address Offset
Size EntSize Flags Link Info Align
[ 0] NULL 0000000000000000 00000000
0000000000000000 0000000000000000 0 0 0
[ 1] .interp PROGBITS 0000000000000238 00000238
000000000000001c 0000000000000000 A 0 0 1
[ 2] .note.ABI-tag NOTE 0000000000000254 00000254
0000000000000020 0000000000000000 A 0 0 4
[ 3] .note.gnu.build-i NOTE 0000000000000274 00000274
0000000000000024 0000000000000000 A 0 0 4
[ 4] .gnu.hash GNU_HASH 0000000000000298 00000298
000000000000001c 0000000000000000 A 5 0 8
[ 5] .dynsym DYNSYM 00000000000002b8 000002b8
00000000000000a8 0000000000000018 A 6 1 8
[ 6] .dynstr STRTAB 0000000000000360 00000360
0000000000000082 0000000000000000 A 0 0 1
[ 7] .gnu.version VERSYM 00000000000003e2 000003e2
000000000000000e 0000000000000002 A 5 0 2
[ 8] .gnu.version_r VERNEED 00000000000003f0 000003f0
0000000000000020 0000000000000000 A 6 1 8
[ 9] .rela.dyn RELA 0000000000000410 00000410
00000000000000c0 0000000000000018 A 5 0 8
[10] .rela.plt RELA 00000000000004d0 000004d0
0000000000000018 0000000000000018 AI 5 22 8
[11] .init PROGBITS 00000000000004e8 000004e8
0000000000000017 0000000000000000 AX 0 0 4
[12] .plt PROGBITS 0000000000000500 00000500
0000000000000020 0000000000000010 AX 0 0 16
[13] .plt.got PROGBITS 0000000000000520 00000520
0000000000000008 0000000000000008 AX 0 0 8
[14] .text PROGBITS 0000000000000530 00000530
00000000000001b2 0000000000000000 AX 0 0 16
[15] .fini PROGBITS 00000000000006e4 000006e4
0000000000000009 0000000000000000 AX 0 0 4
[16] .rodata PROGBITS 00000000000006f0 000006f0
000000000000001a 0000000000000000 A 0 0 4
[17] .eh_frame_hdr PROGBITS 000000000000070c 0000070c
0000000000000044 0000000000000000 A 0 0 4
[18] .eh_frame PROGBITS 0000000000000750 00000750
0000000000000128 0000000000000000 A 0 0 8
[19] .init_array INIT_ARRAY 0000000000200db8 00000db8
0000000000000008 0000000000000008 WA 0 0 8
[20] .fini_array FINI_ARRAY 0000000000200dc0 00000dc0
0000000000000008 0000000000000008 WA 0 0 8
[21] .dynamic DYNAMIC 0000000000200dc8 00000dc8
00000000000001f0 0000000000000010 WA 6 0 8
[22] .got PROGBITS 0000000000200fb8 00000fb8
0000000000000048 0000000000000008 WA 0 0 8
[23] .data # PROGBITS 0000000000201000 00001000
0000000000000010 0000000000000000 WA 0 0 8
[24] .bss NOBITS 0000000000201010 00001010
0000000000000008 0000000000000000 WA 0 0 1
[25] .comment PROGBITS 0000000000000000 00001010
0000000000000029 0000000000000001 MS 0 0 1
[26] .symtab SYMTAB 0000000000000000 00001040
0000000000000618 0000000000000018 27 44 8
[27] .strtab STRTAB 0000000000000000 00001658
000000000000020e 0000000000000000 0 0 1
[28] .shstrtab STRTAB 0000000000000000 00001866
00000000000000fe 0000000000000000 0 0 1
......
//查看可执行程序的ELF Header
readelf -h a.out
ELF Header:
Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 //用来表示该文件是ELF格式的，告诉系统可以用ELF格式读取文件内容
Class: ELF64
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: DYN (Shared object file)
Machine: Advanced Micro Devices X86-64
Version: 0x1
Entry point address: 0x530
Start of program headers: 64 (bytes into file)
Start of section headers: 6504 (bytes into file)
Flags: 0x0
Size of this header: 64 (bytes)
Size of program headers: 56 (bytes)
Number of program headers: 9
Size of section headers: 64 (bytes)
Number of section headers: 29
Section header string table index: 28
//知道了size和number，我们就可以用起始地址+偏移量的方式访文件内容了
//查看section合并的segment
readelf -l a.out
Elf file type is DYN (Shared object file)
Entry point 0x530
There are 9 program headers, starting at offset 64
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
PHDR 0x0000000000000040 0x0000000000000040 0x0000000000000040
0x00000000000001f8 0x00000000000001f8 R 0x8
INTERP 0x0000000000000238 0x0000000000000238 0x0000000000000238
0x000000000000001c 0x000000000000001c R 0x1
[Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000878 0x0000000000000878 R E 0x200000
LOAD 0x0000000000000db8 0x0000000000200db8 0x0000000000200db8
0x0000000000000258 0x0000000000000260 RW 0x200000
......
Section to Segment mapping:
Segment Sections...
00
01 .interp
02 .interp .note.ABI-tag .note.gnu.build-id .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_r .rela.dyn .rela.plt .init .plt .plt.got .text .fini .rodata .eh_frame_hdr .eh_frame
03 .init_array .fini_array .dynamic .got .data .bss
04 .dynamic
05 .note.ABI-tag .note.gnu.build-id
06 .eh_frame_hdr
07
08 .init_array .fini_array .dynamic .got
.text是代码段(权限也是只读的)，.data是数据段，.rodata是只读数据段，符合合并规则。
bss段：是 ELF（或其他可执行文件格式）中用于存储未初始化的全局变量和静态变量的内存区域，可以节省可执行程序占据的磁盘空间。
size a.out
text data bss dec hex filename
1580 600 8 2188 88c a.out
⼀个ELF会有多种不同的Section，在加载到内存的时候，也会进⾏Section合并，形成segment。
为什么要将
section合并成为segment
Section合并的主要原因是为了减少⻚⾯碎⽚，提⾼内存使⽤效率。如果不进⾏合并，假设⻚⾯⼤⼩为4096字节（内存块基本⼤⼩，加载，管理的基本单位），如果.text部分为4097字节，.init部分为512字节，那么它们将占⽤3个⻚⾯，⽽合并后，它们只需2个⻚⾯。- 此外，操作系统在加载程序时，会将具有相同属性的
section合并成⼀个⼤的segment，这样就可以实现不同的访问权限（eg:页表），从⽽优化内存管理和权限访问控制。
注意：内存是以4kb为基本单位的，从文件读取数据也是4kb为单位读取。
对于 程序头表 和 节头表 ⼜有什么⽤呢，其实 ELF ⽂件提供 2 个不同的视图/视⻆来让我们理解这
两个部分：
链接视图
(Linking view)- 对应节头表Section header table
- ⽂件结构的粒度更细，将⽂件按功能模块的差异进⾏划分，静态链接分析的时候⼀般关注的是链接视图，能够理解
ELF⽂件中包含的各个部分的信息。- 为了空间布局上的效率，将来在链接⽬标⽂件时，链接器会把很多节
（section）合并，规整成可执⾏的段（segment）、可读写的段、只读段等。合并了后，空间利⽤率就⾼了，否则，很⼩的很⼩的⼀段，未来物理内存⻚浪费太⼤（物理内存⻚分配⼀般都是整数倍⼀块给你，⽐如4k），所以，链接器趁着链接就把⼩块们都合并了。
执⾏视图
(execution view)- 对应程序头表Program header table
- 告诉操作系统，如何加载可执⾏⽂件，完成进程内存的初始化。⼀个可执⾏程序的格式中，⼀定有
program header table。- 说⽩了就是：⼀个在链接时作⽤，⼀个在运⾏加载时作⽤
从 链接视图 来看：
• 命令 readelf -S hello.o 可以帮助查看ELF⽂件的 节头表。
• .text节 ：是保存了程序代码指令的代码节。
• .data节 ：保存了初始化的全局变量和局部静态变量等数据。
• .rodata节 ：保存了只读的数据，如⼀⾏C语⾔代码中的字符串。由于.rodata节是只读的，所
以只能存在于⼀个可执⾏⽂件的只读段中。因此，只能是在text段（不是data段）中找到.rodata
节。
• .BSS节 ：为未初始化的全局变量和局部静态变量预留位置
• .symtab节 : Symbol Table 符号表，就是源码⾥⾯那些函数名、变量名和代码的对应关系。
• .got.plt节 （全局偏移表-过程链接表）：.got节保存了全局偏移表。.got节和.plt节⼀起提供了对导⼊的共享库函数的访问⼊⼝，由动态链接器在运⾏时进⾏修改。对于GOT的理解，我们后⾯会说。
◦ 使⽤ readelf 命令查看 .so ⽂件可以看到该节。
从 执行视图 来看：
• 告诉操作系统哪些模块可以被加载进内存。
• 加载进内存之后哪些分段是可读可写，哪些分段是只读，哪些分段是可执行的。
理解连接与加载
静态链接
- ⽆论是⾃⼰的.o, 还是静态库中的.o，本质都是把.o⽂件进⾏连接的过程
- 所以：研究静态链接，本质就是研究.o是如何链接的
查看编译后的.o⽬标⽂件
objdump -d 命令：将代码段（.text）进行反汇编查看
code.o 中的 main 函数不认识 printf和run 函数
//cat code.c
#include <stdio.h>
void run();
int main()
{
printf("Hello world\n");
run();
return 0;
}
我们可以看到这⾥的call指令，它们分别对应之前调⽤的printf和run函数，但是你会发现他们的跳转地址都被设成了0。那这是为什么呢？其实就是在编译 hello.c 的时候，编译器是完全不知道printf和run函数的存在的，⽐如他们位于内存的哪个区块，代码⻓什么样都是不知道的。因此，编辑器只能将这两个函数的跳转地址先暂时设为0。
这个地址会在哪个时候被修正？链接的时候！为了让链接器将来在链接时能够正确定位到这些被修正的地址，在代码块（.data）中还存在⼀个重定位表，这张表将来在链接的时候，就会根据表⾥记录的地址将其修正。
//读取code.o的符号表
readelf -s code.o
Symbol table '.symtab' contains 13 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND
1: 0000000000000000 0 FILE LOCAL DEFAULT ABS code.c
2: 0000000000000000 0 SECTION LOCAL DEFAULT 1
3: 0000000000000000 0 SECTION LOCAL DEFAULT 3
4: 0000000000000000 0 SECTION LOCAL DEFAULT 4
5: 0000000000000000 0 SECTION LOCAL DEFAULT 5
6: 0000000000000000 0 SECTION LOCAL DEFAULT 7
7: 0000000000000000 0 SECTION LOCAL DEFAULT 8
8: 0000000000000000 0 SECTION LOCAL DEFAULT 6
9: 0000000000000000 33 FUNC GLOBAL DEFAULT 1 main
10: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND _GLOBAL_OFFSET_TABLE_
11: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND puts
12: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND run
readelf -s hello.o
Symbol table '.symtab' contains 12 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND
1: 0000000000000000 0 FILE LOCAL DEFAULT ABS hello.c
2: 0000000000000000 0 SECTION LOCAL DEFAULT 1
3: 0000000000000000 0 SECTION LOCAL DEFAULT 3
4: 0000000000000000 0 SECTION LOCAL DEFAULT 4
5: 0000000000000000 0 SECTION LOCAL DEFAULT 5
6: 0000000000000000 0 SECTION LOCAL DEFAULT 7
7: 0000000000000000 0 SECTION LOCAL DEFAULT 8
8: 0000000000000000 0 SECTION LOCAL DEFAULT 6
9: 0000000000000000 19 FUNC GLOBAL DEFAULT 1 run
10: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND _GLOBAL_OFFSET_TABLE_
11: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND puts
puts：就是printf的实现
run:就是run的实现
UND就是：undefine，表⽰未定义说⽩了就是本.o⽂件找不到
//读取a.out的符号表
readelf -s a.out
Symbol table '.dynsym' contains 7 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND
1: 0000000000000000 0 NOTYPE WEAK DEFAULT UND _ITM_deregisterTMCloneTab
2: 0000000000000000 0 FUNC GLOBAL DEFAULT UND puts@GLIBC_2.2.5 (2)
3: 0000000000000000 0 FUNC GLOBAL DEFAULT UND __libc_start_main@GLIBC_2.2.5 (2)
4: 0000000000000000 0 NOTYPE WEAK DEFAULT UND __gmon_start__
5: 0000000000000000 0 NOTYPE WEAK DEFAULT UND _ITM_registerTMCloneTable
6: 0000000000000000 0 FUNC WEAK DEFAULT UND __cxa_finalize@GLIBC_2.2.5 (2)
Symbol table '.symtab' contains 65 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND
1: 0000000000000238 0 SECTION LOCAL DEFAULT 1
2: 0000000000000254 0 SECTION LOCAL DEFAULT 2
3: 0000000000000274 0 SECTION LOCAL DEFAULT 3
4: 0000000000000298 0 SECTION LOCAL DEFAULT 4
5: 00000000000002b8 0 SECTION LOCAL DEFAULT 5
6: 0000000000000360 0 SECTION LOCAL DEFAULT 6
7: 00000000000003e2 0 SECTION LOCAL DEFAULT 7
8: 00000000000003f0 0 SECTION LOCAL DEFAULT 8
9: 0000000000000410 0 SECTION LOCAL DEFAULT 9
10: 00000000000004d0 0 SECTION LOCAL DEFAULT 10
11: 00000000000004e8 0 SECTION LOCAL DEFAULT 11
12: 0000000000000500 0 SECTION LOCAL DEFAULT 12
13: 0000000000000520 0 SECTION LOCAL DEFAULT 13
14: 0000000000000530 0 SECTION LOCAL DEFAULT 14
15: 00000000000006e4 0 SECTION LOCAL DEFAULT 15
16: 00000000000006f0 0 SECTION LOCAL DEFAULT 16
17: 000000000000070c 0 SECTION LOCAL DEFAULT 17
18: 0000000000000750 0 SECTION LOCAL DEFAULT 18
19: 0000000000200db8 0 SECTION LOCAL DEFAULT 19
20: 0000000000200dc0 0 SECTION LOCAL DEFAULT 20
21: 0000000000200dc8 0 SECTION LOCAL DEFAULT 21
22: 0000000000200fb8 0 SECTION LOCAL DEFAULT 22
23: 0000000000201000 0 SECTION LOCAL DEFAULT 23
24: 0000000000201010 0 SECTION LOCAL DEFAULT 24
25: 0000000000000000 0 SECTION LOCAL DEFAULT 25
26: 0000000000000000 0 FILE LOCAL DEFAULT ABS crtstuff.c
27: 0000000000000560 0 FUNC LOCAL DEFAULT 14 deregister_tm_clones
28: 00000000000005a0 0 FUNC LOCAL DEFAULT 14 register_tm_clones
29: 00000000000005f0 0 FUNC LOCAL DEFAULT 14 __do_global_dtors_aux
30: 0000000000201010 1 OBJECT LOCAL DEFAULT 24 completed.7698
31: 0000000000200dc0 0 OBJECT LOCAL DEFAULT 20 __do_global_dtors_aux_fin
32: 0000000000000630 0 FUNC LOCAL DEFAULT 14 frame_dummy
33: 0000000000200db8 0 OBJECT LOCAL DEFAULT 19 __frame_dummy_init_array_
34: 0000000000000000 0 FILE LOCAL DEFAULT ABS code.c
35: 0000000000000000 0 FILE LOCAL DEFAULT ABS hello.c
36: 0000000000000000 0 FILE LOCAL DEFAULT ABS crtstuff.c
37: 0000000000000874 0 OBJECT LOCAL DEFAULT 18 __FRAME_END__
38: 0000000000000000 0 FILE LOCAL DEFAULT ABS
39: 0000000000200dc0 0 NOTYPE LOCAL DEFAULT 19 __init_array_end
40: 0000000000200dc8 0 OBJECT LOCAL DEFAULT 21 _DYNAMIC
41: 0000000000200db8 0 NOTYPE LOCAL DEFAULT 19 __init_array_start
42: 000000000000070c 0 NOTYPE LOCAL DEFAULT 17 __GNU_EH_FRAME_HDR
43: 0000000000200fb8 0 OBJECT LOCAL DEFAULT 22 _GLOBAL_OFFSET_TABLE_
44: 00000000000006e0 2 FUNC GLOBAL DEFAULT 14 __libc_csu_fini
45: 0000000000000000 0 NOTYPE WEAK DEFAULT UND _ITM_deregisterTMCloneTab
46: 0000000000201000 0 NOTYPE WEAK DEFAULT 23 data_start
47: 0000000000000000 0 FUNC GLOBAL DEFAULT UND puts@@GLIBC_2.2.5
48: 0000000000201010 0 NOTYPE GLOBAL DEFAULT 23 _edata
49: 000000000000065b 19 FUNC GLOBAL DEFAULT 14 run
50: 00000000000006e4 0 FUNC GLOBAL DEFAULT 15 _fini
51: 0000000000000000 0 FUNC GLOBAL DEFAULT UND __libc_start_main@@GLIBC_
52: 0000000000201000 0 NOTYPE GLOBAL DEFAULT 23 __data_start
53: 0000000000000000 0 NOTYPE WEAK DEFAULT UND __gmon_start__
54: 0000000000201008 0 OBJECT GLOBAL HIDDEN 23 __dso_handle
55: 00000000000006f0 4 OBJECT GLOBAL DEFAULT 16 _IO_stdin_used
56: 0000000000000670 101 FUNC GLOBAL DEFAULT 14 __libc_csu_init
57: 0000000000201018 0 NOTYPE GLOBAL DEFAULT 24 _end
58: 0000000000000530 43 FUNC GLOBAL DEFAULT 14 _start
59: 0000000000201010 0 NOTYPE GLOBAL DEFAULT 24 __bss_start
60: 000000000000063a 33 FUNC GLOBAL DEFAULT 14 main
61: 0000000000201010 0 OBJECT GLOBAL HIDDEN 23 __TMC_END__
62: 0000000000000000 0 NOTYPE WEAK DEFAULT UND _ITM_registerTMCloneTable
63: 0000000000000000 0 FUNC WEAK DEFAULT UND __cxa_finalize@@GLIBC_2.2
64: 00000000000004e8 0 FUNC GLOBAL DEFAULT 11 _init
两个.o进⾏合并之后，在最终的可执⾏程序中，就找到了run
000000000000065b：其实是地址，后⾯说
FUNC:表⽰run符号类型是个函数
14：就是run函数所在的section被合并最终的那⼀个section中了,14就是下标
readelf -S a.out
There are 29 section headers, starting at offset 0x1968:
Section Headers:
[Nr] Name Type Address Offset
Size EntSize Flags Link Info Align
······
[14] .text PROGBITS 0000000000000530 00000530
00000000000001b2 0000000000000000 AX 0 0 16
······
//[14]->.text代码段
静态链接就是把库中的.o进⾏合并，和上述过程⼀样。
所以链接其实就是将编译之后的所有⽬标⽂件连同⽤到的⼀些静态库运⾏时库组合，拼装成⼀个独⽴
的可执⾏⽂件。其中就包括我们之前提到的地址修正，当所有模块组合在⼀起之后，链接器会根据我
们的.o⽂件或者静态库中的重定位表找到那些需要被重定位的函数全局变量，从⽽修正它们的地址。这
其实就是静态链接的过程。
所以，链接过程中会涉及到对.o中外部符号进⾏地址重定位。
ELF加载与进程地址空间
虚拟地址/逻辑地址
问题：
• ⼀个ELF程序，在没有被加载到内存的时候，有没有地址呢？
• 进程mm_struct、vm_area_struct在进程刚刚创建的时候，初始化数据从哪⾥来的？
答案：
⼀个ELF程序，在没有被加载到内存的时候，有地址，这个地址也叫做逻辑地址。
进程mm_struct、vm_area_struct在进程刚刚创建的时候，初始化数据从ELF程序来的。
⼀个ELF程序，在没有被加载到内存的时候,本来就有地址，当代计算机⼯作的时候，都采⽤"平坦
模式"进⾏⼯作。所以也要求ELF对⾃⼰的代码和数据进⾏统⼀编址，下⾯是 objdump -S 反汇编
之后的代码
最左侧的就是ELF的虚拟地址，其实，严格意义上应该叫做逻辑地址(起始地址+偏移量), 但是我们
认为起始地址是0.也就是说，其实虚拟地址在我们的程序还没有加载到内存的时候，就已经把可执
⾏程序进⾏统⼀编址了.
进程
mm_struct、vm_area_struct在进程刚刚创建的时候，初始化数据从哪⾥来的？从ELF各个
segment来，每个segment有⾃⼰的起始地址和⾃⼰的⻓度，⽤来初始化内核结构中的[start, end]
等范围数据，另外在⽤详细地址，填充⻚表
所以：虚拟地址机制，不光光OS要⽀持，编译器也要⽀持.
磁盘上的可执行程序代码和数据编址，其实就是虚拟地址的统一编址，在内存里叫虚拟地址，在磁盘上叫逻辑地址（线性地址），内存上面的地址叫做物理地址。
重新理解进程虚拟地址空间
ELF 在被编译好之后，会把⾃⼰未来程序的⼊⼝地址记录在ELF header的Entry字段中：
动态链接与动态库加载
进程如何看到动态库
进程间如何共享库的
动态链接
动态链接其实远⽐静态链接要常⽤得多。⽐如我们查看下 a.out这个可执⾏程序依赖的动态库，会发
现它就⽤到了⼀个c动态链接库：
ldd a.out
linux-vdso.so.1 (0x00007ffe9dfde000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fca4ba0f000)
/lib64/ld-linux-x86-64.so.2 (0x00007fca4c002000)
# ldd命令⽤于打印程序或者库⽂件所依赖的共享库列表。
这⾥的
libc.so是C语⾔的运⾏时库，⾥⾯提供了常⽤的标准输⼊输出⽂件字符串处理等等这些功能。那为什么编译器默认不使⽤静态链接呢？静态链接会将编译产⽣的所有⽬标⽂件，连同⽤到的各种库，合并形成⼀个独⽴的可执⾏⽂件，它不需要额外的依赖就可以运⾏。照理来说应该更加⽅便才对是吧？
静态链接最大的问题在于生成的文件体积大，并且相当耗费内存资源。随着软件复杂度的提升，我们的操作系统也越来越臃肿，不同的软件就有可能都包含了相同的功能和代码，显然会浪费⼤量的硬盘空间。
这个时候，动态链接的优势就体现出来了，我们可以将需要共享的代码单独提取出来，保存成⼀个独⽴的动态链接库，等到程序运⾏的时候再将它们加载到内存，这样不但可以节省空间，因为同⼀个模块在内存中只需要保留⼀份副本，可以被不同的进程所共享。
动态链接到底是如何工作的？？
⾸先要交代⼀个结论，动态链接实际上将链接的整个过程推迟到了程序加载的时候(这个时候程序和动态库已经被加载到内存了)。⽐如我们去运⾏⼀个程序，操作系统会⾸先将程序的数据代码连同它⽤到的⼀系列动态库先加载到内存，其中每个动态库的加载地址都是不固定的，操作系统会根据当前地址空间的使⽤情况为它们动态分配⼀段内存。当动态库被加载到内存以后，⼀旦它的内存地址被确定，我们就可以去修正动态库中的那些函数跳转地址了。
我们的可执行程序被编译器动了手脚
在C/C++程序中，当程序开始执⾏时，它⾸先并不会直接跳转到 main 函数。实际上，程序的⼊⼝点是 _start ，这是⼀个由C运⾏时库（通常是glibc）或链接器（如ld）提供的特殊函数。在 _start 函数中，会执⾏⼀系列初始化操作，这些操作包括：
设置堆栈：为程序创建⼀个初始的堆栈环境。
初始化数据段：将程序的数据段（如全局变量和静态变量）从初始化数据段复制到相应的内存位
置，并清零未初始化的数据段。动态链接：这是关键的⼀步，
_start函数会调⽤动态链接器的代码来解析和加载程序所依赖的
动态库（shared libraries）。动态链接器会处理所有的符号解析和重定位，确保程序中的函数调
⽤和变量访问能够正确地映射到动态库中的实际地址。
动态链接器：
◦ 动态链接器（如ld-linux.so）负责在程序运⾏时加载动态库。
◦ 当程序启动时，动态链接器会解析程序中的动态库依赖，并加载这些库到内存中。
环境变量和配置文件：
◦ Linux系统通过环境变量（如LD_LIBRARY_PATH）和配置⽂件（如/etc/ld.so.conf及其⼦配置
⽂件）来指定动态库的搜索路径。
◦ 这些路径会被动态链接器在加载动态库时搜索。
缓存文件：
◦ 为了提⾼动态库的加载效率，Linux系统会维护⼀个名为/etc/ld.so.cache的缓存⽂件。
◦ 该⽂件包含了系统中所有已知动态库的路径和相关信息，动态链接器在加载动态库时会⾸先
搜索这个缓存⽂件。调⽤
__libc_start_main：⼀旦动态链接完成，_start函数会调⽤__libc_start_main（这是glibc提供的⼀个函数）。__libc_start_main函数负责执⾏⼀些额外的初始化⼯作，⽐如设置信号处理函数、初始化线程库（如果使⽤了线程）等。调⽤
main函数：最后，__libc_start_main函数会调⽤程序的main函数，此时程序的执⾏控制权才正式交给⽤户编写的代码。处理
main函数的返回值：当main函数返回时，__libc_start_main会负责处理这个返回值，并最终调⽤_exit函数来终⽌程序。
上述过程描述了C/C++程序在 main 函数之前执⾏的⼀系列操作，但这些操作对于⼤多数程序员来说是透明的。程序员通常只需要关注main 函数中的代码，⽽不需要关⼼底层的初始化过程。然⽽，了解这些底层细节有助于更好地理解程序的执⾏流程和调试问题。
动态库中的相对地址
动态库为了随时进⾏加载，为了⽀持并映射到任意进程的任意位置，对动态库中的⽅法，统⼀编址，采⽤相对编址的⽅案进⾏编制的(其实可执⾏程序也⼀样，都要遵守平坦模式，只不过exe是直接加载的)。
我们的程序，怎么和库具体映射起来的
注意：
- 动态库也是⼀个⽂件，要访问也是要被先加载，要加载也是要被打开的
- 让我们的进程找到动态库的本质：也是⽂件操作，不过我们访问库函数，通过虚拟地址进 ⾏跳转访问的，所以需要把动态库映射到进程的地址空间中
我们的程序，怎么进行库函数调用
📌 注意：
• 库已经被我们映射到了当前进程的地址空间中
• 库的虚拟起始地址我们也已经知道了
• 库中每⼀个⽅法的偏移量地址我们也知道
• 所有：访问库中任意⽅法，只需要知道库的起始虚拟地址+⽅法偏移量即可定位库中的⽅法
• ⽽且：整个调⽤过程，是从代码区跳转到共享区，调⽤完毕在返回到代码区，整个过程完全在进程地址空间中进⾏的
全局偏移量表GOT(global offset table)
注意：
• 也就是说，我们的程序运⾏之前，先把所有库加载并映射，所有库的起始虚拟地址都应该提前知道
• 然后对我们加载到内存中的程序的库函数调⽤进⾏地址修改，在内存中⼆次完成地址设置(这个叫做加载地址重定位)
• 等等，修改的是代码区？不是说代码区在进程中是只读的吗？怎么修改？能修改吗？
所以：动态链接采⽤的做法是在 .data （可执⾏程序或者库⾃⼰）中专⻔预留⼀⽚区域⽤来存放函数
的跳转地址，它也被叫做全局偏移表GOT，表中每⼀项都是本运⾏模块要引⽤的⼀个全局变量或函数
的地址。
• 因为.data区域是可读写的，所以可以⽀持动态进⾏修改
readelf -S a.out
There are 29 section headers, starting at offset 0x1968:
Section Headers:
[Nr] Name Type Address Offset
Size EntSize Flags Link Info Align
......
[14] .text PROGBITS 0000000000000530 00000530
00000000000001b2 0000000000000000 AX 0 0 16
......
00000000000001f0 0000000000000010 WA 6 0 8
[22] .got PROGBITS 0000000000200fb8 00000fb8
......
readelf -l a.out
......
03 .init_array .fini_array .dynamic .got .data .bss
......
# .got在加载的时候，会和.data合并成为⼀个segment，然后加载在⼀起
- 由于代码段只读，我们不能直接修改代码段。但有了
GOT表，代码便可以被所有进程共享。但在不同进程的地址空间中，各动态库的绝对地址、相对位置都不同。反映到GOT表上，就是每个进程的每个动态库都有独⽴的GOT表，所以进程间不能共享GOT表。 - 在单个
.so下，由于GOT表与.text的相对位置是固定的，我们完全可以利⽤CPU的相对寻址来找到GOT表。 - 在调⽤函数的时候会⾸先查表，然后根据表中的地址来进⾏跳转，这些地址在动态库加载的时候会被修改为真正的地址。
- 这种⽅式实现的动态链接就被叫做
PIC地址⽆关代码 。换句话说，我们的动态库不需要做任何修改，被加载到任意内存地址都能够正常运⾏，并且能够被所有进程共享，这也是为什么之前我们给编译器指定-fPIC参数的原因，PIC=相对编址+GOT。
PLT是什么？
库间依赖
注意：
• 不仅仅有可执⾏程序调⽤库
• 库也会调⽤其他库！！库之间是有依赖的，如何做到库和库之间互相调⽤也是与地址⽆关的呢？？
• 库中也有.GOT,和可执⾏⼀样！这也就是为什么⼤家为什么都是ELF的格式！
由于动态链接在程序加载的时候需要对⼤量函数进⾏重定位，这⼀步显然是⾮常耗时的。为了进⼀步降低开销，我们的操作系统还做了⼀些其他的优化，⽐如延迟绑定，或者也叫PLT（过程连接表
（Procedure Linkage Table））。与其在程序⼀开始就对所有函数进⾏重定位，不如将这个过程推迟到函数第⼀次被调⽤的时候，因为绝⼤多数动态库中的函数可能在程序运⾏期间⼀次都不会被使⽤到。
思路是:GOT中的跳转地址默认会指向⼀段辅助代码，它也被叫做桩代码/stup。在我们第⼀次调⽤函数的时候，这段代码会负责查询真正函数的跳转地址，并且去更新GOT表。于是我们再次调⽤函数的时候，就会直接跳转到动态库中真正的函数实现。
总⽽⾔之，动态链接实际上将链接的整个过程，⽐如符号查询、地址的重定位从编译时推迟到了程序的运⾏时，它虽然牺牲了⼀定的性能和程序加载时间，但绝对是物有所值的。因为动态链接能够更有 效的利⽤磁盘空间和内存资源，以极⼤⽅便了代码的更新和维护，更关键的是，它实现了⼆进制级别的代码复⽤。
总结
• 静态链接的出现，提⾼了程序的模块化⽔平。对于⼀个⼤的项⽬，不同的⼈可以独⽴地测试和开发⾃⼰的模块。通过静态链接，⽣成最终的可执⾏⽂件。
• 我们知道静态链接会将编译产⽣的所有⽬标⽂件，和⽤到的各种库合并成⼀个独⽴的可执⾏⽂件，其中我们会去修正模块间函数的跳转地址，也被叫做编译重定位(也叫做静态重定位)。
• ⽽动态链接实际上将链接的整个过程推迟到了程序加载的时候。⽐如我们去运⾏⼀个程序，操作系统会⾸先将程序的数据代码连同它⽤到的⼀系列动态库先加载到内存，其中每个动态库的加载地址都是不固定的，但是⽆论加载到什么地⽅，都要映射到进程对应的地址空间，然后通过.GOT⽅式进⾏调⽤(运⾏重定位，也叫做动态地址重定位)。