Linux系统篇22：——文件（六）：目标文件与ELF深度解析：从编译到加载的全景揭秘

上一期介绍了动静态库的使用原理以及两者的区别，但是你是否困惑过：gcc -c 出来的 .o 文件到底是什么？它和 .so、a.out 有什么区别？ELF 又是何方神圣？链接器凭什么能修正函数地址？这篇文章从目标文件讲起，带你层层深入 ELF 的骨髓。

目录

开篇：一段代码的编译之旅

一、目标文件（.o）——编译的"半成品"

1.1 为什么需要目标文件？

1.2 如何生成目标文件

1.3 目标文件的本质

二、ELF 文件——统一一切的二进制格式

2.1 ELF 的定义

三、ELF 文件的解剖——四大部分

3.1 ELF 头（ELF Header）——文件的身份证

1.读取目标文件的ELF文件头部信息

3.2 程序头表（Program Header Table）——执行视图

1.查看可执行文件的段 (Segment)信息

3.3 节头表（Section Header Table）——链接视图

1.打印【节头表 Section Header Table】，列出 ELF 内部所有节 (Section)

3.4 节（Sections）——真正的数据仓库

四、ELF 的形成——从源代码到可执行文件

4.1 编译与链接的两步走

4.2 Section 的合并——为什么需要 Segment？

1.为什么要合并？

五、ELF 的两个视图——链接器看 vs 加载器看

1.从链接视图看

2.从执行视图看

3.三条命令终极汇总

六、透彻理解链接——静态链接的全过程

6.1 目标文件之间"互不相识"

6.2 符号表——标记"未定义"的符号

6.3 链接时的重定位

6.4 静态链接的本质

七、虚拟地址空间——链接时就已编好址

7.1 一个反直觉的事实

7.2 进程地址空间的数据从哪里来？

八、动态链接——运行时才见真章

8.1 为什么需要动态链接？

8.2 程序启动的完整流程

8.3 动态库的PIC原理

8.4 GOT（全局偏移表）——动态链接的基石

8.5 PLT（过程链接表）——延迟绑定

九、总结对比——静态链接 vs 动态链接

它们共同的根——ELF

开篇：一段代码的编译之旅

$ gcc -c hello.c
$ gcc -c code.c
$ ls
code.c code.o hello.c hello.o

当你执行 gcc -c，编译器把源代码翻译成 CPU 能直接运行的机器码，输出一个扩展名为 .o 的文件——这就是目标文件（Object File）。

但问题来了：

• 为什么不是直接生成可执行文件，而是先生成 .o？
• .o 里面到底装了什么？
• 为什么用 file 命令查看，说它是 "ELF"？

别急，这篇文章全部给你讲清楚。

一、目标文件（.o）——编译的"半成品"

1.1 为什么需要目标文件？

假设一个项目有几十个源文件，你只修改了其中一个。如果每次都要重新编译所有文件，效率极低。而引入目标文件后：

修改 hello.c → 只需要重新编译 hello.c → 重新链接即可

这就是增量编译的思想——编译是单个文件的事，链接才是全局的事。

1.2 如何生成目标文件

// hello.c
#include<stdio.h>
void run();
int main() {
printf("hello world!\\n");
run();
return 0;
}

// code.c
#include<stdio.h>
void run() {
printf("running…\\n");
}
$ gcc -c hello.c # → hello.o
$ gcc -c code.c # → code.o
$ ls
code.c code.o hello.c hello.o

gcc -c 的含义是：只编译（compile），不链接（no link）。

1.3 目标文件的本质

file hello.o

file 命令用于辨识文件类型。

目标文件是一个二进制的文件，它的格式是 ELF（Executable and Linkable Format）——对二进制代码的一种封装。

注意这里的描述：relocatable（可重定位），这是目标文件的灵魂属性。意味着其中的地址尚未固定，可以在链接时被重新定位。

