[嵌入式](GCC)STM32进阶修炼之ELF文件剖析

本文拟通过分析一个普通的32位elf文件去剖析32位elf文件结构。(System V ABI基于2013版)

一、32位数据格式

上图表示：

比如Elf32_Addr表示无符号程序地址，其大小为4bytes，字节对齐为4。对于STM32来说，其地址是32位，这个毋庸置疑。在Linux下/usr/include/elf.h中也有定义：

typedef uint16_t Elf32_Half;
typedef uint16_t Elf64_Half;

typedef uint32_t Elf32_Word;
typedef	int32_t  Elf32_Sword;
typedef uint32_t Elf64_Word;
typedef	int32_t  Elf64_Sword;

typedef uint64_t Elf32_Xword;
typedef	int64_t  Elf32_Sxword;
typedef uint64_t Elf64_Xword;
typedef	int64_t  Elf64_Sxword;

typedef uint32_t Elf32_Addr;
typedef uint64_t Elf64_Addr;

typedef uint32_t Elf32_Off;
typedef uint64_t Elf64_Off;

typedef uint16_t Elf32_Section;
typedef uint16_t Elf64_Section;

typedef Elf32_Half Elf32_Versym;
typedef Elf64_Half Elf64_Versym;

可以看到就是一些重定义，这个主要是为了不同平台的兼容性。在平台确定的情况下把它们带入的看做uint32_t或uint16_t等是完全没问题的。 如果是在Windows下使用gcc工具链开发，也可在工具链的?include 文件夹下找到elf.h ，本文所有宏与结构体定义均可在elf.h里找到。

二、ELF Header

这个结构体即为所有elf文件的文件头，是一个固定格式。文件起始对应结构体首地址。

2.1?e_ident[EI_NIDENT]

首先可以看到这是一个unsigned?char类型的数组，大小为16。

这个数组内容标志着这是一个object文件，而且里面包含了和架构等无关的信息(也就是每个字节顺序和含义都是被定义死的，不会受比如大小端等的影响)。数组所存信息如下：

其中每个部分代表：

2.1.1 EI_MAG0~EI_MAG3

很明显，前四个字节是固定的，分别是0x7F和E、L、F的ASCII值。

2.1.2 EI_CLASS

它表示该文件是一个什么类型的文件，可选：无效、32位、64位

?2.1.3 EI_DATA

它表示该文件字节序是大端还是小端，可选：无效、小端、大端

LSB:Least Significant Bit

MSB:Most Significant Bit

2.1.4 EI_VERSION

当前版本，此字节必须为EV_CURRENT，在elf.h里可以看到：

2.1.5?EI_OSABI

此字节用于标识当前文件使用特定的操作系统或者ABI。相关内容如下：

2.1.6?EI_ABIVERSION

此字节用于标识目标文件的ABI版本，从而用来区别那些不相互兼容的ABI版本。

2.1.7?EI_PAD

这些字节未使用，可以看到上面一共用了从0到8字节，所以剩下的从9到15字节都为0。

2.2?e_type

这两个字节表示文件类型，可以看到上图中Systerm V ABI中就有：

无类型、可重定位文件、可执行文件、共享目标文件、核心文件、用以特定操作系统、用以特定处理器等

2.3?e_machine

这两个字节表示目标文件属于哪种的芯片架构类型：

我们也可以到elf.h里查看：

也就是ARM架构是40来表示。

2.4?e_version

这四个字节表示目标文件版本，只有0和1分别表示无效版本、当前版本：

2.5?e_entry

这四个字节表示程序入口的虚拟地址，如果是可执行文件，则程序指令从这个地址开始执行。但是像可重定位文件这些没有入口地址的，一般都为0。

2.6?e_phoff

这四个字节表示文件程序头表的相对偏移，单位字节。如果没有程序头表，则为0。

2.7?e_shoff

这四个字节表示文件段头表的相对偏移，单位字节。如果没有段头表，则为0。

