上一期介绍了动静态库的使用原理以及两者的区别但是你是否困惑过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 的合并——为什么需要 Segment1.为什么要合并五、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 #includestdio.h void run(); int main() { printf(hello world!\n); run(); return 0; } // code.c #includestdio.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.ogcc -c的含义是只编译compile不链接no link。1.3 目标文件的本质file hello.ofile 命令用于辨识文件类型。目标文件是一个二进制的文件它的格式是ELFExecutable and Linkable Format——对二进制代码的一种封装。注意这里的描述relocatable可重定位这是目标文件的灵魂属性。意味着其中的地址尚未固定可以在链接时被重新定位。二、ELF 文件——统一一切的二进制格式2.1 ELF 的定义ELFExecutable and Linkable Format可执行与可链接格式是 Linux 下可执行文件、目标文件、共享库、核心转储的统一文件格式标准。要理解编译和链接的细节我们必须了解 ELF。实际上以下四种文件都是 ELF 文件文件类型扩展名/名称说明可重定位文件.o包含适合与其他目标文件链接来创建可执行文件或共享目标文件的代码和数据可执行文件无扩展名 /a.out即可执行程序经过完整链接可以直接加载运行共享目标文件.so动态链接库包含可在运行时被动态链接器加载和链接的代码和数据内核转储core存放当前进程的执行上下文用于 dump 信号触发后的调试核心思想无论是 .o、.so、a.out它们骨子里都是 ELF三、ELF 文件的解剖——四大部分一个 ELF 文件由以下四部分组成ELF 头 (ELF header)描述文件的主要特性。其位于文件的开始位置它的主要目的是定位文件的其他部分。程序头表 (Program header table)列举了所有有效的段 (segments) 和他们的属性。表里记着每个段的开始的位置和位移offset、长度毕竟这些段都是紧密的放在二进制文件中需要段表的描述信息才能把他们每个段分割开。节头表 (Section header table)包含对节 (sections) 的描述。节SectionELF 文件中的基本组成单位包含了特定类型的数据。ELF 文件的各种信息和数据都存储在不同的节中如代码节存储了可执行代码数据节存储了全局变量和静态数据等。补充一个 Segment段通常由若干个 Section节合并构成。最常见的节代码节.text用于保存机器指令是程序的主要执行部分。数据节.data保存已初始化的全局变量和局部静态变量。size code.o3.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魔数7fELF用来标识这是ELF文件 Class: ELF64 # ELF类别64位程序ELF32代表32位 Data: 2s 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魔数0x7fELF标识该文件为ELF格式 Class: ELF64 # ELF类型64位ELF文件 Data: 2s 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_FRAMEC异常处理栈展开信息 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 # 代码段RE多个代码相关节合并 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程序头的类型含义类型说明LOAD需要加载到内存中的段是加载的核心INTERP指定动态链接器的路径如/lib64/ld-linux-x86-64.so.2DYNAMIC动态链接信息NOTE辅助信息GNU_STACK栈的可执行属性GNU_RELRO只读重定位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磁盘文件不占用空间size0说明无对应变量 [ 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 文件中的基本组成单位包含了特定类型的数据。下面是最常见的几个节各节详细说明节名称全称作用.text代码节保存程序指令机器码是主要执行部分.data数据节保存已初始化的全局变量和局部静态变量.rodata只读数据节保存只读数据如字符串常量。只在只读段text段中.bss未初始化数据节为未初始化的全局变量和局部静态变量预留空间加载时清零.symtab符号表源码中的函数名、变量名与地址的对应关系.strtab字符串表存放符号名称的字符串.got / .got.plt全局偏移表保存全局偏移表提供对导入共享库函数的访问入口查看各节大小size code.o四、ELF 的形成——从源代码到可执行文件4.1 编译与链接的两步走Step 1将多份 C/C 源代码翻译成为目标 .o 文件 动静态库(ELF)Step 2将多份 .o 文件的 Section 进行合并和重定位形成可执行文件4.2 Section 的合并——为什么需要 Segment合并原则相同属性合并——可读、可写、可执行、需要加载时申请空间等。1.为什么要合并两个核心原因原因说明减少内存碎片假设页面大小为 4096 字节内存块基本大小加载管理的基本单位.text 为 4097 字节.init 为 512 字节。不合并会用 3 个页面合并后只用 2 个统一权限控制将所有只读可执行的 Section 放在一起统一设置为 RE所有可读写的放在一起设置为 RW优化内存管理和权限控制合并规则在 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 个不同的视角来观察自己视图对应表使用场景粒度作用链接视图节头表编译/链接时细Section按功能模块划分链接器分析符号依赖执行视图程序头表加载/运行时粗Segment告诉 OS 如何加载、设置权限一句话总结一个在链接时用一个在运行时用。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文件UNDundefine表示本 .o 文件找不到这个符号。hello.o 的 run 是 UNDcode.o 的 run 是已定义的——链接器在链接时会将它们匹配起来。6.3 链接时的重定位再看看两者链接形成的可执行文件这里太长只展示部分readelf -s a.outrun 函数所在的 section 被合并最终的那一个 section 中了13就是下标和main函数在一起看一下a.out的反汇编代码已经有了地址对比链接前hello.o链接后a.outrun 的地址00 00 00 000x401145printf 的地址00 00 00 000x401130putspltSection 编号各自的 .textNr 1合并后的 .textNr 136.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 之前有一段隐藏剧情阶段说明_startC 运行时库glibc或链接器提供的特殊函数程序的真正入口动态链接器ld-linux.so解析程序依赖的所有动态库并加载到内存__libc_start_mainglibc 提供的函数完成额外初始化后调用mainmain程序员编写的入口函数8.3 动态库的PIC原理动态库为了能加载到任意进程的任意地址必须采用相对地址编址——PICPosition Independent Code位置无关码所有地址都是相对于当前指令指针的偏移量。这也就是为什么编译动态库时必须指定-fPIClibmystdio.so: my_stdio.o my_string.o gcc -o $ $^ -shared %.o:%.c gcc -fPIC -c $8.4 GOT全局偏移表——动态链接的基石动态链接面临一个核心矛盾代码段是只读的不能改但函数地址又需要在加载时修正。解决方案就是在.data段可读写中预留一块区域来存放函数的跳转地址——这就是GOTGlobal Offset Table全局偏移表$ readelf -S a.out [24] .got PROGBITS 0000000000003fb8 00002fb8 0000000000000048 0000000000000008 WA 0 0 8 # WA 可写可分配GOT 的四大要点要点说明1由于代码段只读不能直接修改。GOT 在可读写段可在运行时更新2在单个 .so 下GOT 与 .text 的相对位置固定CPU 可通过相对寻址找到 GOT3调用函数时先查 GOT 表根据表中地址跳转地址在加载时被修改4这种机制就是PIC位置无关码 相对编址 GOT8.5 PLT过程链接表——延迟绑定如果程序启动时对所有库函数都进行重定位启动速度会非常慢。因此引入了PLTProcedure Linkage Table——延迟绑定与其一开始就对所有函数重定位不如将这个过程推迟到函数第一次被调用的时候。因为绝大多数动态库中的函数可能在程序运行期间一次都不会被用到九、总结对比——静态链接 vs 动态链接维度静态链接动态链接链接时机编译时链接加载运行时链接可执行文件大小大包含所有库代码小只包含引用信息磁盘空间占用每个程序独立包含库代码 → 浪费多个程序共享库文件 → 节省内存占用每个程序独享一份库代码物理内存中一份库被所有进程共享运行时依赖无依赖独立运行需要系统中存在对应的 .so 文件更新维护替换库后需重新链接整个程序替换 .so 文件即可无需重新编译地址修正方式编译重定位静态重定位加载重定位动态重定位性能无额外加载开销需启动动态链接器有额外开销核心机制重定位表 Section 合并GOT PLT 相对编址PIC它们共同的根——ELF回顾全文你会发现无论是 .o 目标文件、.a 静态库、.so 动态库还是 a.out 可执行文件——它们全部都是 ELF 文件只不过同一份 ELF 格式通过**链接视图节头表服务于编译器和链接器通过执行视图程序头表**服务于操作系统的加载器掌握了 ELF就掌握了 Linux 下程序从源代码 → 编译 → 链接 → 加载 → 运行的完整链路。
)
