2.1 ELF文件的组成结构#

ELF文件由以下四部分组成：

1. ELF头（ELF Header）

   • 位于文件开始位置，描述文件的主要特性（如文件类型、机器架构、入口点地址等）。

   • 定位程序头表和节头表的位置。

2. 程序头表（Program Header Table）

   • 描述如何将文件映射到内存，列举所有段（segments）及其属性（偏移、长度、权限等）。

   • 用于加载可执行文件，是执行视图的核心。

3. 节（Sections）

   • ELF文件的基本组成单元，存储特定类型的数据（如代码、数据、符号表等）。

   • 常见节：

     • .text：代码节，保存机器指令。

     • .data：已初始化的全局变量和静态变量。

     • .rodata：只读数据（如字符串常量）。

     • .bss：未初始化的全局变量和静态变量（仅占位符，不占用文件空间）。

     • .symtab：符号表，记录函数名、变量名与地址的对应关系。

     • .got / .plt：全局偏移表和过程链接表，用于动态链接。

4. 节头表（Section Header Table）

   • 描述所有节的属性（名称、类型、偏移、大小等），是链接视图的核心。

   • 可重定位文件必须有节头表，可执行文件可选。

两个视图：

• 链接视图（Linking View）：通过节头表查看，用于静态链接时合并节。

• 执行视图（Execution View）：通过程序头表查看，用于运行时加载段。

4.1 查看节头表#

1
$ readelf -S a.out
2
There are 31 section headers, starting at offset 0x19d8:
3
Section Headers:
4
  [Nr] Name              Type             Address           Offset
5
       Size              EntSize          Flags  Link  Info  Align
6
  [16] .text             PROGBITS         0000000000001060  00001060
7
       00000000000001a5  0000000000000000  AX       0     0     16
8
  [25] .data             PROGBITS         0000000000004000  00003000
9
       0000000000000010  0000000000000000  WA       0     0     8
10
  [26] .bss              NOBITS           0000000000004010  00003010
11
       0000000000000008  0000000000000000  WA       0     0     1
12
  ...

• Flags：W（可写）、A（可分配内存）、X（可执行）、…

• 可执行文件中，.got、.data、.bss 等通常合并到同一个段（segment）中。

4.2 查看程序头表（段）#

1
$ readelf -l a.out
2
Elf file type is EXEC (Executable file)
3
Entry point 0x4003e0
4
There are 9 program headers, starting at offset 64
5

6
Program Headers:
7
  Type           Offset   VirtAddr           PhysAddr           FileSiz  MemSiz   Flg Align
8
  LOAD           0x000000 0x0000000000400000 0x0000000000400000 0x000744 0x000744 R E 0x200000
9
  LOAD           0x000e10 0x0000000000600e10 0x0000000000600e10 0x000218 0x000220 RW  0x200000
10
  DYNAMIC        0x000e28 0x0000000000600e28 0x0000000000600e28 0x0001d0 0x0001d0 RW  0x8
11
  ...
12

13
Section to Segment mapping:
14
  Segment Sections...
15
   02     .interp .note.ABI-tag .note.gnu.build-id .gnu.hash .dynsym .dynstr .gnu.version ... .text .rodata ...
16
   03     .init_array .fini_array .jcr .dynamic .got .got.plt .data .bss

LOAD段：

• 告诉操作系统哪些模块可以被加载进内存。

• 加载进内存之后哪些分段是可读可写，哪些分段是只读，哪些分段是可执⾏的。

• 多个节合并为段，目的是减少内存页内碎片，提高内存利用率（例如将.text和.rodata合并到只读可执行段）。

5.1 为什么需要重定位？#

编译单个源文件时，编译器无法知道外部函数（如printf、其他模块的函数）的地址，因此临时填充为0或占位符，留待链接时修正。 objdump -d<将代码段>（.text）进⾏反汇编查看

1
$ objdump -d hello.o
2
0000000000000000 <main>:
3
   0:   f3 0f 1e fa          endbr64
4
   4:   55                   push   %rbp
5
   5:   48 89 e5             mov    %rsp,%rbp
6
   8:   48 8d 3d 00 00 00 00 lea    0x0(%rip),%rdi        # f <main+0xf>   # 字符串地址未知
7
   f:   e8 00 00 00 00       callq  14 <main+0x14>        # printf地址未知
8
  14:   b8 00 00 00 00       mov    $0x0,%eax
9
  19:   e8 00 00 00 00       callq  1e <main+0x1e>        # run函数地址未知
10
  1e:   b8 00 00 00 00       mov    $0x0,%eax
11
  23:   5d                   pop    %rbp
12
  24:   c3                   retq

5.2 符号表与未定义符号#

使用 readelf -s 查看符号表：

1
$ readelf -s code.o
2
Symbol table '.symtab' contains 13 entries:
3
   Num:    Value          Size Type    Bind   Vis      Ndx Name