二、ELF 文件——统一一切的二进制格式

2.1 ELF 的定义

ELF（Executable and Linkable Format，可执行与可链接格式）是 Linux 下可执行文件、目标文件、共享库、核心转储的统一文件格式标准。

要理解编译和链接的细节，我们必须了解 ELF。

实际上，以下四种文件都是 ELF 文件：

核心思想：无论是 .o、.so、a.out，它们骨子里都是 ELF！

三、ELF 文件的解剖——四大部分

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

• ELF 头 (ELF header)：描述文件的主要特性。其位于文件的开始位置，它的主要目的是定位文件的其他部分。
• 程序头表 (Program header table)：列举了所有有效的段 (segments) 和他们的属性。表里记着每个段的开始的位置和位移（offset）、长度，毕竟这些段，都是紧密的放在二进制文件中，需要段表的描述信息，才能把他们每个段分割开。
• 节头表 (Section header table)：包含对节 (sections) 的描述。
• 节（Section）：ELF 文件中的基本组成单位，包含了特定类型的数据。ELF 文件的各种信息和数据都存储在不同的节中，如代码节存储了可执行代码，数据节存储了全局变量和静态数据等。

补充：一个 Segment（段）通常由若干个 Section（节）合并构成。

最常见的节：

• 代码节（.text）：用于保存机器指令，是程序的主要执行部分。
• 数据节（.data）：保存已初始化的全局变量和局部静态变量。

size code.o

3.1 ELF 头（ELF Header）——文件的身份证

位置：文件的最开始位置。

作用：描述文件的主要特性，定位文件的其他部分。

1.读取目标文件的ELF文件头部信息

$ readelf -h hello.o
ELF Header:
Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 # ELF魔数，7f+ELF，用来标识这是ELF文件
Class: ELF64 # ELF类别：64位程序；ELF32代表32位
Data: 2's complement, little endian # 字节序：小端序，补码存储
Version: 1 (current) # ELF格式版本号，固定为1
OS/ABI: UNIX – System V # 目标操作系统ABI规范，Linux遵循System V
ABI Version: 0 # ABI版本
Type: REL (Relocatable file) # 文件类型：REL=可重定位文件（*.o目标文件）
Machine: Advanced Micro Devices X86-64 # 目标CPU架构 x86_64
Version: 0x1 # 目标文件版本
Entry point address: 0x0 # 程序入口地址；.o文件没有入口，填0
Start of program headers: 0 (bytes into file) # 程序头表在文件内偏移；当前为0=不存在程序头表
Start of section headers: 672 (bytes into file) # 节头表在文件中的起始偏移位置
Flags: 0x0 # 架构相关标志位，x86_64一般为0
Size of this header: 64 (bytes) # ELF头部自身大小，64位ELF固定64字节
Size of program headers: 0 (bytes) # 单个程序头表项大小；0代表无程序头
Number of program headers: 0 # 程序头表条目数量，0=没有程序头
Size of section headers: 64 (bytes) # 单个节头表项大小，64位ELF固定64字节
Number of section headers: 13 # 节头表总共有13个条目（13个节）
Section header string table index: 12 # 节名字符串表，是第12号节头

作为对比，看下可执行文件的 ELF 头：

