Linux ELF格式与可执行程序加载全解析:从磁盘文件到运行进程

Linux ELF格式与可执行程序加载全解析:从磁盘文件到运行进程

🔥个人主页:Cx330🌸

❄️个人专栏:《C语言》《LeetCode刷题集》《数据结构-初阶》《C++知识分享》

《优选算法指南-必刷经典100题》《Linux操作系统》:从入门到入魔

《Git深度解析》:版本管理实战全解

🌟心向往之行必能至


🎥Cx330🌸的简介:


目录

前言:

一、ELF文件:Linux二进制的标准载体

1.1 ELF文件的四大类型

1.2 ELF文件的双重视角:Section与Segment

1.3 ELF核心结构:从头部到加载指引

(1)ELF Header(文件头)

(2)Program Header Table(程序头表)

(3)Section Header Table(节头表)

二. ELF 的生命周期:从源码到运行

2.1 编译链接(生成可执行 ELF,研究静态链接)

2.2 加载运行(可以暂时先不看,继续往下理解)

三. 进程虚拟地址空间

3.1 虚拟地址的核心作用

四、加载流程核心知识点总结

结语:


前言:

在Linux世界里,我们每天都在和各种可执行程序打交道:ls、gcc、自己编译的二进制文件……这些文件并非杂乱的机器码堆砌,而是遵循一套标准格式——ELF(Executable and Linkable Format,可执行与可链接格式)。它是Linux二进制文件的“身份证”,更是操作系统加载、运行程序的核心依据。

本文将带你吃透ELF文件结构,并一步步拆解可执行程序从触发执行到正式运行的完整加载流程,既有底层原理,也有实操验证,帮你彻底理解Linux程序的“诞生与启动”。

一、ELF文件:Linux二进制的标准载体

ELF并非只代表可执行程序,它是一套通用的二进制格式标准,覆盖了Linux编译、链接、运行全生命周期的文件类型。相比老旧的 a.out 格式,ELF具备跨架构、可扩展、双视角解析(链接/加载)的优势,成为Unix-like系统的主流二进制格式。

实战示例:生成并查看目标文件

// 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"); } 

编译生成目标文件

# 编译源码生成目标文件(-c:只编译不链接) gcc -c hello.c code.c # 查看生成的目标文件 ls -l *.o # 验证文件类型(确认是ELF格式) file hello.o 
  • relocatable:表示该 ELF 文件是 “可重定位文件”(目标文件类型);
  • not stripped:表示文件保留了符号表等调试信息。

1.1 ELF文件的四大类型

我们日常接触的ELF文件主要分为四类,各司其职:

  • 可重定位文件(.o):编译阶段生成,包含独立机器码和重定位信息,无法直接运行,需经链接器合并为可执行文件/共享库;
  • 可执行文件(ET_EXEC):最终运行的程序,包含完整的代码、数据和加载指引,内核可直接加载执行;
  • 共享目标文件(.so,ET_DYN):动态链接库,运行时被加载到内存,多个进程可共享复用,节省内存;
  • 核心转储文件(core):程序崩溃时生成的内存镜像,用于调试定位崩溃原因。

1.2 ELF文件的双重视角:Section与Segment

ELF文件设计最精妙的点,在于同时支持链接视角加载视角,通过两套结构实现分工协作:

  • Section(节区,链接视角):供编译器、链接器使用,按功能拆分代码、数据、符号表、重定位信息等,比如.text(代码)、.data(初始化数据)、.bss(未初始化数据)、.symtab(符号表);
  • Segment(段,加载视角):供操作系统加载器使用,将多个相关Section打包为一个段,统一映射到内存,注重内存权限和加载地址,比如代码段、数据段。
✅️ 为什么要合并节为段?减少内存碎片(减少空间浪费):例如.text(4097 字节)和.init(512 字节),分开加载需 3 个 4KB 内存页,合并后仅需 2 个;统一权限管理:相同属性的节合并后,操作系统可一次性设置权限(如所有只读节合并为一个只读段)。

实战查看段信息

