当前位置：首页 > news >正文

深入解析ELF文件格式：从链接、加载到动态链接的完整指南

news 2026/8/5 4:03:32

1. 从可执行文件说起：为什么需要ELF？

如果你在Linux下用GCC编译过一个简单的“Hello World”程序，然后敲下ls -l a.out，你会看到一个名为a.out的文件。这个文件就是你的程序吗？是，但也不完全是。你双击它并不能直接运行，你需要通过终端输入./a.out来执行。这个看似简单的过程背后，隐藏着操作系统加载和运行一个程序的完整逻辑链。而这一切的起点，就是ELF文件格式。

ELF，全称Executable and Linkable Format，即可执行可链接格式。它是Linux世界（以及许多其他类Unix系统）中二进制文件的“标准身份证”和“结构蓝图”。无论是你编译出的可执行程序、系统里的共享库（.so文件），还是编译中间产生的目标文件（.o文件），甚至内核本身，大都采用ELF格式。理解ELF，是理解程序如何在Linux上“活”起来的第一步。

为什么是ELF，而不是一堆纯粹的机器指令？想象一下你要组装一个复杂的乐高模型。你收到的不是一个已经粘死的整体，而是一袋袋零件（代码段、数据段）、一份拼装说明书（文件头、节头表）、以及一张指示哪些零件袋属于哪个步骤的清单（程序头表）。ELF文件就是这样一个高度结构化的包裹。这种结构化的设计，主要解决了三个核心问题：

链接：一个大型软件通常由多个源文件（.c）编译成多个目标文件（.o），这些目标文件需要被“缝合”在一起，解决彼此间的函数调用、变量引用关系。ELF为目标文件提供了标准的“接口”和“标签”，让链接器知道哪里需要缝合。
加载：操作系统不能直接把整个文件扔进内存。它需要知道哪些部分是必须的指令（代码），哪些是初始化的数据，哪些是未初始化的数据（运行时再分配空间），以及这些部分应该被放到内存的什么地址。ELF的程序头表就是给操作系统加载器看的“装载指南”。
动态链接：现代程序很少把所有代码都打包进一个巨大的可执行文件。它们会依赖像libc.so（C标准库）这样的共享库。程序运行时，这些库的代码需要被映射到进程的地址空间。ELF格式定义了如何记录这些依赖关系，以及动态链接器如何查找和加载它们。

所以，当你面对一个Linux下的二进制文件时，无论是分析崩溃的Core Dump，还是逆向一个程序，亦或是优化启动速度，ELF都是你无法绕开的基础知识。接下来，我们就用实际工具和例程，一层层剥开ELF的外壳。

2. 解剖ELF：结构详解与实用工具

要理解ELF，最好的方式就是直接“看”。Linux提供了强大的工具链来帮助我们审视ELF文件，最核心的就是readelf和objdump。让我们从一个最简单的程序开始。

2.1 创建一个简单的例程并编译

首先，我们创建两个文件来模拟一个多文件编译链接的场景。

main.c:

#include <stdio.h> extern void hello_from_another(); // 声明外部函数 int global_init_var = 84; // 已初始化的全局变量 int global_uninit_var; // 未初始化的全局变量 int main() { static int static_var = 10; // 局部静态变量 hello_from_another(); printf("Hello, ELF! Global var: %d\n", global_init_var); return 0; }

another.c:

#include <stdio.h> void hello_from_another() { printf("Hello from another file!\n"); }

使用GCC分别编译并链接：

# 编译为目标文件 gcc -c main.c -o main.o gcc -c another.c -o another.o # 链接为可执行文件 gcc main.o another.o -o demo # 也可以一步到位 # gcc main.c another.c -o demo

现在，我们有了main.o、another.o（可重定位目标文件）和demo（可执行文件）。它们都是ELF格式，但内部结构侧重不同。

2.2 使用readelf查看ELF全局视图

readelf是专门用于显示ELF文件信息的工具，信息最全。我们先看文件头，它描述了ELF文件的元信息。

readelf -h demo