$ readelf -h a.out
ELF Header:
Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 # ELF魔数，0x7f+"ELF"，标识该文件为ELF格式
Class: ELF64 # ELF类型：64位ELF文件
Data: 2's complement, little endian # 数据编码：补码、小端字节序
Version: 1 (current) # ELF标准版本，固定为1
OS/ABI: UNIX – System V # 遵循System V ABI标准（Linux使用）
ABI Version: 0 # ABI版本号
Type: EXEC (Executable file) # 文件类型：EXEC=可执行文件（a.out，能直接./运行）
Machine: Advanced Micro Devices X86-64 # 目标CPU架构 x86_64
Version: 0x1 # 对象文件版本
Entry point address: 0x401040 # 程序入口虚拟地址，内核从此处开始执行代码
Start of program headers: 64 (bytes into file) # 程序头表在文件内的起始偏移（ELF头大小64字节，紧跟其后）
Start of section headers: 23928 (bytes into file)# 节头表在文件内的起始偏移
Flags: 0x0 # 处理器相关标志位，x86_64平台通常为0
Size of this header: 64 (bytes) # ELF头部自身大小，64位ELF固定64字节
Size of program headers: 56 (bytes) # 单个程序头表项的大小，64位ELF固定56字节
Number of program headers: 11 # 一共有11个程序头（对应11个Segment段）
Size of section headers: 64 (bytes) # 单个节头表项大小，64位ELF固定64字节
Number of section headers: 30 # 节头表一共30个条目（30个Section节）
Section header string table index: 29 # 节名称字符串表，是第29号节

hello.o 是REL 可重定位目标文件，无程序头表、程序入口地址为 0，仅提供节信息供链接器使用；

a.out 是EXEC 可执行文件，拥有程序头表与有效程序入口地址，同时包含节与段信息，可供操作系统加载运行。

总结：

ELF 头中最核心的信息：文件类型（REL/EXEC/DYN）+ 入口点地址 + 程序头表和节头表的位置。

3.2 程序头表（Program Header Table）——执行视图

作用：列举所有有效的段（Segments）和它们的属性。标记每个段的起始位置、偏移量、长度和权限。 这正是操作系统的加载器所关注的内容——它告诉 OS 怎么把这个文件加载到内存。

1.查看可执行文件的段 (Segment)信息

​readelf -l a.out
Elf file type is EXEC (Executable file) # 文件类型：可执行程序
Entry point 0x401040 # 进程启动虚拟入口地址
There are 11 program headers, starting at offset 64 # 共11个段描述项，程序头表在文件偏移0x40处

Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
PHDR 0x0000000000000040 0x0000000000400040 0x0000000000400040
0x0000000000000268 0x0000000000000268 R 0x8
# PHDR段：程序头表自身，加载到内存，只读