关于程序头表和段头表在下面会有更加详细的解释。

2.8?e_flags

这四个字节表示ELF文件平台相关属性，一般格式为EF_machine_flag。其中ARM架构相关flag有：

2.9?e_ehsize

这两个字节表示ELF文件头的大小，单位字节。

2.10?e_phentsize

这两个字节表示程序头表中一个条目大小，单位字节，每个条目大小相同。

2.11?e_phnum

这两个字节表示程序头表中的条目数。没有程序头表，则为0。

2.12?e_shentsize

这两个字节表示段表描述符大小，单位字节。

2.13?e_shnum

这两个字节表示段表描述符数量。

2.14 e_shstrndx

这两个字节表示段表字符串表所在的段在段表中的下标。

2.15 实际文件分析

上图是笔者某个工程的elf文件，把它放在excel里分析如下：

然后使用readelf -a读取elf文件信息：

?*?section有段和节的意思，但是通常站在链接的角度，我们把section译作 “节” ，而站在执行角度我们把它的近义词segment译作 “段” 。此处分析借鉴了《程序员的自我修养-链接、装载与库》，所以叫做段表。

三、section?header

以上是一个section header的标准结构，而段表就是一个包含一个或多个这样相同结构体的列表。

3.1?sh_name

这四个字节表示一个段的名字的偏移。由上文知道在elf的header里面专门有描述字符串段的索引，就是因为所有段的名字都存在这个段内(.shstrtab)，而这个偏移就是在这个段里面的偏移。

3.2 sh_type

这四个字节表示段的类型。如下图：

3.2.1?SHT_NULL

此类型表示该段为非活跃的，它不关联任何有用的信息，也可以理解为无意义。

3.2.2 SHT_PROGBITS

该段所持有的所有信息都是由程序定义，比如代码段、数据段、程序段等都是这种，它们的意义是由程序决定的。

3.2.3 SHT_SYMTAB

该段的内容为完整的符号表。

3.2.4 SHT_STRTAB

该段的内容为字符串表。

3.2.5 SHT_RELA

该段内容为重定位表。

3.2.6 SHT_HASH

该段内容为符号表的哈希表。

3.2.7 SHT_DYNAMIC

该段包含动态链接的相关信息。

3.2.8 SHT_NOTE

该段内容为提示性信息。

3.2.9 SHT_NOBITS

该段在文件中不占用空间，其他同?SHT_PROGBITS 。

3.2.10 SHT_REL

该段内容为重定位信息。

3.2.11 SHT_SHLIB

保留。

3.2.12 SHT_DYNSYM

该段内容为动态链接的符号表。相当于把完整符号表?SHT_SYMTAB?里面关于动态链接的符号全部放在一个段内。

3.2.13 SHT_INIT_ARRAY

该段包含一个指向初始化函数的指针数组。

3.2.14 SHT_FINI_ARRAY

该段包含一个指向终止函数的指针数组。

3.2.15 SHT_PREINIT_ARRAY

本段包含一个指向函数的指针数组，这些函数在所有其他初始化函数之前被调用。

3.2.16 SHT_GROUP

该段定义了一个段组，即一组相关的段。

3.2.17 SHT_SYMTAB_SHNDX

该段与一个符号表部分相关联，如果该符号表引用的任何部分头索引包含转义值SHN_XINDEX，则需要这个段。

3.2.18 SHT_LOOS~SHT_HIOS

这个范围内的值留给特定的操作系统使用。

3.2.19?SHT_LOPROC~SHT_HIPROC

这个范围内的值留给特定的处理器使用。

3.2.20?SHT_LOUSER~SHT_HIUSER

用户可以使用该范围表示自定义段类型，而不用担心和标准段类型冲突。

3.3?sh_flags

这四个字节表示段的标志：

它们分别表示：

3.3.1 SHF_WRITE

该段包含在程序执行时可写的数据。