# 查看a.out的程序头表(段信息) readelf -l a.out 

输出关键信息解读(主要是LOAD加载这个部分)

Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align LOAD 0x0000000000000000 0x0000000000400000 0x0000000000400000 0x0000000000000744 0x0000000000000744 R E 200000 LOAD 0x0000000000000e10 0x0000000000600e10 0x0000000000600e10 0x0000000000000218 0x0000000000000220 RW 200000 
  • LOAD表示该段需要加载到内存;
  • R E只读可执行(对应.text、.rodata 等节);
  • RW可读可写(对应.data、.bss 等节);
  • VirtAddr段加载到内存后的虚拟地址
  • 下图中的A应该是R我这里就不改了

简单来说:链接看Section,加载看Segment

1.3 ELF核心结构:从头部到加载指引

一个标准的ELF文件,由三部分核心结构组成,层层递进指引程序加载:

(1)ELF Header(文件头)

位于文件最开头,是ELF的“总目录”,固定长度(32位52字节、64位64字节),内核加载时首先读取这里验证文件合法性。核心字段包括:

  • 魔数(Magic):前4字节固定为0x7f 45 4c 46(对应ASCII的DEL+ELF),是ELF文件的唯一标识,内核以此判断是否为合法ELF;
  • 文件类型/架构:标明是可执行文件、动态库,以及适配的CPU架构(x86_64、ARM等);
  • 程序入口地址(e_entry):程序加载后第一条指令的虚拟地址;
  • 程序头表/节头表偏移:指向Segment和Section的位置,是加载、链接的入口。

实操查看:执行 readelf -h 可执行文件 即可查看ELF文件头详情。

(2)Program Header Table(程序头表)

仅对可执行文件、动态库有效,是操作系统加载程序的“装载地图”。它是一个数组,每个元素描述一个Segment的信息:

  • 段类型(PT_LOAD:需加载到内存的段;PT_INTERP:动态链接器路径);
  • 文件偏移、虚拟内存地址、内存大小、文件大小;
  • 内存权限(可读R、可写W、可执行X)。

实操查看:执行 readelf -l 可执行文件 查看程序头表(段信息)。

(3)Section Header Table(节头表)

供链接器和调试器使用,描述每个Section的名称、类型、偏移、大小等,调试、反汇编时依赖该表。

实操查看:执行 readelf -S 可执行文件 查看节头表信息。


二. ELF 的生命周期:从源码到运行

ELF 文件的完整生命周期分为 “编译链接” 和 “加载运行” 两个阶段,每个阶段都有明确的核心操作:我们这里主要讲讲编译链接就可以了,运行可以继续往下看看虚拟地址空间先。

2.1 编译链接(生成可执行 ELF,研究静态链接)

无论是自己的 .o , 还是静态库中的 .o ,本质都是把.o文件进行连接的过程,所以:研究静态链接,本质就是研究 .o 是如何链接的,我们这里就不打包成静态库来研究了。
核心目标:将多个目标文件(.o)和库文件合并,修正未解析的符号地址,生成可执行 ELF。

关键步骤

  • 编译:gcc -c将源码(hello.c、code.c)翻译成目标文件(hello.o、code.o),每个目标文件包含独立的.text、.data 等节;
  • 合并节:通过链接,链接器将所有目标文件的同名节合并(如所有.text 节合并为一个大的.text 节,.data 节同理);
  • 符号解析与重定位:链接器通过符号表(.symtab)找到未解析的符号(如 hello.o 中的 run 函数),修正其地址(指向 code.o 中 run 函数的实际位置)
  • 生成程序头表:根据合并后的节的属性,划分段(如只读可执行段、可读可写段),写入程序头表。

实战验证重定位效果

# 反汇编目标文件hello.o,查看未重定位的call指令 objdump -d hello.o | grep callq # 反汇编可执行程序a.out,查看重定位后的call指令 objdump -d a.out | grep callq 

输出对比

  • 目标文件 hello.o 中,call 指令地址为e8 00 00 00 00(地址未修正);
  • 可执行程序 a.out 中,call 指令地址为e8 dc fe ff ff(地址已修正为实际函数地址)。

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