INTERP 0x00000000000002a8 0x00000000004002a8 0x00000000004002a8
0x000000000000001c 0x000000000000001c R 0x1
[Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
# INTERP段：指定动态链接器（解释器），负责加载libc等动态库

LOAD 0x0000000000000000 0x0000000000400000 0x0000000000400000
0x0000000000000438 0x0000000000000438 R 0x1000
# PT_LOAD 可读内存段，映射辅助信息节

LOAD 0x0000000000001000 0x0000000000401000 0x0000000000401000
0x00000000000001e5 0x00000000000001e5 R E 0x1000
# PT_LOAD 可读+可执行段【代码段】，承载 .text .plt 机器指令

LOAD 0x0000000000002000 0x0000000000402000 0x0000000000402000
0x0000000000000168 0x0000000000000168 R 0x1000
# PT_LOAD 只读段【常量段】，承载 .rodata 字符串常量

LOAD 0x0000000000002e10 0x0000000000403e10 0x0000000000403e10
0x0000000000000220 0x0000000000000228 RW 0x1000
# PT_LOAD 可读可写段【数据段】，承载 .data .bss 全局变量；MemSiz > FileSiz 对应.bss（文件不占空间，内存清零）

DYNAMIC 0x0000000000002e20 0x0000000000403e20 0x0000000000403e20
0x00000000000001d0 0x00000000000001d0 RW 0x8
# DYNAMIC段：动态链接信息，符号、依赖库、重定位相关数据

NOTE 0x00000000000002c4 0x00000000004002c4 0x00000000004002c4
0x0000000000000044 0x0000000000000044 R 0x4
# NOTE段：程序版本、ABI标记等附加信息

GNU_EH_FRAME 0x000000000000201c 0x000000000040201c 0x000000000040201c
0x0000000000000044 0x0000000000000044 R 0x4
# GNU_EH_FRAME：C++异常处理栈展开信息

GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000000 0x0000000000000000 RW 0x10
# GNU_STACK：标识栈权限 RW，说明栈**不可执行**（防护缓冲区溢出）

GNU_RELRO 0x0000000000002e10 0x0000000000403e10 0x0000000000403e10
0x00000000000001f0 0x00000000000001f0 R 0x1
# GNU_RELRO：延迟重定位区域，重定位完成后内存改为只读，安全防护

Section to Segment mapping:
# 【重点！节(Section) 映射到 段(Segment)】直观印证：多个节打包合并成一个段
Segment Sections…
00
01 .interp
02 .interp .note.gnu.build-id .note.ABI-tag .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_r .rela.dyn .rela.plt
03 .init .plt .text .fini # 代码段R+E：多个代码相关节合并
04 .rodata .eh_frame_hdr .eh_frame # 只读常量节集合
05 .init_array .fini_array .dynamic .got .got.plt .data .bss # 读写数据相关节
06 .dynamic
07 .note.gnu.build-id .note.ABI-tag
08 .eh_frame_hdr
09

程序头的类型含义：

3.3 节头表（Section Header Table）——链接视图

作用：包含对所有节（Sections）的详细描述，包括节名称、类型、地址、偏移、大小等信息。

这是链接器和编译器所关注的内容。

1.打印【节头表 Section Header Table】，列出 ELF 内部所有节 (Section)

readelf -S hello.o

There are 13 section headers, starting at offset 0x2e0: # 一共13个节，节头表在文件偏移0x2e0位置

Section Headers:
[Nr] Name Type Address Offset
Size EntSize Flags Link Info Align
[ 0] NULL 0000000000000000 00000000
0000000000000000 0000000000000000 0 0 0
# 0号节固定是空节，占位保留

[ 1] .text PROGBITS 0000000000000000 00000040
000000000000001f 0000000000000000 AX 0 0 1
# .text代码节：存放函数机器指令；AX=可分配内存、可执行

[ 2] .rela.text RELA 0000000000000000 00000218
0000000000000048 0000000000000018 I 10 1 8
# .rela.text：.text节对应的重定位表，链接时修正符号地址

[ 3] .data PROGBITS 0000000000000000 0000005f
0000000000000000 0000000000000000 WA 0 0 1
# .data数据节：存放已初始化全局/静态变量；WA=可分配、可写；当前size为0代表没有这类变量

[ 4] .bss NOBITS 0000000000000000 0000005f
0000000000000000 0000000000000000 WA 0 0 1
# .bss：未初始化全局/静态变量；NOBITS=磁盘文件不占用空间；size=0说明无对应变量

[ 5] .rodata PROGBITS 0000000000000000 0000005f
000000000000000d 0000000000000000 A 0 0 1
# .rodata只读数据节：存放字符串常量、const常量；A=运行时分配内存

[ 6] .comment PROGBITS 0000000000000000 0000006c
0000000000000036 0000000000000001 MS 0 0 1
# .comment：编译器版本注释信息，运行时不加载

[ 7] .note.GNU-stack PROGBITS 0000000000000000 000000a2
0000000000000000 0000000000000000 0 0 1
# 栈属性标记，标识栈不可执行（安全保护）

[ 8] .eh_frame PROGBITS 0000000000000000 000000a8
0000000000000038 0000000000000000 A 0 0 8
# C/C++异常处理、栈回溯信息

[ 9] .rela.eh_frame RELA 0000000000000000 00000260
0000000000000018 0000000000000018 I 10 8 8
# .eh_frame节对应的重定位信息

[10] .symtab SYMTAB 0000000000000000 000000e0
0000000000000120 0000000000000018 11 9 8
# .symtab符号表：保存函数名、变量名等符号信息，供链接器使用

[11] .strtab STRTAB 0000000000000000 00000200
0000000000000017 0000000000000000 0 0 1
# .strtab：符号名字符串表，配合symtab使用

[12] .shstrtab STRTAB 0000000000000000 00000278
0000000000000061 0000000000000000 0 0 1
# .shstrtab：节名称字符串表，保存.text/.data这类节名字

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),
l (large), p (processor specific)