4
    10: 0000000000000000    23 FUNC    GLOBAL DEFAULT    1 run
5
    12: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  UND puts   # UND表示未定义

• UND：未定义符号，需要在链接时从其他目标文件或库中解析。

• 静态链接：将所有目标文件的节合并，并根据符号表修正地址（重定位）。

5.3 链接过程#

1. 合并各个.o文件的相同节（如将所有.text合并）。

2. 为合并后的节分配虚拟地址（可执行文件有固定基址，现代系统使用ASLR，但链接时生成相对地址）。

3. 根据重定位表修正指令中的地址（将占位符替换为真实地址）。

1
$ objdump -d a.out
2
0000000000001149 <run>:
3
    1149:   f3 0f 1e fa          endbr64
4
    114d:   55                   push   %rbp
5
    114e:   48 89 e5             mov    %rsp,%rbp
6
    1151:   48 8d 3d ac 0e 00 00 lea    0xeac(%rip),%rdi   # 2004 <_IO_stdin_used+0x4>
7
    1158:   e8 f3 fe ff ff       callq  1050 <puts@plt>     # 已修正为PLT入口
8
    115d:   90                   nop
9
    115e:   5d                   pop    %rbp
10
    115f:   c3                   retq

所以，链接过程中会涉及到对.o中外部符号进行地址重定位。

6.1 为什么需要动态链接？#

• 节省磁盘和内存空间：多个程序共享同一份库代码，内存中只需加载一次。

• 便于更新：升级库无需重新链接所有程序。

6.2 动态库的加载#

程序启动时，动态链接器（如ld-linux.so）负责：

1. 解析可执行文件依赖的共享库（通过.dynamic段和.dynstr）。

2. 将库映射到进程地址空间的共享区。

3. 重定位库中的符号（GOT表更新）。-确保程序中的函数调用和变量访问能正确映射到动态库中的实际地址

查看依赖：

1
$ ldd a.out
2
        linux-vdso.so.1 (0x00007ffc3a5f7000)
3
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f8a1a200000)
4
        /lib64/ld-linux-x86-64.so.2 (0x00007f8a1a5f7000)

6.3 地址无关代码（PIC）与GOT#

动态库需要在任意地址加载，因此编译时必须用 -fPIC 生成地址无关代码。

1
gcc -shared -fPIC -o lib.so source.c

这个选项告诉编译器： “生成代码时，所有访问都用 rip 相对寻址，别用绝对地址”

• 库内部函数调用使用相对寻址。

• 外部函数和全局变量的地址通过全局偏移表（GOT） 间接访问。

GOT（Global Offset Table）：位于数据段（可写），存放全局变量和函数的实际地址。

• 代码中访问外部符号时，先通过GOT获取地址，再跳转。

• GOT表项在动态库加载时由动态链接器填充。

6.4 延迟绑定与PLT#

为了减少启动时的重定位开销，采用延迟绑定技术，通过过程链接表（PLT） 实现。

• PLT（Procedure Linkage Table）：代码段中的一小段桩代码，每个动态函数对应一个PLT条目。

• 第一次调用函数时，PLT跳转到动态链接器的解析函数，解析后将真实地址填入GOT，然后执行函数。

• 后续调用直接通过GOT跳转。

反汇编观察：

1
0000000000001050 <puts@plt>:
2
    1050:   f3 0f 1e fa          endbr64
3
    1054:   f2 ff 25 75 2f 00 00 bnd jmpq *0x2f75(%rip)        # 3fd0 <puts@GLIBC_2.2.5>
4
    # 第一次调用时，*0x2f75 指向下一行指令（解析代码），解析后指向真正的puts

6.5 GOT的修改#

动态库映射完成后，动态链接器根据库的基址和函数偏移，计算实际地址，并写入GOT表项。 因此GOT表位于可写段（如.got），而代码段保持只读，可被多个进程共享。

7.1 ELF文件中的虚拟地址#

ELF文件在编译时就已经为代码和数据分配了虚拟地址（从0开始编址）。 可执行文件的入口点（Entry point）就是虚拟地址，由ELF头指定。

1
$ readelf -h a.out | grep Entry
2
  Entry point address:               0x1060

7.2 进程地址空间的初始化#

当程序被加载时，内核根据程序头表（LOAD段）创建 vm_area_struct 结构，描述各段在虚拟内存中的位置（起始、结束、权限）。

• 代码段：只读、可执行

• 数据段：可读写

• 堆、栈、共享库映射区等

1
// task_struct 中包含 mm_struct，mm_struct 中包含 vm_area_struct 链表
2
struct mm_struct {
3
    struct vm_area_struct *mmap;  // 虚拟区间链表
4
    // ...
5
};

7.3 动态库映射到进程地址空间#

动态库通过mmap系统调用映射到进程的共享区。

• 库的代码段映射为只读可执行，数据段映射为可读写。

