Linux笔记---动静态库(原理篇)
1. ELF文件格式
动静态库文件的构成是什么样的呢？或者说二者的内容是什么？
实际上，可执行文件，目标文件，静态库文件，动态库文件都是使用ELF文件格式进行组织的。
ELF（Executable and Linkable Format）文件格式是Unix系统及其衍生系统中广泛使用的可执行文件、共享库和核心转储的二进制文件格式。
主要包括以下四种文件*
- 可重定位文件（Relocatable File）：包含适合于与其他目标文件链接来创建可执行文件或者共享目标文件的代码和数据，如xxx.o文件。
- 可执行文件（Executable File）：包含适合于执行的一个程序，规定了exec()如何创建一个程序的进程映像，如a.out文件。
- 共享目标文件（Shared Object File）：包含可在两种上下文中链接的代码和数据。首先链接编辑器可以将它和其它可重定位文件和共享目标文件一起处理，生成另外一个目标文件；其次，动态链接器可能将它与某个可执行文件以及其它共享目标一起组合，创建进程映像，如xxx.so文件。
- 内核转储（core dumps）：存放当前进程的执行上下文，用于dump信号触发。
结构组成
ELF头（ELF header）：位于文件的开始位置，主要目的是定位文件的其他部分。
程序头表（Program header table）：列举了所有有效的段（segments）和它们的属性。
节（Section）：文件的最小逻辑组织单元，用于存储程序在编译、链接或执行过程中需要的特定类型数据。每个Section都有明确的用途，例如存储代码、全局变量、符号表或调试信息等。
节头表（Section header table）：包含对节（sections）的描述。
总结来说，除了节以外的三个部分实际上都是帮助定位的辅助信息，程序的核心信息在节部分。
我们可以通过 readelf 工具来查看一个可执行程序的各个部分，下面我们以ls为例展示各个部分。
1.1 ELF header
位于文件的开始位置，主要目的是定位文件的其他部分。包含文件类型、目标结构、ELF文件格式的版本、程序入口地址、程序头表的文件偏移、节头表的文件偏移等重要信息。
readelf -h /usr/bin/lsshishen@hcss-ecs-b8e6:~$ readelf -h /usr/bin/ls
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: DYN (Position-Independent Executable file)
Machine: Advanced Micro Devices X86-64
Version: 0x1
Entry point address: 0x6aa0
Start of program headers: 64 (bytes into file)
Start of section headers: 136232 (bytes into file)
Flags: 0x0
Size of this header: 64 (bytes)
Size of program headers: 56 (bytes)
Number of program headers: 13
Size of section headers: 64 (bytes)
Number of section headers: 31
Section header string table index: 30
Magic： 标识ELF文件的魔数字节序列。
Class： 文件位数（32位或64位）。
Data： 数据存储的字节序（小端或大端）。
Version： ELF格式版本号。
OS/ABI： 目标操作系统和应用二进制接口（ABI）。
ABI Version： ABI的版本号。
Type： 文件类型（可执行、共享库等）。
Machine： 目标CPU架构。
Version： ELF版本（通常为1）。
Entry point address： 程序执行的起始地址。
Start of program headers： 程序头表在文件中的偏移量。
Start of section headers： 节头表在文件中的偏移量。
Flags： 处理器特定的标志位。
Size of this header： ELF头的大小（字节）。
Size of program headers： 单个程序头条目的大小。
Number of program headers： 程序头条目数量。
Size of section headers： 单个节头条目的大小。
Number of section headers： 节头条目数量。
Section header string table index：节名称字符串表的索引号。1.2 Section header table
ELF文件的链接视图(Linking view)，包含对节（sections）的描述。即一个ELF文件中到底有哪些具体的sections，以及这些sections的属性信息。
简单来说，这部分包含了一个个的section header，它们与section一一对应，指示各个section的属性信息，这与文件系统中的inode table的设计思路相同。
readelf -S /usr/bin/lsshishen@hcss-ecs-b8e6:~$ readelf -S /usr/bin/ls
There are 31 section headers, starting at offset 0x21428:
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 0000000000000318 00000318
000000000000001c 0000000000000000 A 0 0 1
[ 2] .note.gnu.pr[...] NOTE 0000000000000338 00000338
0000000000000030 0000000000000000 A 0 0 8
[ 3] .note.gnu.bu[...] NOTE 0000000000000368 00000368
0000000000000024 0000000000000000 A 0 0 4
[ 4] .note.ABI-tag NOTE 000000000000038c 0000038c
0000000000000020 0000000000000000 A 0 0 4
[ 5] .gnu.hash GNU_HASH 00000000000003b0 000003b0
000000000000004c 0000000000000000 A 6 0 8
[ 6] .dynsym DYNSYM 0000000000000400 00000400
0000000000000b88 0000000000000018 A 7 1 8
[ 7] .dynstr STRTAB 0000000000000f88 00000f88
00000000000005a6 0000000000000000 A 0 0 1
[ 8] .gnu.version VERSYM 000000000000152e 0000152e
00000000000000f6 0000000000000002 A 6 0 2
[ 9] .gnu.version_r VERNEED 0000000000001628 00001628
00000000000000c0 0000000000000000 A 7 2 8
[10] .rela.dyn RELA 00000000000016e8 000016e8
0000000000001410 0000000000000018 A 6 0 8
[11] .rela.plt RELA 0000000000002af8 00002af8
0000000000000960 0000000000000018 AI 6 25 8
[12] .init PROGBITS 0000000000004000 00004000
000000000000001b 0000000000000000 AX 0 0 4
[13] .plt PROGBITS 0000000000004020 00004020
0000000000000650 0000000000000010 AX 0 0 16
[14] .plt.got PROGBITS 0000000000004670 00004670
0000000000000030 0000000000000010 AX 0 0 16
[15] .plt.sec PROGBITS 00000000000046a0 000046a0
0000000000000640 0000000000000010 AX 0 0 16
[16] .text PROGBITS 0000000000004ce0 00004ce0
00000000000123a2 0000000000000000 AX 0 0 16
[17] .fini PROGBITS 0000000000017084 00017084
000000000000000d 0000000000000000 AX 0 0 4
[18] .rodata PROGBITS 0000000000018000 00018000
0000000000004dcc 0000000000000000 A 0 0 32
[19] .eh_frame_hdr PROGBITS 000000000001cdcc 0001cdcc
000000000000056c 0000000000000000 A 0 0 4
[20] .eh_frame PROGBITS 000000000001d338 0001d338
0000000000002120 0000000000000000 A 0 0 8
[21] .init_array INIT_ARRAY 0000000000020fd0 0001ffd0
0000000000000008 0000000000000008 WA 0 0 8
[22] .fini_array FINI_ARRAY 0000000000020fd8 0001ffd8
0000000000000008 0000000000000008 WA 0 0 8
[23] .data.rel.ro PROGBITS 0000000000020fe0 0001ffe0
0000000000000a78 0000000000000000 WA 0 0 32
[24] .dynamic DYNAMIC 0000000000021a58 00020a58
0000000000000200 0000000000000010 WA 7 0 8
[25] .got PROGBITS 0000000000021c58 00020c58
00000000000003a0 0000000000000008 WA 0 0 8
[26] .data PROGBITS 0000000000022000 00021000
0000000000000278 0000000000000000 WA 0 0 32
[27] .bss NOBITS 0000000000022280 00021278
00000000000012c0 0000000000000000 WA 0 0 32
[28] .gnu_debugaltlink PROGBITS 0000000000000000 00021278
0000000000000049 0000000000000000 0 0 1
[29] .gnu_debuglink PROGBITS 0000000000000000 000212c4
0000000000000034 0000000000000000 0 0 4
[30] .shstrtab STRTAB 0000000000000000 000212f8
000000000000012f 0000000000000000 0 0 1
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
L (link order), O (extra OS processing required), G (group), T (TLS),
C (compressed), x (unknown), o (OS specific), E (exclude),
D (mbind), l (large), p (processor specific)
// 注：
// [Nr] 节的索引号（从 1 开始），0 表示无效节。
// Name 节的名称（如 .text、.data、.rodata）。
// Type 节的类型（如 PROGBITS 表示程序数据，SYMTAB 表示符号表）。
// Address 节加载到内存时的虚拟地址（未加载时为 0）。
// Offset 节在文件中的起始偏移量（字节）。
// Size 节的大小（字节）。
// EntSize 如果节是表格（如符号表），表示每个条目的大小；否则为 0。
// Flags 节的属性标志（如 A 可分配，X 可执行，W 可写）。
// Link 链接到其他节的索引（如符号表会链接到字符串表）。
// Info 节的附加信息（如符号表的局部符号起始索引）。
// Align 节的对齐要求（如 16 表示按 16 字节对齐）。
链接视图的含义是：目标文件以及动静态库在进行链接形成可执行程序时，是以section为单位进行的，即各个section各自进行合并。
1.3 Program header table
ELF文件的执行视图(execution view)，列举了所有有效的段（segments）和它们的属性。
同样地，这部分包含了一个个的program header（或者说segment header），它们与segment一一对应，指示各个segment的属性信息。
可执行程序在被加载到内存当中时，多个节会合并成一个段（合并原则：相同属性，比如可读，可写，可执行，需要加载时申请空间等）。所以，Program header table其实就是对中间部分的一个重新划分。
readelf -l /usr/bin/lsshishen@hcss-ecs-b8e6:~$ readelf -l /usr/bin/ls
Elf file type is DYN (Position-Independent Executable file)
Entry point 0x6aa0
There are 13 program headers, starting at offset 64
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
PHDR 0x0000000000000040 0x0000000000000040 0x0000000000000040
0x00000000000002d8 0x00000000000002d8 R 0x8
INTERP 0x0000000000000318 0x0000000000000318 0x0000000000000318
0x000000000000001c 0x000000000000001c R 0x1
[Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000003458 0x0000000000003458 R 0x1000
LOAD 0x0000000000004000 0x0000000000004000 0x0000000000004000
0x0000000000013091 0x0000000000013091 R E 0x1000
LOAD 0x0000000000018000 0x0000000000018000 0x0000000000018000
0x0000000000007458 0x0000000000007458 R 0x1000
LOAD 0x000000000001ffd0 0x0000000000020fd0 0x0000000000020fd0
0x00000000000012a8 0x0000000000002570 RW 0x1000
DYNAMIC 0x0000000000020a58 0x0000000000021a58 0x0000000000021a58
0x0000000000000200 0x0000000000000200 RW 0x8
NOTE 0x0000000000000338 0x0000000000000338 0x0000000000000338
0x0000000000000030 0x0000000000000030 R 0x8
NOTE 0x0000000000000368 0x0000000000000368 0x0000000000000368
0x0000000000000044 0x0000000000000044 R 0x4
GNU_PROPERTY 0x0000000000000338 0x0000000000000338 0x0000000000000338
0x0000000000000030 0x0000000000000030 R 0x8
GNU_EH_FRAME 0x000000000001cdcc 0x000000000001cdcc 0x000000000001cdcc
0x000000000000056c 0x000000000000056c R 0x4
GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000000 0x0000000000000000 RW 0x10
GNU_RELRO 0x000000000001ffd0 0x0000000000020fd0 0x0000000000020fd0
0x0000000000001030 0x0000000000001030 R 0x1
Section to Segment mapping:
Segment Sections...
00
01 .interp
02 .interp .note.gnu.property .note.gnu.build-id .note.ABI-tag .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_r .rela.dyn .rela.plt
03 .init .plt .plt.got .plt.sec .text .fini
04 .rodata .eh_frame_hdr .eh_frame
05 .init_array .fini_array .data.rel.ro .dynamic .got .data .bss
06 .dynamic
07 .note.gnu.property
08 .note.gnu.build-id .note.ABI-tag
09 .note.gnu.property
10 .eh_frame_hdr
11
12 .init_array .fini_array .data.rel.ro .dynamic .got
// 注：
// Type 段的类型（如 LOAD 表示可加载段，DYNAMIC 表示动态链接信息）。
// Offset 段在文件中的起始偏移量（字节）。
// VirtAddr 段加载到内存时的虚拟地址（程序运行时访问的地址）。
// PhysAddr 段加载到内存时的物理地址（通常与 VirtAddr 相同，现代系统忽略）。
// FileSiz 段在文件中的大小（字节）。
// MemSiz 段在内存中的大小（字节，可能大于 FileSiz，如 .bss 节会填充零）。
// Flags 段的权限标志（R=读，W=写，X=执行）。
// Align 段在内存和文件中的对齐要求（如 0x1000 表示按 4KB 对齐）。
Section to Segment mapping部分就显示了各个segment包含了哪些section。
执行视图的含义是：该部分负责告诉操作系统，如何加载可执行文件，完成进程内存的初始化。一个可执行程序的格式中，一定有 program header table。
节（Section） 是链接时的逻辑划分（如 .text、.data），数量多且大小不一。
段（Segment） 是执行时的物理加载单元（如代码段、数据段），合并相同权限的节后，操作系统只需按段映射内存，减少内存碎片和系统调用次数。
加载到内存时将节合并为段的原因
- 符合操作系统的内存页管理：操作系统以 页（Page） 为单位管理内存（如4KB）。段会按页对齐，避免跨页的节导致内存浪费或权限冲突。如果不进行合并，假设页面大小为4096字节（内存块基本大小，加载，管理的基本单位），如果.text部分为4097字节，.init部分为512字节，那么它们将占用3个页面，而合并后，它们只需2个页面。
- 统一内存访问权限：每个段有明确的权限（读/写/执行），而节可能分散且权限不同。
2. 静态链接原理
2.1 地址重定位
重定位（Relocation）的核心目标是将程序中的地址引用调整为实际加载到内存后的正确地址。但具体操作方式分为两种：
- 代码段重定位：直接修改代码指令中的绝对地址（例如 call 0x200 → call 0x400）。
问题：破坏代码的只读性和共享性，无法被多个进程共享。- 数据段重定位：将需要调整的地址集中在数据区域（如 GOT 表），代码段仅通过相对偏移访问这些数据。
优势：代码段无需修改，保持只读，支持共享。
显然，静态链接采用代码段重定位，在编译链接时完成；动态链接采用数据段重定位，在运行时动态完成。
接下来我们将演示什么是代码段重定位：
// hello.c
#include
void run();
int main() {
printf("hello world!
");
run();
return 0;
}
// code.c
#include
void run() {
printf("running...
");
} 我们将这两个原文件进行编译得到目标文件：
shishen@hcss-ecs-b8e6:~/113code/linux-c/动静态库/display$ gcc -c *.c
shishen@hcss-ecs-b8e6:~/113code/linux-c/动静态库/display$ ls
code.c code.o hello.c hello.o这里，我们需要用到一个指令objdump -d：将代码段（.text）进行反汇编查看。
shishen@hcss-ecs-b8e6:~/113code/linux-c/动静态库/display$ objdump -d hello.o > hello.s
shishen@hcss-ecs-b8e6:~/113code/linux-c/动静态库/display$ objdump -d code.o > code.s
shishen@hcss-ecs-b8e6:~/113code/linux-c/动静态库/display$ ls
code.c code.o code.s hello.c hello.o hello.s
这里的call很明显就是函数调用，call指令的编码为e8。
对比源文件可以看出，无论是printf函数还是run函数，e8跳转到的地址都为0。这是因为，在完成链接之前，编译器并不知道这些外部函数的实现与定义，无法为其分配地址（逻辑地址），就以0代替其地址。
所以，在链接时，编译器还需要将代码段中这些为0的地址修改为实际为这些函数分配的地址。
要完成这项工作，编译器还需要符号表的帮助。每个目标文件都有自己的符号表，在进行链接时，大家相互对照符号表，就能找到外部函数或变量是在哪一个文件当中声明的了，进而就能为其分配地址。
readelf -s # 读取目标文件的符号表shishen@hcss-ecs-b8e6:~/113code/linux-c/动静态库/display$ readelf -s hello.o
Symbol table '.symtab' contains 7 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 .text
3: 0000000000000000 0 SECTION LOCAL DEFAULT 5 .rodata
4: 0000000000000000 40 FUNC GLOBAL DEFAULT 1 main
5: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND puts
6: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND run
shishen@hcss-ecs-b8e6:~/113code/linux-c/动静态库/display$ readelf -s code.o
Symbol table '.symtab' contains 6 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 .text
3: 0000000000000000 0 SECTION LOCAL DEFAULT 5 .rodata
4: 0000000000000000 26 FUNC GLOBAL DEFAULT 1 run
5: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND puts
// 注：printf底层就是puts其中，每一行就代表一个符号，我们主要关注Ndx列和Name列。
- ABS：该符号的值是绝对地址，不依赖于任何节（Section），通常是文件名或特殊定义的全局符号。
- UND：该符号在当前目标文件中未定义，需要在链接时从其他目标文件或库中解析（如外部函数或全局变量）。
数字：表示符号定义在对应索引号的节中。例如：Ndx=1：符号属于 .text 节（代码段）。Ndx=5：符号属于 .rodata 节（只读数据段）。
可以看到，在hello.o中，run和puts都是未定义，而code.o中，run有定义但puts依然未定义。
当我们将二者进行链接之后：
shishen@hcss-ecs-b8e6:~/113code/linux-c/动静态库/display$ gcc -o main hello.o code.o
shishen@hcss-ecs-b8e6:~/113code/linux-c/动静态库/display$ objdump -d main > main.s
puts我们暂时也不关心，因为puts使用的是动态链接。可以看到，run函数的地址为1171，该地址也标注在run函数的名称之前。
这就说明编译器在链接时，找到了run函数，并为其分配了地址。
shishen@hcss-ecs-b8e6:~/113code/linux-c/动静态库/display$ readelf -s main
Symbol table '.dynsym' contains 7 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND
1: 0000000000000000 0 FUNC GLOBAL DEFAULT UND _[...]@GLIBC_2.34 (2)
2: 0000000000000000 0 NOTYPE WEAK DEFAULT UND _ITM_deregisterT[...]
3: 0000000000000000 0 FUNC GLOBAL DEFAULT UND puts@GLIBC_2.2.5 (3)
4: 0000000000000000 0 NOTYPE WEAK DEFAULT UND __gmon_start__
5: 0000000000000000 0 NOTYPE WEAK DEFAULT UND _ITM_registerTMC[...]
6: 0000000000000000 0 FUNC WEAK DEFAULT UND [...]@GLIBC_2.2.5 (3)
Symbol table '.symtab' contains 38 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND
1: 0000000000000000 0 FILE LOCAL DEFAULT ABS Scrt1.o
2: 000000000000038c 32 OBJECT LOCAL DEFAULT 4 __abi_tag
3: 0000000000000000 0 FILE LOCAL DEFAULT ABS crtstuff.c
4: 0000000000001090 0 FUNC LOCAL DEFAULT 16 deregister_tm_clones
5: 00000000000010c0 0 FUNC LOCAL DEFAULT 16 register_tm_clones
6: 0000000000001100 0 FUNC LOCAL DEFAULT 16 __do_global_dtors_aux
7: 0000000000004010 1 OBJECT LOCAL DEFAULT 26 completed.0
8: 0000000000003dc0 0 OBJECT LOCAL DEFAULT 22 __do_global_dtor[...]
9: 0000000000001140 0 FUNC LOCAL DEFAULT 16 frame_dummy
10: 0000000000003db8 0 OBJECT LOCAL DEFAULT 21 __frame_dummy_in[...]
11: 0000000000000000 0 FILE LOCAL DEFAULT ABS hello.c
12: 0000000000000000 0 FILE LOCAL DEFAULT ABS code.c
13: 0000000000000000 0 FILE LOCAL DEFAULT ABS crtstuff.c
14: 0000000000002120 0 OBJECT LOCAL DEFAULT 20 __FRAME_END__
15: 0000000000000000 0 FILE LOCAL DEFAULT ABS
16: 0000000000003dc8 0 OBJECT LOCAL DEFAULT 23 _DYNAMIC
17: 000000000000201c 0 NOTYPE LOCAL DEFAULT 19 __GNU_EH_FRAME_HDR
18: 0000000000003fb8 0 OBJECT LOCAL DEFAULT 24 _GLOBAL_OFFSET_TABLE_
19: 0000000000000000 0 FUNC GLOBAL DEFAULT UND __libc_start_mai[...]
20: 0000000000000000 0 NOTYPE WEAK DEFAULT UND _ITM_deregisterT[...]
21: 0000000000004000 0 NOTYPE WEAK DEFAULT 25 data_start
22: 0000000000000000 0 FUNC GLOBAL DEFAULT UND puts@GLIBC_2.2.5
23: 0000000000004010 0 NOTYPE GLOBAL DEFAULT 25 _edata
24: 0000000000001171 26 FUNC GLOBAL DEFAULT 16 run
25: 000000000000118c 0 FUNC GLOBAL HIDDEN 17 _fini
26: 0000000000004000 0 NOTYPE GLOBAL DEFAULT 25 __data_start
27: 0000000000000000 0 NOTYPE WEAK DEFAULT UND __gmon_start__
28: 0000000000004008 0 OBJECT GLOBAL HIDDEN 25 __dso_handle
29: 0000000000002000 4 OBJECT GLOBAL DEFAULT 18 _IO_stdin_used
30: 0000000000004018 0 NOTYPE GLOBAL DEFAULT 26 _end
31: 0000000000001060 38 FUNC GLOBAL DEFAULT 16 _start
32: 0000000000004010 0 NOTYPE GLOBAL DEFAULT 26 __bss_start
33: 0000000000001149 40 FUNC GLOBAL DEFAULT 16 main
34: 0000000000004010 0 OBJECT GLOBAL HIDDEN 25 __TMC_END__
35: 0000000000000000 0 NOTYPE WEAK DEFAULT UND _ITM_registerTMC[...]
36: 0000000000000000 0 FUNC WEAK DEFAULT UND __cxa_finalize@G[...]
37: 0000000000001000 0 FUNC GLOBAL HIDDEN 12 _init
从上面的结果中可以看到run函数对应的section的编号为16，这意味着run函数在编号为16的节中。
readelf -S main
从main.s中可以得到验证（只关注开头的描述以及main函数和run函数即可）：
Disassembly of section .text:
0000000000001060 <_start>:
1060: f3 0f 1e fa endbr64
1064: 31 ed xor %ebp,%ebp
1066: 49 89 d1 mov %rdx,%r9
1069: 5e pop %rsi
106a: 48 89 e2 mov %rsp,%rdx
106d: 48 83 e4 f0 and $0xfffffffffffffff0,%rsp
1071: 50 push %rax
1072: 54 push %rsp
1073: 45 31 c0 xor %r8d,%r8d
1076: 31 c9 xor %ecx,%ecx
1078: 48 8d 3d ca 00 00 00 lea 0xca(%rip),%rdi # 1149
107f: ff 15 53 2f 00 00 call *0x2f53(%rip) # 3fd8 <__libc_start_main@GLIBC_2.34>
1085: f4 hlt
1086: 66 2e 0f 1f 84 00 00 cs nopw 0x0(%rax,%rax,1)
108d: 00 00 00
0000000000001090 :
1090: 48 8d 3d 79 2f 00 00 lea 0x2f79(%rip),%rdi # 4010 <__TMC_END__>
1097: 48 8d 05 72 2f 00 00 lea 0x2f72(%rip),%rax # 4010 <__TMC_END__>
109e: 48 39 f8 cmp %rdi,%rax
10a1: 74 15 je 10b8
10a3: 48 8b 05 36 2f 00 00 mov 0x2f36(%rip),%rax # 3fe0 <_ITM_deregisterTMCloneTable@Base>
10aa: 48 85 c0 test %rax,%rax
10ad: 74 09 je 10b8
10af: ff e0 jmp *%rax
10b1: 0f 1f 80 00 00 00 00 nopl 0x0(%rax)
10b8: c3 ret
10b9: 0f 1f 80 00 00 00 00 nopl 0x0(%rax)
00000000000010c0 :
10c0: 48 8d 3d 49 2f 00 00 lea 0x2f49(%rip),%rdi # 4010 <__TMC_END__>
10c7: 48 8d 35 42 2f 00 00 lea 0x2f42(%rip),%rsi # 4010 <__TMC_END__>
10ce: 48 29 fe sub %rdi,%rsi
10d1: 48 89 f0 mov %rsi,%rax
10d4: 48 c1 ee 3f shr $0x3f,%rsi
10d8: 48 c1 f8 03 sar $0x3,%rax
10dc: 48 01 c6 add %rax,%rsi
10df: 48 d1 fe sar %rsi
10e2: 74 14 je 10f8
10e4: 48 8b 05 05 2f 00 00 mov 0x2f05(%rip),%rax # 3ff0 <_ITM_registerTMCloneTable@Base>
10eb: 48 85 c0 test %rax,%rax
10ee: 74 08 je 10f8
10f0: ff e0 jmp *%rax
10f2: 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1)
10f8: c3 ret
10f9: 0f 1f 80 00 00 00 00 nopl 0x0(%rax)
0000000000001100 <__do_global_dtors_aux>:
1100: f3 0f 1e fa endbr64
1104: 80 3d 05 2f 00 00 00 cmpb $0x0,0x2f05(%rip) # 4010 <__TMC_END__>
110b: 75 2b jne 1138 <__do_global_dtors_aux+0x38>
110d: 55 push %rbp
110e: 48 83 3d e2 2e 00 00 cmpq $0x0,0x2ee2(%rip) # 3ff8 <__cxa_finalize@GLIBC_2.2.5>
1115: 00
1116: 48 89 e5 mov %rsp,%rbp
1119: 74 0c je 1127 <__do_global_dtors_aux+0x27>
111b: 48 8b 3d e6 2e 00 00 mov 0x2ee6(%rip),%rdi # 4008 <__dso_handle>
1122: e8 19 ff ff ff call 1040 <__cxa_finalize@plt>
1127: e8 64 ff ff ff call 1090
112c: c6 05 dd 2e 00 00 01 movb $0x1,0x2edd(%rip) # 4010 <__TMC_END__>
1133: 5d pop %rbp
1134: c3 ret
1135: 0f 1f 00 nopl (%rax)
1138: c3 ret
1139: 0f 1f 80 00 00 00 00 nopl 0x0(%rax)
0000000000001140 :
1140: f3 0f 1e fa endbr64
1144: e9 77 ff ff ff jmp 10c0
0000000000001149 :
1149: f3 0f 1e fa endbr64
114d: 55 push %rbp
114e: 48 89 e5 mov %rsp,%rbp
1151: 48 8d 05 ac 0e 00 00 lea 0xeac(%rip),%rax # 2004 <_IO_stdin_used+0x4>
1158: 48 89 c7 mov %rax,%rdi
115b: e8 f0 fe ff ff call 1050
1160: b8 00 00 00 00 mov $0x0,%eax
1165: e8 07 00 00 00 call 1171
116a: b8 00 00 00 00 mov $0x0,%eax
116f: 5d pop %rbp
1170: c3 ret
0000000000001171 :
1171: f3 0f 1e fa endbr64
1175: 55 push %rbp
1176: 48 89 e5 mov %rsp,%rbp
1179: 48 8d 05 91 0e 00 00 lea 0xe91(%rip),%rax # 2011 <_IO_stdin_used+0x11>
1180: 48 89 c7 mov %rax,%rdi
1183: e8 c8 fe ff ff call 1050
1188: 90 nop
1189: 5d pop %rbp
118a: c3 ret
Disassembly of section .fini:
目标文件又叫可重定位文件，这里的重定位就是指的为这些外部函数或变量重新分配地址的过程。
总结来说，静态链接的原理就是将各个目标文件的对应节分别合并，并对照符号表完成对外部函数或变量的重定位。
2.1 虚拟地址空间补充
我们前面在main.s中看到，run函数的地址是1171，但实际上这个说法并不准确。准确的说法是：1171是run函数在代码段的地址，也即run函数在代码段的偏移量（各个段内部从0开始编址）。
run函数最终被加载到内存当中的虚拟地址应该是代码段的地址+偏移量。
其中代码段的地址是在每次程序被加载到内存当中时随机分配的。
我们修改一下hello.c的代码：
#include
void run();
int main() {
printf("hello world!
");
run();
printf("%p
", &run);
return 0;
} 重新编译链接之后，run函数的地址变为：
00000000000011af : 运行./main可以看到结果：
shishen@hcss-ecs-b8e6:~/113code/linux-c/动静态库/display$ ./main
hello world!
running...
0x55b1458801af
shishen@hcss-ecs-b8e6:~/113code/linux-c/动静态库/display$ ./main
hello world!
running...
0x55ca012441af
shishen@hcss-ecs-b8e6:~/113code/linux-c/动静态库/display$ ./main
hello world!
running...
0x56372f8ed1af很明显，run函数的虚拟地址是极富规律且与其偏移量强相关的。
ELF文件是地址空间初始化的基础，但完整的内存布局是内核、ELF、动态链接器共同作用的结果。
| 地址类型 | 描述 | 生成方式 | 转换关系 | 应用场景 |
|---|---|---|---|---|
| 逻辑地址 | 程序直接使用的地址，由段选择符和段内偏移组成 | 编译器或程序员定义 | 分段机制→线性地址 | 编程时的指针操作、进程内部寻址 |
| 虚拟地址 | 进程虚拟内存空间中的地址（通常与线性地址等价） | 操作系统分配 | 分页机制→物理地址 | 多进程隔离、内存抽象管理 |
| 物理地址 | 内存硬件实际使用的地址 | 硬件直接寻址 | 无转换（最终地址） | 硬件操作、内存芯片级访问 |
| 绝对地址 | 固定地址，直接对应物理内存或编译时确定的绝对位置 | 编译时静态分配 | 直接映射到物理地址 | 早期嵌入式系统、无虚拟内存环境 |
| 相对地址 | 相对于基址（如程序加载基址）的偏移量，属于逻辑地址的一部分 | 程序运行时动态计算（基址+偏移） | 基址+偏移=逻辑/线性地址 | 动态链接库、可重定位代码 |
3. 动态链接的原理
进程是如何跳转到动态库并共享动态库的代码的呢？
概括来说很简单，将动态库函数的逻辑地址映射到物理地址空间中动态库代码所在位置即可。
即库的起始虚拟地址 + 方法偏移量 ---> 库的起始物理地址 + 方法偏移量。
但实际上其中的细节与机制并不简单。
3.1 链接的时机
动态库地链接是通过动态链接器完成的，动态链接器的调用时机主要分为两个阶段：程序启动时的初始加载阶段和运行时的延迟绑定阶段。
3.1.1 程序启动时的初始加载阶段
当操作系统加载并执行一个动态链接的可执行文件时，内核会首先检查该文件的解释器字段（ELF 文件中的 .interp 段），该字段指定了动态链接器的路径（如 Linux 中的 /lib64/ld-linux-x86-64.so.2）。此时，内核会执行以下操作：
- 加载动态链接器：内核将动态链接器加载到内存，并将其作为程序的解释器启动。
- 传递参数：动态链接器接收可执行文件的路径和参数，例如执行 /proc/self/exe 时，内核会调用 /lib64/ld-linux.so.2 /proc/self/exe，但动态链接器会正确处理这种自引用场景5。
- 加载依赖库：动态链接器解析可执行文件依赖的共享库（如 .so 文件），递归加载并初始化它们。
- 初始重定位：对需要立即解析的符号（如全局变量、静态构造函数）进行地址重定位，确保程序入口点前的准备工作完成。
/lib64/ld-linux-x86-64.so.2 用于程序初始化：
在C/C++程序中，当程序开始执行时，它首先并不会直接跳转到 main 函数。实际上，程序的入口点是 _start ，这是一个由C运行时库（通常是glibc）或链接器（如ld）提供的特殊函数。
从main.s中可以看到，_start的地址位1060，而ELF header中指明的程序入口地址就是1060：
shishen@hcss-ecs-b8e6:~/113code/linux-c/动静态库/display$ readelf -h main
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: DYN (Position-Independent Executable file)
Machine: Advanced Micro Devices X86-64
Version: 0x1
Entry point address: 0x1060 # 程序入口地址
Start of program headers: 64 (bytes into file)
Start of section headers: 14032 (bytes into file)
Flags: 0x0
Size of this header: 64 (bytes)
Size of program headers: 56 (bytes)
Number of program headers: 13
Size of section headers: 64 (bytes)
Number of section headers: 31
Section header string table index: 30在 _start 函数中，会执行一系列初始化操作，这些操作包括：
- 设置堆栈：为程序创建一个初始的堆栈环境。
- 初始化数据段：将程序的数据段（如全局变量和静态变量）从初始化数据段复制到相应的内存位置，并清零未初始化的数据段。
- 动态链接：这是关键的一步， _start 函数会调用动态链接器的代码来解析和加载程序所依赖的动态库（shared libraries）。
- 调用 __libc_start_main ：一旦动态链接完成， _start 函数会调用__libc_start_main （这是glibc提供的⼀个函数）。 __libc_start_main 函数负责执行一些额外的初始化工作，比如设置信号处理函数、初始化线程库（如果使用了线程）等。
- 调用 main 函数：最后， __libc_start_main 函数会调用程序的 main 函数，此时程序的执行控制权才正式交给用户编写的代码。
- 处理 main 函数的返回值：当 main 函数返回时， __libc_start_main 会负责处理这个返回值，并最终调用 _exit 函数来终止程序。
3.1.2 运行时的延迟绑定阶段（Lazy Binding）
对于大部分函数调用，动态链接器采用延迟绑定（Lazy Binding）机制，即函数地址的解析和重定位推迟到第一次调用时完成。这一过程通过 PLT（过程链接表） 和 GOT（全局偏移表） 实现。
3.2 全局偏移量表GOT
- 动态库（.so 文件）必须编译为位置无关代码（下文会说明），以便加载到任意内存地址。此时，代码段无法直接使用绝对地址（因为库的加载地址在运行时才确定）。
- 那么，我们要在加载时对代码段进行重定位吗？但代码段的权限为只读，我们无法对代码段进行修改。为了实现这一点，动态链接需要一种机制来在运行时查找和绑定符号的地址，这就是GOT的作用。
全局偏移量表（GOT，Global Offset Table）是Linux系统下ELF格式可执行文件中用于定位全局变量和函数的表，主要用于动态链接。
其实际上就是在专门预留的一片用来存放函数的跳转地址的区域：.got节。
[24] .got PROGBITS 0000000000003fb0 00002fb0
0000000000000050 0000000000000008 WA 0 0 8由于.got所在的段是可读可写的，所以就可以实现在运行当中动态地完成重定位。
3.3 过程链接表PLT
我们在main.s中可以看到，动态链接库函数的函数名之后都会跟着PLT：
PLT（Procedure Linkage Table，过程链接表）是程序动态链接中的关键机制，主要用于延迟绑定（Lazy Binding）动态库中的函数地址。
延迟绑定：程序启动时不会立即解析所有动态库函数的地址，而是在首次调用时才通过PLT解析并缓存地址，减少启动时间。
3.3.1 GOT与PLT的作用
存储全局变量和函数地址：GOT存储了程序中使用的外部函数和全局变量的实际地址，使得程序在运行时能够正确地访问这些外部符号。
支持动态链接：在动态链接过程中，GOT允许程序在运行时解析和绑定外部符号，而不需要在编译时就确定所有符号的地址。
实现延迟绑定：通过GOT和PLT（过程链接表）的配合，实现了函数的延迟绑定，即函数在第一次被调用时才进行地址绑定，提高了程序的启动速度。
3.3.2 工作原理
第一次调用：当程序第一次调用某个外部函数时，会通过PLT跳转到GOT，由于GOT中此时没有该函数的地址，会再次跳转回PLT，PLT会将函数的ID压入栈中，然后调用_dl_runtime_resolve函数进行符号查找和重定位，找到函数地址后，将其填充到GOT中，之后再跳转到该函数地址执行。
后续调用：当再次调用该函数时，PLT会直接跳转到GOT中存储的函数地址，无需再次进行符号查找和重定位。
3.3.3 GOT 与 PLT 的关系
- GOT：存储符号的实际地址（数据）。是数据段的一部分，存储动态链接器填充的地址。
- PLT：实现延迟绑定的跳转逻辑（代码）。是代码段的一部分，包含跳转到 GOT 的指令。
3.4 地址无关代码PIC
动态库被加载到内存当中之后，其内部函数的虚拟地址就都是确定了的。当我们使用这些共享代码时，在我们进程的虚拟地址空间当中也应当为其分配对应的虚拟地址，否则代码与其地址就对应不起来了（代码也是要编址的，分支跳转循环都需要访问这些地址）。
这就会导致一个问题：动态库要求的地址与其他部分发生冲突。
为了解决这个问题，我们希望动态库中的代码被加载到任意位置都能运行，这就是地址无关代码。
PIC（Position Independent Code）地址无关代码是一种编程技术，它使得代码不依赖于特定的内存地址。
所以我们在编译动态库对应的目标文件时，需要加上-fPIC选项：
gcc -fPIC -c3.4.1 原理
相对寻址：PIC代码通过使用相对寻址方式来访问数据和代码，而不是使用绝对地址。这意味着代码可以在内存中的任何位置加载和执行，而不需要进行代码段重定位。
全局偏移表（GOT）：在PIC中，全局变量和函数的地址是通过全局偏移表（GOT）来访问的。GOT是一个数据结构，用于存储全局变量和函数的实际地址。当代码需要访问这些全局符号时，它会通过GOT中的相应项来间接引用。
3.4.2 绝对寻址 VS 相对寻址
- 绝对寻址：指令直接使用固定内存地址访问数据或跳转代码。
示例：若指令 call 0x200 调用位于地址 0x200 的函数，当代码被加载到新地址（如 0x300），该指令仍需调用 0x200，但此时函数可能已移动（如到 0x400），导致错误。- 相对寻址：指令基于当前程序计数器（PC）的偏移量计算地址。
示例：指令 call +0x100 表示“跳转到当前指令地址 + 0x100 的位置”。无论代码加载到何处（如 0x100 或 0x300），偏移量 0x100 始终有效，无需修改指令。
4. 总结
动静态库的原理本质上可以看作是虚拟地址（绝对地址）分配的时机与原理，因为我们将虚拟地址映射到实际的物理地址就可以访问对应的代码。
绝对地址的分配时机取决于具体的场景（如静态链接、动态链接、是否启用PIC等）：
4.1. 静态链接（非PIC）
-
分配时机：链接阶段（编译后）
-
在静态链接的非PIC代码中，绝对地址（虚拟地址）由链接器在生成可执行文件时直接分配。
-
链接器将所有目标文件（
.o文件）合并，并根据预设的虚拟内存布局（如Linux默认加载地址0x400000）为代码和数据段分配固定的虚拟地址。 -
特点：地址在编译时已知，但程序必须加载到固定虚拟地址才能运行。
-
4.2. 静态链接（启用PIC）
-
分配时机：加载阶段（程序启动时）
-
在PIC（位置无关代码）中，代码段通过相对寻址实现位置无关，但全局数据/函数的绝对地址需要通过**全局偏移表（GOT）**动态获取。
-
加载时重定位：程序启动时，操作系统加载器（如
ld-linux.so）将程序加载到任意虚拟地址，并解析GOT中全局符号的绝对地址，填入对应的GOT条目。 -
特点：绝对地址在加载时确定，程序可加载到任意虚拟地址。
-
4.3. 动态链接（共享库）
-
分配时机：运行时（首次调用时）
-
动态链接的共享库（
.so文件）使用PIC，其全局符号的绝对地址通过**延迟绑定（Lazy Binding）**实现：-
PLT（过程链接表）：程序首次调用共享库函数时，跳转到PLT条目。
-
动态链接器介入：动态链接器（如
ld-linux.so）解析函数绝对地址，更新GOT条目。 -
后续调用：直接通过GOT跳转到目标地址。
-
-
特点：地址分配延迟到首次调用时，减少启动开销。
-
4.4 物理地址的分配
-
分配时机：由操作系统和硬件（MMU）运行时动态管理。
-
程序使用的是虚拟地址，物理地址由操作系统在页表（Page Table）中动态映射。
-
即使程序的虚拟地址在链接时固定（非PIC），物理地址仍由操作系统在加载时和运行时按需分配（通过分页机制）。
-