查看可执行文件的节数

readelf -S a.out

There are 30 section headers, starting at offset 0x5d78:
# 一共有30个节，节头表在ELF文件内偏移0x5d78的位置

注意对比：hello.o 有 13 个节，而 a.out 有 31 个节——链接后的可执行文件更复杂。

3.4 节（Sections）——真正的数据仓库

节是 ELF 文件中的基本组成单位，包含了特定类型的数据。

下面是最常见的几个节：

各节详细说明：

查看各节大小

size code.o

四、ELF 的形成——从源代码到可执行文件

4.1 编译与链接的两步走

• Step 1：将多份 C/C++ 源代码，翻译成为目标 .o 文件 + 动静态库(ELF)
• Step 2：将多份 .o 文件的 Section 进行合并和重定位，形成可执行文件

4.2 Section 的合并——为什么需要 Segment？

合并原则：相同属性合并——可读、可写、可执行、需要加载时申请空间等。

1.为什么要合并？

两个核心原因：

合并规则在 ELF 编绎时就已经确定，被记录在程序头表（Program Header Table）的 Section to Segment mapping 中：

Section to Segment mapping:
Segment Sections…
02 .interp .note.ABI-tag .gnu.hash .dynsym .dynstr .init .plt .text .fini .rodata … # 第02号段，集合各类只读、可读可执行节，内存权限R/RE
03 .init_array .fini_array .dynamic .got .got.plt .data .bss # 第03号段，集合各类运行时需要读写的节，内存权限RW

五、ELF 的两个视图——链接器看 vs 加载器看

ELF 提供 2 个不同的视角来观察自己：

一句话总结：一个在链接时用，一个在运行时用。

1.从链接视图看

$ readelf -S hello.o # 查看目标文件的节头表

链接器关注的是一个个的 Section：

• 将同名 Section 合并（如多个 .o 的 .text 合并成一个大的 .text）
• 解析符号表，定位外部符号
• 根据重定位表修正地址

2.从执行视图看

$ readelf -l a.out # 查看可执行文件的程序头表

操作系统关注的是一个个的 Segment：

• 哪些模块需要加载进内存（LOAD 类型的 Segment）
• 加载进内存后，哪些段可读可写，哪些只读，哪些可执行
• 入口点地址在哪

3.三条命令终极汇总

readelf -h 文件名 # -h：查看ELF头部（文件基础元信息）
readelf -S 文件名 # 大写S：查看节头表 Section（链接器视角）
readelf -l 文件名 # 小写L：查看程序头表 Segment（操作系统加载视角）

六、透彻理解链接——静态链接的全过程

6.1 目标文件之间"互不相识"

以之前的 hello.c 和 code.c 为例。编译后的两个 .o 文件各自独立，彼此不知道对方的存在：

对目标文件 hello.o 进行反汇编：

objdump -d hello.o

可以看到，这里的 call 指令对应的 printf 和 run 函数，跳转地址都被设为了 0x00000000。因为编译器在编译 hello.c 时，完全不知道 printf 和 run 函数位于内存的哪个位置，甚至根本不知道它们的代码长什么样。

6.2 符号表——标记"未定义"的符号

readelf -s hello.o

注意：S和s对应的不同的命令

readelf -s hello.o # 小写s：–symbols，【查看符号表】（符号名、全局/局部、函数/变量）
readelf -S hello.o # 大写S：–section-headers，【查看段头表（节表）】.text/.data/.bss/.rodata这些section

再看 code.o文件：