2.2 加载运行(可以暂时先不看,继续往下理解)

核心目标:操作系统根据 ELF 的程序头表,将文件加载到内存,创建进程并执行。
关键步骤

  • 创建进程:操作系统调用fork创建新进程,分配进程控制块(task_struct)和虚拟地址空间;
  • 解析程序头表:读取 ELF 的程序头表,识别需要加载的段(LOAD 类型);
  • 内存映射:通过mmap系统调用,将 ELF 文件中的段映射到进程虚拟地址空间的对应区域(如只读可执行段映射到 0x400000 开始的地址);
  • 初始化内存
    • 为.bss 节分配内存并清零;
    • 将.data 节的数据从文件复制到内存;
  • 设置程序入口:将 CPU 的程序计数器(PC)指向 ELF 头中的入口点地址(Entry),程序开始执行。
  • 注意:建议大家先往下看,这里我们可以暂时先不去理解,主要还是需要理解下面哪些图里面的一些逻辑过程。

三. 进程虚拟地址空间

3.1 虚拟地址的核心作用

现代操作系统都采用 “虚拟地址机制”,程序加载时使用的是虚拟地址,而非物理内存地址:

  • 隔离进程:每个进程有独立的虚拟地址空间,互不干扰;
  • 简化编程:程序编译时使用 “平坦地址空间”(从 0 开始的连续地址)(加载到内存之前在磁盘上我们系统叫它逻辑地址,加载到内存之后我们习惯叫虚拟地址(线性地址)),无需关心物理内存布局;
  • 高效利用内存:通过页表映射物理内存,支持内存共享(如动态库)和交换(Swap)。
  • 大家可以仔细看下下面的图示解析,有点多但都很重要

四、加载流程核心知识点总结

  • 内核只负责加载,不负责动态链接:动态链接由用户态ld-linux.so完成,内核仅做内存映射和权限管理;
  • 虚拟地址而非物理地址:加载时使用虚拟地址,通过页表映射到物理内存,实现内存隔离和共享;
  • 按需加载(懒加载):内核并非一次性将整个ELF加载到内存,而是通过缺页异常,按需加载代码和数据,节省内存;
  • 内存权限隔离:代码段不可写、数据段不可执行,防范内存篡改、栈溢出等安全风险。

结语:

ELF格式是Linux二进制程序的基石,而加载流程则是连接磁盘文件与运行进程的桥梁。理解ELF结构,能帮我们更好地排查程序崩溃、库依赖、内存异常等问题;吃透加载流程,才能真正掌握Linux程序运行的底层逻辑。

下一篇我们将深入动态链接PLT/GOT机制静态链接与动态链接的优劣对比,继续拆解Linux程序运行的底层细节,敬请关注。

🔥如果你在调试ELF文件、排查加载报错时遇到问题,欢迎留言交流,我会逐一解答。

Read more

Linux 源配置不用慌!CentOS/Ubuntu 源更新(含恢复)+Yum 操作 + Vim 入门,新手也能懂!

Linux 源配置不用慌!CentOS/Ubuntu 源更新(含恢复)+Yum 操作 + Vim 入门,新手也能懂!

✨ 孤廖:个人主页 🎯 个人专栏:《C++:从代码到机器》 🎯 个人专栏:《Linux系统探幽:从入门到内核》 🎯 个人专栏:《算法磨剑:用C++思考的艺术》 折而不挠,中不为下 文章目录 * 前言: * 正文: * 软件包管理器 * 1.什么是软件包 * 2. Linux软件⽣态 * 3. yum具体操作 * 查看软件包 * 安装软件 * 卸载软件 * Centos7更新yum源 * 1. 备份现有Yum源 * 2. 下载新的Yum源配置⽂件 * 3. 清理并⽣成缓存 * 4. 更新系统 * 5. 恢复原有Yum源(可选) * 6. 验证Yum源 * Ubuntu 更新apt源 * 1. 备份现有APT源 * 2. 直接下载新的APT源配置⽂