• 映射后，动态链接器更新GOT表，完成重定位。

8.1 最初状态：程序在磁盘上#

1
磁盘上的可执行文件：
2
┌─────────────────────────┐
3
│        ELF头            │
4
├─────────────────────────┤
5
│       代码段 .text       │
6
│   call printf@plt       │  ← 只知道要调用 printf
7
│   call malloc@plt       │     但不知道 printf 在哪
8
├─────────────────────────┤
9
│       数据段 .data       │
10
│   GOT表(初始状态)        │
11
│   printf_addr = 0       │  ← 还没填地址
12
│   malloc_addr = 0       │
13
└─────────────────────────┘
14

15
磁盘上的 libc.so：
16
┌─────────────────────────┐
17
│       代码段 .text       │
18
│   printf函数在这里       │
19
│   malloc函数在这里       │
20
└─────────────────────────┘

8.2 加载程序到内存#

1
步骤1：程序被加载器加载到内存
2
┌─────────────────────────┐
3
│     进程地址空间         │
4
├─────────────────────────┤
5
│   代码段 (来自可执行文件) │
6
│   call printf@plt       │
7
├─────────────────────────┤
8
│   数据段 (来自可执行文件) │
9
│   GOT表(还是空的)        │
10
└─────────────────────────┘
11

12
此时程序还不知道 libc.so 在哪

8.3 动态链接器介入#

1
步骤2：动态链接器 /lib/ld-linux.so 被加载
2
┌─────────────────────────┐
3
│     进程地址空间         │
4
├─────────────────────────┤
5
│   程序代码段             │
6
├─────────────────────────┤
7
│   程序数据段             │
8
├─────────────────────────┤
9
│   动态链接器             │ ← 负责找库、加载库
10
└─────────────────────────┘

8.4 查找需要的动态库#

1
步骤3：动态链接器查看程序头
2
程序说："我需要 libc.so"
3

4
动态链接器开始找：
5
1. 检查 LD_LIBRARY_PATH 环境变量
6
2. 检查 /etc/ld.so.cache
7
3. 检查 /lib, /usr/lib
8

9
找到 libc.so 在 /lib/x86_64-linux-gnu/libc.so.6

8.5 打开并映射动态库#

1
步骤4：动态链接器打开 libc.so 文件
2

3
int fd = open("/lib/libc.so.6", O_RDONLY);
4

5
步骤5：用 mmap 映射到进程地址空间
6

7
┌─────────────────────────┐
8
│     进程地址空间         │
9
├─────────────────────────┤
10
│   程序代码段             │
11
├─────────────────────────┤
12
│   程序数据段             │
13
├─────────────────────────┤
14
│   动态链接器             │
15
├─────────────────────────┤
16
│   libc.so 代码段         │ ← mmap 到这里
17
│   printf函数实际代码在这里│
18
├─────────────────────────┤
19
│   libc.so 数据段         │
20
└─────────────────────────┘

• 动态库也是文件，要访问也是要被先加载，要加载也是要被先打开
• 进程找到动态库的本质也是文件操作，不过我们访问库函数是通过虚拟地址进行跳转访问，所以需要把动态库映射到进程的地址空间

8.6 填写 GOT 表#

1
步骤6：动态链接器计算函数地址
2

3
libc.so 起始地址 = 0x7f8a4000
4
printf 在 libc 中的偏移 = 0x3a
5
printf 真实地址 = 0x7f8a4000 + 0x3a = 0x7f8a403a
6

7
步骤7：把这个地址写入 GOT 表
8

9
┌─────────────────────────┐
10
│   GOT表                  │
11
│   printf_addr = 0x7f8a403a │ ← 填好了！
12
│   malloc_addr = 0x7f8a4120 │
13
└─────────────────────────┘

8.7 进程终于”看到”了动态库#

1
现在进程的完整视图：
2

3
┌─────────────────────────┐ 0x7f8a4000 (libc 起始)
4
│   libc.so 代码段         │
5
│   0x7f8a403a: printf     │ ← 进程通过 GOT 知道这里
6
│   0x7f8a4120: malloc     │
7
├─────────────────────────┤
8
│   libc.so 数据段         │
9
└─────────────────────────┘
10

11
┌─────────────────────────┐
12
│   程序代码段             │
13
│   call printf@plt       │
14
│   ↓                     │
15
│   printf@plt:           │
16
│       jmp *GOT[printf]  │ → 跳到 0x7f8a403a
17
└─────────────────────────┘
18

19
进程终于能看到并调用 printf 了！

动态库最初在磁盘上，通过 mmap 预订虚拟地址，通过第一次访问时的缺页异常触发从磁盘到物理内存的加载，之后所有进程共享这同一份物理内存 动态库的物理内存只有一份，但虚拟地址在不同进程中不一样，通过页表映射。程序调用库函数时，先通过 GOT/PLT 找到虚拟地址，再通过页表找到物理地址。