3.3.2 SHF_ALLOC

该段在进程空间中必须要被分配空间。

3.3.3 SHF_EXECINSTR

该段包含可以被执行的机器码。

3.3.4 SHF_MERGE

该段的数据可以被合并以消除重复。除非SHF_STRINGS标志也被设置，否则段中的数据元素是统一大小的。每个元素的大小在段头表的sh_entsize字段中指定。如果SHF_STRINGS标志也被设置，数据元素由空尾的字符串组成。每个字符的大小在段头表的sh_entsize字段中指定。

3.3.5 SHF_STRINGS

该段中的数据元素由以空字符结尾的字符串组成。每个字符的大小在段头表的?sh_entsize?字段中指定。

3.3.6 SHF_INFO_LINK

该段的?sh_info?字段保存一个段头表索引。

3.3.7 SHF_LINK_ORDER

这个标志为链接编辑增加了特殊的排序要求。这些要求适用于本段头的sh_link字段引用另一段（被链接的段）的情况。如果这个部分与输出文件中的其他部分结合在一起，它必须以与这些部分相同的相对顺序出现，因为被链接的部分与被链接的部分结合在一起。

3.3.8 SHF_OS_NONCONFORMING

这一部分需要特殊的操作系统处理（超出标准的链接规则）以避免不正确的行为。如果这部分有一个sh_type值或者包含在操作系统特定范围内的sh_flags位，而处理这部分的链接编辑器不能识别这些值，那么链接编辑器应该以一个错误拒绝包含这部分的对象文件。

3.3.9 SHF_GROUP

这个部分是一个部分组的成员（可能是唯一的一个）。

3.3.10 SHF_TLS

该部分持有线程本地存储，这意味着每个独立的执行流程都有自己的该数据的不同实例。

3.3.11 SHF_COMPRESSED

这个标志标识了一个包含压缩数据的部分。SHF_COMPRESSED只适用于不可分配的部分，并且不能与SHF_ALLOC一起使用。此外，SHF_COMPRESSED不能应用于SHT_NOBITS类型的部分。
所有对压缩区的重定位都指定了对未压缩区数据的偏移量。因此，在应用重定位之前，有必要对部分数据进行解压。每个压缩部分都独立地指定了算法。允许在一个给定的ELF对象中的不同部分采用不同的压缩算法。

被压缩的部分以一个描述压缩相关信息的结构体开始，该结构体标识了压缩算法。压缩信息结构体如下：

typedef struct {
	Elf32_Word	ch_type;//压缩算法类型
	Elf32_Word	ch_size;//未压缩数据大小
	Elf32_Word	ch_addralign;//未压缩数据所需对齐方式
} Elf32_Chdr;

而压缩算法类型包含：

可以看到只有 1 是被指定为 ZLIB，其他?0x60000000 ~?0x6fffffff?都保留给了操作系统去指定，而?0x7000000 ~ 0x7fffffff都保留给了处理器去指定。

3.3.12 SHF_MASKOS

保留给操作系统去指定。

3.3.13 SHF_MASKPROC

保留给处理器去指定。

更多信息请查看资料引用。

3.3.14 一些标准段的类型及其属性

3.4?sh_addr

段的虚拟地址，如果该段可以被加载，则次字段为该段被加载后在进程空间中的虚拟地址，否则为0 。

3.5?sh_offset

如果该段在文件中，表示该段在文件中的相对偏移。比如 SHT_NOBITS 类型的段该字段就没有意义。

3.6?sh_size

该段的长度。单位：字节。

3.7?sh_link

该字段保存一个段头表的索引链接，具体解释取决于段的类型。

3.8?sh_info

该字段包含额外的信息，具体解释取决于段的类型。

sh_link 和 sh_info 具体信息在下表：

3.9?sh_addralign

段地址对齐，此值是2的指数。比如8字节对齐，则sh_addralign = 3 。