输出会类似这样（关键字段已加粗）：

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: **EXEC (Executable file)** Machine: Advanced Micro Devices X86-64 Version: 0x1 **Entry point address: 0x401040** Start of program headers: 64 (bytes into file) Start of section headers: 14664 (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

关键信息解读：

Type: EXEC：表明这是一个可执行文件。如果是.o文件，这里会是REL (Relocatable file)；如果是.so文件，则是DYN (Shared object file)。
Entry point address：程序执行的入口地址，即_start函数的地址（不是main！_start是C运行时库的一部分，负责初始化环境后调用main）。
Number of section headers：节头表（Section Header Table）的条目数。节（Section）是链接视图的基本单位，包含了代码、数据、符号表、重定位表等所有信息。链接器主要关心这个。

接下来看节头表，它详细列出了文件中所有的节。

readelf -S demo | less

你会看到一个很长的列表，包含几十个节。几个最重要的节：

.text：存放编译后的机器指令（代码）。
.data：存放已初始化的全局变量和静态变量（如我们的global_init_var和static_var）。
.bss：存放未初始化的全局变量和静态变量（如global_uninit_var）。注意，.bss节在文件中不占实际空间，它只是在节头表中声明“我需要这么多字节的零初始化内存”。
.rodata：存放只读数据，比如字符串常量（我们printf里的格式字符串）。
.symtab：符号表，记录所有函数和全局变量的名字、类型、所在节、偏移量等信息。注意：默认情况下，发布的可执行文件会去掉符号表（用strip命令或gcc -s），以减小体积。我们编译时没加-s，所以还有。
.strtab：字符串表，存放.symtab等节中用到的字符串（如符号名）。

实操心得：调试时如果遇到“core dumped”但没有行号信息，很可能是因为可执行文件被strip了。生产环境为了安全性和体积通常会strip，但测试环境建议保留调试信息（gcc -g）并不要strip，以便定位问题。

2.3 使用objdump进行反汇编与深入分析

objdump功能更强大，可以反汇编、查看符号、重定位信息等。查看代码段：

objdump -d demo | less

这会输出demo中所有可执行节（主要是.text）的反汇编代码。你可以找到main函数和hello_from_another函数的汇编指令。

查看符号表（类似于readelf -s，但格式不同）：

objdump -t demo | grep -E ‘main|hello|global’

这可以帮助你确认符号的地址和类型。

对于目标文件（.o），最关键的是看它的重定位信息。目标文件中的地址都是临时的，从0开始。链接器需要根据这些信息在合并时修正地址。

objdump -r main.o

输出会显示哪些地方需要被“重定位”。例如，对于main.o中调用printf和hello_from_another的指令，因为目标文件不知道这些函数最终在哪，所以会生成一个重定位条目，告诉链接器：“在偏移量XX处，有一个对符号printf/hello_from_another的引用，请你链接时把这个地址填上。”

2.4 ELF的两种“视图”：节（Section）与段（Segment）

这是理解ELF加载的关键。前面讲的.text、.data、.bss都是“节”，这是链接视图，面向链接器。链接器关心如何把多个目标文件的各个节合并同类项（例如把所有.text节合并）。

当链接器生成可执行文件后，它会根据一个链接脚本（linker script）的规则，将多个属性相似的“节”打包成一个“段”（Segment），并生成程序头表。这是执行视图，面向操作系统加载器。加载器不关心有多少个.text节，它只关心需要把哪些“段”加载到内存，以及这些段的读写执行权限。

查看程序头表：

readelf -l demo

输出如下（简化）：

Elf file type is EXEC (Executable file) Entry point 0x401040 There are 13 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0x0000000000400040 0x0000000000400040 0x00000000000002d8 0x00000000000002d8 R 0x8 INTERP 0x0000000000000318 0x0000000000400318 0x0000000000400318 0x000000000000001c 0x000000000000001c R 0x1 [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2] LOAD 0x0000000000000000 0x0000000000400000 0x0000000000400000 0x00000000000005c8 0x00000000000005c8 R E 0x1000 LOAD 0x0000000000001000 0x0000000000401000 0x0000000000401000 0x00000000000001f5 0x00000000000001f5 R 0x1000 LOAD 0x0000000000002000 0x0000000000402000 0x0000000000402000 0x0000000000000158 0x0000000000000158 R 0x1000 LOAD 0x0000000000002df0 0x0000000000403df0 0x0000000000403df0 0x0000000000000220 0x0000000000000228 RW 0x1000 ...（其他段，如动态链接相关段）

重点关注Type为LOAD的段。加载器就是把这些LOAD段映射到进程的虚拟地址空间。注意Flags列：

R E：可读可执行。这通常对应包含.text节的段。
R：只读。对应包含.rodata等的段。
RW：可读可写。对应包含.data、.bss的段。注意.bss在文件中大小为0（FileSiz），但在内存中需要占用空间（MemSiz），加载器负责将这部分内存清零。

核心原理：为什么代码段（.text）通常不可写，数据段（.data）不可执行？这是现代操作系统安全机制（如W^X，即可写与可执行互斥）的一部分，可以防止缓冲区溢出攻击轻易地将数据段中的恶意代码执行。这种权限隔离在ELF的段级别就得到了体现和强制执行。

3. 静态链接：把零件组装成整体

链接是将多个目标文件（.o）和库文件（.a）合并成一个可执行文件或共享库的过程。我们上面使用的gcc main.o another.o -o demo就触发了链接。链接器（通常是ld）主要做两件事：符号解析和重定位。

3.1 符号解析：解决“谁是谁”的问题

每个目标文件都有一个符号表（.symtab），记录了它定义的符号（函数、全局变量）和引用的符号（外部函数、变量）。链接器的任务就是，对于每个被引用的符号，在整个输入文件中找到唯一的定义。

用nm工具可以方便地查看目标文件的符号：

nm main.o

输出中，U表示未定义（Undefined）的符号，如hello_from_another和printf；T表示在代码段定义的函数，如main；D表示在初始化数据段定义的全局变量，如global_init_var；C或B通常表示未初始化数据（common block或.bss），如global_uninit_var。

链接时，如果hello_from_another在another.o中找到了定义（T），那么对这个符号的引用就解析成功。如果printf在所有.o和.a文件中都找不到定义，链接器就会报“undefined reference”错误。

3.2 重定位：给所有东西一个最终地址

目标文件中的代码和数据地址都是从0开始的虚拟地址。当所有节被合并到输出文件后，它们被分配了最终的虚拟内存地址。链接器必须修改所有引用这些符号的指令和数据，让它们指向正确的地址，这个过程就是重定位。

我们之前用objdump -r main.o看到的重定位条目，就是告诉链接器：“在.text节的偏移量0xXX处，有一个四字节的数据，它需要被替换成符号hello_from_another的最终地址。”链接器根据hello_from_another被分配到的地址，计算出具体的值，然后回填到那个位置。

3.3 静态库（.a）是什么？

静态库（.a文件）本质上是一组目标文件（.o）的打包集合，使用ar命令创建。例如，C标准库的静态版本是libc.a。当你在链接时使用-lc，链接器会去查找libc.a，但只从中提取出那些被你的程序引用到的目标文件，合并进最终的可执行文件。这就是为什么静态链接的可执行文件通常比较大，因为它包含了所用库代码的副本。

创建一个简单的静态库并使用的例程：

创建库源码：mylib.c:

int add(int a, int b) { return a + b; } int sub(int a, int b) { return a - b; }

编译成目标文件并打包成静态库：

gcc -c mylib.c -o mylib.o ar rcs libmymath.a mylib.o # r: 替换/插入， c: 创建， s: 建立索引

编写主程序使用库：use_static.c:

#include <stdio.h> int add(int, int); // 声明 int main() { printf("3+4=%d\n", add(3,4)); return 0;}

编译链接：

gcc -c use_static.c -o use_static.o gcc use_static.o -L. -lmymath -o use_static # -L. 指定在当前目录查找库， -lmymath 链接 libmymath.a

运行./use_static，输出3+4=7。

注意事项：链接器对库的顺序是敏感的。因为它按命令行中出现的顺序解析符号。如果A.o依赖libB.a中的函数，而libB.a又依赖libC.a，那么命令行通常需要写成gcc A.o -lB -lC。如果顺序错了（如gcc A.o -lC -lB），链接器在处理A.o时发现未定义符号，去libC.a里找，找不到就报错，而不会向后看libB.a。一个简单的规则是：把基础库、被依赖的库放在后面。更稳妥的做法是，如果循环依赖，可以将库重复放置，或者使用-(和-)进行分组（如gcc -Wl,--start-group A.o -lB -lC -Wl,--end-group），让链接器循环解析。

4. 动态链接：运行时才完成的拼图

静态链接的缺点是每个程序都自带库的副本，浪费磁盘和内存，且库更新需要重新编译所有程序。动态链接解决了这个问题。

4.1 共享库（.so）与动态链接器

共享库（.so， Shared Object）是编译好的、可在运行时被多个进程共享的代码和数据。可执行文件本身不包含库的代码，只记录它依赖哪些共享库。程序启动时，由动态链接器（在ELF程序头INTERP段指定的，通常是/lib64/ld-linux-x86-64.so.2）负责将这些共享库加载到内存，并完成最后的符号解析和地址重定位。

创建一个简单的共享库并使用的例程：

创建库源码（同上mylib.c）。
编译成位置无关代码（PIC）并创建共享库：
```
gcc -c -fPIC mylib.c -o mylib.o # -fPIC是关键！生成位置无关代码 gcc -shared mylib.o -o libmymath.so
```
-fPIC（Position Independent Code）使得库代码可以被加载到内存的任何位置而不需要修改。因为同一个库可能被映射到不同进程的不同地址。
编译主程序，动态链接：
```
gcc use_static.c -L. -lmymath -o use_dynamic
```
注意，虽然命令一样，但链接器会优先查找libmymath.so（动态库），如果找不到才找.a。你可以用file命令验证：file use_dynamic会显示dynamically linked。
运行前的准备：操作系统需要知道去哪找libmymath.so。
- 方法一：将.so文件放到标准库路径下，如/usr/local/lib，然后运行ldconfig更新缓存。
- 方法二：设置环境变量LD_LIBRARY_PATH：
```
export LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH ./use_dynamic
```
- 方法三（编译时指定rpath）：
```
gcc use_static.c -L. -lmymath -Wl,-rpath,‘$ORIGIN‘ -o use_dynamic_rpath
```
  -Wl,-rpath,‘$ORIGIN‘告诉链接器，运行时先在可执行文件所在目录（$ORIGIN）查找库。这样发布程序时可以把.so放在同级目录。

4.2 动态链接的底层机制：PLT与GOT

动态链接在程序启动时或函数第一次被调用时完成地址绑定，这涉及到两个关键的数据结构：过程链接表（PLT）和全局偏移表（GOT）。

GOT（Global Offset Table）：一个数组，存放着所有动态符号（如printf）的绝对地址。数据段中，可读写。
PLT（Procedure Linkage Table）：一小段存根代码（stub）。代码段中，可执行。

第一次调用动态函数的流程（延迟绑定，Lazy Binding）：

程序调用printf@plt（实际上是PLT中的一个条目）。
printf@plt的第一条指令跳转到GOT[n]中存储的地址。第一次调用时，GOT[n]里存的并不是printf的真实地址，而是printf@plt中下一条指令的地址（即“拉回”到PLT）。
于是执行流程回到PLT，接着压栈一个标识符（表示要找printf），然后跳转到动态链接器的_dl_runtime_resolve函数。
动态链接器根据标识符，在已加载的共享库中查找printf的真实地址，将其写回GOT[n]。
最后跳转到printf的真实地址执行。

此后再次调用printf：

调用printf@plt。
跳转到GOT[n]，此时里面已经是printf的真实地址了。
直接跳转执行。

这个过程就是“延迟绑定”，避免了程序启动时一次性解析所有动态符号带来的开销。你可以用objdump -d demo查看PLT的代码，用readelf -r demo查看重定位条目（其中类型为R_X86_64_JUMP_SLOT的就是需要动态链接器填充的GOT条目）。

4.3 查看动态依赖与调试

ldd命令：列出可执行文件或共享库所依赖的所有共享库。
```
ldd use_dynamic
```
输出会显示libmymath.so的路径（如果找不到会显示not found）。
LD_DEBUG环境变量：一个强大的调试工具。
```
LD_DEBUG=libs ./use_dynamic 2>&1 | head -20
```
可以输出动态链接器查找、加载库的详细过程。其他有用的值还有symbols（符号绑定）、bindings（绑定信息）、files（处理文件）等。

踩坑实录：最经典的动态链接问题就是“找不到共享库”。除了上述的LD_LIBRARY_PATH和rpath，还要注意：
库的ABI兼容性：如果依赖的库版本升级导致ABI（应用二进制接口）不兼容（比如函数签名变了），即使找到了库，也可能在运行时因符号解析失败而崩溃。错误信息可能是“undefined symbol: xxx”。
直接运行 vs 通过脚本/服务运行：LD_LIBRARY_PATH环境变量可能在某些上下文中（如cron job、systemd服务、sudo环境）不被继承或重置。对于系统服务，更可靠的方式是将库路径配置在/etc/ld.so.conf.d/目录下的文件中，并运行ldconfig。
静态链接与动态链接混合：如果一个库同时存在静态版（.a）和动态版（.so），链接器默认优先选择动态链接。如果你想强制静态链接某个库，可以使用-static选项（全部静态）或-Wl,-Bstatic -lmylib -Wl,-Bdynamic（部分静态）。

5. 程序的加载与运行：从文件到进程

当你在shell中输入./demo并回车后，一个复杂的接力赛就开始了。

5.1 内核的加载工作

Shell解析与fork：Shell解析命令，调用fork()创建一个新的子进程。
execve系统调用：子进程调用execve(“./demo”, …)。这个系统调用是加载的核心。
内核检查文件：内核检查./demo是否是一个有效的可执行文件（通过魔数7f 45 4c 46识别ELF）。
读取程序头表：内核读取ELF文件的程序头表，找到所有LOAD类型的段。
建立内存映射：内核为进程创建新的虚拟地址空间（页表），然后根据每个LOAD段的Offset、VirtAddr、FileSiz、MemSiz、Flags，将文件中的相应部分映射到虚拟内存的指定位置（VirtAddr）。对于.bss这种MemSiz大于FileSiz的段，内核会映射匿名内存（初始为0）来补足。
设置栈和堆：内核还会为用户态栈（stack）和堆（heap）分配内存区域。栈的地址通常在高位，向下增长；堆在数据段之上，向上增长。
传递控制权：内核将入口地址（Entry point）设置到ELF头中指定的地址（如0x401040，即_start），并将CPU的控制权从内核态切换到用户态，跳转到该地址开始执行。

至此，进程的“骨架”已经搭建好，代码和数据都在内存里了，但还不能直接执行main函数，因为动态链接还没完成。

5.2 动态链接器的接力

还记得ELF程序头里的INTERP段吗？它指定了动态链接器的路径（/lib64/ld-linux-x86-64.so.2）。内核在加载可执行文件后，会把动态链接器也加载到内存（它本身也是一个特殊的共享库），并将控制权先交给动态链接器的入口点。

动态链接器（也称为ld.so）开始工作：

自举：完成自身的一些初始化。
加载依赖库：读取可执行文件的.dynamic段（其中包含了依赖库列表，如libc.so.6），按照一定的搜索规则（LD_LIBRARY_PATH、/etc/ld.so.cache、默认路径等）找到这些库文件，并将它们映射到进程的地址空间。
重定位与符号解析：对可执行文件和所有加载的共享库进行重定位，填充它们的GOT表。这就是前面提到的延迟绑定的准备工作。
调用初始化函数：执行各共享库中的初始化代码（如果有，如C++的全局对象构造函数）。
跳转到程序入口：最终，动态链接器跳转到可执行文件的入口点_start。

5.3 从_start到main

_start是C运行时库（crt）的一部分，它负责设置一些最终的环境，比如准备好main函数的参数（argc,argv）、环境变量指针envp，然后调用__libc_start_main。这个函数是libc的，它会做更多初始化工作（如设置线程局部存储、初始化标准IO等），最后才调用我们写的main函数。

所以，main并不是程序的起点，而是“用户代码”的起点。当main函数返回后，控制权会回到__libc_start_main，它再调用exit()系统调用结束进程。

一个简单的实验验证加载地址：我们可以写一个小程序来打印一些地址，看看它们是否和ELF文件中描述的一致。

addr.c:

#include <stdio.h> #include <stdlib.h> int global_init = 42; int global_uninit; const int global_const = 100; int main() { int local_var = 5; static int static_local = 7; const int local_const = 200; printf("main function address: %p\n", main); printf("global_init address: %p\n", &global_init); printf("global_uninit address: %p\n", &global_uninit); printf("global_const address: %p\n", &global_const); printf("static_local address: %p\n", &static_local); printf("local_var address: %p\n", &local_var); printf("local_const address: %p\n", &local_const); printf("malloc‘ed address: %p\n", malloc(100)); return 0; }

编译运行：gcc addr.c -o addr && ./addr。你会看到：