UND（undefine） 表示本 .o 文件找不到这个符号。hello.o 的 run 是 UND，code.o 的 run 是已定义的——链接器在链接时会将它们匹配起来。

6.3 链接时的重定位

 再看看两者链接形成的可执行文件：（这里太长，只展示部分）

readelf -s a.out

run 函数所在的 section 被合并最终的那一个 section 中了，13就是下标（和main函数在一起）

看一下a.out的反汇编代码（已经有了地址）

6.4 静态链接的本质

静态链接 = 合并所有 .o 的 Section + 地址修正

无论是你自己的 .o，还是静态库中的 .o，本质上都是把 .o 文件进行连接。链接器会根据重定位表找到那些需要被重定位的函数和全局变量，修正它们的地址。

七、虚拟地址空间——链接时就已编好址

7.1 一个反直觉的事实

一个 ELF 程序，在没有被加载到内存的时候，就已经有地址了！

$ readelf -h a.out
Entry point address: 0x1060

可执行文件的入口地址在编译链接时就已确定，这不是物理内存地址，而是虚拟地址。

当代计算机都采用 平坦模式 工作，所以 ELF 对自己的代码和数据进行了统一编址。反汇编出来的最左侧一列就是 ELF 的虚拟地址（逻辑地址=起始地址+偏移量）。

7.2 进程地址空间的数据从哪里来？

答案：从 ELF 的各个 Segment 来。

每个 Segment 有自己的起始地址和长度，操作系统用它来初始化内核结构中的 [start, end] 范围数据，另外还用更详细的地址填充页表。

结论：虚拟地址机制，不光 OS 要支持，编译器也要支持。

八、动态链接——运行时才见真章

8.1 为什么需要动态链接？

静态链接会产生巨大的可执行文件，并且多个程序如果都包含相同的库代码（如 printf），内存中会有大量副本：

动态链接将符号解析和地址重定位从编译时推迟到程序加载运行的时候，这是性价比极高的取舍

8.2 程序启动的完整流程

你以为是 main() 开始一切？实际上在 main 之前有一段"隐藏剧情"：

8.3 动态库的PIC原理

动态库为了能加载到任意进程的任意地址，必须采用相对地址编址——PIC（Position Independent Code，位置无关码）所有地址都是相对于当前指令指针的偏移量。这也就是为什么编译动态库时必须指定 -fPIC：

libmystdio.so: my_stdio.o my_string.o
gcc -o $@ $^ -shared
%.o:%.c
gcc -fPIC -c $<

8.4 GOT（全局偏移表）——动态链接的基石

动态链接面临一个核心矛盾：代码段是只读的不能改，但函数地址又需要在加载时修正。

解决方案就是在 .data 段（可读写）中预留一块区域来存放函数的跳转地址——这就是 GOT（Global Offset Table，全局偏移表）

$ readelf -S a.out
[24] .got PROGBITS 0000000000003fb8 00002fb8
0000000000000048 0000000000000008 WA 0 0 8 # WA = 可写+可分配

GOT 的四大要点：

8.5 PLT（过程链接表）——延迟绑定

如果程序启动时对所有库函数都进行重定位，启动速度会非常慢。因此引入了 PLT（Procedure Linkage Table）——延迟绑定：

与其一开始就对所有函数重定位，不如将这个过程推迟到函数第一次被调用的时候。因为绝大多数动态库中的函数可能在程序运行期间一次都不会被用到！

九、总结对比——静态链接 vs 动态链接

它们共同的根——ELF

回顾全文，你会发现：

无论是 .o 目标文件、.a 静态库、.so 动态库，还是 a.out 可执行文件——它们全部都是 ELF 文件！

只不过同一份 ELF 格式，通过**链接视图（节头表）服务于编译器和链接器，通过执行视图（程序头表）**服务于操作系统的加载器：

掌握了 ELF，就掌握了 Linux 下程序从源代码 → 编译 → 链接 → 加载 → 运行的完整链路。