By Ne0inhk
LINUX DO社区无需邀请码,2025最新加入社区方法:填写50字申请自述和加入缘由即可加入

LINUX DO社区无需邀请码,2025最新加入社区方法:填写50字申请自述和加入缘由即可加入

LINUX DO社区无需邀请码,2025最新加入社区方法:填写50字申请自述和加入缘由即可加入 近期,很多粉丝纷纷咨询关于LINUX DO社区的邀请码问题。之前,LINUX DO社区的加入确实需要邀请码,这给一些小伙伴带来了不小的困扰。要想加入社区,大家不仅需要从他人处获取邀请码,还需要通过社区管理的严格审核。由于邀请码获取的途径有限,导致许多人错失了加入的机会。 但从2025年起,LINUX DO社区已经取消了强制邀请码的限制,新的加入方式变得更加简单和直接。现在,想要加入社区的用户,只需要在申请时填写50字左右的真实自述和加入缘由即可。通过这种方式,社区能够更好地了解你的加入动机,而你也能顺利加入这个技术交流的大家庭。 对于那些一直因邀请码难以获取而感到遗憾的朋友,现在终于可以轻松加入社区了。本文将为你详细介绍2025年最新的加入方法,帮助你顺利成为LINUX DO社区的一员。 文章目录 * LINUX DO社区无需邀请码,2025最新加入社区方法:填写50字申请自述和加入缘由即可加入 * 一、加入LINUX DO社区前需要了解的内容 * 二、如何进行

By Ne0inhk
Flutter 组件 heart 适配鸿蒙 HarmonyOS 实战:分布式心跳监控,构建全场景保活检测与链路哨兵架构

Flutter 组件 heart 适配鸿蒙 HarmonyOS 实战:分布式心跳监控,构建全场景保活检测与链路哨兵架构

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net Flutter 组件 heart 适配鸿蒙 HarmonyOS 实战:分布式心跳监控,构建全场景保活检测与链路哨兵架构 前言 在鸿蒙(OpenHarmony)生态迈向万物智联、涉及海量传感器节点通信、分布式长连接保活及实时状态同步的背景下,如何确保终端设备在弱网、休眠或异常断电场景下仍能被母座感知,已成为决定系统可用性的“生命信标”。在鸿蒙设备这类强调分布式软总线协同与严苛电源管理的环境下,如果应用依然依赖基础的 HTTP 定时轮询执行状态探测,由于由于 CPU 频繁唤醒带来的功耗负担及无状态协议的连接开销,极易由于由于心跳风暴导致设备续航崩穿或大规模误判掉线。 我们需要一种能够实现毫秒级超时检测、支持异步回调闭环且具备高性能状态机控制的心跳监控方案。 heart 为 Flutter 开发者引入了轻量级且工业标准的“心搏”治理范式。它通过对 Ping-Pong 交互的时序解构,将复杂的超时重试与状态翻转逻辑封装为声明式的配置。在适配到鸿蒙 HarmonyO

By Ne0inhk

Flutter 三方库 at_server_status 的鸿蒙化适配指南 - 在鸿蒙系统上构建极致、透明、实时的 @protocol 去中心化身份服务器状态感知与鉴权监控引擎

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net Flutter 三方库 at_server_status 的鸿蒙化适配指南 - 在鸿蒙系统上构建极致、透明、实时的 @protocol 去中心化身份服务器状态感知与鉴权监控引擎 在鸿蒙(OpenHarmony)系统的隐私保护应用、去中心化身份管理工具(基于 @protocol 协议)或需要实时监控全球分布式节点健康状况的场景中,如何判定一个 @sign(电子签名标识)背后的 Root 服务器或 Secondary 服务器是否在线、配置是否由于由于由于由于已就绪?at_server_status 为开发者提供了一套工业级的、基于协议栈的状态审计与自检方案。本文将深入实战其在鸿蒙 Web3 身份安全底座中的应用。 前言 什么是 atServer Status?它是 @protocol(一种旨在让用户完全掌控数据的去中心化协议)官方生态的核心组件。

By Ne0inhk