第一章：ELF文件格式基础与二进制世界初探
1.1 什么是ELF文件以及为什么它至关重要
在嵌入式ARM开发的世界中，您会频繁地接触到各种各样的文件。其中，.s（汇编源文件）、.c（C语言源文件）、.o（目标文件）、.a（静态库文件）和最终生成的二进制文件（通常没有特定后缀，或者如.axf, .elf）构成了整个软件开发流程的核心。而ELF（Executable and Linkable Format，可执行与可链接格式）正是贯穿这一切的标准、灵活、可扩展的二进制文件格式。
1.1.1 ELF：连接、加载和执行的标准桥梁
想象一下，您的嵌入式系统是一个复杂的乐高积木王国。您有许多不同的小块（比如各种函数、数据），它们由不同的工程师（编译器）制作，存放在不同的盒子（源文件）里。要搭建一个完整的城堡（程序），您需要将这些小块精确地组装起来，并将其放置在正确的位置，以便机器人（处理器）能够按照您的指令一步步完成任务。
ELF文件正是实现这种“组装”、“放置”和“执行”的通用 blueprint。它不仅仅是最终的可执行文件格式，更重要的是，它是链接器（Linker）和加载器（Loader）之间沟通的标准协议。
-
可链接性 (Linkable): 在编译阶段，每个源代码文件（
.c或.s）会被编译成一个独立的目标文件（.o）。这些目标文件包含了机器码、数据以及符号信息（例如函数名、变量名），但它们是独立的，彼此之间可能存在未解析的引用（比如一个函数调用了另一个在别的文件中定义的函数）。ELF格式的目标文件提供了一种标准的方式来存储这些信息，使得链接器能够将多个.o文件、库文件（.a）组合在一起，解析所有外部引用，最终生成一个完整的、可执行的ELF文件。这种标准化的中间表示形式极大地提高了开发效率和模块化程度。 -
可执行性 (Executable): 最终生成的ELF文件包含了处理器可以直接执行的机器指令和程序运行时所需的数据。它还包含了操作系统（或嵌入式环境中的Bootloader/加载器）如何将程序加载到内存中、从何处开始执行等关键信息。对于嵌入式系统而言，这意味着ELF文件可以被烧录到非易失性存储器（如Flash）中，并在上电后由处理器直接或通过Bootloader加载执行。
-
可共享性 (Shared): 虽然在裸机嵌入式开发中不常用，但在带有操作系统的嵌入式Linux等环境中，ELF也支持动态链接库（Shared Objects，
.so文件）。这允许多个程序共享同一个库的代码，节省内存并方便更新。
1.1.2 ELF在嵌入式系统中的作用：从固件到操作系统
在嵌入式开发领域，ELF文件的应用无处不在，无论您是在编写简单的裸机固件，还是开发复杂的嵌入式操作系统应用：
-
裸机固件 (Bare-Metal Firmware): 对于没有操作系统的嵌入式项目，例如控制一个LED闪烁、读取传感器数据等简单任务，您编写的C或汇编代码会被编译、链接成一个单一的ELF文件。这个ELF文件通常不包含操作系统相关的头，其程序入口点直接对应于处理器上电后跳转的地址。Bootloader或烧录工具会直接将这个ELF文件的内容（通常是ELF文件中可加载段的数据）写入到目标设备的Flash存储器中。
-
Bootloader (引导加载程序): Bootloader本身也是一个ELF文件编译而成的程序。它的作用是在系统上电后初始化硬件、加载并跳转到应用程序。Bootloader的ELF文件通常是一个非常精简的裸机程序，它知道如何从Flash读取应用程序的ELF文件，并将其加载到RAM中。
-
实时操作系统 (RTOS) 应用: 如果您的嵌入式项目使用RTOS（如FreeRTOS, RT-Thread），那么您的应用程序（例如一个任务、一个驱动）同样会编译成ELF格式。RTOS的内核本身也是一个ELF文件。您的应用程序ELF文件通常会被RTOS的加载器处理，加载到指定的内存区域，并由RTOS调度执行。
-
嵌入式Linux应用: 在基于嵌入式Linux的系统中，ELF的应用更加复杂和丰富。所有的用户空间应用程序、系统服务、共享库和甚至Linux内核本身，都是ELF格式的。Linux内核负责解析和加载用户空间的ELF可执行文件，管理进程的内存空间，并提供动态链接等高级功能。
理解ELF文件格式的内部结构，对于嵌入式开发者来说，意味着：
- 深入理解程序启动过程： 明白处理器上电后，是如何找到并执行您的代码的。
- 调试能力提升： 当程序崩溃或行为异常时，能够通过分析Core Dump文件（ELF格式）来定位问题。
- 优化程序大小与性能： 理解各个段（如代码段、数据段、BSS段）的布局和加载方式，有助于进行存储器优化和启动时间优化。
- 自定义加载器或链接脚本： 在高级嵌入式开发中，您可能需要为特定硬件编写自定义的Bootloader或链接脚本，此时对ELF格式的掌握是必不可少的。
1.1.3 ELF与ARM架构的紧密结合
ELF文件格式本身是平台独立的，但其内部的某些字段（如e_machine，指示目标机器架构）会明确指定其针对的CPU类型。对于ARM架构，这意味着ELF文件将包含ARM处理器能够理解的指令集（ARM或Thumb指令集）以及特定于ARM的数据表示（如小端序/大端序）。
当您使用ARM交叉编译工具链（例如arm-none-eabi-gcc）编译您的C/汇编代码时，它会生成针对ARM架构的ELF文件。这个文件不仅包含ARM指令，还会在ELF头部标识出EM_ARM（ARM架构标识符），确保只有ARM处理器或模拟器能够正确解析和执行它。
1.2 从裸机启动的视角看ELF
为了真正理解ELF文件在嵌入式ARM系统中的作用，我们必须将视角拉回到最原始的场景：裸机启动。想象一下，一块全新的开发板刚刚通电，上面只有处理器和一块Flash存储器。
1.2.1 处理器上电后执行的第一条指令
当嵌入式ARM处理器上电或复位时，它会执行一系列固定的硬件初始化步骤。其中最关键的一步是：处理器内部的程序计数器（Program Counter, PC）会被强制设置为一个预设的、固定的地址。这个地址被称为复位向量 (Reset Vector)。
对于大多数ARM Cortex-M系列处理器（例如Cortex-M0, M3, M4, M7），这个复位向量通常位于**0x00000000地址。处理器上电后，会立即从这个地址读取两个字**（对于32位ARM处理器，一个字是4字节）的内容：
- 第一个字 (通常在
0x00000000): 这不是指令，而是主堆栈指针（MSP）的初始值。在Cortex-M系列中，这是ARMv7-M架构定义的一部分。处理器在进入主模式前，会将这个值加载到MSP寄存器中。 - 第二个字 (通常在
0x00000004): 这才是程序的入口点地址，也就是处理器上电后真正要跳转执行的第一条指令的地址。这个地址通常指向您的**启动代码（Startup Code）**的起始位置。
因此，当您编写嵌入式ARM程序时，您的程序必须确保在0x00000000（或处理器指定的其他复位地址）及其后续地址上放置正确的值，以便处理器能够正确初始化堆栈并跳转到您的程序入口。而ELF文件正是如何组织这些内容的标准。
1.2.2 启动代码（Startup Code）与ELF文件的关系
启动代码通常是一段用汇编语言编写的、非常精简的程序。它的主要任务是：
- 初始化堆栈指针 (Stack Pointer, SP): 这是非常关键的第一步，因为C/C++程序运行时需要堆栈来存储局部变量、函数参数和返回地址。
- 初始化数据段 (.data): 将初始化数据从Flash（ROM）复制到RAM中。
- 清零BSS段 (.bss): 将未初始化全局变量所在的BSS段清零。
- 配置时钟和PLL (Phase-Locked Loop): 确保处理器以正确的频率运行。
- 初始化中断向量表: 设置好中断服务程序的入口地址。
- 跳转到C语言的main函数: 完成所有硬件和基本运行时环境的设置后，将控制权交给您的C语言
main函数。
所有这些任务都体现在最终的ELF文件中。ELF文件会包含：
.text段： 存储启动代码的机器指令和您的C/C++代码的机器指令。.data段： 存储所有已初始化全局变量和静态变量的初始值。这些值在ELF文件中位于Flash对应的位置，但在程序运行时需要被复制到RAM中。.bss段： 存储所有未初始化全局变量和静态变量的信息。ELF文件只记录其大小，运行时这些内存区域会被清零。- 中断向量表： 通常也作为
.text段的一部分或一个独立的段，包含各个中断服务程序的入口地址，其中就包括复位向量。
ELF文件正是将这些不同类型的数据和代码组织成逻辑上的“段”（Sections）和可加载的“程序段”（Segments），以便链接器和加载器能够正确处理它们。
1.2.3 如何将ELF文件“烧录”到Flash/ROM中
在裸机嵌入式开发中，我们通常不会直接“运行”ELF文件。而是将ELF文件中那些需要存储在非易失性存储器（如Flash）中的内容“烧录”进去。这个过程通常涉及：
-
将ELF转换为可烧录格式： ELF文件包含调试信息、符号表等运行时不必要的信息。烧录工具通常需要一个更纯粹的二进制镜像。因此，
objcopy这样的工具会将ELF文件转换为二进制（.bin）文件或Intel HEX（.hex）文件。.bin文件： 这是一个纯粹的内存映像，包含了ELF文件中所有可加载段的原始二进制数据。它的优点是简单、直接，可以按地址直接写入Flash。.hex文件： 这是一个文本格式的文件，它用ASCII字符表示二进制数据，并且包含了地址信息和校验和。.hex文件对于文本编辑器可读，且在传输过程中具有一定的校验能力。
-
烧录工具： 使用J-Link、ST-Link、OpenOCD等调试/烧录工具，通过SWD（Serial Wire Debug）或JTAG接口将
.bin或.hex文件写入到目标设备的Flash存储器中。烧录工具会根据文件的地址信息，将数据写入到Flash的正确位置。
关键点： 烧录时，我们烧录的不是完整的ELF文件本身，而是ELF文件中**可加载的程序段（Program Segments）**的数据内容。这些程序段包含了代码（.text）和初始化数据（.data）。而像符号表、调试信息等只在开发和调试阶段有用的ELF内部结构，则不会被烧录到目标设备中，以节省存储空间。
理解这一点至关重要：ELF文件是编译链接的产物和加载运行的蓝图，而烧录到设备中的是它的核心内容（可执行代码和数据）。
1.3 ELF文件头的二进制解析 (Binary Parsing of the ELF Header)
现在，我们准备深入ELF文件的最前端：ELF文件头 (ELF Header)。ELF文件头是整个ELF文件的“身份证”，它包含了关于文件类型、目标架构、程序入口点、段表和程序头表位置等关键元数据。正确解析ELF文件头是理解和处理任何ELF文件的第一步。
我们将主要关注32位ELF文件头，因为大多数ARM Cortex-M微控制器运行在32位模式下。其C语言结构体定义通常是 Elf32_Ehdr。
1.3.1 Elf32_Ehdr 结构体概述
虽然我们不会直接使用C语言结构体来解析（因为我们是在从二进制层面分析），但了解其字段定义有助于我们理解每个字节的含义。一个典型的Elf32_Ehdr结构体（在elf.h或类似头文件中定义）大致如下：
typedef struct {
unsigned char e_ident[EI_NIDENT]; // 16字节：ELF标识符，包含魔数、位数、字节序等
Elf32_t e_type; // 2字节：文件类型（可重定位文件、可执行文件、共享文件等）
Elf32_t e_machine; // 2字节：目标机器架构（ARM、X86等）
Elf32_Word e_version; // 4字节：ELF版本
Elf32_Addr e_entry; // 4字节：程序入口点虚拟地址
Elf32_Off e_phoff; // 4字节：程序头表（Program Header Table）在文件中的偏移量
Elf32_Off e_shoff; // 4字节：节头表（Section Header Table）在文件中的偏移量
Elf32_Word e_flags; // 4字节：处理器特定的标志
Elf32_Half e_ehsize; // 2字节：ELF文件头本身的大小
Elf32_Half e_phentsize; // 2字节：程序头表中每个条目的大小
Elf32_Half e_phnum; // 2字节：程序头表中条目的数量
Elf32_Half e_shentsize; // 2字节：节头表中每个条目的大小
Elf32_Half e_shnum; // 2字节：节头表中条目的数量
Elf32_Half e_shstrndx; // 2字节：节字符串表在节头表中的索引
} Elf32_Ehdr;
现在，让我们逐个字段从二进制层面进行深入解析。
1.3.2 详细解析 e_ident (ELF标识符)
e_ident 是ELF文件头的第一个字段，占据文件的前16个字节。它是ELF文件的“魔法”签名，包含了最基本的文件识别信息。
二进制数据偏移量： 0x00 - 0x0F (16 字节)
| 偏移量 (HEX) | 字段名 (C语言定义) | 字节数 | 含义及重要性（嵌入式ARM） | 示例值 (小端序) |
|---|---|---|---|---|
0x00 - 0x03 |
EI_MAG |
4 | 魔数 (Magic Number)：固定为 0x7F 'E' 'L' 'F'。这是所有ELF文件的标志，用于快速识别文件类型。如果文件不以这四个字节开头，它就不是一个有效的ELF文件。对于嵌入式系统，Bootloader或烧录工具会首先检查这个魔数。 |
7F 45 4C 46 |
0x04 |
EI_CLASS |
1 | 文件位数 (File Class)：0x01 表示32位ELF（ELFCLASS32），0x02 表示64位ELF（ELFCLASS64）。对于绝大多数嵌入式ARM Cortex-M微控制器，这个值是 0x01。 |
01 |
0x05 |
EI_DATA |
1 | 数据编码 (Data Encoding)：0x01 表示小端序（ELFDATA2LSB），0x02 表示大端序（ELFDATA2MSB）。ARM处理器既可以配置为小端序也可以配置为大端序。目前主流的ARM嵌入式系统（如STM32、NXP i.MX RT）大多采用小端序，因此这个值通常是 0x01。如果这个值与目标处理器的字节序不符，程序将无法正确运行，因为多字节数据（如e_entry、e_phoff）的解析会出错。 |
01 |
0x06 |
EI_VERSION |
1 | ELF版本 (ELF Version)：通常为 0x01（EV_CURRENT），表示当前ELF规范版本。 |
01 |
0x07 |
EI_OSABI |
1 | 操作系统/ABI (Operating System/ABI)：指示目标操作系统或应用程序二进制接口。0x00通常表示System V ABI（通用），在裸机或RTOS环境中常见。对于嵌入式Linux，可能是0x03（Linux）。 |
00 |
0x08 |
EI_ABIVERSION |
1 | ABI版本 (ABI Version)：进一步的ABI版本信息。通常为 0x00。 |
00 |
0x09 - 0x0F |
EI_PAD |
7 | 填充字节 (Padding)：保留字节，通常为 0x00。 |
00 00 00 00 00 00 00 |
1.3.3 解析 e_type (文件类型)
二进制数据偏移量： 0x10 - 0x11 (2 字节)
这个字段指示ELF文件的类型。对于嵌入式开发，我们最常遇到的是以下几种：
| 值 (HEX) | 类型 (C语言定义) | 含义及重要性（嵌入式ARM） |
|---|---|---|
0x0001 |
ET_REL |
可重定位文件 (Relocatable file)：这是编译器生成的目标文件（.o）。它们包含代码和数据，但其中的地址都是相对于模块内部的，尚未进行链接。多个.o文件通过链接器合并。 |
0x0002 |
ET_EXEC |
可执行文件 (Executable file)：这是链接器生成的最终可执行程序。所有的符号都已解析，地址都已确定。对于裸机嵌入式系统，通常将这类ELF文件烧录到Flash中。 |
0x0003 |
ET_DYN |
共享对象文件 (Shared object file)：即动态链接库（.so）。在嵌入式Linux等操作系统环境中使用，裸机环境中不常见。 |
对于您编译的最终烧录到Flash的裸机程序，e_type的值通常是 0x0002。注意，这是一个2字节的字段，根据EI_DATA指定的字节序来解析。如果是小端序，0x0002会表示为 02 00。
1.3.4 解析 e_machine (目标机器架构)
二进制数据偏移量： 0x12 - 0x13 (2 字节)
这个字段指定了ELF文件设计运行的目标处理器架构。
| 值 (HEX) | 架构 (C语言定义) | 含义及重要性（嵌入式ARM） |
|---|---|---|
0x0008 |
EM_MIPS |
MIPS架构 |
0x0028 |
EM_ARM |
ARM架构 |
0x0032 |
EM_X86_64 |
AMD x86-64架构 |
0x00B7 |
EM_AARCH64 |
ARM AArch64（64位ARM）架构 |
对于我们专注于的32位ARM嵌入式开发，这个值将是 0x0028。同样，如果字节序是小端，则表示为 28 00。
1.3.5 解析 e_version (ELF版本)
二进制数据偏移量： 0x14 - 0x17 (4 字节)
这是ELF规范的版本号，通常为 0x00000001 (EV_CURRENT)。
1.3.6 解析 e_entry (程序入口点虚拟地址)
二进制数据偏移量： 0x18 - 0x1B (4 字节)
这是程序执行的虚拟地址入口点。对于裸机嵌入式系统，这个虚拟地址通常就是程序的物理起始地址，即处理器上电后应该跳转到的第一条指令的地址。
- 重要性： 链接器在生成ELF文件时，会根据链接脚本（Linker Script）中的配置，将程序的入口点设置为一个特定的地址。对于ARM Cortex-M系列，这个地址通常指向您的启动代码中的复位处理函数（例如，在GNU工具链中通常是
Reset_Handler或_start）。Bootloader或裸机加载器会从这里获取地址，然后跳转到这个地址开始执行程序。
例如，如果您的程序入口点被链接器设置为0x08000100（Flash存储器的起始地址偏移），那么这四个字节会是 00 01 00 08（小端序）。
1.3.7 解析 e_phoff (程序头表偏移量)
二进制数据偏移量： 0x1C - 0x1F (4 字节)
这个字段指示程序头表 (Program Header Table) 在文件中的偏移量（从文件开头算起）。程序头表描述了如何将ELF文件的段（Sections）加载到内存中，对于可执行文件或共享对象文件至关重要。
- 重要性： 对于加载器（包括操作系统加载器和嵌入式Bootloader），
e_phoff和e_phnum（程序头条目数量）是解析文件，将代码和数据加载到正确内存位置的关键信息。Bootloader会读取这里，找到程序头表，然后根据每个程序头条目的描述，将ELF文件中对应的段加载到RAM中。
1.3.8 解析 e_shoff (节头表偏移量)
二进制数据偏移量： 0x20 - 0x23 (4 字节)
这个字段指示节头表 (Section Header Table) 在文件中的偏移量。节头表包含了ELF文件中所有“节”（Section）的详细信息，例如.text、.data、.bss、.rodata等。
- 重要性： 节头表主要用于链接器在处理可重定位文件时，以及调试器在调试时解析文件结构。在程序加载到内存后，节头表通常不再需要，因此它通常不会被烧录到Flash或加载到RAM中。但在开发和调试阶段，它是理解程序内存布局和查找符号的关键。
1.3.9 解析 e_flags (处理器特定标志)
二进制数据偏移量： 0x24 - 0x27 (4 字节)
这是一个用于存储处理器特定标志的字段。对于ARM架构，这些标志可以指示ARM ABI（应用程序二进制接口）版本、浮点单元（FPU）的使用情况、处理器模式（ARM/Thumb）等。
例如，它可能包含以下位：
EF_ARM_EABI_VERSION: 指示ARM EABI（Embedded ABI）版本。EF_ARM_BE8: 指示Big-endian 8位字节序。EF_ARM_ABI_FLOAT_SOFT: 软件浮点ABI。EF_ARM_ABI_FLOAT_HARD: 硬件浮点ABI。
在不同的交叉编译工具链版本中，这些标志的含义可能略有差异，但它们通常用于确保链接器和加载器能够正确处理特定于ARM的二进制特性。
1.3.10 解析 e_ehsize (ELF文件头大小)
二进制数据偏移量： 0x28 - 0x29 (2 字节)
这个字段表示ELF文件头本身的大小，单位是字节。对于32位ELF文件，它通常是 0x0034 (52 字节)。
1.3.11 解析 e_phentsize (程序头表条目大小) 和 e_phnum (程序头表条目数量)
e_phentsize (2 字节): 二进制数据偏移量： 0x2A - 0x2B
e_phnum (2 字节): 二进制数据偏移量： 0x2C - 0x2D
e_phentsize: 程序头表中每个条目的大小（字节）。对于32位ELF，通常是0x0020(32 字节)。e_phnum: 程序头表中的条目数量。
这两个字段结合e_phoff，使得加载器能够准确地定位和遍历程序头表，从而了解如何加载程序的不同部分。
1.3.12 解析 e_shentsize (节头表条目大小) 和 e_shnum (节头表条目数量)
e_shentsize (2 字节): 二进制数据偏移量： 0x2E - 0x2F
e_shnum (2 字节): 二进制数据偏移量： 0x30 - 0x31
e_shentsize: 节头表中每个条目的大小（字节）。对于32位ELF，通常是0x0028(40 字节)。e_shnum: 节头表中的条目数量。
这两个字段结合e_shoff，使得链接器和调试器能够准确地定位和遍历节头表，从而获取每个节的详细属性。
1.3.13 解析 e_shstrndx (节字符串表索引)
二进制数据偏移量： 0x32 - 0x33 (2 字节)
这个字段表示节头表中，哪一个条目是节字符串表 (Section String Table)。节字符串表是一个特殊的节，它存储了所有其他节的名称（例如“.text”、“.data”等）。
- 重要性： 通过这个索引，链接器和调试器可以找到节字符串表，从而将节的名称（以字符串形式）与节头表中的数值索引关联起来。
1.3.14 一个最简单ARM汇编ELF文件的头部分析示例
为了让您对上述概念有更直观的理解，我们将编写一个非常简单的ARM汇编程序，并概念性地分析其生成的ELF文件头。
汇编源代码 (minimal_arm.s):
; minimal_arm.s
; 这是一个非常简单的ARM汇编程序，用于演示ELF文件生成和头部结构。
; 它仅仅包含一个无限循环，在嵌入式系统中常用于测试或保持处理器活跃。
; 这段代码假定链接到从0x8000000地址开始的Flash区域。
.syntax unified ; 统一汇编语法，推荐用于ARMv7及以上架构
; 允许同时使用ARM和Thumb指令集语法
.cpu cortex-m0 ; 指定目标CPU为Cortex-M0，这是常见的嵌入式ARM核
; Cortex-M0只支持Thumb指令集，所以默认会编译成Thumb指令
.thumb ; 明确指示使用Thumb指令集编译，确保所有指令都是16位或32位Thumb指令
.global _start ; 声明_start为全局符号，这是程序的入口点
; 链接器会从这里开始执行程序。对于裸机，通常是复位向量跳转到的地址。
.section .text ; 定义一个名为.text的代码段，通常用于存放程序的执行代码
_start:
b . ; 这是Thumb指令，分支到当前指令的地址，形成一个无限循环。
; 相当于 'b _start'，但使用'.'表示当前地址，更简洁。
; 在裸机程序中，这种循环常用于测试、空闲或防止程序跑飞。
.end ; 汇编文件结束标志，表示文件解析完毕
概念性编译和链接过程：
假设我们使用arm-none-eabi-gcc工具链进行编译和链接：
- 汇编：
arm-none-eabi-as -mcpu=cortex-m0 -mthumb -o minimal_arm.o minimal_arm.s- 这条命令将
minimal_arm.s汇编成一个名为minimal_arm.o的目标文件（ET_REL类型的ELF文件）。
- 这条命令将
- 链接：
arm-none-eabi-ld -Tlinker_script.ld -o minimal_arm.elf minimal_arm.o- 这里需要一个
linker_script.ld（链接脚本），它告诉链接器如何将.o文件中的各个段放置到目标内存地址。例如，它会指定.text段放置到0x08000000（Flash起始地址）。 - 链接后生成
minimal_arm.elf，这是一个ET_EXEC类型的ELF文件。
- 这里需要一个
假设生成的minimal_arm.elf文件头的前52个字节（以小端序十六进制表示）可能如下所示：
7F 45 4C 46 01 01 01 00 00 00 00 00 00 00 00 00 ; e_ident (0x00 - 0x0F)
02 00 ; e_type (0x10 - 0x11): 0x0002 (ET_EXEC)
28 00 ; e_machine (0x12 - 0x13): 0x0028 (EM_ARM)
01 00 00 00 ; e_version (0x14 - 0x17): 0x00000001 (EV_CURRENT)
01 00 00 08 ; e_entry (0x18 - 0x1B): 0x08000001 (程序入口点，注意Thumb模式下的地址奇偶性)
34 00 00 00 ; e_phoff (0x1C - 0x1F): 0x00000034 (程序头表偏移量，紧随ELF头之后)
B8 00 00 00 ; e_shoff (0x20 - 0x23): 0x000000B8 (节头表偏移量，示例值)
05 00 00 00 ; e_flags (0x24 - 0x27): 0x00000005 (ARM特定标志，例如EABI版本)
34 00 ; e_ehsize (0x28 - 0x29): 0x0034 (52字节，ELF头大小)
20 00 ; e_phentsize (0x2A - 0x2B): 0x0020 (32字节，每个程序头条目大小)
02 00 ; e_phnum (0x2C - 0x2D): 0x0002 (2个程序头条目，例如一个LOAD段用于代码，一个LOAD段用于数据)
28 00 ; e_shentsize (0x2E - 0x2F): 0x0028 (40字节，每个节头条目大小)
06 00 ; e_shnum (0x30 - 0x31): 0x0006 (6个节头条目，例如.text, .data, .bss, .symtab, .strtab, .shstrtab)
05 00 ; e_shstrndx (0x32 - 0x33): 0x0005 (节字符串表在节头表中的索引)
对e_entry的额外说明：
在ARM Cortex-M微控制器中，如果程序执行的是Thumb指令集（这是Cortex-M的默认和唯一模式），那么程序的入口点地址的最低位（bit 0）会被设置为1，以指示处理器在跳转时切换到Thumb状态。所以，如果实际的物理地址是0x08000000，那么在e_entry中看到的值会是0x08000001。这被称为Thumb位 (Thumb Bit)，它是处理器识别指令集状态的关键。
第二章：ELF文件格式深度剖析——程序头表与内存加载机制
2.1 程序头表 (Program Header Table, PHT) 的核心作用
ELF文件有两种不同的视图：
- 链接视图 (Linking View): 这是编译器和链接器在构建文件时所关注的视图。它由节 (Sections) 组成，每个节包含特定类型的数据或代码（如
.text、.data、.bss、.rodata、.symtab、.debug等）。节头表 (Section Header Table) 详细描述了这些节。 - 执行视图 (Execution View): 这是加载器（无论是操作系统的加载器，还是嵌入式系统中的Bootloader）在将程序加载到内存中并执行时所关注的视图。它由程序段 (Program Segments) 组成。程序头表 (Program Header Table) 描述了这些程序段，以及它们如何被映射到内存中。
程序头表的核心作用是定义ELF文件中的哪些部分需要被加载到内存中，以及它们应该被加载到内存的哪个位置、以何种权限（读、写、执行）加载。 对于可执行文件（ET_EXEC类型）和共享对象文件（ET_DYN类型），程序头表是必不可少的。对于可重定位文件（ET_REL类型，即.o文件），程序头表通常是可选的或为空，因为它们尚未被链接到最终的内存布局。
在嵌入式ARM裸机开发中，Bootloader（如果有的话）或者烧录工具在准备将ELF内容写入Flash或加载到RAM时，会严格依据程序头表中的信息。它会忽略节头表中那些只在链接或调试时有用的信息（如.symtab、.debug），只关注程序头表中标记为可加载的段。
2.2 Elf32_Phdr 结构体详解
程序头表由一系列结构体组成，每个结构体描述一个程序段。对于32位ELF文件，这个结构体被称为 Elf32_Phdr。其C语言定义大致如下：
typedef struct {
Elf32_Word p_type; // 4字节：段类型
Elf32_Off p_offset; // 4字节：段在文件中的偏移量
Elf32_Addr p_vaddr; // 4字节：段在虚拟内存中的地址
Elf32_Addr p_paddr; // 4字节：段在物理内存中的地址（对于嵌入式裸机，p_vaddr和p_paddr通常相同）
Elf32_Word p_filesz; // 4字节：段在文件中的大小（字节）
Elf32_Word p_memsz; // 4字节：段在内存中的大小（字节）
Elf32_Word p_flags; // 4字节：段的权限标志（读、写、执行）
Elf32_Word p_align; // 4字节：段在内存和文件中对齐要求
} Elf32_Phdr;
回想一下ELF文件头中的 e_phoff、e_phentsize 和 e_phnum 字段：
e_phoff: 指向程序头表在文件中的起始偏移量。e_phentsize: 每个Elf32_Phdr结构体的大小（通常是32字节）。e_phnum: 程序头表中的条目数量。
通过这些信息，加载器可以精确地定位并遍历程序头表中的每一个程序段描述符。现在，让我们逐个字段进行深入解析。
2.2.1 详细解析 p_type (段类型)
二进制数据偏移量： 0x00 - 0x03 (4 字节)
这个字段是程序段的类型，它告诉加载器这个段的用途。这是程序头表中最重要的字段之一。
| 值 (HEX) | 类型 (C语言定义) | 含义及重要性（嵌入式ARM） |
|---|---|---|
0x00000000 |
PT_NULL |
空类型 (Null segment)：指示该程序头条目未使用。通常在程序头表中有一些保留或未使用的条目时出现。加载器会忽略这种类型的段。 |
0x00000001 |
PT_LOAD |
可加载段 (Loadable segment)：这是最重要且最常见的类型。 它表示这个程序段包含了程序运行时需要加载到内存中的数据或代码。对于裸机嵌入式系统，.text（代码）和.data（初始化数据）通常会组合成一个或多个PT_LOAD类型的程序段。加载器会根据p_offset、p_vaddr、p_filesz和p_memsz等信息，将文件中的数据复制到指定的内存地址。 |
0x00000002 |
PT_DYNAMIC |
动态链接信息 (Dynamic linking information)：如果ELF文件是一个动态链接的可执行文件或共享库，这个段包含了动态链接器所需的信息（如依赖的共享库列表、符号解析信息等）。在裸机嵌入式系统中通常不使用。 |
0x00000003 |
PT_INTERP |
解释器路径 (Path to interpreter)：对于动态链接的可执行文件，这个段指定了程序解释器（通常是/lib/ld-linux.so.2等动态链接器）的路径。在裸机嵌入式系统中不使用。 |
0x00000004 |
PT_NOTE |
辅助信息 (Auxiliary information)：包含一些辅助信息，如操作系统或ABI版本等。这些信息通常对程序执行不是必需的，加载器可以选择忽略。 |
0x00000005 |
PT_SHLIB |
保留 (Reserved)：保留给共享库。 |
0x00000006 |
PT_PHDR |
程序头表本身 (Program header table itself)：如果程序头表本身作为程序的一个段存在于内存中，则使用此类型。这允许程序在运行时访问自己的程序头表。在某些复杂加载场景下有用，但裸机通常不包含此类型。 |
0x00000007 |
PT_TLS |
线程本地存储 (Thread-local storage)：用于线程本地存储区域的段。在支持多线程的操作系统环境中使用。 |
0x60000000 |
PT_LOOS |
操作系统特定范围低位 (OS-specific range low)：操作系统特定的段类型，范围从PT_LOOS到PT_HIOS。 |
0x6FFFFFFF |
PT_HIOS |
操作系统特定范围高位 (OS-specific range high)。 |
0x70000000 |
PT_LOPROC |
处理器特定范围低位 (Processor-specific range low)：处理器特定的段类型，范围从PT_LOPROC到PT_HIPROC。对于ARM，可能会定义一些ARM特有的段类型。 |
0x7FFFFFFF |
PT_HIPROC |
处理器特定范围高位 (Processor-specific range high)。 |
对于嵌入式ARM裸机程序，您最需要关注的是 PT_LOAD 类型的段。 所有的代码和初始化数据都必须包含在这种类型的段中，才能被Bootloader或烧录工具正确处理。
2.2.2 解析 p_offset (文件偏移量)
二进制数据偏移量： 0x04 - 0x07 (4 字节)
这个字段指示当前程序段在ELF文件内部的起始偏移量（从文件开头算起）。
- 重要性： 加载器使用这个偏移量来找到ELF文件中对应程序段的原始数据。例如，如果要加载一个代码段，加载器会跳转到
e_phoff+p_offset的位置开始读取指令。
2.2.3 解析 p_vaddr (虚拟地址)
二进制数据偏移量： 0x08 - 0x0B (4 字节)
这个字段指示当前程序段在虚拟内存中的起始地址。
- 重要性： 对于带有内存管理单元（MMU）的复杂处理器（如ARM Cortex-A系列运行Linux），这是程序段被映射到的虚拟地址。对于不带MMU的简单处理器（如ARM Cortex-M系列，通常是裸机），虚拟地址和物理地址通常是相同的，或者在某些情况下，虚拟地址可以被视为“期望的”加载地址。
2.2.4 解析 p_paddr (物理地址)
二进制数据偏移量： 0x0C - 0x0F (4 字节)
这个字段指示当前程序段在物理内存中的起始地址。
- 重要性： 在许多嵌入式系统中，特别是裸机环境，
p_vaddr和p_paddr的值通常是相同的，因为没有MMU进行地址转换。p_paddr是实际的RAM或Flash地址，加载器会把数据复制到这个物理地址。当程序被烧录到Flash中时，这个地址就是Flash的起始地址。当程序加载到RAM中执行时，这个地址就是RAM的起始地址。
2.2.5 解析 p_filesz (文件中的大小)
二进制数据偏移量： 0x10 - 0x13 (4 字节)
这个字段指示当前程序段在ELF文件内部所占据的大小，单位是字节。
- 重要性： 加载器会从
p_offset开始，读取p_filesz个字节的数据，并将其复制到内存中。
2.2.6 解析 p_memsz (内存中的大小)
二进制数据偏移量： 0x14 - 0x17 (4 字节)
这个字段指示当前程序段在内存中应该占据的大小，单位是字节。
- 重要性：
p_memsz可以大于p_filesz。这种情况通常发生在包含.bss节的程序段中。.bss节存储的是未初始化的全局变量和静态变量。在ELF文件中，.bss节不占用实际的存储空间，因为它们的值在程序启动时被清零。所以，p_filesz只包含.text和.data等实际在文件中存在的段的大小，而p_memsz会包含.text、.data以及需要清零的.bss段的总大小。
加载器会复制p_filesz字节的数据到内存，然后将接下来的p_memsz - p_filesz字节（如果p_memsz > p_filesz）清零。这个操作对于确保未初始化变量拥有确定值（通常是0）至关重要。
2.2.7 解析 p_flags (权限标志)
二进制数据偏移量： 0x18 - 0x1B (4 字节)
这个字段指示程序段在内存中的访问权限。这些权限通常是位掩码（bitmask）。
| 位 (Bit) | 标志 (C语言定义) | 含义及重要性（嵌入式ARM） |
|---|---|---|
0x00000001 |
PF_X |
可执行 (Executable)：如果设置了此位，表示该段包含可执行代码。例如，.text段将具有此标志。 |
0x00000002 |
PF_W |
可写 (Writable)：如果设置了此位，表示该段包含可写数据。例如，.data段（在RAM中可写）将具有此标志，而.rodata（只读数据）则不会。.bss段也需要可写权限。 |
0x00000004 |
PF_R |
可读 (Readable)：如果设置了此位，表示该段包含可读数据或代码。所有加载到内存的段通常都至少具有可读权限。 |
这些标志的组合表示了该内存区域的访问权限。例如：
PF_R | PF_X(0x5): 可读可执行（通常用于代码段，如.text）。PF_R | PF_W(0x6): 可读可写（通常用于数据段，如.data、.bss）。PF_R(0x4): 只读（通常用于常量数据段，如.rodata）。
虽然在裸机Cortex-M微控制器中，硬件MMU可能不强制执行这些权限，但这些标志对于操作系统加载器或更复杂的嵌入式系统来说仍然是重要的元数据，用于设置内存保护。
2.2.8 解析 p_align (内存对齐)
二进制数据偏移量： 0x1C - 0x1F (4 字节)
这个字段指示程序段在文件和内存中的对齐要求。其值必须是2的幂，例如1、2、4、8、4096等。它表示p_vaddr和p_offset的值必须是p_align的倍数。
- 重要性： 内存对齐对于处理器性能和硬件访问至关重要。例如，ARM处理器通常要求字（Word，4字节）访问是4字节对齐的。如果一个段的起始地址没有正确对齐，可能会导致性能下降甚至硬件异常。
p_align确保了加载器在将段映射到内存时满足这些对齐约束。常见的对齐值是0x1000(4096字节)，这与许多页（Page）大小相匹配，便于操作系统的内存管理。
2.3 程序头表与内存加载过程的实战模拟
现在，让我们结合一个更实际的嵌入式ARM程序，来模拟ELF文件的程序头表是如何被Bootloader解析和加载的。
假设我们有一个稍微复杂一点的裸机ARM程序，包含：
- 启动代码 (
startup.s)：初始化堆栈，跳转到Cmain函数。 - C代码 (
main.c)：定义了一些初始化和未初始化变量，以及一个简单的函数。 - 链接脚本 (
linker.ld)：定义了内存布局。
假设的链接脚本 (linker.ld) 关键部分：
/* linker.ld - 简化版链接脚本示例 */
MEMORY
{
FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 1M /* 假设Flash从0x08000000开始，1MB大小 */
SRAM (rwx) : ORIGIN = 0x20000000, LENGTH = 128K /* 假设SRAM从0x20000000开始，128KB大小 */
}
SECTIONS
{
.isr_vector :
{
. = ALIGN(4);
KEEP(*(.isr_vector)) /* 中断向量表，通常在Flash起始 */
} > FLASH
.text :
{
. = ALIGN(4);
*(.text) /* 代码段 */
*(.text.*) /* 编译后的函数通常在.text.funcName */
*(.rodata) /* 只读数据段，如字符串常量 */
*(.rodata.*)
} > FLASH
.data :
{
. = ALIGN(4);
_sdata = .; /* .data段在RAM中的起始地址 */
*(.data) /* 已初始化数据，从Flash复制到RAM */
*(.data.*)
_edata = .; /* .data段在RAM中的结束地址 */
} > SRAM AT > FLASH /* .data段在运行时在SRAM，但其初始值存储在Flash中 */
.bss :
{
. = ALIGN(4);
_sbss = .; /* .bss段在RAM中的起始地址 */
*(.bss) /* 未初始化数据，运行时清零 */
*(.bss.*)
*(COMMON) /* 通用符号，也放在.bss */
_ebss = .; /* .bss段在RAM中的结束地址 */
} > SRAM /* .bss段只在SRAM中存在，不占用Flash空间 */
.ARM.exidx :
{
*(.ARM.exidx) /* ARM异常处理索引表 */
*(.ARM.exidx.*)
} > FLASH
. = ALIGN(4);
_end = .; /* 程序结束地址，用于堆栈和堆的起始 */
}
模拟生成的ELF文件结构和程序头表条目：
在上述链接脚本的指导下，链接器通常会生成至少两个 PT_LOAD 类型的程序段，以优化加载过程：
-
第一个
PT_LOAD段： 包含所有位于Flash中的代码和只读数据。- 它将包含
.isr_vector、.text、.rodata等节。 - 这个段的
p_vaddr和p_paddr将指向Flash的起始地址（例如0x08000000）。 p_filesz将是所有这些节在文件中占用的大小。p_memsz通常与p_filesz相同，因为这些段不需要额外清零。p_flags将是PF_R | PF_X(可读可执行)。
- 它将包含
-
第二个
PT_LOAD段： 包含需要从Flash复制到RAM的初始化数据 (.data)，以及需要在RAM中清零的未初始化数据 (.bss)。- 这个段的
p_vaddr和p_paddr将指向RAM中的起始地址（例如0x20000000），这是.data节在RAM中的最终位置。 p_offset将指向这个段在ELF文件（Flash）中的原始数据（.data节）的起始位置。p_filesz将是.data节在ELF文件中的大小（即需要从Flash复制到RAM的部分）。p_memsz将是.data节和.bss节的总大小（即在RAM中总共需要占据的空间，其中.bss部分需要清零）。p_flags将是PF_R | PF_W(可读可写)。
- 这个段的
程序头表 (PHT) 示例二进制数据 (概念性，小端序):
假设ELF文件头中 e_phoff 指向 0x34 (52字节)，并且 e_phnum 是 0x0002 (2个条目)。
第一个程序头条目 (Elf32_Phdr) - 位于文件偏移量 0x34：
（对应 Flash 中的代码和只读数据）
01 00 00 00 ; p_type: 0x00000001 (PT_LOAD)
00 00 00 00 ; p_offset: 0x00000000 (从文件开头加载)
00 00 00 08 ; p_vaddr: 0x08000000 (虚拟地址：Flash起始)
00 00 00 08 ; p_paddr: 0x08000000 (物理地址：Flash起始)
A0 1F 00 00 ; p_filesz: 0x00001FA0 (假设代码+只读数据大小为8KB)
A0 1F 00 00 ; p_memsz: 0x00001FA0 (内存中大小与文件大小相同)
05 00 00 00 ; p_flags: 0x00000005 (PF_R | PF_X，可读可执行)
00 10 00 00 ; p_align: 0x00001000 (4KB对齐)
第二个程序头条目 (Elf32_Phdr) - 位于文件偏移量 0x34 + 0x20 = 0x54：
（对应 RAM 中的初始化数据和未初始化数据）
01 00 00 00 ; p_type: 0x00000001 (PT_LOAD)
A0 1F 00 00 ; p_offset: 0x00001FA0 (在ELF文件中的偏移量，紧接在第一个LOAD段之后)
00 00 00 20 ; p_vaddr: 0x20000000 (虚拟地址：SRAM起始)
00 00 00 20 ; p_paddr: 0x20000000 (物理地址：SRAM起始)
B0 00 00 00 ; p_filesz: 0x000000B0 (假设.data节大小为176字节)
D0 02 00 00 ; p_memsz: 0x000002D0 (假设.data + .bss总大小为720字节)
06 00 00 00 ; p_flags: 0x00000006 (PF_R | PF_W，可读可写)
00 10 00 00 ; p_align: 0x00001000 (4KB对齐)
2.3.1 Bootloader/加载器的工作流程模拟
基于上述程序头表，一个裸机Bootloader或简化的加载器会执行以下步骤：
-
读取ELF文件头：
- 从文件起始（或Flash起始）读取前52字节，解析
e_ident（确认ELF格式、32位、小端序等）、e_entry（程序入口点）、e_phoff（程序头表偏移量）、e_phnum（程序头条目数量）。
- 从文件起始（或Flash起始）读取前52字节，解析
-
遍历程序头表：
- 根据
e_phoff和e_phentsize，跳转到程序头表的起始位置。 - 循环
e_phnum次，每次读取一个Elf32_Phdr结构体。
- 根据
-
处理第一个
PT_LOAD段 (代码和只读数据)：- 识别类型： 读到
p_type为0x00000001(PT_LOAD)。 - 获取源和目标信息：
p_offset(0x00000000): 表示代码段从ELF文件的最开头开始。p_vaddr/p_paddr(0x08000000): 表示代码段应该加载到Flash的0x08000000地址。p_filesz(0x00001FA0): 表示需要从文件（Flash）中读取8KB的数据。p_memsz(0x00001FA0): 表示在内存中也占据8KB。
- 加载操作： 由于这个段的
p_vaddr和p_paddr指向Flash，并且它通常是程序本身的存储位置，Bootloader可能不会“复制”它，而是直接在原地执行。如果是在PC上模拟加载，则会将ELF文件偏移量0x0开始的0x1FA0字节复制到内存地址0x08000000。 - 权限设置： 标记为可读可执行 (
PF_R | PF_X)。
- 识别类型： 读到
-
处理第二个
PT_LOAD段 (初始化数据和未初始化数据)：- 识别类型： 读到
p_type为0x00000001(PT_LOAD)。 - 获取源和目标信息：
p_offset(0x00001FA0): 表示数据段在ELF文件中从8KB偏移处开始。p_vaddr/p_paddr(0x20000000): 表示数据段应该加载到SRAM的0x20000000地址。p_filesz(0x000000B0): 表示需要从文件（Flash）中读取176字节的初始化数据。p_memsz(0x000002D0): 表示在内存中总共占据720字节的空间。
- 加载操作：
- Bootloader会从Flash的
0x08000000 + 0x1FA0地址（即ELF文件中的p_offset位置）开始，读取p_filesz（176）字节的数据。 - 将这176字节的数据复制到SRAM的
0x20000000地址。 - 然后，将SRAM中从
0x20000000 + 176开始，到0x20000000 + p_memsz（即0x20000000 + 720）结束的区域全部清零。这个清零的区域就是.bss段。
- Bootloader会从Flash的
- 权限设置： 标记为可读可写 (
PF_R | PF_W)。
- 识别类型： 读到
-
所有
PT_LOAD段处理完毕后：- 加载器（或Bootloader）会获取ELF文件头中
e_entry指定的用户程序入口点地址（例如0x08000001）。 - 最后，执行一条跳转指令（如ARM汇编的
BX或JMP），将处理器控制权交给用户程序的入口点，程序开始执行。
- 加载器（或Bootloader）会获取ELF文件头中
这个过程完美地诠释了程序头表如何作为加载器的指令清单，指导着ELF文件内容的内存映射和初始化。
2.4 程序段与节的对应关系 (Segments vs. Sections)
理解程序段 (Segments) 和节 (Sections) 之间的区别和联系是深入ELF的关键。
-
节 (Sections): 是链接视图的组成部分。它们是更细粒度的逻辑单元，将代码和数据按类型划分。例如，
.text是可执行指令，.data是已初始化的全局变量，.rodata是只读数据，.bss是未初始化的全局变量，.symtab是符号表，.debug_info是调试信息等。一个ELF文件可以包含很多节。节头表描述了每个节的详细属性。 -
程序段 (Program Segments): 是执行视图的组成部分。它们是加载到内存中的连续内存区域，由一个或多个相关联的节组成。程序头表描述了这些程序段。加载器只关心程序段，不关心其内部的节。多个节可以“合并”到一个程序段中，只要它们具有相似的内存属性（如都可执行，或都可读写）并且在内存中是连续的。
常见的节到程序段的映射方式：
-
代码/只读数据段 (Text Segment):
- 通常包含节：
.text,.rodata,.eh_frame,.init,.fini,.interp等。 p_flags:PF_R | PF_X(可读可执行)。p_filesz==p_memsz。- 加载到Flash或程序存储器中。
- 通常包含节：
-
数据段 (Data Segment):
- 通常包含节：
.data,.bss。 p_flags:PF_R | PF_W(可读可写)。p_filesz<p_memsz(因为.bss不占用文件空间)。.data部分从文件（Flash）加载到RAM。.bss部分在RAM中被清零。
- 通常包含节：
为何需要两种视图？
- 链接视图 (节)： 提供给链接器和调试器更细粒度的信息，以便它们能够理解程序的各个组成部分，进行符号解析、重定位、调试等操作。例如，调试器需要知道某个变量属于哪个节，其类型是什么。
- 执行视图 (程序段)： 简化了加载器的任务。加载器不需要知道每个具体节的含义，它只需要知道哪些连续的字节块需要从文件加载到内存的哪个位置，以及加载后的内存区域的权限。这提高了加载效率。
在嵌入式ARM裸机开发中，尤其是在没有复杂操作系统的情况下，我们编写链接脚本时，本质上就是在定义这些程序段的布局。链接脚本通过PHDRS命令或AT关键字，指示链接器如何将不同的节归类到程序段中，以及这些程序段在内存和文件中的起始地址。
例如，在上面的链接脚本中：
.data :
{
/* ... */
} > SRAM AT > FLASH
这行代码明确告诉链接器：.data节运行时在SRAM区域（这是p_paddr/p_vaddr），但其初始内容（p_filesz）存储在FLASH区域（这是p_offset指向的地方）。这直接对应了PT_LOAD段的p_vaddr、p_paddr、p_offset和p_filesz的定义。
2.5 ARM体系结构特定的程序段处理
虽然ELF格式是通用的，但在ARM体系结构中，尤其是在嵌入式领域，有一些特有的考量会影响程序段的处理。
2.5.1 Thumb指令集与地址的最低位
在第一章我们提到，ARM Cortex-M处理器主要使用Thumb指令集。当ELF文件头中的e_entry地址的最低位（LSB）设置为1时，表示程序将以Thumb模式开始执行。例如，0x08000001意味着实际的入口地址是0x08000000，并且处理器将在Thumb状态下开始执行。
这个约定也适用于程序段的p_vaddr和p_paddr。如果一个PT_LOAD段包含Thumb代码，其对应的虚拟/物理地址也可能在最低位设置为1，尽管这在内存映射时通常会被硬件忽略，因为内存地址是字节寻址的，不会是奇数。这个最低位更多是作为一种“元信息”传递给处理器或模拟器，指示执行模式。
2.5.2 向量表在程序段中的位置
对于ARM Cortex-M微控制器，中断向量表（ISR Vector Table）是程序启动时最先被处理器读取的重要结构。它包含了堆栈指针的初始值和各种异常（包括复位、NMI、硬故障等）的处理函数地址。中断向量表通常被放置在Flash的起始地址（0x08000000）。
在ELF文件中，中断向量表通常是一个独立的节（如.isr_vector或由链接脚本指定），并且这个节会作为第一个PT_LOAD程序段的一部分，一同被加载到Flash中。确保这个段的p_vaddr和p_paddr与处理器的复位向量地址匹配至关重要。
2.5.3 闪存（Flash）与内存（RAM）的差异处理
在嵌入式系统中，Flash是非易失性存储器，用于存储程序代码和常量数据。RAM是易失性存储器，用于存储运行时变量、堆栈和堆。
-
Flash加载段： 通常一个
PT_LOAD段会映射到Flash区域，包含程序的代码（.text）和只读数据（.rodata）。这些数据在烧录时直接写入Flash，程序运行时直接从Flash读取执行，无需从别处复制。因此，p_offset、p_vaddr、p_paddr通常会一致（相对Flash基地址），且p_filesz == p_memsz。 -
RAM加载段： 另一个
PT_LOAD段会映射到RAM区域，包含初始化数据（.data）和未初始化数据（.bss）。.data的初始值存储在ELF文件的Flash区域，加载时从p_offset处复制p_filesz字节到p_paddr（RAM）。.bss在ELF文件中不占用空间，但在内存中需要p_memsz - p_filesz字节的连续区域并清零。
Bootloader必须根据程序头表中这两个不同PT_LOAD段的信息，分别执行不同的加载策略：对Flash段进行就地执行（或者烧录），对RAM段进行复制和清零。
2.6 深入理解加载器与虚拟地址空间
尽管许多嵌入式ARM Cortex-M微控制器没有MMU，因此p_vaddr和p_paddr通常相同，但理解“虚拟地址”的概念仍然是有益的。
在更高级的ARM处理器（如Cortex-A系列）上运行Linux等操作系统时，MMU会引入虚拟内存的概念。每个进程都有自己的独立虚拟地址空间。ELF文件的p_vaddr字段就变得非常重要，它定义了程序段在这个虚拟地址空间中的映射位置。操作系统内核的加载器会负责配置MMU，将程序的虚拟地址映射到物理RAM地址。
即使在没有MMU的裸机系统中，p_vaddr也代表了链接器所期望的内存布局。它是一个“抽象的”地址，即使它恰好与物理地址相同。这种抽象性使得ELF文件格式具有更强的通用性和可移植性，能够适应从简单裸机到复杂操作系统的各种环境。
为什么要理解这些？
- 自定义链接脚本： 当您需要为特定的嵌入式硬件定制内存布局时，深入理解
p_vaddr、p_paddr、p_offset和p_align之间的关系，以及它们如何影响PT_LOAD段的生成，是编写高效链接脚本的关键。 - 调试问题： 当程序在启动时崩溃，或者变量值异常时，能够通过检查ELF文件的程序头表，确认代码和数据是否被正确加载到预期的内存地址，是诊断问题的有效方法。
- Bootloader开发： 如果您需要开发自己的Bootloader，那么精确解析ELF程序头表并执行内存加载操作是其核心功能之一。
2.7 实战代码案例：使用Python解析ELF程序头表
为了更好地理解ELF文件头和程序头表的二进制结构，我们现在将编写一段原创的Python代码，用于解析一个简单的32位ELF文件的头部和程序头表。这段代码是完全原创，不依赖任何第三方ELF解析库，目的是让您从最底层亲手解析二进制数据。
注意： Python的struct模块用于处理二进制数据。小端序通常用<表示。
import struct # 导入struct模块，用于处理二进制数据
def parse_elf_header(f): # 定义一个函数，用于解析ELF文件头
"""
解析ELF文件的头部信息。
f: 文件对象，已打开并处于二进制读取模式。
"""
elf_header_size = 52 # 定义ELF文件头的大小，32位ELF文件头通常为52字节
# 读取ELF文件头的前52个字节
header_bytes = f.read(elf_header_size) # 从文件当前位置读取指定数量的字节
if len(header_bytes) < elf_header_size: # 检查是否成功读取了足够的字节
print("错误：文件太小，无法读取完整的ELF文件头。") # 打印错误信息
return None # 返回None表示解析失败
# 解析e_ident (ELF Identification)
e_ident = header_bytes[0:16] # 提取e_ident字段，前16个字节
magic_number = e_ident[0:4] # 提取魔数，e_ident的前4个字节
if magic_number != b'\x7fELF': # 检查魔数是否为b'\x7fELF'
print(f"错误：不是有效的ELF文件，魔数是 {
magic_number.hex()}") # 打印错误信息，显示实际的魔数
return None # 返回None表示解析失败
file_class = e_ident[4] # 提取文件位数，e_ident的第5个字节
data_encoding = e_ident[5] # 提取数据编码（字节序），e_ident的第6个字节
# 根据数据编码确定字节序
if data_encoding == 1: # 如果数据编码是1，表示小端序
endian_char = '<' # struct模块中使用'<'表示小端序
print("ELF文件字节序：小端序") # 打印字节序信息
elif data_encoding == 2: # 如果数据编码是2，表示大端序
endian_char = '>' # struct模块中使用'>'表示大端序
print("ELF文件字节序：大端序") # 打印字节序信息
else: # 其他值表示未知或无效
print("错误：未知的ELF数据编码。") # 打印错误信息
return None # 返回None表示解析失败
# 根据文件位数确定ELF类型（32位或64位）
if file_class == 1: # 如果文件位数是1，表示32位ELF
print("ELF文件类型：32位") # 打印文件类型信息
elif file_class == 2: # 如果文件位数是2，表示64位ELF
print("ELF文件类型：64位") # 打印文件类型信息
else: # 其他值表示未知或无效
print("错误：未知的ELF文件位数。") # 打印错误信息
return None # 返回None表示解析失败
# 解析ELF文件头中的其他字段
# struct.unpack(format, buffer) 根据格式字符串解析字节缓冲区
# H: unsigned short (2 bytes), I: unsigned int (4 bytes)
(
e_type, # 2字节：文件类型
e_machine, # 2字节：目标机器架构
e_version, # 4字节：ELF版本
e_entry, # 4字节：程序入口点虚拟地址
e_phoff, # 4字节：程序头表在文件中的偏移量
e_shoff, # 4字节：节头表在文件中的偏移量
e_flags, # 4字节：处理器特定的标志
e_ehsize, # 2字节：ELF文件头本身的大小
e_phentsize, # 2字节：程序头表中每个条目的大小
e_phnum, # 2字节：程序头表中条目的数量
e_shentsize, # 2字节：节头表中每个条目的大小
e_shnum, # 2字节：节头表中条目的数量
e_shstrndx # 2字节：节字符串表在节头表中的索引
) = struct.unpack(endian_char + 'HHIIIIIHHHHHH', header_bytes[16:]) # 使用struct.unpack解析剩余的字节，格式字符串为'HHIIIIIHHHHHH'，并根据endian_char确定字节序
print("\n--- ELF文件头信息 ---") # 打印分隔线和标题
print(f"文件类型 (e_type): 0x{
e_type:04X} ({
get_elf_type_name(e_type)})") # 打印文件类型，十六进制格式，并转换为名称
print(f"机器架构 (e_machine): 0x{
e_machine:04X} ({
get_elf_machine_name(e_machine)})") # 打印机器架构，十六进制格式，并转换为名称
print(f"入口点地址 (e_entry): 0x{
e_entry:08X}") # 打印入口点地址，十六进制格式
print(f"程序头表偏移 (e_phoff): 0x{
e_phoff:08X}") # 打印程序头表偏移量，十六进制格式
print(f"节头表偏移 (e_shoff): 0x{
e_shoff:08X}") # 打印节头表偏移量，十六进制格式
print(f"处理器标志 (e_flags): 0x{
e_flags:08X}") # 打印处理器标志，十六进制格式
print(f"ELF头大小 (e_ehsize): {
e_ehsize} 字节") # 打印ELF头大小
print(f"程序头条目大小 (e_phentsize): {
e_phentsize} 字节") # 打印程序头条目大小
print(f"程序头条目数量 (e_phnum): {
e_phnum}") # 打印程序头条目数量
print(f"节头条目大小 (e_shentsize): {
e_shentsize} 字节") # 打印节头条目大小
print(f"节头条目数量 (e_shnum): {
e_shnum}") # 打印节头条目数量
print(f"节字符串表索引 (e_shstrndx): {
e_shstrndx}") # 打印节字符串表索引
return {
# 返回一个字典，包含解析后的ELF头信息
'endian_char': endian_char, # 字节序字符
'e_phoff': e_phoff, # 程序头表偏移
'e_phentsize': e_phentsize, # 程序头条目大小
'e_phnum': e_phnum # 程序头条目数量
}
def parse_program_headers(f, elf_header_info): # 定义一个函数，用于解析程序头表
"""
解析ELF文件的程序头表信息。
f: 文件对象。
elf_header_info: 从parse_elf_header返回的字典，包含ELF头信息。
"""
endian_char = elf_header_info['endian_char'] # 从ELF头信息中获取字节序字符
phoff = elf_header_info['e_phoff'] # 获取程序头表偏移量
phentsize = elf_header_info['e_phentsize'] # 获取程序头条目大小
phnum = elf_header_info['e_phnum'] # 获取程序头条目数量
print("\n--- 程序头表信息 ---") # 打印分隔线和标题
if phnum == 0: # 如果程序头条目数量为0
print("没有可用的程序头条目。") # 打印信息
return # 返回
f.seek(phoff) # 将文件指针移动到程序头表的起始偏移量
for i in range(phnum): # 遍历每个程序头条目
print(f"\n--- 程序头条目 {
i+1} ---") # 打印当前条目编号
phdr_bytes = f.read(phentsize) # 读取当前程序头条目的字节
if len(phdr_bytes) < phentsize: # 检查是否成功读取了足够的字节
print(f"错误：无法读取完整的程序头条目 {
i+1}。") # 打印错误信息
break # 退出循环
# 解析Elf32_Phdr结构体
# I: unsigned int (4 bytes)
(
p_type, # 4字节：段类型
p_offset, # 4字节：段在文件中的偏移量
p_vaddr, # 4字节：段在虚拟内存中的地址
p_paddr, # 4字节：段在物理内存中的地址
p_filesz, # 4字节：段在文件中的大小
p_memsz, # 4字节：段在内存中的大小
p_flags, # 4字节：段的权限标志
p_align # 4字节：段在内存和文件中对齐要求
) = struct.unpack(endian_char + 'IIIIIIII', phdr_bytes) # 使用struct.unpack解析字节，格式字符串为'IIIIIIII'
print(f"段类型 (p_type): 0x{
p_type:08X} ({
get_program_segment_type_name(p_type)})") # 打印段类型，并转换为名称
print(f"文件偏移 (p_offset): 0x{
p_offset:08X}") # 打印文件偏移量
print(f"虚拟地址 (p_vaddr): 0x{
p_vaddr:08X}") # 打印虚拟地址
print(f"物理地址 (p_paddr): 0x{
p_paddr:08X}") # 打印物理地址
print(f"文件大小 (p_filesz): {
p_filesz} 字节") # 打印文件大小
print(f"内存大小 (p_memsz): {
p_memsz} 字节") # 打印内存大小
flags_str = [] # 初始化权限标志字符串列表
if p_flags & 0x4: # 检查PF_R位是否设置
flags_str.append("PF_R (可读)") # 添加可读标志
if p_flags & 0x2: # 检查PF_W位是否设置
flags_str.append("PF_W (可写)") # 添加可写标志
if p_flags & 0x1: # 检查PF_X位是否设置
flags_str.append("PF_X (可执行)") # 添加可执行标志
print(f"权限标志 (p_flags): 0x{
p_flags:08X} ({
' | '.join(flags_str)})") # 打印权限标志，并组合成字符串
print(f"对齐要求 (p_align): {
p_align} 字节") # 打印对齐要求
# 辅助函数，将ELF类型码转换为可读名称
def get_elf_type_name(e_type): # 定义一个辅助函数，将ELF文件类型代码转换为可读名称
types = {
# 定义一个字典，映射类型代码到名称
0x0001: "ET_REL (可重定位文件)", # 可重定位文件
0x0002: "ET_EXEC (可执行文件)", # 可执行文件
0x0003: "ET_DYN (共享对象文件)", # 共享对象文件
0x0004: "ET_CORE (核心转储文件)" # 核心转储文件
}
return types.get(e_type, "未知类型") # 返回对应的名称，如果不存在则返回“未知类型”
# 辅助函数，将ELF机器架构码转换为可读名称
def get_elf_machine_name(e_machine): # 定义一个辅助函数，将ELF机器架构代码转换为可读名称
machines = {
# 定义一个字典，映射机器架构代码到名称
0x0008: "EM_MIPS", # MIPS架构
0x0028: "EM_ARM", # ARM架构
0x003E: "EM_X86_64", # AMD x86-64架构
0x00B7: "EM_AARCH64" # ARM AArch64（64位ARM）架构
}
return machines.get(e_machine, "未知架构") # 返回对应的名称，如果不存在则返回“未知架构”
# 辅助函数，将程序段类型码转换为可读名称
def get_program_segment_type_name(p_type): # 定义一个辅助函数，将程序段类型代码转换为可读名称
types = {
# 定义一个字典，映射程序段类型代码到名称
0x00000000: "PT_NULL (空)", # 空类型
0x00000001: "PT_LOAD (可加载)", # 可加载段
0x00000002: "PT_DYNAMIC (动态链接信息)", # 动态链接信息
0x00000003: "PT_INTERP (解释器路径)", # 解释器路径
0x00000004: "PT_NOTE (辅助信息)", # 辅助信息
0x00000005: "PT_SHLIB (保留)", # 保留
0x00000006: "PT_PHDR (程序头表本身)", # 程序头表本身
0x00000007: "PT_TLS (线程本地存储)" # 线程本地存储
}
# 检查操作系统和处理器特定范围的类型
if 0x60000000 <= p_type <= 0x6FFFFFFF: # 如果类型在操作系统特定范围低位到高位之间
return "PT_LOOS 到 PT_HIOS (操作系统特定)" # 返回操作系统特定类型名称
if 0x70000000 <= p_type <= 0x7FFFFFFF: # 如果类型在处理器特定范围低位到高位之间
return "PT_LOPROC 到 PT_HIPROC (处理器特定)" # 返回处理器特定类型名称
return types.get(p_type, "未知类型") # 返回对应的名称，如果不存在则返回“未知类型”
# 主执行逻辑
if __name__ == "__main__": # 当脚本作为主程序执行时
elf_file_path = "minimal_arm.elf" # 定义要解析的ELF文件路径
# 请将 'minimal_arm.elf' 替换为您实际的ARM ELF文件路径
# 例如：如果您编译了一个STM32的裸机程序，其输出可能是 'project.elf'
try: # 尝试执行文件操作，捕获可能发生的异常
with open(elf_file_path, 'rb') as f: # 以二进制读取模式打开ELF文件
print(f"正在解析ELF文件：{
elf_file_path}") # 打印正在解析的文件路径
elf_header_info = parse_elf_header(f) # 调用函数解析ELF文件头
if elf_header_info: # 如果ELF文件头解析成功
parse_program_headers(f, elf_header_info) # 调用函数解析程序头表
except FileNotFoundError: # 捕获文件未找到的异常
print(f"错误：文件 '{
elf_file_path}' 未找到。请确保文件存在于正确路径。") # 打印文件未找到的错误信息
except Exception as e: # 捕获其他所有异常
print(f"发生了一个错误：{
e}") # 打印发生的错误信息
如何使用上述Python代码：
- 保存代码： 将上述Python代码保存为一个
.py文件，例如elf_parser.py。 - 准备ELF文件： 您需要一个实际的ARM ELF文件。如果您正在进行嵌入式ARM开发，您的项目编译后会生成一个
.elf文件。您可以将该文件复制到与elf_parser.py相同的目录下，或者修改elf_file_path变量指向您的ELF文件的绝对路径。- 如果您没有现成的ARM ELF文件，可以尝试使用
arm-none-eabi-gcc编译一个简单的C或汇编程序来生成。例如，编译第一章提到的minimal_arm.s：
或者，最简单的方式是编译一个简单的C程序（需要一个稍微完整的链接脚本），例如：# 假设你已经安装了arm-none-eabi-gcc工具链 # 编译汇编文件为目标文件 arm-none-eabi-as -mcpu=cortex-m0 -mthumb -o minimal_arm.o minimal_arm.s # 链接目标文件生成ELF可执行文件 # 注意：这里需要一个简单的链接脚本。为了简化，你可以先尝试一个非常简单的C程序， # 或者使用一个假定的链接命令，它可能生成一个仅包含.text段的ELF # 这是一个非常简化的链接脚本，仅用于生成最简单的ELF文件 # linker_script_simple.ld 内容: # ENTRY(_start) # SECTIONS { # .text : { *(.text) } > 0x08000000 # } # arm-none-eabi-ld -Tlinker_script_simple.ld -o minimal_arm.elf minimal_arm.o
编译命令大致如下（具体取决于您的开发环境和MCU）：// main.c volatile int global_var_init = 123; volatile int global_var_uninit; int main() { global_var_uninit = global_var_init; while(1); return 0; }
请确保您编译生成的是arm-none-eabi-gcc -mcpu=cortex-m4 -mthumb -specs=nosys.specs -g -T linker_script.ld -o my_program.elf main.c startup_stm32f4xx.s # 假设有启动文件和链接脚本ET_EXEC类型的ELF文件，这样它会包含程序头表。
- 如果您没有现成的ARM ELF文件，可以尝试使用
- 运行Python脚本： 在命令行中运行
python elf_parser.py。
您将看到脚本输出的ELF文件头和程序头表的详细解析信息，这些信息将与我们之前讨论的理论知识完美对应，帮助您直观地理解ELF文件的二进制结构。
第三章：ELF文件格式深度剖析——节头表与链接、调试机制
3.1 节头表 (Section Header Table, SHT) 的重要性与视图切换
在第二章中，我们详细探讨了程序头表 (Program Header Table, PHT)，它为加载器（如Bootloader或操作系统加载器）提供了一种执行视图，描述了如何将ELF文件中的代码和数据映射到内存中以供执行。PHT关注的是“段”（Segments），这些段是加载到内存中的连续区域。
然而，ELF文件内部还有另一种非常重要的组织形式，即链接视图。这种视图主要服务于链接器和调试器。它将ELF文件内容划分为更细粒度的、逻辑上独立的单元，称为节 (Sections)。节头表 (Section Header Table, SHT) 正是这种视图的核心，它详细描述了文件中所有节的属性、位置和大小。
节头表的核心作用在于：
- 链接器的“蓝图”： 当链接器将多个目标文件（
.o，ET_REL类型ELF）和库文件组合成一个可执行文件（ET_EXEC类型ELF）时，它需要知道每个目标文件中有哪些代码、哪些数据、哪些是可写、哪些是只读、哪些是需要重定位等等。节头表提供了这些信息，使得链接器能够正确地合并相同类型的节，解析符号引用，并最终生成完整的内存布局。 - 调试器的“地图”： 调试器（如GDB）需要精确地知道变量、函数、指令等在内存中的具体位置，以及它们所属的类型。调试信息（如DWARF格式）通常存储在特定的节中。节头表帮助调试器找到这些调试节，从而能够进行源代码级调试、变量查看、断点设置等。
- 文件结构分析： 对于开发者来说，分析ELF文件的节头表可以帮助我们深入理解程序在编译链接后的内部结构，例如代码占用了多少空间，初始化数据有多少，未初始化数据有多少，以及各种调试信息、符号表等的大小和位置。这对于优化程序大小、内存使用和诊断链接错误非常有帮助。
与程序头表不同，节头表及其描述的大多数节（特别是那些只用于链接和调试的节，如符号表、字符串表、调试信息）在程序运行时通常不会被加载到目标设备的内存中。它们是ELF文件作为“容器”的一部分，主要在开发、编译和链接阶段发挥作用。
回想一下ELF文件头中的 e_shoff、e_shentsize 和 e_shnum 字段：
e_shoff: 指向节头表在文件中的起始偏移量。e_shentsize: 每个Elf32_Shdr结构体的大小（通常是40字节）。e_shnum: 节头表中的条目数量。e_shstrndx: 指向节字符串表的索引，节字符串表存储了所有节的名称。
通过这些信息，工具链和分析器可以精确地定位并遍历节头表中的每一个节描述符。
3.2 Elf32_Shdr 结构体详解
节头表由一系列结构体组成，每个结构体描述一个节。对于32位ELF文件，这个结构体被称为 Elf32_Shdr。其C语言定义大致如下：
typedef struct {
Elf32_Word sh_name; // 4字节：节名称在节字符串表中的偏移量
Elf32_Word sh_type; // 4字节：节的类型
Elf32_Word sh_flags; // 4字节：节的属性标志
Elf32_Addr sh_addr; // 4字节：节在内存中的虚拟地址（如果节需要加载到内存）
Elf32_Off sh_offset; // 4字节：节在文件中的偏移量
Elf32_Word sh_size; // 4字节：节的大小（字节）
Elf32_Word sh_link; // 4字节：与其他节的链接信息
Elf32_Word sh_info; // 4字节：节的附加信息
Elf32_Word sh_addralign; // 4字节：节的内存对齐要求
Elf32_Word sh_entsize; // 4字节：如果节包含固定大小的条目，则为每个条目的大小
} Elf32_Shdr;
与程序头表类似，Elf32_Shdr的每个字段都提供了关于其所描述节的详细元数据。现在，让我们逐个字段进行深入解析。
3.2.1 详细解析 sh_name (节名称偏移)
二进制数据偏移量： 0x00 - 0x03 (4 字节)
这个字段不是节的实际名称字符串，而是该节的名称在节字符串表 (.shstrtab) 中的字节偏移量。节字符串表是一个特殊的节（通常名称是.shstrtab），它包含了文件中所有节的名称字符串。
- 重要性： 链接器、调试器以及任何ELF分析工具，都需要先读取节字符串表，然后根据
sh_name提供的偏移量，在节字符串表中查找对应的字符串，从而获取节的实际名称（例如，.text、.data、.bss、.symtab等）。
3.2.2 详细解析 sh_type (节类型)
二进制数据偏移量： 0x04 - 0x07 (4 字节)
这个字段指示节的类型，它告诉链接器或调试器这个节中包含什么样的数据。这是节头表中最重要的字段之一。
| 值 (HEX) | 类型 (C语言定义) | 含义及重要性（嵌入式ARM） |
|---|---|---|
0x00000000 |
SHT_NULL |
空节 (Null section)：表示该节头条目未使用。通常用于填充或作为列表的终止符。 |
0x00000001 |
SHT_PROGBITS |
程序数据 (Program data)：该节包含程序定义的信息。这是最常见的节类型，用于存放程序的代码 (.text)、已初始化的数据 (.data)、只读数据 (.rodata) 等。对于嵌入式开发，代码和初始化数据通常属于此类型。 |
0x00000002 |
SHT_SYMTAB |
符号表 (Symbol table)：该节包含链接器和调试器使用的符号定义和引用。例如，函数名、全局变量名等。调试时查找符号的关键。 |
0x00000003 |
SHT_STRTAB |
字符串表 (String table)：该节包含以空字符结尾的字符串序列。通常与符号表 (SHT_SYMTAB) 和节头表 (SHT_SHSTRTAB) 配合使用，存储符号名或节名。 |
0x00000004 |
SHT_RELA |
带附加的重定位表 (Relocation entries with explicit addends)：该节包含重定位条目。每个条目都指定了一个需要修正的位置以及如何修正它。带附加的重定位条目包含显式的加数，在目标文件链接时使用。在目标文件（.o文件）中非常常见，用于解决未解析的符号引用。 |
0x00000005 |
SHT_HASH |
哈希表 (Hash table)：用于动态链接的符号哈希表。在嵌入式Linux等动态链接环境中使用，裸机通常不涉及。 |
0x00000006 |
SHT_DYNAMIC |
动态链接信息 (Dynamic linking information)：与PT_DYNAMIC程序段类似，用于动态链接。裸机通常不涉及。 |
0x00000007 |
SHT_NOTE |
辅助信息 (Note section)：包含一些辅助信息。 |
0x00000008 |
SHT_NOBITS |
无数据的节 (No data)：该节在文件中不占用空间，但运行时需要分配内存。最典型的例子是**.bss节**，用于存放未初始化的全局变量和静态变量。链接器会确保在程序启动时，此内存区域被清零。 |
0x00000009 |
SHT_REL |
重定位表 (Relocation entries)：类似于SHT_RELA，但不包含显式的加数。 |
0x0000000A |
SHT_SHLIB |
保留 (Reserved)。 |
0x0000000B |
SHT_DYNSYM |
动态链接符号表 (Dynamic linker symbol table)：用于动态链接。 |
0x0000000E |
SHT_INIT_ARRAY |
初始化函数指针数组 (Array of constructors)：存放构造函数指针数组，在main函数之前执行。 |
0x0000000F |
SHT_FINI_ARRAY |
终止函数指针数组 (Array of destructors)：存放析构函数指针数组，在程序退出时执行。 |
0x00000010 |
SHT_PREINIT_ARRAY |
预初始化函数指针数组 (Array of pre-constructors)：在SHT_INIT_ARRAY之前执行。 |
0x00000011 |
SHT_GROUP |
节组 (Section group)：将多个节组合在一起。 |
0x00000012 |
SHT_SYMTAB_SHNDX |
符号表节索引扩展 (Extended symbol table section index)：用于大型符号表。 |
0x60000000 |
SHT_LOOS |
操作系统特定范围低位 (OS-specific range low)：操作系统特定的节类型。 |
0x6FFFFFFF |
SHT_HIOS |
操作系统特定范围高位 (OS-specific range high)。 |
0x70000000 |
SHT_LOPROC |
处理器特定范围低位 (Processor-specific range low)：处理器特定的节类型。对于ARM，例如SHT_ARM_ATTRIBUTES（0x70000003）用于存储ARM体系结构的ABI属性。 |
0x7FFFFFFF |
SHT_HIPROC |
处理器特定范围高位 (Processor-specific range high)。 |
对于嵌入式ARM开发，您需要重点关注以下节类型：
SHT_PROGBITS:.text,.rodata,.data,.isr_vector等。SHT_NOBITS:.bss。SHT_SYMTAB:.symtab。SHT_STRTAB:.strtab,.shstrtab。SHT_RELA/SHT_REL: 重定位节，在目标文件（.o）中非常常见。
3.2.3 详细解析 sh_flags (节属性标志)
二进制数据偏移量： 0x08 - 0x0B (4 字节)
这个字段是一个位掩码，表示节的各种属性。这些标志指示了节在内存中的行为和特征。
| 位 (Bit) | 标志 (C语言定义) | 含义及重要性（嵌入式ARM） |
|---|---|---|
0x00000001 |
SHF_WRITE |
可写 (Writable)：如果设置了此位，表示该节在进程虚拟地址空间中是可写的。例如，.data和.bss节通常会设置此标志。 |
0x00000002 |
SHF_ALLOC |
需要分配内存 (Allocatable)：如果设置了此位，表示该节在程序运行时需要加载到内存中。.text、.data、.bss等运行时需要的节都会设置此标志。而.symtab、.debug_info等调试信息节则不会设置此标志，因为它们不需要加载到目标设备RAM中。 |
0x00000004 |
SHF_EXECINSTR |
包含可执行指令 (Executable instructions)：如果设置了此位，表示该节包含处理器可执行的指令。例如，.text节会设置此标志。 |
0x00000010 |
SHF_MERGE |
可合并 (Mergeable)：如果设置了此位，表示该节可以与其他具有相同类型和标志的节合并。例如，一些字符串常量池可能会使用此标志。 |
0x00000020 |
SHF_STRINGS |
包含空终止字符串 (Contains null-terminated strings)：如果设置了此位，表示该节包含以空字符结尾的字符串。通常用于字符串表。 |
0x00000040 |
SHF_INFO_LINK |
sh_info字段包含节索引 (sh_info holds a section index)：指示sh_info字段包含一个节索引而不是其他信息。 |
0x00000080 |
SHF_LINK_ORDER |
链接顺序依赖 (Preserve order after combining)：指示链接器在合并此节时应保留其顺序。 |
0x00000100 |
SHF_OS_NONCONFORMING |
操作系统特定非标准 (OS-specific non-conforming)：表示该节的语义在操作系统之间可能不兼容。 |
0x00000200 |
SHF_GROUP |
节组成员 (Section is member of a group)：表示该节是某个节组的成员。 |
0x00000400 |
SHF_TLS |
线程本地存储 (Thread-local storage)：表示该节包含线程本地存储数据。 |
0xF0000000 |
SHF_MASKOS |
操作系统特定掩码 (Mask for operating system specific flags)。 |
0x0F000000 |
SHF_MASKPROC |
处理器特定掩码 (Mask for processor specific flags)。 |
0x04000000 |
SHF_ARM_UNALIGNED |
ARM特定：非对齐访问 (ARM-specific: Unaligned access permitted)：如果设置了此位，表示该节允许非对齐访问。这对于某些ARM处理器和数据类型可能很重要，因为它影响了内存访问的效率和正确性。 |
0x08000000 |
SHF_ARM_PURECODE |
ARM特定：纯代码 (ARM-specific: Pure code)：指示该节只包含纯代码，不包含数据。 |
在嵌入式开发中，SHF_ALLOC、SHF_WRITE和SHF_EXECINSTR是最重要的标志。 它们直接影响到链接器如何将节合并到程序段中，以及Bootloader如何处理内存映射。
SHF_ALLOC: 决定了节是否最终成为PT_LOAD程序段的一部分并加载到内存。SHF_WRITE: 决定了节所在的内存区域是否可写，这对应于PT_LOAD段的PF_W权限。SHF_EXECINSTR: 决定了节所在的内存区域是否可执行，这对应于PT_LOAD段的PF_X权限。
3.2.4 详细解析 sh_addr (虚拟地址)
二进制数据偏移量： 0x0C - 0x0F (4 字节)
如果该节在程序的虚拟地址空间中占用内存（即SHF_ALLOC标志已设置），则此字段给出该节的虚拟地址。否则，此字段为零。
- 重要性： 对于运行时需要的节（如
.text,.data,.bss），sh_addr就是它们在内存中的预期起始地址。这个地址是由链接器根据链接脚本计算出来的。调试器会使用这个地址来定位内存中的代码和数据。
3.2.5 详细解析 sh_offset (文件偏移量)
二进制数据偏移量： 0x10 - 0x13 (4 字节)
这个字段指示该节在ELF文件内部的起始偏移量（从文件开头算起）。
- 重要性： 对于
SHT_PROGBITS类型的节，sh_offset指向其在文件中的实际数据。SHT_NOBITS类型的节（如.bss）的sh_offset没有意义，因为它们在文件中不占用空间。
3.2.6 详细解析 sh_size (节大小)
二进制数据偏移量： 0x14 - 0x17 (4 字节)
这个字段指示节的大小，单位是字节。
- 重要性： 对于
SHT_PROGBITS类型的节，sh_size是它在文件中和内存中都占用的大小。对于SHT_NOBITS类型的节（如.bss），sh_size是它在内存中需要分配的大小。这个字段是链接器和调试器计算内存布局和查找信息的重要依据。
3.2.7 详细解析 sh_link (链接信息)
二进制数据偏移量： 0x18 - 0x1B (4 字节)
这个字段的值取决于sh_type。它通常用于将一个节与其他节关联起来。
- 如果
sh_type是SHT_SYMTAB，sh_link是其关联的字符串表（通常是.strtab）的节索引。 - 如果
sh_type是SHT_HASH或重定位节（SHT_REL/SHT_RELA），sh_link是其关联的符号表（通常是.dynsym或.symtab）的节索引。 - 对于其他类型，其含义特定于节。
3.2.8 详细解析 sh_info (附加信息)
二进制数据偏移量： 0x1C - 0x1F (4 字节)
这个字段的值也取决于sh_type，提供附加信息。
- 如果
sh_type是SHT_SYMTAB，sh_info是本地符号（Local Symbols）的索引加一。 - 如果
sh_type是重定位节（SHT_REL/SHT_RELA），sh_info是要重定位的节的节索引。 - 对于
SHT_GROUP，sh_info是组中第一个符号的索引。
3.2.9 详细解析 sh_addralign (地址对齐)
二进制数据偏移量： 0x20 - 0x23 (4 字节)
这个字段指示节在内存中的地址对齐要求。其值必须是2的幂，例如1、2、4、8、16等。节的sh_addr必须是这个值的倍数。
- 重要性： 编译器和链接器会确保节满足其对齐要求，以优化处理器访问效率。例如，一个包含
double类型变量的节可能需要8字节对齐。对于指令，通常需要4字节对齐。
3.2.10 详细解析 sh_entsize (条目大小)
二进制数据偏移量： 0x24 - 0x27 (4 字节)
如果节包含固定大小的条目（例如，符号表中的每个符号条目都是固定大小的），则此字段给出每个条目的大小，单位是字节。如果节不包含固定大小的条目，则此字段为零。
- 重要性： 对于符号表、重定位表等，
sh_entsize与sh_size结合，可以计算出表中包含的条目数量（sh_size / sh_entsize）。
3.3 节与程序段的协同工作：链接器如何构建加载视图
现在我们已经理解了节和程序段各自的详细结构。是时候更深入地理解它们是如何协同工作的，以及链接器在其中扮演的角色。
回想一下：
- 节 (Sections) 是链接器的输入和输出，它们是更细粒度的逻辑代码/数据块，用于组织源文件的内容。
- 程序段 (Program Segments) 是加载器的输入，它们是ELF文件到内存的宏观映射视图。
链接器在将目标文件和库文件组合成最终的可执行ELF文件时，会执行一个关键的步骤：将相关的节（具有相似属性和内存区域的节）打包成程序段。 这个过程是由链接脚本（如GNU ld 的链接脚本）来指导的。
3.3.1 链接脚本如何定义节到段的映射
链接脚本中的SECTIONS命令和PHDRS命令是定义这种映射的关键。
SECTIONS命令定义了ELF文件中各个节的布局，包括它们的名称、内容、加载地址（LMA, Load Memory Address）和运行时地址（VMA, Virtual Memory Address）。PHDRS命令（可选但常用）定义了程序头表中的程序段，以及哪些节应该包含在哪些程序段中。
示例：一个简化的链接脚本片段
/* 链接脚本片段，展示节与段的映射 */
PHDRS
{
CODE_FLASH PT_LOAD; /* 定义一个名为CODE_FLASH的PT_LOAD程序段 */
DATA_RAM PT_LOAD; /* 定义一个名为DATA_RAM的PT_LOAD程序段 */
}
SECTIONS
{
/* 将中断向量表、代码和只读数据放入CODE_FLASH段 */
.text :
{
KEEP(*(.isr_vector)) /* 中断向量表 */
*(.text) /* 代码 */
*(.rodata) /* 只读数据 */
} > FLASH AT > FLASH : CODE_FLASH /* 放在FLASH区域，加载地址也在FLASH，并归属于CODE_FLASH程序段 */
/* 将已初始化数据和未初始化数据放入DATA_RAM段 */
.data : AT(ADDR(.text) + SIZEOF(.text)) /* .data的加载地址在.text之后，即Flash中代码的后面 */
{
_sdata = .;
*(.data)
_edata = .;
} > SRAM : DATA_RAM /* .data的运行时地址在SRAM中，并归属于DATA_RAM程序段 */
.bss :
{
_sbss = .;
*(.bss)
_ebss = .;
} > SRAM : DATA_RAM /* .bss的运行时地址也在SRAM中，并归属于DATA_RAM程序段 */
}
在上述链接脚本中：
.text、.isr_vector、.rodata等节被归入CODE_FLASH程序段。这些节都具有SHF_ALLOC和SHF_EXECINSTR（如果是代码）或SHF_ALLOC（如果是只读数据）标志，并且它们的加载地址和运行时地址都在Flash中。.data和.bss节被归入DATA_RAM程序段。这些节都具有SHF_ALLOC和SHF_WRITE标志。.data节的原始数据（p_filesz部分）被放置在Flash中紧随.text段之后（由AT(ADDR(.text) + SIZEOF(.text))指定），这对应于PT_LOAD段的p_offset。.data和.bss节的运行时内存区域（p_memsz部分）被放置在SRAM中，这对应于PT_LOAD段的p_vaddr和p_paddr。
链接器如何操作：
- 收集节信息： 链接器从所有输入的
.o文件和库中收集节的详细信息（名称、类型、标志、大小、对齐等）。 - 合并节： 根据链接脚本的规则，链接器将相同类型的节（例如所有
.text节）合并成一个大的输出节。 - 分配地址： 链接器根据链接脚本中定义的内存区域和VMA/LMA规则，为每个输出节分配运行时地址和加载地址。
- 构建程序段： 根据
PHDRS命令，链接器遍历其已知的输出节，并将具有SHF_ALLOC标志且具有相似内存属性的连续节组合成一个或多个PT_LOAD程序段。它会计算每个程序段的p_offset,p_vaddr,p_paddr,p_filesz,p_memsz和p_flags。
因此，节是ELF文件在链接时的内部逻辑划分，而程序段则是链接器为了方便加载器而创建的内存视图的抽象。
3.4 节头表在调试与分析中的实际应用
虽然节头表不直接参与程序执行，但它在开发和调试阶段的重要性不言而喻。
3.4.1 理解程序的内存布局
通过分析节头表，您可以清晰地看到程序中各种代码和数据分别存储在哪里，占用了多少空间。这对于内存受限的嵌入式系统至关重要：
- Flash占用：
SHT_PROGBITS且SHF_ALLOC的节（如.text,.rodata,.data的初始值）的总大小就是程序烧录到Flash中实际占用的大小。 - RAM占用：
SHF_ALLOC的节（.text,.data,.bss）的sh_size总和就是程序在运行时需要占据的RAM大小。特别是.bss段的大小，它直接影响了RAM的使用量。 - 优化： 如果发现某个节（如调试信息或不必要的字符串）占用了过多的Flash空间，可以通过链接器选项将其剥离（strip）或不加载。如果
.bss段过大，可能需要检查未初始化的全局变量使用情况。
示例：arm-none-eabi-size 工具
在ARM交叉编译工具链中，arm-none-eabi-size工具可以解析ELF文件的节头表，并汇总.text（代码）、.data（初始化数据）和.bss（未初始化数据）节的大小，提供一个快速的内存使用概览。
arm-none-eabi-size my_program.elf
输出可能类似：
text data bss dec hex filename
20480 1024 512 22016 5600 my_program.elf
这里：
text是.text节的大小。data是.data节的大小。bss是.bss节的大小。dec和hex是这三部分的总和（十进制和十六进制），表示程序在内存中所需的总RAM空间（假设.text也加载到RAM执行）。
3.4.2 符号表与调试器
SHT_SYMTAB类型的节（通常是.symtab）包含了程序中所有的符号（函数、全局变量、静态变量等）及其地址、类型、大小等信息。
调试器的运作：
当您在GDB等调试器中设置断点、查看变量或单步执行时，调试器会：
- 解析ELF文件： 读取ELF文件头和节头表，找到
.symtab节和.strtab节（字符串表，存储符号名称）。 - 构建符号映射： 从
.symtab中读取符号条目，并结合.strtab获取符号名称，建立符号名称与内存地址的映射。 - 源代码关联： 如果存在调试信息节（如
.debug_info、.debug_line等），调试器还会解析这些节，将机器指令地址与源代码文件和行号关联起来。 - 执行调试命令： 当您输入
b main（在main函数设置断点）时，调试器会查找main符号的地址，然后通知目标硬件（通过JTAG/SWD）在特定地址设置硬件断点。当您查看变量时，调试器会根据符号表的地址去读取内存中的值。
示例：arm-none-eabi-nm 工具
arm-none-eabi-nm工具可以列出ELF文件中的符号，这对于分析程序结构和调试非常有帮助。
arm-none-eabi-nm my_program.elf
输出可能类似：
08000100 T _start # _start函数，在0x08000100地址，类型为T（代码段中的全局符号）
08000200 T main # main函数，在0x08000200地址
20000000 D global_var_init # global_var_init变量，在0x20000000地址，类型为D（已初始化数据段中的全局符号）
20000004 B global_var_uninit # global_var_uninit变量，在0x20000004地址，类型为B（未初始化数据段中的全局符号）
...
这里的T, D, B等表示符号的类型和所属的节。这些信息都是从符号表和节头表中解析出来的。
3.4.3 重定位表与链接过程
SHT_REL和SHT_RELA类型的节（通常在.o文件中存在，如.rel.text, .rel.data）包含了重定位条目。每个重定位条目告诉链接器：在某个地址，有一个需要修正的引用，以及如何修正它。
重定位的场景：
假设在file1.c中调用了file2.c中定义的函数func_from_file2。当file1.c被编译成file1.o时，编译器并不知道func_from_file2的最终地址。它会在file1.o中生成一个对func_from_file2的“占位符”引用，并在.rel.text节中生成一个重定位条目，指示链接器在链接时需要修正这个占位符。
链接器在处理重定位节时，会：
- 查找符号： 在符号表中查找被引用符号（如
func_from_file2）的最终地址。 - 修正引用： 根据重定位类型，将占位符地址替换为正确的最终地址。
理解重定位表对于分析链接错误、理解程序如何跨文件协同工作以及在某些特殊情况下进行二进制修改非常有用。
3.4.4 ARM架构特定的节
ARM体系结构定义了一些特定的ELF节类型和标志，用于支持其特有的ABI和特性。例如：
-
.ARM.attributes节： 类型为SHT_ARM_ATTRIBUTES（0x70000003），通常包含有关ELF文件生成环境和目标的属性信息，如：- ARM体系结构版本 (e.g., ARMv7-M)
- 浮点单元 (FPU) 使用情况 (Hardware/Software float)
- 字节序 (Endianness)
- ABI版本
这些属性帮助链接器和调试器确保所有链接在一起的代码都兼容，并且目标环境能够正确执行。
-
.ARM.exidx和.ARM.extab节： 用于ARM的异常处理（Exception Handling）。exidx是异常索引表，extab是异常表格。它们在C++异常处理（try-catch）和调试回溯时发挥作用。
这些特定于ARM的节进一步展示了ELF文件格式的灵活性，使其能够适应不同架构和ABI的需求。
3.5 实战代码案例：扩展Python解析器以解析节头表和节字符串表
现在，我们将进一步扩展我们上一章的Python ELF解析器，使其能够解析节头表，并从节字符串表中读取节的名称。这将使我们的解析器能够更全面地展现ELF文件的内部结构。
import struct # 导入struct模块，用于处理二进制数据
# 辅助函数：将ELF文件类型码转换为可读名称
def get_elf_type_name(e_type): # 定义一个辅助函数，将ELF文件类型代码转换为可读名称
types = {
# 定义一个字典，映射类型代码到名称
0x0001: "ET_REL (可重定位文件)", # 可重定位文件
0x0002: "ET_EXEC (可执行文件)", # 可执行文件
0x0003: "ET_DYN (共享对象文件)", # 共享对象文件
0x0004: "ET_CORE (核心转储文件)" # 核心转储文件
}
return types.get(e_type, "未知类型") # 返回对应的名称，如果不存在则返回“未知类型”
# 辅助函数：将ELF机器架构码转换为可读名称
def get_elf_machine_name(e_machine): # 定义一个辅助函数，将ELF机器架构代码转换为可读名称
machines = {
# 定义一个字典，映射机器架构代码到名称
0x0008: "EM_MIPS", # MIPS架构
0x0028: "EM_ARM", # ARM架构
0x003E: "EM_X86_64", # AMD x86-64架构
0x00B7: "EM_AARCH64" # ARM AArch64（64位ARM）架构
}
return machines.get(e_machine, "未知架构") # 返回对应的名称，如果不存在则返回“未知架构”
# 辅助函数：将程序段类型码转换为可读名称
def get_program_segment_type_name(p_type): # 定义一个辅助函数，将程序段类型代码转换为可读名称
types = {
# 定义一个字典，映射程序段类型代码到名称
0x00000000: "PT_NULL (空)", # 空类型
0x00000001: "PT_LOAD (可加载)", # 可加载段
0x00000002: "PT_DYNAMIC (动态链接信息)", # 动态链接信息
0x00000003: "PT_INTERP (解释器路径)", # 解释器路径
0x00000004: "PT_NOTE (辅助信息)", # 辅助信息
0x00000005: "PT_SHLIB (保留)", # 保留
0x00000006: "PT_PHDR (程序头表本身)", # 程序头表本身
0x00000007: "PT_TLS (线程本地存储)" # 线程本地存储
}
if 0x60000000 <= p_type <= 0x6FFFFFFF: # 如果类型在操作系统特定范围低位到高位之间
return "PT_LOOS 到 PT_HIOS (操作系统特定)" # 返回操作系统特定类型名称
if 0x70000000 <= p_type <= 0x7FFFFFFF: # 如果类型在处理器特定范围低位到高位之间
return "PT_LOPROC 到 PT_HIPROC (处理器特定)" # 返回处理器特定类型名称
return types.get(p_type, "未知类型") # 返回对应的名称，如果不存在则返回“未知类型”
# 辅助函数：将节类型码转换为可读名称
def get_section_type_name(sh_type): # 定义一个辅助函数，将节类型代码转换为可读名称
types = {
# 定义一个字典，映射节类型代码到名称
0x00000000: "SHT_NULL (空)", # 空类型
0x00000001: "SHT_PROGBITS (程序数据)", # 程序数据
0x00000002: "SHT_SYMTAB (符号表)", # 符号表
0x00000003: "SHT_STRTAB (字符串表)", # 字符串表
0x00000004: "SHT_RELA (带附加的重定位表)", # 带附加的重定位表
0x00000005: "SHT_HASH (哈希表)", # 哈希表
0x00000006: "SHT_DYNAMIC (动态链接信息)", # 动态链接信息
0x00000007: "SHT_NOTE (辅助信息)", # 辅助信息
0x00000008: "SHT_NOBITS (无数据的节)", # 无数据的节
0x00000009: "SHT_REL (重定位表)", # 重定位表
0x0000000A: "SHT_SHLIB (保留)", # 保留
0x0000000B: "SHT_DYNSYM (动态链接符号表)", # 动态链接符号表
0x0000000E: "SHT_INIT_ARRAY (初始化函数数组)", # 初始化函数数组
0x0000000F: "SHT_FINI_ARRAY (终止函数数组)", # 终止函数数组
0x00000010: "SHT_PREINIT_ARRAY (预初始化函数数组)", # 预初始化函数数组
0x00000011: "SHT_GROUP (节组)", # 节组
0x00000012: "SHT_SYMTAB_SHNDX (符号表节索引扩展)", # 符号表节索引扩展
0x70000003: "SHT_ARM_ATTRIBUTES (ARM属性)" # ARM属性（示例）
}
if 0x60000000 <= sh_type <= 0x6FFFFFFF: # 如果类型在操作系统特定范围低位到高位之间
return "SHT_LOOS 到 SHT_HIOS (操作系统特定)" # 返回操作系统特定类型名称
if 0x70000000 <= sh_type <= 0x7FFFFFFF: # 如果类型在处理器特定范围低位到高位之间
return "SHT_LOPROC 到 SHT_HIPROC (处理器特定)" # 返回处理器特定类型名称
return types.get(sh_type, "未知类型") # 返回对应的名称，如果不存在则返回“未知类型”
def parse_elf_header(f): # 定义一个函数，用于解析ELF文件头
"""
解析ELF文件的头部信息。
f: 文件对象，已打开并处于二进制读取模式。
"""
elf_header_size = 52 # 定义ELF文件头的大小，32位ELF文件头通常为52字节
# 读取ELF文件头的前52个字节
header_bytes = f.read(elf_header_size) # 从文件当前位置读取指定数量的字节
if len(header_bytes) < elf_header_size: # 检查是否成功读取了足够的字节
print("错误：文件太小，无法读取完整的ELF文件头。") # 打印错误信息
return None # 返回None表示解析失败
# 解析e_ident (ELF Identification)
e_ident = header_bytes[0:16] # 提取e_ident字段，前16个字节
magic_number = e_ident[0:4] # 提取魔数，e_ident的前4个字节
if magic_number != b'\x7fELF': # 检查魔数是否为b'\x7fELF'
print(f"错误：不是有效的ELF文件，魔数是 {
magic_number.hex()}") # 打印错误信息，显示实际的魔数
return None # 返回None表示解析失败
file_class = e_ident[4] # 提取文件位数，e_ident的第5个字节
data_encoding = e_ident[5] # 提取数据编码（字节序），e_ident的第6个字节
if file_class != 1: # 确保是32位ELF文件，此解析器只支持32位
print("错误：此解析器目前只支持32位ELF文件。") # 打印错误信息
return None # 返回None表示解析失败
# 根据数据编码确定字节序
if data_encoding == 1: # 如果数据编码是1，表示小端序
endian_char = '<' # struct模块中使用'<'表示小端序
print("ELF文件字节序：小端序") # 打印字节序信息
elif data_encoding == 2: # 如果数据编码是2，表示大端序
endian_char = '>' # struct模块中使用'>'表示大端序
print("ELF文件字节序：大端序") # 打印字节序信息
else: # 其他值表示未知或无效
print("错误：未知的ELF数据编码。") # 打印错误信息
return None # 返回None表示解析失败
# 解析ELF文件头中的其他字段
(
e_type, # 2字节：文件类型
e_machine, # 2字节：目标机器架构
e_version, # 4字节：ELF版本
e_entry, # 4字节：程序入口点虚拟地址
e_phoff, # 4字节：程序头表在文件中的偏移量
e_shoff, # 4字节：节头表在文件中的偏移量
e_flags, # 4字节：处理器特定的标志
e_ehsize, # 2字节：ELF文件头本身的大小
e_phentsize, # 2字节：程序头表中每个条目的大小
e_phnum, # 2字节：程序头表中条目的数量
e_shentsize, # 2字节：节头表中每个条目的大小
e_shnum, # 2字节：节头表中条目的数量
e_shstrndx # 2字节：节字符串表在节头表中的索引
) = struct.unpack(endian_char + 'HHIIIIIHHHHHH', header_bytes[16:]) # 使用struct.unpack解析剩余的字节，格式字符串为'HHIIIIIHHHHHH'
print("\n--- ELF文件头信息 ---") # 打印分隔线和标题
print(f"文件类型 (e_type): 0x{
e_type:04X} ({
get_elf_type_name(e_type)})") # 打印文件类型
print(f"机器架构 (e_machine): 0x{
e_machine:04X} ({
get_elf_machine_name(e_machine)})") # 打印机器架构
print(f"入口点地址 (e_entry): 0x{
e_entry:08X}") # 打印入口点地址
print(f"程序头表偏移 (e_phoff): 0x{
e_phoff
最低0.47元/天 解锁文章
扫一扫
77
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