3.10?sh_entsize

该字段在某些包含固定长度条目的段中，表示单个条目的大小，比如符号表。如果为0表示不包含固定长度条目的表。

3.11?实际文件分析

还使用上一节的elf文件，从ELF文件头可以看到Section headers的偏移是 0x00021824 ，单个项目大小是 40 字节，共有 22 个项目。我们找到段头表起始地址：

可以看到22个项目中第一个也就是索引0的项目40个字节全是0，但与标准规定相符：

段头表之【索引0】：

使用readelf -S也可以看到：

我们继续看第二个项目：

我们实际分析一下：

首先我们如果想知道名称，必须要先找到包含段名的字符串表，这也是为什么ELF文件头里面要把包含段名的字符串表的索引单独列出来的原因，由上一节我们知道段名字符串表索引是 21?，注意索引是从 0?开始的。所以字符串表在段表里面的起始地址应该是?0x00021824 + 21?* 40 = 0x21B6C?，查看该地址处数据：

同样对它进行分析：

由该段在文件中的偏移我们可以找到该段内容的首地址：

注意，字符串表的查表方式为从索引开始，到0x00结束的字符串内容。可以看到从第9个字节开始到0x00用字符串表示刚好是 .shstrtab?，而从第27个字节开始到0x00为止字符串内容刚好是 .isr_vector ，与预期相符。

回到刚才段表中索引1的项，通过段名我们知道索引1的段表项保存的是向量表。它的类型是?SHT_PROGBITS ，所以它的内容被程序所定义，而且它需要被分配空间，它被加载时的虚拟地址是0x0800 0000，这个地址在STM32里就是0x0000 0000，这与向量表在运行时存放地址不谋而合。其次该段在文件中的相对偏移是0x010000，我们找到它的内容：

这与bin文件中地址相同：

四、program?header?

以上是一个program?header的标准结构，程序头表就是包含一个或多个program?header的列表。

4.1?p_type

段类型。仔细看会发现和段表很多类型有点类似。

4.1.1 PT_NULL

数组元素未使用。

4.1.2 PT_LOAD

数组元素指定一个可加载段，由p_filesz和p_memsz描述。

4.1.3 PT_DYNAMIC

数组元素指定动态链接信息。

4.1.4 PT_INTERP

数组元素指定一个以null结尾的路径名的位置与大小，被解释器调用。只对可执行文件有意义。

4.1.5 PT_NOTE

数组元素指定辅助信息的位置和大小。

4.1.6 PT_SHLIB

保留。

4.1.7 PT_PHDR

数组元素指定程序头表本身在文件和程序程序运行空间中的位置和大小。

4.1.8 PT_TLS

数组元素指定TLS模版。(Thread-Local Storage)

4.1.9 PT_LOOS~PT_HIOS

此范围内类型由操作系统指定。

4.1.10 PT_LOPROC~PT_HIPROC

此范围内类型由处理器指定。

4.2?p_offset

段在文件中的相对偏移。

4.3?p_vaddr

段在内存中的虚拟地址。

4.4?p_paddr

段的物理地址。

4.5?p_filesz

段在镜像文件中的大小，单位：字节。

4.6?p_memsz

段在运行运行空间中的大小，单位：字节。

4.7?p_flags

段的相关标志。如下图：

4.8?p_align

该字段指定段的对齐字节。

4.9?实际文件分析

还是由之前的elf文件分析，由ELF文件头可知，程序头表单个项大小为32字节，一共有3个项，程序头表起始位置为 0x34 。我们看索引0的?program?header：

实际分析如下：

使用readelf -l 查看程序头表可以看到：

查看3个段的划分：?

资料引用：

SYSTEM V ABI 4.1

System V Application Binary Interface - DRAFT - 10 June 2013

《程序员的自我修养——链接、装载与库》

《新程序员》：云原生和全面数字化实践

50位技术专家共同创作，文字、视频、音频交互阅读