1、这篇文章是对ELF文件的一个比较完整的总结。
2、部分未写完，有时间再来补。

1 简介(Introduction)

  ELF(Executable and Linkable Format)，即可执行与可链接格式，是可执行文件(Executable Files)、可重定位文件(Relocatable Files)、共享目标文件(Shared Object File)和核心转储(Core Dumps)的通用标准文件格式。首次发布在名为System V Release 4(SVR4)的Unix操作系统版本的应用程序二进制接口(Application Binary Interface,ABI)规范中，随后在工具接口标准(Tool Interface Standard,TIS)中发布，很快就被Unix系统的不同供应商所接受。在1999年，它被86open项目选定为x86处理器上Unix和类Unix系统的标准二进制文件格式，用来取代通用目标文件格式(Common Object File Format,COFF)。

  通过设计，ELF格式是灵活的，可扩展的和跨平台的。例如，它支持不同的字节序和地址大小，因此它不排除任何特定的中央处理单元(CPU)或指令集体系结构。这使得它可以被许多不同硬件平台上的许多不同操作系统所采用。

ELF文件的扩展名[^2]：

• none: ELF文件可以没有扩展名。
• .bin: BIN文件是以二进制格式存储数据的文件。编译的计算机程序就是典型的例子。它与基于文本的文件不同，后者可以在文本编辑器中编辑，而前者不可以在文本编辑器中编辑，但可以在16进制编辑器中进行编辑。磁盘映像(Disk Images)通常是二进制文件，尽管它们经常使用其他文件扩展名。BIN文件也可以用于固件更新[^4]。
• .axf: AXF文件是由ARM的RealView编译器(Keil的ARM-MDK的一部分)生成的目标文件格式，并且包含目标代码和调试信息。在调试器中，虽然仅将目标代码加载到目标本身，但是代码和调试信息都会加载到开发主机的内存中。通过JTAG，SWD或其他连接进行调试时(任何类型的-不仅仅是崩溃)，代码都需要在主机上可用，并且调试信息需要将该代码与原始源代码相关联。通过调试连接，仅传输了诸如寄存器值之类的最少数据，因此，例如，调试器将获取程序计数器值，并能够使用AXF中的调试数据显示主机上可用的汇编程序和源代码[^4]。
• .o: 可重定位文件(Relocatable File)。见下方。
• .elf：可执行文件(Executable File)。见下方。
• .so: 共享目标文件(Shared Object File)。见下方。
• .ko: 内核对象(Kernel Object)。内核模块。
• .prx: 索尼的PRX(PSP Relocation eXecutable?)格式是基于标准ELF格式的重定位可执行文件。它具有自定义的程序头(Program Headers)，非标准MIPS重定位节(Relocation Sections)和唯一的ELF类型，从而与普通的ELF文件区分开。
• .puff:
• .mod:

ELF格式的目标文件(Object Files)主要有以下三种类型:

• 可重定位文件(Relocatable File): 包含由编译器生成的代码以及数据。链接器会将它与其它目标文件链接起来从而创建可执行文件或者共享目标文件。在Linux系统中，这种文件的后缀一般为.o 。
• 可执行文件(Executable File): 就是我们通常在Linux中执行的程序。
• 共享目标文件(Shared Object File): 包含代码和数据，这种文件是我们所称的库文件，一般以.so结尾。一般情况下，它有以下两种使用情景：
  • 链接器(Link eDitor, ld)可能会将它和其它可重定位文件以及共享目标文件一起处理，以生成另外一个目标文件。
  • 动态链接器(Dynamic Linker)将它与可执行文件以及其它共享目标文件组合在一起，以生成进程镜像。

  目标文件由汇编器(Assembler)和链接器(Link Editor)创建，是文本程序(源代码)的二进制形式，可以直接在处理器上运行。那些需要虚拟机才能够执行的程序(例如：Java)不属于这一范围。

本文章使用的Linux Kernel代码：
/linux/include/elf.h.html,Copyright (C) 1995-2018

1.1 文件格式(File Format)

  目标文件既会参与程序链接(构建程序)又会参与程序执行(运行程序)。出于方便性和效率考虑，根据过程的不同，目标文件格式提供了其内容的两种并行视图，如下：

Figure 1-1：Object File Format

注意：
  尽管该图显示程序头表(Program Header Table)紧跟在ELF头(ELF Header)之后，节头表(Section Header Table)紧跟在各节(Sections)之后，但实际文件可能会有所不同。此外，节(Sections)和段(Segments)没有指定的顺序，只有ELF头(ELF Header)在文件中具有固定的位置。

  节(Section)表示可以在ELF文件中处理的最小不可分割的单元。段(Segment)是节(Section)的集合。段(Segment)表示可由exec(2)或运行时链接器映射到内存映像的最小单元[^6]。

这里给出一个关于链接视图和执行视图比较形象的展示：

Figure 1-2：Linking Execution View

1.1.1 链接视图(Linking View)

  文件开始处是ELF头(ELF Header)，它给出了整个文件的组织情况。

  如果程序头表(Program Header Table)存在，它会告诉系统如何创建进程映像。用于构建进程映像(执行程序)的文件必须具有程序头表。但是可重定位文件(Relocatable File)不需要这个表。

  节(Sections)区域包含了在链接视图中要使用的大部分信息：指令、数据、符号表、重定位信息等等。

  节头表(Section Header Table)包含了描述文件节(Section)的信息，每个节在节头表中都有一个表项，会给出节的名称、节的大小等信息。用于链接的目标文件必须有节头表，其它目标文件则无所谓，可以有，也可以没有。

1.1.2 执行视图(Execution View)

  对于执行视图来说，其主要的不同点在于没有了节(Section)，而有了多个段(Segment)。其实这里的段(Segment)大都是来源于链接视图中的节(Section)。

1.2 数据表示(Data Representation)

  目标文件格式支持具有8位/32位/64位架构的各种处理器。当然，这种格式是可以扩展的，也可以支持更小的或者更大位数的处理器架构。因此，目标文件会包含一些控制数据，这部分数据以机器无关的格式进行表示，从而有可能以通用的方式识别目标文件并解释其内容。目标文件中的其它数据采用目标处理器的格式进行编码，与在何种机器上创建没有关系。这里其实想表明的意思是目标文件可以进行交叉编译，我们可以在x86平台生成ARM平台的可执行代码。

  目标文件格式定义的所有数据结构均遵循相关类的“自然”大小和对齐准则。如有必要，数据结构包含显式填充以确保4字节对象的4字节对齐，从而强制使数据结构的大小为4字节的整数倍，依此类推。文件开头的数据也具有适当的对齐方式，因此，例如，包含Elf32_Addr成员的结构将在文件内的4字节边界上对齐，包含Elf64_Addr成员的结构将在文件内的8字节边界上对齐。出于可移植性的原因，ELF文件格式没有使用位域。

Table 1-1：32-Bit Data Types

Table 1-2：64-Bit Data Types

1.3 字符表示(Character Representations)

  本节描述默认的ELF字符表示，并定义外部文件使用的标准字符集，这些文件应该可以在系统之间移植。几种外部文件格式用字符表示控制信息。这些单字节字符使用7位ASCII字符集。换句话说，当ELF接口文档提到字符常量时，例如“/”或“\n”，它们的数值应该遵循7位ASCII准则。对于前面的字符常量，单字节值分别为47和10。

  根据字符编码，0~127范围之外的字符值可能占用一个或多个字节。应用程序可以控制它们自己的字符集，根据需要为不同的语言使用不同的字符集扩展。尽管工具接口标准(Tool Interface Standard,TIS)一致性不限制字符集，但它们通常应遵循一些简单的准则。

• 0~127之间的字符值应对应于7位ASCII代码。也就是说，编码超过127的字符集应该包括7位ASCII代码字符集，作为其子集。
• 字符值大于127的多字节字符编码应该仅包含值在0到127范围之外的字节。也就是说，每个字符使用超过一个字节的字符集不应该在多字节、非ASCII字符中“嵌入”类似于7位ASCII字符的字节。
• 多字节字符应该是自识别的。例如，这允许在任何多字节字符对之间插入任何多字节字符，而不会改变字符的解释。

  这些注意事项与多语言(多国语言)应用程序特别相关。

注意：ELF常量有指定处理器范围的命名约定。用于处理器特定扩展的名称，例如：DT、PT，包含了处理器种类的名称，例如：DT_M32_SPECIAL。但是，不使用此约定的现有处理器扩展将受到支持。例如：DT_JMP_REL。

2 ELF头(ELF Header)

  某些目标文件控制结构可以增长，因为ELF头(ELF Header)包含它们的实际大小。如果目标文件格式发生变化，程序可能会遇到比预期更大或更小的控制结构。因此，程序可能会忽略“额外”的信息。“缺失”的信息的处理取决于上下文，并将在定义扩展时指定。

  ELF头(ELF Header)描述了ELF文件的概要信息，利用这个数据结构可以索引到ELF文件的全部信息，数据结构如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

#define EI_NIDENT (16)

typedef struct
{
    unsigned char e_ident[EI_NIDENT];   /* Magic number and other info */
    Elf32_Half    e_type;               /* Object file type */
    Elf32_Half    e_machine;            /* Architecture */
    Elf32_Word    e_version;            /* Object file version */
    Elf32_Addr    e_entry;              /* Entry point virtual address */
    Elf32_Off     e_phoff;              /* Program header table file offset */
    Elf32_Off     e_shoff;              /* Section header table file offset */
    Elf32_Word    e_flags;              /* Processor-specific flags */
    Elf32_Half    e_ehsize;             /* ELF header size in bytes */
    Elf32_Half    e_phentsize;          /* Program header table entry size */
    Elf32_Half    e_phnum;              /* Program header table entry count */
    Elf32_Half    e_shentsize;          /* Section header table entry size */
    Elf32_Half    e_shnum;              /* Section header table entry count */
    Elf32_Half    e_shstrndx;           /* Section header string table index */
} Elf32_Ehdr;

typedef struct
{
    unsigned char e_ident[EI_NIDENT];   /* Magic number and other info */
    Elf64_Half    e_type;               /* Object file type */
    Elf64_Half    e_machine;            /* Architecture */
    Elf64_Word    e_version;            /* Object file version */
    Elf64_Addr    e_entry;              /* Entry point virtual address */
    Elf64_Off     e_phoff;              /* Program header table file offset */
    Elf64_Off     e_shoff;              /* Section header table file offset */
    Elf64_Word    e_flags;              /* Processor-specific flags */
    Elf64_Half    e_ehsize;             /* ELF header size in bytes */
    Elf64_Half    e_phentsize;          /* Program header table entry size */
    Elf64_Half    e_phnum;              /* Program header table entry count */
    Elf64_Half    e_shentsize;          /* Section header table entry size */
    Elf64_Half    e_shnum;              /* Section header table entry count */
    Elf64_Half    e_shstrndx;           /* Section header string table index */
} Elf64_Ehdr;

  其中每个成员都是以“e_”开头的，应该都是ELF的缩写。每个成员具体的说明如下。

• e_ident: ELF头(ELF Header)或目标文件的初始字节将文件标记为目标文件，并提供与机器无关的数据，用于解码和解释文件的内容。
• e_type: e_type标识目标文件类型。
• e_machine: e_machine指定了当前文件可以运行的处理器架构(指令集)。
• e_version: e_version标识目标文件的版本。
• e_entry: 这一项为系统转交控制权给ELF中相应代码的虚拟地址，从而启动进程。如果ELF文件没有相关的入口点(Entry Point)，则该成员保持为0。
• e_phoff: 这一项给出程序头表(Program Header Table)在文件中的字节偏移(Program Header table OFFset)。如果文件中没有程序头表，则为0。
• e_shoff: 这一项给出节头表(Section Header Table)在文件中的字节偏移(Section Header table OFFset)。如果文件中没有节头表，则为0。
• e_flags: 这一项给出文件中与特定处理器相关的标志，这些标志命名格式为EF_machine_flag。
• e_ehsize: 这一项给出ELF头(ELF Header)的字节长度(ELF Header Size)。
• e_phentsize: 这一项给出程序头表(Program Header Table)中每个表项的字节长度(Program Header ENTry SIZE)。每个表项的大小相同。
• e_phnum: 这一项给出程序头表的项数(Program Header entry NUMber)。因此，e_phnum与e_phentsize的乘积即为程序头表的字节长度。如果文件中没有程序头表，则该项值为0。
    如果程序头(Program Header Table)的数量大于65534，则该成员的值为PN_XNUM(0xFFFF)。程序头表(Program Header Table)条目的实际数量包含在索引0处的节头(Section Header)的sh_info字段中。否则，初始节头条目的sh_info成员值为0。请参见“扩展的节头”[^6]。
• e_shentsize: 这一项给出节头表(Section Header Table)中每个表项的字节长度(Section Header ENTry SIZE)。节头表中所有项占据的空间大小相同。
• e_shnum: 这一项给出节头表的项数(Section Header NUMber)。因此，e_shnum与e_shentsize的乘积即为节头表的字节长度。如果文件中没有节头表，则该项值为0。
    如果节的数量大于65279，则e_shnum的值为0。节头表(Section Header Table)条目的实际数量包含在索引0处的节头(Section Header)的sh_size字段中。否则，初始节头条目的sh_size成员的值为0。请参见“扩展的节头”[^6]。
• e_shstrndx: 这一项给出节头表(Section Header Table)中与节名称字符串表(Section Header String Table)相关的表项的索引值(Section Header STRing table iNDeX)。如果文件中没有节名称字符串表，则该项值为SHN_UNDEF。关于细节的介绍，请参考后面的“节(Sections)”和“字符串表(String Table)”部分。
    如果节名称字符串表(Section Header String Table)的节索引大于65279，则该成员的值为SHN_XINDEX(0xFFFF)，并且节名称字符串表节的实际索引包含在索引0处的节头的sh_link字段中。否则，初始节头条目的sh_link成员的值为0。请参见“扩展的节头”[^6]。

2.1 初始数组(e_ident[EI_NIDENT])

  如上所述，ELF提供了一个目标文件框架来支持多处理器、多数据编码以及多种类型的机器。为了支持这个目标文件族，文件的初始字节指定了如何解释机器无关的文件内容，并且独立于文件的剩余内容。

  ELF头(ELF Header)或目标文件的初始字节对应于e_ident成员。这个数组对于不同的下标的含义如下：

Table 2-1：e_ident[] Identification Indexes

2.1.1 e_ident[EI_MAG0] ~ e_ident[EI_MAG3]

  这些索引访问到的字节保存一下的值。e_ident[EI_MAG0]到e_ident[EI_MAG3]，即文件的头4个字节，被称作“魔数(Magic Number)”，标识该文件是一个ELF目标文件。至于开头为什么是0x7f，并没有仔细去查过。

Table 2-2：Magic Number

2.1.2 e_ident[EI_CLASS]

  e_ident[EI_CLASS]为e_ident[EI_MAG3]的下一个字节，标识文件的类型或容量。

Table 2-3：e_ident[EI_CLASS] Value

  ELF文件的设计使得它可以在多种字节长度的机器之间移植，而不需要强制规定机器的最长字节长度和最短字节长度。文件的类型定义了对象文件容器的数据结构所使用的基本类型。包含在目标文件节(Section)中的数据可以遵循不同的编程模型[^6]。

  ELFCLASS32类型支持文件大小和虚拟地址空间上限为4GB的机器，例如：x86；它使用上述定义中的基本类型。

  ELFCLASS64类型指的是64位架构，例如：64位的SPARC和x86-x64。

  它出现在此处，展示了目标文件可能会如何更改。其他类型将根据需要定义，目标文件数据具有不同的基本类型和大小。

2.1.3 e_ident[EI_DATA]

  e_ident[EI_DATA]字节给出了目标文件中的特定处理器数据的编码方式。这将影响从偏移量0x10开始的多字节字段的解释。下面是目前已定义的编码：

Table 2-4：e_ident[EI_DATA] Value

  有关这些编码的更多信息如下所示。其他值被保留并将根据需要分配给新的编码。

  文件数据编码方式表明了文件内容的解析方式。正如之前所述，ELFCLASS32类型文件和ELFCLASS64类型文件使用了占用1，2，4和8字节的整数来表示偏移量，地址和其他信息。对于已定义的不同的编码方式，其表示如下所示，其中字节号在左上角。

  编码ELFDATA2LSB使用2的补码，最低有效字节(Least Significant Byte)占据最低地址。这种编码通常被非正式地称为小端序(Little Endian)。

Figure 2-1：Data Encoding ELFDATA2LSB

  编码ELFDATA2MSB使用2的补码，最高有效字节(Most Significant Byte)占据最低地址。这种编码通常被非正式地称为大端序(Big Endian)。

Figure 2-2：Data Encoding ELFDATA2MSB

2.1.4 e_ident[EI_VERSION]

  字节e_ident[EI_VERSION]指定ELF头(ELF Header)的版本号。当前，此值必须为EV_CURRENT，如介绍e_version时所说的那样。

2.1.5 e_ident[EI_OSABI]

  字节e_ident[EI_OSABI]指示此ELF文件能够运行的目标操作系统ABI编号。其他ELF结构中的一些字段具有操作系统或ABI特定含义的标志和值，这些字段的解释由该字节的值决定。无论目标平台是什么，它通常都被设置为0。目前定义的不同操作系统ABI对应的编号如下：

Table 2-5：e_ident[EI_OSABI] Value

2.1.6 e_ident[EI_ABIVERSION]

  e_ident[EI_ABIVERSION]用于进一步指定ABI的版本。此字段用于区分ABI的不兼容版本。它的解释取决于能够运行此文件的目标操作系统ABI，也就是EI_OSABI字段标识的ABI。如果没有为目标文件的EI_OSABI字段指定值，或者没有为由EI_OSABI字节的特定值确定的ABI指定版本值，则使用0用于指示未指定[^6]。

  Linux内核(至少在版本2.6之后)没有定义它，所以它被静态链接的可执行文件忽略。在这种情况下，EI_PAD的值为8。在glibc 2.12+中，如果e_ident[EI_OSABI]==3，则将此字段视为动态链接器的ABI版本：它定义了动态链接器的特性列表，将e_ident[EI_ABIVERSION]作为共享对象(可执行程序库或动态库)请求的特性级别，并在请求未知特性时拒绝加载它，即e_ident[EI_ABIVERSION]大于最大的已知特性[^2]。

2.1.7 EI_PAD

  EI_PAD为e_ident[]中未使用字节的起始索引。这些字节被保留并置为0；处理目标文件的程序应该忽略它们。如果之后这些字节被使用，EI_PAD的值就会改变。

2.2 目标文件类型(e_type)

  e_type标识目标文件类型。

Table 2-6：e_type Value

  虽然核心转储文件的内容没有被详细说明，但ET_CORE还是被保留用于标识此类文件。从ET_LOPROC到ET_HIPROC(包括边界)被保留用于特定处理器的场景。其他值被保留，并在未来根据需要分配给新的目标文件类型。

2.3 处理器架构(e_machine)

  e_machine指定了当前文件可以运行的处理器架构(指令集)。下面列出一些常见处理器架构(我见过的)对应的编码：

Table 2-7：e_machine Value

  其中“EM”应该是“ELF Machine”的简写。

  其他值被保留并将根据需要分配给新机器。此外，特定处理器的ELF名称使用机器名称来进行区分。例如，下面提到的标志使用前缀EF_(ELF Flag)。在EM_XYZ机器上名叫WIDGET的标志将被称为EF_XYZ_WIDGET。

2.4 目标文件版本(e_version）

  e_version标识目标文件的版本。

Table 2-8：e_version Value

  1表示原始文件格式；未来扩展(extensions)新的版本的时候将使用更大的数字。虽然在上面EV_CURRENT的值为1，但是为了反映当前版本号，它可能会改变，比如ELF到现在也就是1.2版本。

3 程序头表(Program Header Table)

  可执行文件(Executable File)或共享目标文件(Shared Object File)的程序头表(Program Header Table)是一个结构体数组，每一个元素的类型是Elfxx_Phdr，描述了系统准备执行程序时所需的一个段(Segment)的信息或其他信息。一个目标文件的段包含一个或多个节(Section)。程序头仅对可执行文件和共享目标文件有意义。一个文件用ELF头(ELF Header)中的e_phentsize和e_phnum成员指定它自己的程序头表表项的大小和程序头表的项数。

  可以说，程序头表(Program Header Table)就是专门为ELF文件运行时中的段(Segment)所准备的。程序头表表项所使用的结构体Elfxx_Phdr的定义如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

#define PN_XNUM		0xffff

typedef struct
{
    Elf32_Word	p_type;			/* Segment type */
    Elf32_Off	p_offset;		/* Segment file offset */
    Elf32_Addr	p_vaddr;		/* Segment virtual address */
    Elf32_Addr	p_paddr;		/* Segment physical address */
    Elf32_Word	p_filesz;		/* Segment size in file */
    Elf32_Word	p_memsz;		/* Segment size in memory */
    Elf32_Word	p_flags;		/* Segment flags */
    Elf32_Word	p_align;		/* Segment alignment */
} Elf32_Phdr;

typedef struct
{
    Elf64_Word	p_type;			/* Segment type */
    Elf64_Word	p_flags;		/* Segment flags */
    Elf64_Off	p_offset;		/* Segment file offset */
    Elf64_Addr	p_vaddr;		/* Segment virtual address */
    Elf64_Addr	p_paddr;		/* Segment physical address */
    Elf64_Xword	p_filesz;		/* Segment size in file */
    Elf64_Xword	p_memsz;		/* Segment size in memory */
    Elf64_Xword	p_align;		/* Segment alignment */
} Elf64_Phdr;

  各个字段的含义如下：

• p_type: 这个成员告诉该数组元素描述了什么样的段(Segment)或者如何解释该数组元素的信息。其类型值及其含义见下方。
• p_offset: 该成员给出了从文件开始到该段(Segment)开头的第一个字节的偏移量。
• p_vaddr: 该成员给出了该段(Segment)第一个字节在内存中的虚拟地址(Virtual Address)。
• p_paddr: 该成员仅用于物理地址寻址相关的系统中，该成员保留用于段(Segment)的物理地址。由于“System V”忽略了应用程序的物理寻址，可执行文件(Executable File)或共享目标文件(Shared Object File)的该项内容并未被限定。
• p_filesz: 该成员给出了文件映像中该段(Segment)的大小，可能为0。
• p_memsz: 该成员给出了内存映像中该段(Segment)的大小，可能为0。
• p_flags: 该成员给出了与段(Segment)相关的标记。详细内容见下方。
• p_align: 可加载的程序的段(Segment)的p_vaddr以及p_offset的大小必须是page的整数倍。该成员给出了段在文件以及内存中的对齐方式。如果该值为0或1的话，表示不需要对齐。除此之外，p_align应该是2的整数指数次方，并且p_vaddr与p_offset在模p_align的情况下，结果应该相等。

  PN_XNUM(0xFFFF)为e_phnum的特殊值。这表明程序头(Program Header Table)的实际数量太大而无法放入e_phnum，因此实际值位于节头表(Section Header Table)第0个节头(Section Header)的sh_info字段中。

3.1 段类型(p_type)

  一些条目描述了进程段(Process Segments)，另外一些条目则提供补充信息，但与进程映像没有关系(Process Image)。

Table 3-1：Segment Types

注意：除非其他地方特别要求，所有程序头段类型都是可选的。也就是说，文件的程序头表可能只包含与其内容相关的那些元素。

3.2 段权限(p_flags)

  被系统加载到内存中的程序至少有一个可加载的段(PT_LOAD)。当系统为可加载的段创建内存映像时，它会按照p_flags为段(Segments)设置相应的访问权限。

Table 3-2：Segment Flag Bits, p_flags

  其中，所有在PF_MASKOS中的比特位都是被保留用于与操作系统相关的语义信息。所有在PF_MASKPROC中的比特位都是被保留用于与处理器相关的语义信息。如果指定了含义，则操作系统和处理器补充说明它们。

  如果权限位为0，则拒绝该类型的访问。实际的内存权限取决于相应的内存管理单元，这可能因系统而异。尽管所有的权限组合都是可以的，但是系统一般会授予比请求更多的权限。在任何情况下，除非明确说明，否则段不会有写权限。下表显示了确切的标志解释和允许的标志解释。符合工具接口标准(Tool Interface Standard,TIS)的系统可以设置任何一种。

Table 3-3：Segment Permissions

  例如，一般来说，代码段一般具有读和执行权限，但是不会有写权限。数据段一般具有写，读，以及执行权限。

3.3 段内容(Segment Contents)

  一个目标文件段(Segment)可能包括一到多个节(Section)，尽管这对程序头(Program Header)是透明的。文件的段(Segment)是否包含一个或多个节(Section)并不会影响程序的加载。尽管如此，我们也必须需要各种各样的数据来使得程序可以执行以及动态链接等等。下面会给出一般情况下的段(Segment)的内容。对于不同的段(Segment)来说，它内部的节(Section)的顺序以及所包含的节(Section)的个数有所不同。此外，与处理相关的约束可能会改变对应的段(Segment)的结构。

  如下所示，代码段(Text Segment)包含只读的指令以及数据，通常包括以下节(Section)。其他节(Section)也可以驻留在可加载的段(Segment)中。当然这个例子并没有给出所有的可能的段(Segment)内容。

Figure 3-1：Text Segment

  数据段(Data Segment)包含可写的数据以及指令，通常包括以下节(Section)。

Figure 3-2：Data Segment

  程序头表(Program Header Table)的PT_DYNAMIC类型的元素指向.dynamic节(Section)。其中，.got节和.plt节包含与地址无关代码和动态链接相关的信息。尽管在上面给出的例子中，.plt节出现在代码段(Text Segment)，但它可以驻留在代码段(Text Segment)或数据段(Data Segment)中，这取决于处理器。

  .bss节的类型为SHT_NOBITS，虽然它不占用文件中的空间，但它占用段的内存映像的空间。通常情况下，没有初始化的数据在段的尾部，因此，p_memsz才会比p_filesz大。

注意：不同的段(Segment)的内容可能会有所重合，即不同的段(Segment)可能包含相同的节(Section)。

3.4 基地址(Base Address)

  程序头(Program Header)中的虚拟地址可能并不是程序内存映像中实际虚拟地址。通常来说，可执行文件(Executable File)都会包含绝对地址的代码。为了使得程序可以正常执行，段(Segments)必须在用于构建可执行文件的虚拟地址中。另一方面，共享目标文件(Shared Object File)通常包含与地址无关的代码。这可以使得共享目标文件(Shared Object File)可以被多个进程加载，同时保持程序执行的正确性。尽管系统会为不同的进程选择不同的虚拟地址，但它维护了这些段(Segments)的相对位置。因为地址无关代码使用段(Segments)之间的相对地址来进行寻址，内存中的虚拟地址之间的差值必须与文件中的虚拟地址之间的差值相匹配。内存中任何段(Segments)的虚拟地址与文件中对应的虚拟地址之间的差值对于给定进程中的任何一个可执行文件(Executable File)或共享目标文件(Shared Object File)来说是一个单一常量值。这个差值就是基地址(Base Address)，基地址的一个用途就是在动态链接期间重新定位程序的内存映像。

  可执行文件(Executable File)或者共享目标文件(Shared Object File)的基地址是在执行过程中由以下三个数值计算得到的：

• 虚拟内存加载地址
• 最大页面大小
• 程序可加载段的最低虚拟地址

  要计算基地址(Base Address)，首先要确定与PT_LOAD段的最小p_vaddr相关联的内存虚拟地址。然后把该内存虚拟地址调整为与之最接近的最大页面的整数倍，即是基地址(Base Address)。相应的p_vaddr值本身也被调整为与之最接近的最大页面的整数倍。基地址(Base Address)就是调整后的内存虚拟地址和调整后的p_vaddr值之间的差值。根据要加载到内存中的文件的类型，内存虚拟地址可能与p_vaddr相同也可能不同。

4 节头表(Section Header Table)

  节头表(Section Header Table)在ELF文件的尾部(为什么要放在文件尾部呢？)，但是为了讲解方便，这里将这个表放在这里进行讲解。

  该结构用于定位ELF文件中的每个节(Section)的具体位置。节头表(Section Header Table)是一个结构体数组，每一个元素的类型是Elfxx_Shdr，描述了一个节(Section)的概要内容。节头表索引是该数组的下标。ELF头(ELF Header)中的e_shoff成员给出了从文件开头到节头表(Section Header Table)的字节偏移。e_shnum告诉了我们节头表包含的表项数；e_shentsize给出了每一表项的大小，以字节为单位。

  如果节(Section)的数量大于或等于SHN_LORESERVE(0xFF00)，则e_shnum的值为SHN_UNDEF(0)。节头表(Section Header Table)条目的实际数量包含在索引0处的节头的sh_size字段中。否则，初始条目的sh_size成员的值为0。请参见扩展的节头(Extended Section Header)[^6]。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

typedef struct
{
    Elf32_Word	sh_name;		/* Section name (string tbl index) */
    Elf32_Word	sh_type;		/* Section type */
    Elf32_Word	sh_flags;		/* Section flags */
    Elf32_Addr	sh_addr;		/* Section virtual addr at execution */
    Elf32_Off	sh_offset;		/* Section file offset */
    Elf32_Word	sh_size;		/* Section size in bytes */
    Elf32_Word	sh_link;		/* Link to another section */
    Elf32_Word	sh_info;		/* Additional section information */
    Elf32_Word	sh_addralign;	/* Section alignment */
    Elf32_Word	sh_entsize;		/* Entry size if section holds table */
} Elf32_Shdr;

typedef struct
{
    Elf64_Word	sh_name;		/* Section name (string tbl index) */
    Elf64_Word	sh_type;		/* Section type */
    Elf64_Xword	sh_flags;		/* Section flags */
    Elf64_Addr	sh_addr;		/* Section virtual addr at execution */
    Elf64_Off	sh_offset;		/* Section file offset */
    Elf64_Xword	sh_size;		/* Section size in bytes */
    Elf64_Word	sh_link;		/* Link to another section */
    Elf64_Word	sh_info;		/* Additional section information */
    Elf64_Xword	sh_addralign;	/* Section alignment */
    Elf64_Xword	sh_entsize;		/* Entry size if section holds table */
} Elf64_Shdr;

• sh_name: 此成员指定节(Section)的名称，它的值是节头字符串表节(.shstrtab)中内容距节头字符串表节起始的偏移量(以字节为单位)，因此该字段实际是一个数值。字符串表中的具体内容是以Null结尾的字符串。
• sh_type: 此成员对该节(Section)的内容和语义进行分类。节(Section)的类型及其说明会在后面进行介绍。
• sh_flags: 每一比特代表不同的标志，描述节(Section)是否可写，可执行，需要分配内存等属性。
• sh_addr: 如果该节(Section)将出现在进程的内存映像中，则此成员将给出该节(Section)的第一个字节应该在进程映像中的位置。否则，此字段为0。
• sh_offset: 此成员给出从文件开头到该节(Section)的第一个字节的偏移量。SHT_NOBITS类型的节(Section)不占用文件的空间，因此其sh_offset成员给出的是概念性的偏移。
• sh_size: 此成员给出节(Section)的字节大小。除非节(Section)的类型是SHT_NOBITS，否则该节(Section)占用文件中的sh_size字节。类型为SHT_NOBITS的节大小可能非零，不过却不占用文件中的空间。
• sh_link: 此成员给出节头表(Section Header Table)索引链接，其具体的解释依赖于节(Section)类型。
• sh_info: 此成员给出附加信息，其解释依赖于节类型。
• sh_addralign: 某些节(Section)的地址需要对齐。例如，如果一个节(Section)有一个doubleword类型的变量，那么系统必须保证整个节(Section)按双字对齐。也就是说，sh_addr%sh_addralign=0。目前它仅允许为0，以及2的正整数幂。0和1表示该节(Section)没有对齐约束。
• sh_entsize: 某些节(Section)中存在具有固定大小的表项的表，如符号表(Symbol Table)。对于这类节，该成员给出每个表项的字节大小。反之，此成员取值为0。

4.1 特殊的节头表索引(Special Section Indexes)

  一些节头表索引被保留，目标文件(Object Files)将不会有这些特殊索引对应的节(Section)。

  在索引大小受限的上下文中保留了一些节头表索引。例如，符号表(Symbol Table)条目的st_shndx成员以及ELF头(ELF Header)的e_shnum和e_shstrndx成员。在这种情况下，保留值不代表目标文件中的实际节(Section)。同样在这样的上下文中，溢出值指示实际的节索引将在其他地方，在更大的字段中找到[^6]。

Table 4-1：Special Section Indexes

  虽然0号索引被保留用于未定义值，但节头表(Section Header Table)仍然包含索引为0的项。也就是说，如果ELF头(ELF Header)的e_shnum为6，那么索引应该为0~5。更加详细的内容在后面会说明。

  系统预留SHN_LORESERVE和SHN_HIRESERVE之间的索引值(含边界)，这些值不引用节头表(Section Header Table)。也就是说，节头表(Section Header Table)不包含保留索引值对应的条目。

  正如之前所说，节头表索引为0(SHN_UNDEF)的节头存在，此索引标记的是未定义的节引用。此条目包含以下内容。

Table 4-2：Section Header Table Entry: Index 0

4.2 节类型(sh_type)

  节头(Section Header)的sh_type成员指定了节的类型。节类型目前有下列可选范围，其中“SHT”是“Section Header Table”的简写。

Table 4-3：Section Types, sh_type

4.3 节标志(sh_flags)[^6]

  节头(Section Header)中sh_flags字段的每一个比特位都可以定义相应的标志信息，其定义了对应节的内容是否可以被修改、被执行等信息。如果sh_flags中的一个标志位被设置，则该位取值为1，未定义的位都为0。目前已定义标志位如下，其他值保留。

Table 4-4：Section Attribute Flags, sh_flags

• SHF_WRITE: 标识在进程执行期间可写的节(Section)。
• SHF_ALLOC: 标识在进程执行期间占用内存的节(Section)。某些控制节(Section)不驻留在目标文件的内存映像中。对于这些节(Section)，不设置此属性。
• SHF_EXECINSTR: 标识包含可执行机器指令的节(Section)。
• SHF_MERGE: 标识包含可以合并以消除重复的数据的节(Section)。除非还设置了SHF_STRINGS标志，否则该节(Section)中的数据元素具有统一的大小。每个元素的大小在节头(Section Header)的sh_entsize字段中指定。如果还设置了SHF_STRINGS标志，则数据元素由以Null结尾的字符串组成。每个字符的大小在节头(Section Header)的sh_entsize字段中指定。
• SHF_STRINGS: 标识由以Null结尾的字符串组成的节(Section)。每个字符的大小在节头(Section Header)的sh_entsize字段中指定。
• SHF_INFO_LINK: 该节头(Section Header)的sh_info字段包含一个节头表索引(Section Header Table Index)。
• SHF_LINK_ORDER: 本节(Section)为链接器添加了特殊的排序要求。这些要求适用于由本节头(Section Header)的sh_link字段标识的引用节。如果此节(Section)与输出文件中的其他节(Section)组合，则该节(Section)相对于这些节(Section)必须以相同的相对顺序出现，就像被引用节(Section)相对于与其组合的节(Section)出现一样。链接到的节(Section)必须是无序的，并且不能反过来指定SHF_LINK_ORDER或SHF_ORDERED。
    此标志的典型用途是构建按地址顺序引用文本或数据节(Section)的表。
    除了添加排序要求之外，SHF_LINK_ORDER还指示该节(Section)包含描述引用的节(Section)的元数据。当执行未使用的节消除时，链接器确保该节和引用的节被一起保留或丢弃。从SHF_LINK_ORDER节(Section)到其引用的节(Section)的重定位本身，并不表示使用了引用的节(Section)。
    在没有sh_link排序信息的情况下，来自单个输入文件的节(Section)组合在输出文件的一个节(Section)中时，它们是连续的。这些节(Section)与输入文件中的节(Section)具有相同的相对顺序。来自多个输入文件的节(Section)以链接行顺序(link-line order)出现。

注意：特殊的sh_link值SHN_BEFORE和SHN_AFTER意味着排序后的节(Section)将分别排在排序集中所有其他节(Section)的前面或后面。如果有序集中的多个节(Section)具有这些特殊值之一，则保留输入文件链接行顺序。SHN_BEFORE和SHN_AFTER与使用扩展节索引的对象不兼容。他们已被弃用。

• SHF_OS_NONCONFORMING: 本节(Section)需要在标准链接规则之外进行特定于操作系统的特殊处理，以避免错误行为。如果此节(Section)具有sh_type值或包含了这些字段在特定操作系统范围内的sh_flags位，并且链接器无法识别这些值，则包含此节(Section)的目标文件将因错误而被拒绝。
• SHF_GROUP: 此节(Section)是节组(Section Group)的成员，可能是唯一的成员。该节(Section)必须由SHT_GROUP类型的节(Section)引用。 SHF_GROUP标志只能为包含在可重定位对象中的节(Section)设置。
• SHF_TLS: 此节(Section)包含线程本地存储(Thread-Local Storage)。进程内的每个线程都有该数据的不同实例。
• SHF_COMPRESSED: 标识包含压缩数据的节(Section)。SHF_COMPRESSED仅适用于不可分配的节(Section)，不能与SHF_ALLOC一起使用。此外，SHF_COMPRESSED不能应用于SHT_NOBITS类型的节。
• SHF_MASKOS: 此掩码中包含的所有位都保留用于特定操作系统的语义。
• SHF_MASKPROC: 此掩码中包含的所有位都保留用于特定处理器的语义。
• SHF_AMD64_LARGE: x64的默认编译模型仅提供32位偏移量(Displacements)。这种偏移量将节(Section)的大小和最终段(Segment)的大小限制为2GB。此属性标志标识可以容纳超过2GB的节(Section)。此标志允许链接使用不同代码模型的目标文件。
    使用小代码模型的对象可以自由引用不包含 SHF_AMD64_LARGE属性标志的x64对象文件节(Section)。包含此标志的节(Section)只能由使用较大代码模型的对象引用。例如，x64中等代码模型对象可以引用包含此属性标志的节(Section)和不包含此属性标志的节(Section)中的数据。但是，x64小代码模型对象只能引用不包含此标志的节(Section)中的数据。
• SHF_ORDERED: SHF_ORDERED是SHF_LINK_ORDER提供的功能的旧版本，已被SHF_LINK_ORDER取代。不再支持SHF_ORDERED。

注意：特殊的sh_info值SHN_BEFORE和SHN_AFTER意味着排序后的节(Section)将分别排在排序集中所有其他节(Section)的前面或后面。如果有序集中的多个节(Section)具有这些特殊值之一，则保留输入文件链接行顺序。SHN_BEFORE和SHN_AFTER与使用扩展节索引的对象不兼容。他们已被弃用。

• SHF_EXCLUDE: 此节(Section)不包含在可执行文件或共享对象的链接输入中。如果还设置了SHF_ALLOC标志，或者该节(Section)存在重定位，则忽略此标志。

4.4 sh_link & sh_info

  节头(Section Header)中的两个成员sh_link和sh_info包含特殊信息，具体取决于节类型。

Table 4-5：ELF sh_link and sh_info Interpretation

4.5 扩展的节头表(Extended Section Header Table)[^6]

  标准ELF数据结构可以表示的节(Section)数量有限制的。

  ELF头(ELF Header)的e_shnum和e_shstrndx元素都被限制为能够表示65535个节(Section)。

  此外，符号表(Symbol Table)条目可以使用st_shndx元素引用与其关联的节(Section)，该元素仅限于能够表示65279个节(Section)。尽管此元素的大小可以表示65535个节(Section)，但为特殊符号类型保留了一系列值，SHN_LORESERVE(0xFF00) - SHN_HIRESERVE(0xFFFF)。

  为了允许ELF对象包含超过65279个节(Section)，提供了许多特殊定义和特殊节类型。由此生成的ELF对象被认为包含扩展节头(Extended Section Header)信息。

  在标准ELF对象中，第一个节头(Section Header)是用0填充的。当节数超过ELF头(ELF Header)中相应数据(e_shnum)的大小时，第一个节头(Section Header)元素用于定义扩展ELF头属性。下表显示了这些值。

Table 4-6：Extended Section Header Table Entry: Index 0

  当使用这个节头0(Section Header 0)信息时，ELF头(ELF Header)的e_shnum元素应该设置为0，e_shstrndx元素应该设置为SHN_XINDEX(0xFFFF)。

  SHT_SYMTAB_SHNDX节是一个Elf32_Word值数组。每个值与符号表(Symbol Table)条目一一对应，并以与符号表(Symbol Table)条目相同的顺序出现。这些值表示定义符号表(Symbol Table)条目的节头索引。只有当符号表(Symbol Table)条目的st_shndx字段包含溢出值SHN_XINDEX(0xFFFF)时，相应的 SHT_SYMTAB_SHNDX条目才保存实际的节头索引。否则，SHT_SYMTAB_SHNDX条目必须是SHN_UNDEF(0)。

  如果一个ELF文件需要超过65534个程序头(Program Header)，则节头表(Section Header Table)的节头0的sh_info元素用于定义程序头(Program Header)的数量，ELF头(ELF Header)的e_phnum元素包含PN_XNUM(0xFFFF)。

5 节(Sections)

  节(Sections)包含目标文件中除了ELF头、程序头表、节头表之外的所有信息。此外，目标文件的节(Sections)满足以下几个条件：

• 目标文件中的每一个节(Sections)都只有一个对应的节头(Section Header)来描述它。但是，可能存在没有对应节(Section)的节头(Section Header)。
• 每个节(Sections)在目标文件中是连续的，但是大小可能为0。
• 任意两个节(Sections)不能重叠，即一个字节不能同时存在于两个节(Sections)中。
• 目标文件中可能会有闲置空间(Inactive Space)，各种头和节不一定会覆盖到目标文件中的所有字节，闲置区域的内容是未指定的。

  许多在ELF文件中的节(Section)都是预定义的，它们包含程序和控制信息。这些节(Section)被操作系统使用，但是对于不同的操作系统，同一节(Section)可能会有不同的类型以及属性。

  可执行文件(Executable files)是由链接器将一些单独的目标文件以及库文件链接起来而得到的。其中，链接器会解析不同目标文件之间的引用(子例程的引用以及数据的引用)，调整目标文件中的绝对引用，并且重定位指令。加载与链接过程需要目标文件中的信息，并且会将处理后的信息存储在一些特定的节(Section)中，比如.dynamic。

  每一种操作系统都会支持一组链接模型，但这些模型都大致可以分为两种:

• 静态链接(Static): 静态链接的文件中所使用的库文件或者第三方库都被静态绑定了，其引用已经被解析了，是一个完全自包含的可执行文件。
• 动态链接(Dynamic): 动态链接的文件中所使用的库文件或者第三方库只是单纯地被链接到可执行文件中。当可执行文件执行的时候使用到相应的函数时，相应的函数地址才会被解析。加载此可执行文件时，必须在系统中提供其他共享资源和动态库，才能使程序成功运行。

  有一些特殊的节(Section)可以支持调试，比如说.debug以及.line节；支持程序控制的节有.bss，.data，.data1，.rodata，.rodata1。

Table 5-1：

5.1 Note Related Sections

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

typedef struct
{
    Elf32_Word n_namesz;			/* Length of the note's name.  */
    Elf32_Word n_descsz;			/* Length of the note's descriptor.  */
    Elf32_Word n_type;			    /* Type of the note.  */
} Elf32_Nhdr;

typedef struct
{
    Elf64_Word n_namesz;			/* Length of the note's name.  */
    Elf64_Word n_descsz;			/* Length of the note's descriptor.  */
    Elf64_Word n_type;			    /* Type of the note.  */
} Elf64_Nhdr;

/* ---------------------------------------------------------------------------------------- */

/* Known names of notes. */
/* 已知的注释名称. */

// Solaris entries in the note section have this name.
// Note节中的Solaris条目有这个名称。
#define ELF_NOTE_SOLARIS	"SUNW Solaris"

// Note entries for GNU systems have this name.
// Note节中的GNU Systems有这个名称。
#define ELF_NOTE_GNU		"GNU"

/* ---------------------------------------------------------------------------------------- */

  有时候供应商或者系统构建者可能需要使用一些特殊的信息来标记ELF文件，从而其它程序可以来检查该ELF文件的一致性以及兼容性。SHT_NOTE类型的节(Section)和PT_NOTE类型的程序头(Program Header)元素可用于来实现这个目的。节和程序头元素中的Note信息包含任意数量的表项，每一个表项都是目标处理器格式的4字节的字数组。下面出现的标签有助于解释注释信息的组织形式，但是这并不在ELF文件的规范内。

Figure 5-1：Note Information

• namesz和name: name的前namesz字节包含了一个以Null结尾的字符串，这表示该项的拥有者或者发起人。但是目前并没有避免冲突的格式化的命名机制。一般来说，供应商会使用他们自己公司的名字，例如“XYZ Computer Company”作为标识符。如果没有任何名字的话，namesz应该是0。如有必要，需要进行填充，以使name区域4字节对齐。这样的填充大小不包含在namesz中。
• descsz和desc: desc的前descsz字节包含了注释(Note)的描述。ELF文件对于描述的内容没有任何约束。如果没有任何描述的话，descsz应该为0。如有必要，需要进行填充，以使desc区域4字节对齐。这样的填充大小不包含在descsz中。
• type: 这个字段给出了描述的解释，每个发起者控制自己的类型。对于同一类型来说，有可能有多个描述与其对应。因此，发起者必须能够识别名称和类型以便于来理解对应的描述。目前来说，类型值必须为非负值，ELF文件的规范里并不定义描述符的意思。这也是为什么type在前面。

  为了进一步说明，下面给出一个简单的例子。以下注释段(Note Segment)包含两个条目。

Figure 5-2：Example Note Segment

  以上注释段(Note Segment)包含两个注释信息(Note Information)，第一个注释信息的descsz为0，说明不存在desc。第二个注释信息是一个完整的注释信息。

注意：
1、系统保留没有name(namesz==0)和name长度为0(name[0]==’\0’)的注释信息(Note Information)，但目前没有定义类型。所有其他names必须至少有一个非空字符。
2、注释信息(Note Information)是可选的。注释信息(Note Information)的存在不会影响程序的工具接口标准(Tool Interface Standard,TIS)的一致性，前提是该信息不影响程序的执行行为。否则，程序不符合TIS ELF规范并具有未定义的行为。

5.1.1 .note

  此节(Section)存储各种注释信息。此节(Section)的节类型是SHT_NOTE。不使用任何节标志(sh_flags)。[^11]

5.1.2 .note.ABI-tag

  此节(Section)存储运行此ELF文件的目标操作系统的ABI信息。

  此节(Section)用于声明ELF映像的预期运行时API。它可能包括操作系统名称及其运行时版本。此节(Section)的节类型是SHT_NOTE。唯一使用的节标志(sh_flags)是SHF_ALLOC。[^11]

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

/* Defined note types for GNU systems(为GNU Systems定义注释类型). */
/* ABI information.  The descriptor consists of words:
   word 0: OS descriptor
   word 1: major version of the ABI
   word 2: minor version of the ABI
   word 3: subminor version of the ABI
*/
#define NT_GNU_ABI_TAG	1
#define ELF_NOTE_ABI	NT_GNU_ABI_TAG  // Old name.

// Known OSes. These values can appear in word 0 of an NT_GNU_ABI_TAG note section entry.
// 已定义的OS描述符。这些值可以出现在NT_GNU_ABI_TAG注释节条目的desc的第0个字中。
#define ELF_NOTE_OS_LINUX	    0
#define ELF_NOTE_OS_GNU		    1
#define ELF_NOTE_OS_SOLARIS2	2
#define ELF_NOTE_OS_FREEBSD	    3

  下面是一个.note.ABI-tag节的例子，取自libc6_2.23-0ubuntu11.2_i386的libc-2.23.so：

1
2
3
4
5
6
7
8
9
10
11
12
13

00000198 _note_ABI_tag segment dword public 'DATA' use32
00000198                 assume cs:_note_ABI_tag
00000198                 ;org 198h
00000198                 dd 4                    ; namesz
0000019C                 dd 10h                  ; descsz
000001A0 dword_1A0       dd 1                    ; DATA XREF: sub_E90A0+16B↓o
000001A0                                         ; type, ELF_NOTE_ABI = 0x1
000001A4 aGnu_0          db 'GNU',0              ; name, ELF_NOTE_GNU = "GNU"
000001A8                 dd 0                    ; OS: Linux
000001AC                 dd 2                    ; ABI Version: 2.6.32
000001B0                 dd 6
000001B4                 dd 32
000001B4 _note_ABI_tag ends

你也可以使用readelf对此节(Section)进行查看：

1
2
3
4
5
6
7
8

$ readelf -n libc-2.23.so 

[...]
Displaying notes found at file offset 0x00000198 with length 0x00000020:
  Owner                 Data size	Description
  GNU                  0x00000010	NT_GNU_ABI_TAG (ABI version tag)
    OS: Linux, ABI: 2.6.32
[...]

  ABI Version: 2.6.32指的是运行编译器的主机上的Glibc构建时使用的内核头文件版本。从广义上讲，它显示了可执行文件能够运行的系统的最小内核版本。如果程序在小于2.6.32的内核上运行，则会显示内核太旧警告。

参考：linux command “file” shows “for GNU/Linux 2.6.24”

5.1.3 .note.gnu.build-id

  此节(Section)存储此ELF文件的Build ID信息。Build ID被用来唯一标识一个链接文件。

  此节(Section)用于保存唯一标识ELF映像内容的ID。具有相同build ID的不同文件应该包含相同的可执行内容。有关更多详细信息，请参阅GNU链接器(ld (1))的–build-id选项。此节(Section)的节类型是SHT_NOTE。唯一使用的节标志(sh_flags)是SHF_ALLOC。[^11]

ld --build-id=style: ld
  请求创建“.note.gnu.build-id”ELF注释节(Section)。注释的内容是标识此链接文件的唯一标识。标识的样式可以是使用128个随机位的“uuid”，对输出内容的标准部分使用160位SHA1散列的“sha1”，对输出内容的标准部分使用128位md5散列的“md5”，或者使用指定为偶数个十六进制数字的选定位串的”0x hexstring”(忽略数字对之间的”-“和”:”字符)。如果省略样式，则使用“sha1”。
  “md5”和“sha1”样式产生的标识符在相同的输出文件中总是相同的，但在所有不相同的输出文件中是唯一的。它不打算作为文件内容的校验和进行比较。链接文件稍后可能会被其他工具更改，但标识原始链接文件的Build ID位字符串不会更改。
  为style传递“none”会禁用命令行前面任何“–build-id”选项的设置。

1
2
3

/* Build ID bits as generated by ld --build-id. The descriptor consists of any nonzero number of bytes. */
/* 由ld --build-id生成的Build ID。此描述符包含任何非零的字节数。 */
#define NT_GNU_BUILD_ID	3

  下面是一个.note.gnu.build-id节的例子，取自libc6_2.23-0ubuntu11.2_i386的libc-2.23.so：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

root@kali:~/Desktop# file libc-2.23.so 
libc-2.23.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (GNU/Linux), dynamically linked, interpreter /lib/ld-linux.so.2, BuildID[sha1]=bde4e8b0230b1b474cd8a1ca6e9f81bb2b438914, for GNU/Linux 2.6.32, stripped

00000174 _note_gnu_build_id segment dword public 'DATA' use32
00000174                 assume cs:_note_gnu_build_id
00000174                 ;org 174h
00000174 dword_174       dd 4                    ; DATA XREF: .program.header:off_DC↑o
00000174                                         ; namesz
00000178                 dd 14h                  ; descsz
0000017C                 dd 3                    ; DATA XREF: .rodata:0014CAE0↓o
0000017C                                         ; type, NT_GNU_BUILD_ID = 0x3
00000180 aGnu            db 'GNU',0              ; name, ELF_NOTE_GNU = "GNU"
00000184                                         ; desc, BuildID[sha1]=bde4e8b0230b1b474cd8a1ca6e9f81bb2b438914
00000184 byte_184        db 0BDh, 0E4h, 0E8h, 0B0h, 23h, 0Bh, 1Bh, 47h, 4Ch, 0D8h
00000184                                         ; DATA XREF: .eh_frame:off_177E90↓o
00000184                 db 0A1h, 0CAh, 6Eh, 9Fh, 81h, 0BBh, 2Bh, 43h, 89h, 14h 
00000184 _note_gnu_build_id ends

你也可以使用readelf对此节(Section)进行查看：

1
2
3
4
5
6
7

$ readelf -n libc-2.23.so 

Displaying notes found at file offset 0x00000174 with length 0x00000024:
  Owner                 Data size	Description
  GNU                  0x00000014	NT_GNU_BUILD_ID (unique build ID bitstring)
    Build ID: bde4e8b0230b1b474cd8a1ca6e9f81bb2b438914
[...]

5.1.4 .note.gnu.property

binfmt_elf: Extract .note.gnu.property from an ELF file

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70

/* Program property. */
/* 程序属性。 */
#define NT_GNU_PROPERTY_TYPE_0 5

/* Note section name of program property. */
/* 程序属性的注释节名称。 */
#define NOTE_GNU_PROPERTY_SECTION_NAME ".note.gnu.property"

/* ---------------------------------------------------------------------------------------- */

/* Values used in GNU .note.gnu.property notes (NT_GNU_PROPERTY_TYPE_0). */
/* 用于GNU的.note.gnu.property注释节的值。 */

// Stack size.
// 栈大小。
#define GNU_PROPERTY_STACK_SIZE			1
// No copy relocation on protected data symbol.
// 对受保护的数据符号没有拷贝重定位。
#define GNU_PROPERTY_NO_COPY_ON_PROTECTED	2

// Processor-specific semantics, lo
// 特定于处理器的语义类型值范围的下限。
#define GNU_PROPERTY_LOPROC			0xc0000000
// Processor-specific semantics, hi 
// 特定于处理器的语义类型值范围的上限。
#define GNU_PROPERTY_HIPROC			0xdfffffff

// Application-specific semantics, lo 
// 特定于应用程序的语义类型值范围的下限。
#define GNU_PROPERTY_LOUSER			0xe0000000
// Application-specific semantics, hi 
// 特定于应用程序的语义类型值范围的上限。
#define GNU_PROPERTY_HIUSER			0xffffffff

/* The x86 instruction sets indicated by the corresponding bits are used in program. Their support in the hardware is optional. */
/* 程序中使用相应的位表示的x86指令集。它们在硬件上的支持是可选的。 */
#define GNU_PROPERTY_X86_ISA_1_USED		0xc0000000
/* The x86 instruction sets indicated by the corresponding bits are used in program and they must be supported by the hardware. */
/* 程序中使用相应的位表示的x86指令集，它们必须得到硬件的支持 */
#define GNU_PROPERTY_X86_ISA_1_NEEDED		0xc0000001
/* X86 processor-specific features used in program. */
/* 在程序中使用的特定的x86处理器特性。*/
#define GNU_PROPERTY_X86_FEATURE_1_AND		0xc0000002

/* This indicates that all executable sections are compatible with IBT. */
/* 这表明所有可执行节都与IBT兼容 */
#define GNU_PROPERTY_X86_FEATURE_1_IBT		(1U << 0)
/* This indicates that all executable sections are compatible with SHSTK. */
/* 这表明所有可执行节都与SHSTK兼容。*/
#define GNU_PROPERTY_X86_FEATURE_1_SHSTK	(1U << 1)

#define GNU_PROPERTY_X86_ISA_1_486		    (1U << 0)
#define GNU_PROPERTY_X86_ISA_1_586		    (1U << 1)
#define GNU_PROPERTY_X86_ISA_1_686		    (1U << 2)
#define GNU_PROPERTY_X86_ISA_1_SSE		    (1U << 3)
#define GNU_PROPERTY_X86_ISA_1_SSE2		    (1U << 4)
#define GNU_PROPERTY_X86_ISA_1_SSE3		    (1U << 5)
#define GNU_PROPERTY_X86_ISA_1_SSSE3		(1U << 6)
#define GNU_PROPERTY_X86_ISA_1_SSE4_1		(1U << 7)
#define GNU_PROPERTY_X86_ISA_1_SSE4_2		(1U << 8)
#define GNU_PROPERTY_X86_ISA_1_AVX		    (1U << 9)
#define GNU_PROPERTY_X86_ISA_1_AVX2		    (1U << 10)
#define GNU_PROPERTY_X86_ISA_1_AVX512F		(1U << 11)
#define GNU_PROPERTY_X86_ISA_1_AVX512CD		(1U << 12)
#define GNU_PROPERTY_X86_ISA_1_AVX512ER		(1U << 13)
#define GNU_PROPERTY_X86_ISA_1_AVX512PF		(1U << 14)
#define GNU_PROPERTY_X86_ISA_1_AVX512VL		(1U << 15)
#define GNU_PROPERTY_X86_ISA_1_AVX512DQ		(1U << 16)
#define GNU_PROPERTY_X86_ISA_1_AVX512BW		(1U << 17)
/* ---------------------------------------------------------------------------------------- */

5.1.5 .note.GNU-stack

  .note.GNU-stack的内容告诉系统将ELF加载到内存时如何控制堆栈。

  此节(Section)用于在Linux目标文件(Odject File)中声明堆栈属性。此节(Section)的节类型是SHT_PROGBITS。唯一使用的节标志(sh_flags)是SHF_EXECINSTR。这向GNU链接器表明目标文件(Odject File)需要一个可执行堆栈。[^11]

参考：
1、Hardened/GNU stack quickstart
2、Why data and stack segments are executable?

5.1.6 .note.stapsdt

  LTTng是Linux的开源跟踪框架。

  使用LTTng的用户空间动态跟踪通过Hook到代码中的预定位置来工作，这些位置可以是ELF函数(ELF functions)或SDT探针(Statically Defined Tracing Probes)。

  ELF文件的函数列在文件元数据的符号表(Symbol Table)中。您无需执行任何特殊操作即可使这些函数可以用于跟踪(Tracing)。

  另一方面，SDT探针(SDT probes)由其作者单独插入到应用程序(Apps)和库(Libraries)中，并且需要额外的工具链支持。SDT探针(SDT probes)用于许多Linux发行版上的各种库和应用程序，它们是通过在源代码中使用STAP_PROBE*系列宏的任何位置插入nop指令来实现的。使用nop指令作为占位符允许在附加探针时插入其他可执行指令，但在禁用它们时几乎不会影响性能。

  无论您是在跟踪ELF函数(ELF functions)还是SDT探针(SDT probes)，实际的探针插入和事件记录都由Linux内核的uprobe接口处理，并且事件记录在内核的缓冲区中。这意味着您需要一个以root身份运行的会话守护程序来加载所需的内核模块并使用此功能。

附加到一个SDT探针：

  与跟踪库函数不同，开发人员明确插入SDT探针以帮助调试和跟踪，这意味着它们被战略性地(Strategically)放置在代码中您可能需要附加到探针的位置。例如，libc:memory_sbrk_more探针位于libc的malloc()中，当需要分配更多内存来为内存请求提供服务时，会记录sbrk()系统调用的参数。

  在附加到SDT探针之前，您需要知道您正在使用的应用程序库中有哪些探针可用。您可以通过使用readelf查看ELF注释节(Notes Section)来发现探针列表。例如，这里是readelf显示的libc.so.6库的ELF注释节(Notes Section)的一部分。

1
2
3
4
5
6
7
8
9
10

$ readelf -n /lib/x86_64-linux-gnu/libc.so.6
 [...]
 Displaying notes found in: .note.stapsdt
   Owner                 Data size	Description
   stapsdt              0x0000003a	NT_STAPSDT (SystemTap probe descriptors)
     Provider: libc
     Name: setjmp
     Location: 0x000000000003ebb1, Base: 0x00000000001bdd48, Semaphore: 0x0000000000000000
     Arguments: 8@%rdi -4@%esi 8@%rax
 [...]

  您感兴趣的是stapsdt拥有的带有NT_STAPSDT描述的注释部分。这些注释部分显示了库或应用程序中的所有探针，以及每个条目中最重要的部分，Provider和Name - 附加到探针时您将需要这两个部分。

参考：The new dynamic user space tracing feature in LTTng

5.1.7 .stapsdt.base

  SystemTap是一个Linux非常有用的调试(跟踪/探测)工具，常用于Linux内核或者应用程序的信息采集，比如：获取一个函数里面运行时的变量、调用堆栈，甚至可以直接修改变量的值，对诊断性能或功能问题非常有帮助。SystemTap提供非常简单的命令行接口和很简洁的脚本语言，以及非常丰富的tapset和例子。

  Systemtap使用编译器宏来注册它的SDT探针，因此不可能在运行时注册探针。下面显示了一个示例，我们将一个名为Probe的探针注册到一个名为Provider的提供者。

1
2
3
4
5
6

#include <sys/sdt.h>

int main() {
    DTRACE_PROBE(Provider, Probe);
    return 0;
}

  此代码生成的二进制文件将有一个名为.stapsdt.base的新的ELF节(Section)，位于代码之后(通常是.text节)。此基址(Base)与帮助跟踪工具在二进制文件加载到内存后计算任何探针的内存地址相关。

  它还将有一个ELF注释节(Notes Section)，其中将存储所有探针数据[名称(name)、地址(address)、信号量(semaphores)、参数(arguments)]以供任何跟踪工具稍后读取。编译器还将用函数调用替换我们的DTRACE_PROBE宏，这就是探针指向的地方，从而可以轻松地将参数传递给探针。此函数是空操作(no-op)。

1
2
3
4
5
6
7

Displaying notes found at file offset 0x00001064 with length 0x0000003c:
  Owner                 Data size       Description
  stapsdt              0x00000028       NT_STAPSDT (SystemTap probe descriptors)
    Provider: Provider
    Name: Probe
    Location: 0x00000000004004da, Base: 0x0000000000400574, Semaphore: 0x0000000000000000
    Arguments:

  这里有更多关于Systemtap如何实现SDT探针的信息。

参考：libstapsdt - How Systemtap SDT works

5.1.8 .note.openbsd.ident

  OpenBSD原生可执行文件通常包含此节(Section)来标识自己，因此内核可以在加载文件时绕过任何兼容性ELF二进制仿真测试。[^11]

5.2 Hash Related Sections

  高版本GCC编译完的程序，一般只包含.gnu.hash节。我们可以使用如下参数编译程序，使其拥有两种或两种中的一种Hash表。

1
2
3

gcc test.c -Wl,--hash-style=sysv -o test    # 只有.hash
gcc test.c -Wl,--hash-style=gnu -o test     # 只有.gnu.hash
gcc test.c -Wl,--hash-style=both -o test    # .hash和.gnu.hash都有

  上面的命令行参数的意义如下：

-Wl,<options\>：传递以逗号分隔的选项给链接器(Linker)。
--hash-style=：链接器(Linker)选项，设置链接器(Linker)给编译后的ELF文件添加的Hash表的类型。

5.2.1 Hash函数

  符号名中@及其后的所有字符都不参与Hash计算。

  使用下列命令，可以查看某种Hash算法在某一对象中的表现情况：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

$ readelf -I libc-2.23-64.so 

Histogram for bucket list length (total of 1017 buckets):
 Length  Number     % of total  Coverage
      0  622        ( 61.2%)
      1  260        ( 25.6%)     46.7%
      2  109        ( 10.7%)     85.8%
      3  25         (  2.5%)     99.3%
      4  1          (  0.1%)    100.0%

Histogram for `.gnu.hash' bucket list length (total of 1011 buckets):
 Length  Number     % of total  Coverage
      0  104        ( 10.3%)
      1  232        ( 22.9%)     10.4%
      2  286        ( 28.3%)     36.0%
      3  208        ( 20.6%)     63.9%
      4  120        ( 11.9%)     85.4%
      5  41         (  4.1%)     94.5%
      6  18         (  1.8%)     99.4%
      7  2          (  0.2%)    100.0%

  Length表具有相同(hash % nBucket)值的符号对应的Chains[]表元素形成的Chain中的元素数量，Number为某一Chain的数量，也是相应Buckets[]元素的数量(其保存Chain首元素的索引)。

5.2.1.1 .hash Hash函数[^1]

  .hash使用的Hash函数是ELF Hash(Sysv Hash)。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

unsigned long elf_hash(const unsigned char *name)
{
    unsigned long h = 0, g;
    while (*name)
    {
        h = (h << 4) + *name++;     // hash左移4位，把当前字符ASCII存入hash低8位。 
        if (g = h & 0xf0000000)
            // 如果最高的四位不为0，则说明字符多余7个，现在正在存第7个字符，如果不处理，再加下一个字符时，第一个字符会被移出，因此要有如下处理。
            // 该处理，如果最高位为0，就会仅仅影响5-8位，否则会影响5-32位，因为C语言使用的算数移位。
            // 因为1-4位刚刚存储了新加入到字符的低4位，所以不能>>28。
            // 这行代码并不会对g有影响，g本身和hash的高4位相同。
            h ^= g >> 24;
        // 下面这行代码&~即对29-32位(高4位)清零。
        h &= ~g;
    }
    return h;
}

5.2.1.2 .gnu.hash Hash函数[^8]

  .gnu.hash使用的Hash函数是DJB Hash，该Hash算法由Bernstein(Daniel J Bernstein)教授在多年以前发表在comp.lang.c新闻组(usenet newsgroup):

1
2
3
4
5
6
7
8
9

uint32_t dl_new_hash(const char *s)
{
    uint32_t h = 5381;

    for(unsigned char c = *s; c != '\0'; c = *++s)
        h = h * 33 + c;

    return h;
}

  如果你在线搜索这个算法，你会发现表达式“h = h * 33 + c”以另一种方式表示：

1

h = ((h << 5) + h) + c

  它们是等价的语句，将整型乘法运算替换成成本更低的移位和加法运算。实际中是否能够降低成本取决于使用的CPU。对旧机器来说这两种形式将会有显著差异，但是对当代机器来说整型乘法运算相当的快。

  该算法的另一种变化是将返回值剪切为31位:

1

return h & 0x7fffffff;

  然而，GNU Hash使用完整的32位无符号结果。

  GNU binutils实现使用uint_fast32_t类型来计算哈希。此类型被定义为当前系统上能够表示至少32位的最快的可用整数型机器类型。由于可能使用更宽的类型实现，结果在返回之前被显式地剪切为32位的无符号值。

1
2
3
4
5
6
7
8
9

static uint_fast32_t dl_new_hash(const char *s)
{
    uint_fast32_t h = 5381;

    for(unsigned char c = *s; c != '\0'; c = *++s)
        h = h * 33 + c;

    return h & 0xffffffff;
}

5.2.2 .hash

5.2.2.1 .hash表结构

  标准哈希表(.hash)由链接器(Link Editor)构建。此节(Section)的节类型是SHT_HASH，使用的属性是SHF_ALLOC。动态节(Dynamic Section)中此节的节标记为DT_HASH。它的结构非常简单：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

// Pseudo-C
struct {
    Elf32_Word nBucket;            /* Number of buckets */
    Elf32_Word nChain;             /* Numer of entries in .dynsym */
    Elf32_Word Buckets[nbucket];   /* First entry in the chain */
    Elf32_Word Chains[nchain];     /* Next entry in the chain */
};

struct {
    Elf64_Word nBucket;            /* Number of buckets */
    Elf64_Word nChain;             /* Numer of entries in .dynsym */
    Elf64_Word Buckets[nbucket];   /* First entry in the chain */
    Elf64_Word Chains[nchain];     /* Next entry in the chain */
};

  哈希表(Hash Table)由Elf32_Word或Elf64_Word对象组成，其提供对符号表(Symbol Table)的访问。与哈希表(Hash Table)中哈希相关联的符号表(Symbol Table)在哈希表的节头(Section Header)的sh_link条目中指定。下图中使用标签来帮助解释哈希表(Hash Table)的组织形式，但这些标签不是此规范的一部分。

Figure 5-3：Symbol Hash Table

  Buckets表包含nBucket个项，Chains表包含nChain个项。索引从0开始。Buckets和Chains都保存符号表索引。Chains表项与符号表(Symbol Table)项是平行的。符号表项的数量应等于nChain，因此符号表索引也可以索引Chains表项。

  一个接受符号名称的Hash函数，返回一个值来计算Bucket表索引。因此，如果Hash函数返回某个符号名称的hash值，通过Buckets[hash % nBucket]可以得到一个索引index。该索引是符号表和Chain表的索引。如果符号表项不包含所需的符号名称，Chains[index]给出具有相同(hash % nBucket)值的下一个符号的符号表项索引。

  可以跟踪Chain链，直到所选符号表项包含所需名称，或者Chain表项包含值STN_UNDEF。这个特殊的索引值表示Chain的结尾，意味着在Chain表中找不到更多的符号表索引。[^6]

总结如下：
Buckets[hash % nBucket]：给出动态符号表(Dynamic Symbol Table)符号项的索引或Chains数组的初始索引。根据动态链接符号的数量来获得。(binutils/bfd/elflink.c有具体细节)
Chains[index]：给出Chains[]中的下一个项的索引(与前一项具有相同的(hash % nBucket)值)。
index：STN_UNDEF标记Chain的结尾(具有相同Hash值的符号对应的Chains[]元素形成的Chain)。

参考：binutils/bfd/elflink.c有具体细节，bfd_elf_size_dynsym_hash_dynstr()。

  查找过程是这样的:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

const Elf64_Sym* lookup_symbol(
    const char* symbol,
    const Elf64_Sym* symbol_table
    const char* string_table,
    const Elf32_Word* hash_table)
{
    Elf32_Word nbucket           = hash_table[0];
    Elf32_Word nchain            = hash_table[1];
    const Elf32_Word* buckets    = hash_table + 2;
    const Elf32_Word* chains     = hash_table + 2 + nbucket;
    Elf32_Word index;

    unsigned int hash = elf_hash(symbol_name);

    // Iterate on the chain:
    for(index = buckets[hash % nbucket]; chains[index] != STN_UNDEF; index = chains[index])
        if (strcmp(symbol, string_table + symbol_table[index].st_name) == 0)
            return symbol_table + index;

    return NULL;
}

5.2.2.2 符号查找实例

  首先我们写一个计算符号名Hash的程序：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

// gcc hash.c -o hash
#include <stdio.h>

unsigned int elf_hash(const unsigned char *name)
{
    unsigned int h = 0, g;
    while (*name)
    {
        h = (h << 4) + *name++;
        if (g = h & 0xf0000000)
            h ^= g >> 24;
        h &= ~g;
    }
    return h;
}

int main(int argc, char** argv) {
   printf("%X\n", elf_hash(argv[1]));
   return 0;
}

  这里使用libc6_2.23-0ubuntu11.2_amd64的libc-2.23-64.so(我重命名了)来做测试，使用64位的程序，主要是为了证明不管是32位程序还是64位程序，通过ELF Hash来进行符号查找，Hash的位数都是32位，而且.hash表中的内容由Elf32_Word(32位)或Elf64_Word(32位)对象组成。我们随便找一个示例程序中的符号来进行测试，以“putwchar”为例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

$ readelf -s libc-2.23-64.so 

Symbol table '.dynsym' contains 2245 entries:
   Num:    Value          Size Type    Bind   Vis      Ndx Name
     0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND 
     1: 000000000001f8b0     0 SECTION LOCAL  DEFAULT   13 
     2: 00000000003c07c0     0 SECTION LOCAL  DEFAULT   23 
     3: 0000000000000000     0 OBJECT  GLOBAL DEFAULT  UND _rtld_global@GLIBC_PRIVATE (26)
     4: 0000000000000000     0 OBJECT  GLOBAL DEFAULT  UND __libc_enable_secure@GLIBC_PRIVATE (26)
     5: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __tls_get_addr@GLIBC_2.3 (27)
     6: 0000000000000000     0 OBJECT  GLOBAL DEFAULT  UND _rtld_global_ro@GLIBC_PRIVATE (26)
     7: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND _dl_find_dso_for_object@GLIBC_PRIVATE (26)
     8: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND _dl_starting_up
     9: 0000000000000000     0 OBJECT  GLOBAL DEFAULT  UND _dl_argv@GLIBC_PRIVATE (26)
    10: 0000000000071100   349 FUNC    GLOBAL DEFAULT   13 putwchar@@GLIBC_2.2.5    <----
    11: 000000000009ec20    32 FUNC    GLOBAL DEFAULT   13 __strspn_c1@@GLIBC_2.2.5
    12: 00000000001187e0    16 FUNC    GLOBAL DEFAULT   13 __gethostname_chk@@GLIBC_2.4
    13: 000000000009ec40    37 FUNC    GLOBAL DEFAULT   13 __strspn_c2@@GLIBC_2.2.5
    [...]

  从上面的输出信息中，我们可以知道动态符号表(Dynamic Symbol Table)总共有2245项，符号“putwchar”的索引为10。通过上面计算Hash的函数进行计算“putwchar”的Hash：

1
2

$ ./hash putwchar
CBD99F2

  接下来，我们需要计算Bucket表索引，使用Bucket[hash % nBucket]公式。所以我们需要知道nBucket的值。我们将libc-2.23-64.so使用IDA打开，找到.hash节所在位置，IDA不能很好地识别.hash，所以需要我们自己添加一个Section，并使用IDA Python脚本对.hash节的内容进行解析，结果如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

.hash:001BC8A8 _hash segment byte public '' use32
.hash:001BC8A8       assume cs:_hash
.hash:001BC8A8       ;org 1BC8A8h
.hash:001BC8A8       assume es:nothing, ss:nothing, ds:nothing, fs:nothing, gs:nothing
.hash:001BC8A8       dd 3F9h                 ; nbucket
.hash:001BC8AC       dd 8C5h                 ; nchain
-----------------------------------------------------------------------------------------------------------------------------------
.hash:001BC8B0       dd 1D5h, 30Ah, 88Bh, 400h, 59Dh, 2BDh, 0, 0B0h, 658h, 66Ah, 0A6h, 416h, 118h, 468h, 18Bh, 6E2h     ; 0  ; bucket
.hash:001BC8B0       dd 1D1h, 3C4h, 779h, 5EAh, 441h, 543h, 0, 2DBh, 753h, 0, 77Dh, 5D3h, 6BFh, 3E2h, 3CCh, 5F2h        ; 10h
.hash:001BC8B0       dd 141h, 0, 872h, 83Fh, 72h, 6CBh, 564h, 7BFh, 8BEh, 71Dh, 453h, 40Eh, 726h, 5A4h, 7A3h, 4Dh       ; 20h
[...]
.hash:001BC8B0       dd 6DCh, 27Dh, 6F5h, 66Ch, 275h, 530h, 74h, 0Ah, 828h, 2D6h, 34Ch, 5A6h, 72Ah, 3CEh, 663h, 6EAh    ; 100h
.hash:001BC8B0       dd 0, 0, 391h, 7E4h, 793h, 636h, 0, 718h, 4DBh, 881h, 2EDh, 780h, 242h, 1A1h, 486h, 2FCh           ; 110h
.hash:001BC8B0       dd 21Dh, 73Fh, 54Ch, 0, 745h, 0, 413h, 26Bh, 53h, 44h, 94h, 2FDh, 0, 3, 50Eh, 7BEh                 ; 120h
[...]
.hash:001BC8B0       dd 7C4h, 3E8h, 5CAh, 80Fh, 0, 4E4h, 48Fh, 386h, 0, 0, 7ACh, 0B6h, 0, 5C2h, 1C7h, 30Eh              ; 3D0h
.hash:001BC8B0       dd 1A6h, 738h, 7Ch, 6D4h, 1B7h, 14h, 68Bh, 4DAh, 3DDh, 6Ch, 62h, 30h, 3FDh, 4E7h, 7CEh, 4C7h       ; 3E0h
.hash:001BC8B0       dd 32Ch, 669h, 487h, 7A8h, 7F4h, 301h, 599h, 0, 35Ch                                               ; 3F0h
-----------------------------------------------------------------------------------------------------------------------------------
.hash:001BD894       dd 0, 0, 0, 0, 0, 0, 0, 32Dh, 0, 0, 3E6h, 3BEh, 102h, 79Ch, 510h, 6CCh                             ; 0 ; chain
.hash:001BD894       dd 0, 0, 0, 0, 33h, 81Eh, 0, 0, 177h, 0BBh, 0, 0, 3E3h, 532h, 0, 0                                 ; 10h
.hash:001BD894       dd 552h, 3B6h, 861h, 0, 23h, 0, 7B9h, 63Ch, 0, 0, 0, 5DCh, 0, 0, 313h, 723h                        ; 20h
[...]
.hash:001BD894       dd 0, 367h, 473h, 19Fh, 0, 804h, 1F2h, 0, 1D7h, 47Ch, 499h, 7Ah, 857h, 491h, 65Ah, 74Fh            ; 8A0h
.hash:001BD894       dd 0, 0, 71Fh, 0, 210h, 0, 0, 372h, 4B8h, 0, 0, 29Eh, 727h, 0, 276h, 0                             ; 8B0h
.hash:001BD894       dd 3CDh, 640h, 0, 86h, 28Dh                                                                        ; 8C0h

  我们可以知道nBucket为0x3F9=1017，nChain为0x8C5=2245。nChain等于动态符号表(Dynamic Symbol Table)的项数。接下来我们计算Bucket表索引，并得到对应Bucket表项的值：

1

Bucket[hash % nBucket] = Bucket[0xCBD99F2 % 0x3F9] = Bucket[0x107] = 0x0Ah = 10

  我们可以看到Bucket数组相应表项的内容就是所查找符号在动态符号表(Dynamic Symbol Table)中的索引。

  我们可以使用如下命令查看符号表中符号索引与Buckets[]数组索引的对应关系：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

$ readelf -sD libc-2.23-64.so 

Symbol table for image:
  Num Buc:    Value          Size   Type   Bind Vis      Ndx Name
  469   0: 00000000000ace20   530 FUNC    GLOBAL DEFAULT  13 __mbrtowc
  949   0: 00000000000fe6a0    89 FUNC    GLOBAL DEFAULT  13 __setmntent
 1604   0: 0000000000034ee0    55 FUNC    WEAK   DEFAULT  13 isnanl
  778   1: 000000000002d800   187 FUNC    WEAK   DEFAULT  13 freelocale
   33   1: 0000000000117db0   231 FUNC    GLOBAL DEFAULT  13 __vswprintf_chk
  950   1: 00000000001025a0   219 FUNC    WEAK   DEFAULT  13 hcreate_r
 2187   2: 00000000000ea7e0    22 FUNC    GLOBAL DEFAULT  13 getopt_long_only
 1024   3: 0000000000131cc0   197 FUNC    GLOBAL DEFAULT  13 endrpcent
  472   3: 0000000000115050    38 FUNC    GLOBAL DEFAULT  13 pthread_mutex_lock
 2222   3: 00000000003c4b00     8 OBJECT  WEAK   DEFAULT  33 __memalign_hook
 1626   3: 0000000000034b60    33 FUNC    WEAK   DEFAULT  13 isinff
 1437   4: 00000000000fca50    33 FUNC    WEAK   DEFAULT  13 setrlimit
  701   5: 000000000010b6e0   188 FUNC    GLOBAL DEFAULT  13 getspent
 1714   5: 0000000000107530     7 FUNC    WEAK   DEFAULT  13 umount
 2090   5: 0000000000096a90    69 FUNC    GLOBAL DEFAULT  13 __argz_count
  400   5: 0000000000127800   161 FUNC    GLOBAL DEFAULT  13 __res_nclose
  176   7: 000000000008d8f0   524 FUNC    GLOBAL DEFAULT  13 strsignal
 1078   7: 000000000007bfb0    54 FUNC    GLOBAL DEFAULT  13 _IO_sungetc
 1624   8: 000000000009eaa0   159 FUNC    GLOBAL DEFAULT  13 __stpcpy_small
  427   8: 0000000000106190    33 FUNC    GLOBAL DEFAULT  13 listxattr
  283   8: 00000000003c6f38     8 OBJECT  WEAK   DEFAULT  34 _environ
 1642   9: 0000000000034e90    69 FUNC    WEAK   DEFAULT  13 isinfl
  166  10: 0000000000115270    90 FUNC    GLOBAL DEFAULT  13 __libc_pthread_init
 1489  10: 00000000001176b0    19 FUNC    GLOBAL DEFAULT  13 __recv_chk
[...]

  Num列为动态符号表(.dynsym)索引，Buc列为Buckets[]数组索引。我们可以看到有三个符号都与Buckets[0]相关联，这三个符号计算出的Hash值对nBucket求模，结果都是0。我们可以通过以下方法访问到这三个符号：

1
2
3
4
5
6
7

Buckets[0](469) --> Chains[469](949) --> Chains[949](1604)
            |                    |                    |
            ↓                    ↓                    ↓
        dynsym[469]          dynsym[949]          dynsym[1604]
            |                    |                    |
            ↓                    ↓                    ↓
        __mbrtowc            __setmntent            isnanl

5.2.3 .gnu.hash

  GNU哈希表(.gnu.hash)是标准哈希表(.hash)的更有效的替代方案。两者都可以出现在同一个ELF文件中，但现代GNU ELF文件通常只包含GNU哈希表。此节(Section)的节类型是SHT_GNU_HASH，动态节(Dynamic Section)中此节的节标记为DT_GNU_HASH。

主要区别：

• 它添加了一个Bloom Filter以加速无效查找(Negative Lookups)。无效查找是常见的情况，因为符号是按顺序在不同的ELF文件中搜索的。
• 它在Hash Chain的每个条目中保存哈希值以避免无用的字符串比较。(比较Hash值比比较字符串更快)
• 通过避免在哈希表内存中跳转，它对缓存更加友好。
• 它使用DJB Hash函数。

  .gnu.hash节由四个独立的部分组成，顺序如下:

Header：一个提供节参数的32位(4字节)字数组。
Bloom Filter：此Filter用于快速拒绝在对象中不存在的符号的查找请求。
Hash Buckets：一个拥有nbuckets个32位Hash Bucket的数组。第N个Bucket字的内容为动态符号表(Dynamic Symbol Table)中具有相同(hash % nbuckets == N)的符号项的最低索引。
Hash Chains(Hash Values)：GNU Hash节的最后一部分包含(dynsymcount - symndx)个32位字，动态符号表(Dynamic Symbol Table)的第二部分中的每个符号对应一个条目。

  .gnu.hash表的结构如下所示：

1
2
3
4
5
6
7
8
9
10

// Pseudo-C
struct GNU_Hash_Table {
    uint32_t nBuckets;                      /* Number of buckets */
    uint32_t Symndx;                        /* Index of the first accessible symbol in .dynsym */
    uint32_t Maskwords;                     /* Number of elements in the Bloom Filter */
    uint32_t Shift2;                        /* Shift count for the Bloom Filter */
    uintXX_t Bloom_Filter[Maskwords];       /* Bloom Filter */
    uint32_t Buckets[nBuckets];             /* Buckets */
    uint32_t Chains[dynsymCount - Symndx];  /* Hash Chains(Hash Values) */
};

  Header、Bloom Filter、Buckets和Chains始终是32位字，而Bloom Filter可以是32位或64位字，具体取决于ELF对象的类别。这意味着ELFCLASS32类型的.gnu.hash节仅包含32位字，因此将它们的节头中的sh_entsize字段设置为4。ELFCLASS64类型的.gnu.hash节既包含32位字，也包含64位字，因此将sh_entsize设置为0。

  假设.gnu.hash节已正确对齐以访问ELFCLASS大小的字，则在Bloom Filter之前紧接着的32位字(4个)确保了Filter Mask字始终正确对齐并可直接在内存中访问。

5.2.3.1 Dynamic Section Requirements[^8]

  GNU Hash节(.gnu.hash)对动态符号表(Dynamic Symbol Table)的内容设置了一些额外的排序要求。这与标准SVR4 Hash节(.hash)形成了对比，后者允许符号按ELF标准允许的任何顺序排列。

  一个标准的SVR4哈希表(.hash)包含动态符号表(Dynamic Symbol Table)中的所有符号。然而，其中一些符号永远不会通过.gnu.hash中查找到：

• 本地符号(LOCAL Symbols)：除非被重定位引用(在某些架构上)
• 文件符号(FILE Symbols)
• 对于共享对象(Sharable Objects)：所有UNDEF符号
• 对于可执行文件(Executables)：任何未被PLT引用的UNDEF符号
• 特殊索引0对应的符号(UNDEF的一种特殊情况)

  上面所说都是针对.gnu.hash节的，我经过测试libc6_2.23-0ubuntu11.2_amd64的libc-2.23-64.so(我重命名了)中的符号“_rtld_global”是UNDEF的，但是可以在.hash表中找到其在动态符号表(Dynamic Symbol Table)中的索引。

  从哈希表节(Hash Table Section)省略这些符号不会影响正确性，并且会导致更少的哈希表拥塞(Congestion)、更短的哈希链(Chains)以及相应地更好的哈希性能。

  使用GNU哈希(.gnu.hash)，动态符号表(Dynamic Symbol Table)被分为两部分。第一部分接收可以从哈希表(.hash)中省略的符号。GNU哈希(.gnu.hash)不会对动态符号表(Dynamic Symbol Table)的这一部分中的符号强加任何特定的顺序。

  动态符号表(Dynamic Symbol Table)的后半部分接收可从.gnu.hash访问的符号。这些符号需要使用上述GNU Hash函数进行升序排序(hash % nBuckets)。Hash Buckets的数量(nBuckets)记录在GNU Hash节中，如下所述。因此，在单个哈希链(Hash Chain)中找到的符号的符号表项和Chains[]数组元素在内存中都是相邻的，从而获得更好的缓存性能。

5.2.3.2 Header

  Header中包含4个32位字的节参数：

• nBuckets：Buckets[]中元素的数量。根据动态链接符号的数量来获得(最小值为2)。
  
• Symndx：动态符号表(.dynsym)具有dynsymCount个符号，Symndx是动态符号表(.dynsym)中可通过.gnu.hash表访问的第一个符号的索引。这意味着可通过.gnu.hash表访问(dynsymCount - Symndx)个符号。
  
• Maskwords：.gnu.hash节中Bloom Filter部分中ELFCLASS大小的掩码字(Mask Word)的数量。该值必须为非0，并且必须是2的幂，如下所述。请注意，值0可以解释为.gnu.hash中不存在Bloom Filter。然而，GNU链接器(GNU linkers)不会这样做 —— .gnu.hash节总是包含至少1个掩码字(Mask Word)。
  
• Shift2：用于Bloom Filter产生第二个Hash函数的移位计数。细节见下方。

参考：binutils/bfd/elflink.c有具体细节，bfd_elf_size_dynsym_hash_dynstr()。

5.2.3.3 Bloom Filter

  GNU Hash节包括一个Bloom Filter。Bloom Filter是概率性的(Probabilistic)，这意味着可能会出现误报(False Positives)，但不会出现漏报(False Negatives)(换句话说，就是通过Bloom Filter的不一定在Hash表中，但不通过的一定不在Hash表中)。此Bloom Filter用于快速拒绝在对象中不存在的符号的查找请求，从而避免更耗时的哈希查找操作。通常，一个进程中只有一个对象具有给定的符号。跳过对所有其他对象的哈希操作可以大大加快符号查找速度。

  Bloom Filter由Maskwords个掩码字(Mask Word)组成，每个字是32位(ELFCLASS32)或64位(ELFCLASS64)，具体取决于ELF对象的类别。在下面的讨论中，C将用于代表一个掩码字(Mask Word)的大小(以bit为单位)。掩码字(Mask Word)共同组成一个拥有(C * Maskwords)个位的逻辑位掩码(Logical Bitmask)。

  GNU Hash使用k=2的Bloom Filter，这意味着每个符号使用两个独立的Hash函数。Bloom Filter参考包含以下语句：

  对于较大的k，不需要设计k个不同的独立Hash函数。对于具有宽输出的良好Hash函数，此类Hash的不同位域(bit-fields)之间应该几乎没有相关性，因此这种类型的Hash可用于通过将其输出切片为多个位域(bit-fields)来生成多个“不同”的Hash函数。

  GNU Hash所使用的Hash函数具有此属性。利用这一事实，可以从上面描述的单个Hash函数中产生Bloom Filter所需的两个Hash函数:

1
2

H1 = dl_new_hash(name);
H2 = H1 >> shift2;

  如上所述，链接器(Link Editor)确定要使用多少个掩码字(Maskwords个)，以及第一个Hash结果右移以产生第二个Hash结果的移位数(Shift2)。使用的掩码字(Mask Word)越多，Hash节越大，但误报率(False Positives)越低。我在私人电子邮件中被告知，GNU链接器(GNU Linker)首先从输入到哈希表(Hash Table)中的符号数(dynsymCount - Symndx)的以2为底的对数得到Shift2，对于ELFCLASS32的最小值为5，对于ELFCLASS64的最小值为6。这些值明确记录在哈希节(Hash Section)中，以便链接器(Link Editor)在将来出现更好的启发式方法时可以灵活地更改它们。

  Bloom Filter掩码为两个Hash值分别设置一位。根据Bloom Filter参考，要设置的bit所在的掩码字(Mask Word)和要设置的具体bit将按如下计算方法计算：

1
2
3
4
5

N1 = ((H1 / C) % Maskwords);    // 要设置的bit所在的掩码字(Mask Word)
N2 = ((H2 / C) % Maskwords);

B1 = H1 % C;                    // 要设置的具体bit
B2 = H2 % C;

  在构建Filter时设置位：

1
2

Bloom[N1] |= (1 << B1);
Bloom[N2] |= (1 << B2);

  然后对Filter进行测试：

1

(Bloom[N1] & (1 << B1)) && (Bloom[N2] & (1 << B2))

  GNU Hash与上述内容有很大的不同。不是分别计算N1和N2，而是使用单个掩码字(Mask Word)，对应于上面的N1。这是GNU Hash开发人员为优化缓存行为而做出的合理的(Conscious)决定：

  这使得Bloom Filter的2个Hash函数比使用两个不同的N时更加依赖，但在我们的测试中，拒绝应该被拒绝的查找的比率仍然非常好，并且对缓存更加友好。在查找期间尽可能少地接触缓存行(Cache Lines)是非常重要的。

  因此，在GNU Hash中，单个掩码字(Mask Word)实际上通过如下方式进行计算：

1

N = ((H1 / C) % Maskwords);

  设置Bloom Filter掩码字N中的两个位的方式如下所示：

1

BITMASK = (1 << (H1 % C)) | (1 << (H2 % C));

  链接器(Link-Editor)设置这些位的方式如下：

1

Bloom[N] |= BITMASK;

5.2.3.3.1 Bit Fiddling: 为何maskwords应为2的幂

  通常，Bloom Filter可以使用任意数量的字(Words)来构造。但是，如上所述，GNU Hash要求Maskwords是2的幂(Maskwords只有1位为1)。这个要求允许下面的取模操作写成一个简单的掩码操作:

1
2
3
4

N = ((H1 / C) % Maskwords);
        |           |
        ↓           ↓
N = ((H1 / C) & (Maskwords - 1));

  注意(Maskwords - 1)可以预先计算一次，然后用于每一个Hash：

1
2
3

MASKWORDS_BITMASK = Maskwords - 1;

N = ((H1 / C) & MASKWORDS_BITMASK);

5.2.3.3.2 Bloom Filter特殊情况

  Bloom Filter有两个有趣的特殊情况：

• 当Bloom Filter的所有位都设置时，所有测试都会产生一个True值(接受符号查找请求)。GNU链接器(GNU Linker)利用这一点，当它想要“禁用”Bloom Filter时，.gnu.hash节包含一个所有位都设置的1个掩码字(Mask Word)的Bloom Filter。Bloom Filter仍然存在，并且仍在使用，开销最小，但它让一切都通过。
• 掩码字(Mask Word)中的任何一位都没有设置的Bloom Filter在所有情况下都将返回False。这种情况在ELF文件中比较少见，因为不导出符号的对象的应用有限。然而，有时对象是以这种方式构建的，其依赖于.init/.fini节来运行来自对象的代码。

5.2.3.4 Buckets[]

  Bloom Filter之后是nBuckets个32位字。第N个字的内容为动态符号表(Dynamic Symbol Table)中具有相同(hash % nBuckets)结果的符号项的最低索引，其中：

1

(dl_new_hash(symname) % nBuckets) == N

  由于动态符号表(Dynamic Symbol Table)按相同的键(hash % nBuckets)排序，因此dynsym[Buckets[N]]是包含所需符号(如果存在)的Hash Chain的第一个符号。

  如果Hash Table中没有给定值N的符号，则Bucket[]数组元素将包含索引0。由于dynsym的索引0是保留值，该索引不会出现在有效符号中，因此是没有歧义的。

5.2.3.5 Chains[]

  GNU Hash节的最后一部分Chains[]包含(dynsymCount - Symndx)个32位字，动态符号表(Dynamic Symbol Table)的第二部分中的每个符号对应一个Chains[]条目。每个字的高31位包含相应符号Hash的高31位。最低有效位用作停止位。当一个符号是给定Hash Chain中的最后一个符号时，它被设置为1：

1
2
3
4

lsb = (N == dynsymCount - 1) ||
      ((dl_new_hash(name[N]) % nBuckets) != (dl_new_hash(name[N + 1]) % nBuckets))

hashval = (dl_new_hash(name) & ~1) | lsb;

  由于Chains[]的元素中保存符号的Hash值，此节也被称作Values[]。

5.2.3.6 使用.gnu.hash节查找符号

  下面显示了如何使用.gnu.hash节在对象中查找符号。我们将假设存在包含所需信息的内存记录：

1
2
3
4
5
6
7
8
9
10
11

typedef struct {
    const char      *os_dynstr;      /* Dynamic string table */
    Sym             *os_dynsym;      /* Dynamic symbol table */
    Word            os_nbuckets;     /* The number of hash buckets */
    Word            os_symndx;       /* Index of 1st dynsym in hash */
    Word            os_maskwords_bm; /* The number of Bloom filter words, minus 1 */
    Word            os_shift2;       /* Bloom filter hash shift */
    const BloomWord *os_bloom;       /* Bloom filter words */
    const Word      *os_buckets;     /* Hash buckets */
    const Word      *os_hashval;     /* Hash value array */
} obj_state_t;

  为了简化问题，我们省略了处理不同ELFCLASS的细节。在上面，Word是一个32位无符号值，BloomWord是32位还是64位取决于ELFCLASS，而Sym是Elf32_Sym或Elf64_Sym。

  给定一个包含上述对象信息的变量，以下伪代码返回一个指向所需符号的符号表项的指针(如果该符号存在于对象中)，否则返回NULL。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75

Sym *symhash(obj_state_t *os, const char *symname)
{
    Word            c;
    Word            h1, h2;
    Word            n;
    Word            bitmask; 
    const Sym       *sym;
    Word            *hashval;

    /*
    * Hash the name, generate the "second" hash from it for the Bloom filter.
    * 对符号名求Hash,然后以其为基础为Bloom Filter计算第2个Hash.
    */
    h1 = dl_new_hash(symname);
    h2 = h1 >> os->os_shift2;

    /* Test against the Bloom filter */
    /* 验证Bloom Filter */
    c = sizeof(BloomWord) * 8;                      // 一个掩码字(Mask Word)包含的掩码位(Mask bit)的个数
    n = (h1 / c) & os->os_maskwords_bm;             // 求出要验证的掩码字在os_bloom[]中的索引
    bitmask = (1 << (h1 % c)) | (1 << (h2 % c));    // 求出本次要验证的掩码字中的位组成的位掩码
    if ((os->os_bloom[n] & bitmask) != bitmask)     // 本次要验证的掩码字中的位并未设置，说明要查找的符号不能通过该对象的.gnu.hash节找到
        return (NULL);

    /* Locate the hash chain, and corresponding hash value element */
    /* 定位Chains[]/hashval[]的位置，以及相应的Chains[]/hashval[]的元素 */
    n = os->os_buckets[h1 % os->os_nbuckets];       // 得到os_buckets[]中相应元素中存储的符号表索引/Chains[]索引
    if (n == 0)                                     // 符号不存在
        return (NULL);
    sym = &os->os_dynsym[n];                        // 符号可能存在，获取指向与待查找符号具有相同(h1 % os->os_nbuckets)值的最小索引的符号项的指针
    hashval = &os->os_hashval[n - os->os_symndx];   // 获取指向相应Chain在Chains[]中的首元素的指针

    /*
    * Walk the chain until the symbol is found or the chain is exhausted.
    * 遍历Chain，直到符号被找到，或到Chain结尾了
    */
    for (h1 &= ~1; 1; sym++) {
        h2 = *hashval++;

        /*
        * Compare the strings to verify match. Note that a given hash chain can contain different hash values. 
        * 比较字符串，以验证是否匹配。请注意，给定的Hash Chain可以包含不同的Hash值。
        * 
        * We'd get the right result by comparing every string, but comparing the hash values first lets us
        * screen obvious mismatches at very low cost and avoid the relatively expensive string compare.
        * 通过比较每个字符串，我们会得到正确的结果，但是首先比较Hash值可以让我们以非常低的成本明显的筛选出不匹配的情况，
        * 并避免相对耗时的字符串比较。
        *
        * We are intentionally glossing over some things here:
        * 这里我们有意地忽略了一些东西:
        *
        * - We could test sym->st_name for 0, which indicates a NULL string, and avoid a strcmp() in that case.
        * - 我们可以测试sym->st_name是否为0，这表示NULL字符串，并在这种情况下避免使用strcmp()。
        *
        * - The real runtime linker must also take symbol versioning into account. This is an orthogonal
        *   issue to hashing, and is left out of this example for simplicity.
        * - 真正的运行时链接器还必须考虑符号版本。这是Hash的一个正交问题，为了简单起见，本示例中省略了此问题。
        *
        * A real implementation might test (h1 == (h2 & ~1), and then call a (possibly inline) function to validate the rest.
        * 一个真正的实现可能会验证[h1 == (h2 & ~1)]，然后调用一个(可能是内联的)函数来验证其余的条件。
        */
        if ((h1 == (h2 & ~1)) &&                                // 所查找符号的Hash值是否与当前Chains[]元素中存储的Hash值相等
            !strcmp(symname, os->os_dynstr + sym->st_name))     // 比较待查找符号字符串与当前符号项对应的字符串
                return (sym);                                   // 找到了，返回响应符号项的指针

        /* Done if at end of chain */
        /* 如果已经到了Chain的结尾，则退出。 */
        if (h2 & 1)
            break;
    }

    /* This object does not have the desired symbol */
    /* 此对象没有所需的符号。 */
    return (NULL);
}

5.2.3.7 符号查找实例

  首先我们写一个计算符号名Hash的程序：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

// gcc gnu_hash.c -o gnu_hash
#include <stdio.h>
#include <stdint.h>

uint32_t dl_new_hash(const char *s)
{
    uint32_t h = 5381;
    for (unsigned char c = *s; c != '\0'; c = *++s)
        h = h * 33 + c;
    return h;
}

int main(int argc, char** argv) {
    printf("%X\n", dl_new_hash(argv[1]));
    return 0;
}

  这里依然使用libc6_2.23-0ubuntu11.2_amd64的libc-2.23-64.so(我重命名了)来做测试，我们随便找一个示例程序中的符号来进行测试，以“__gethostname_chk”为例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

$ readelf -s libc-2.23-64.so 

Symbol table '.dynsym' contains 2245 entries:
   Num:    Value          Size Type    Bind   Vis      Ndx Name
     0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND 
     1: 000000000001f8b0     0 SECTION LOCAL  DEFAULT   13 
     2: 00000000003c07c0     0 SECTION LOCAL  DEFAULT   23 
     3: 0000000000000000     0 OBJECT  GLOBAL DEFAULT  UND _rtld_global@GLIBC_PRIVATE (26)
     4: 0000000000000000     0 OBJECT  GLOBAL DEFAULT  UND __libc_enable_secure@GLIBC_PRIVATE (26)
     5: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __tls_get_addr@GLIBC_2.3 (27)
     6: 0000000000000000     0 OBJECT  GLOBAL DEFAULT  UND _rtld_global_ro@GLIBC_PRIVATE (26)
     7: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND _dl_find_dso_for_object@GLIBC_PRIVATE (26)
     8: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND _dl_starting_up
     9: 0000000000000000     0 OBJECT  GLOBAL DEFAULT  UND _dl_argv@GLIBC_PRIVATE (26)
    10: 0000000000071100   349 FUNC    GLOBAL DEFAULT   13 putwchar@@GLIBC_2.2.5    
    11: 000000000009ec20    32 FUNC    GLOBAL DEFAULT   13 __strspn_c1@@GLIBC_2.2.5
    12: 00000000001187e0    16 FUNC    GLOBAL DEFAULT   13 __gethostname_chk@@GLIBC_2.4     <----
    13: 000000000009ec40    37 FUNC    GLOBAL DEFAULT   13 __strspn_c2@@GLIBC_2.2.5
    [...]

  从上面的输出信息中，我们可以知道动态符号表(Dynamic Symbol Table)总共有2245项，符号“__gethostname_chk”的索引为12。通过上面计算Hash的函数进行计算“__gethostname_chk”的Hash：

1
2

$ ./gnu_hash __gethostname_chk
8ADCAD37

  要查找符号，我们需要知道.gnu.hash节的Header中的4个元素(nBuckets、Symndx、Maskwords、Shift2)，以及Bloom[]、Buckets[]、Chains[]的位置。我们将libc-2.23-64.so使用IDA打开，找到.gnu.hash节所在位置，IDA可以很好地识别.gnu.hash，结果如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

00000000000002B8 _gnu_hash       segment para public '' use64
00000000000002B8                 assume cs:_gnu_hash
00000000000002B8                 ;org 2B8h
00000000000002B8                 assume es:nothing, ss:nothing, ds:nothing, fs:nothing, gs:nothing
00000000000002B8 elf_gnu_hash_nbuckets dd 3F3h          ; nBuckets
00000000000002BC elf_gnu_hash_symbias dd 0Ah            ; Symndx
00000000000002C0 elf_gnu_hash_bitmask_nwords dd 100h    ; Maskwords
00000000000002C4 elf_gnu_hash_shift dd 0Eh              ; Shift2
00000000000002C8 elf_gnu_hash_indexes dq 10220A044103000h, 8C45C590E60388h, 60008405000800C4h, 4000C8A0D0080C0h; 0  ; Bloom[]
[...]
00000000000002C8                 dq 3EC61742383B5430h, 0A4000000A8200BF3h, 0A10CE71132329000h, 10C0449000Eh; 0B4h
[...]
00000000000002C8                 dq 2D0C018808080010h, 2200018216A12002h, 310060803094E008h, 483501A800183400h; 0FCh
0000000000000AC8 elf_gnu_hash_bucket dd 0, 0Ah, 0Dh, 0Eh, 11h, 14h, 15h, 16h, 17h, 19h, 1Bh, 1Eh, 20h, 22h, 25h, 27h; 0 ; Buckets[]
[...]
0000000000000AC8                 dd 8BFh, 8C2h, 8C3h     ; 3F0h
0000000000001A94 elf_gnu_hash_chain dd 1E160E72h, 0A6511920h, 8ADCAD37h, 0A6511921h; 0  ; Chains[]
[...]
0000000000001A94                 dd 10993873h, 949872D0h, 24B37FFBh; 8B8h
0000000000001A94 _gnu_hash       ends

  接下来我们需要通过Bloom Filter来验证当前对象中是否存在“__gethostname_chk”符号，首先通过计算出的Hash值得到Bloom Filter中要验证的掩码字在Bloom[]中的索引，以及改掩码字中相应的bit：

1
2
3
4
5
6
7
8
9
10

H1 = dl_new_hash(“__gethostname_chk”) = 0x8ADCAD37
H2 = H1 >> Shift2 = 0x8ADCAD37 >> 0xE = 0x22B72

C = sizeof(BloomWord) * 8 = 8*8 = 64
N = ((H1 / C) % Maskwords) = ((0x8ADCAD37 / 64) % 0x100) = 0x22B72B4 % 0x100 = 0x180 = 0xB4

BITMASK = (1 << (H1 % C)) | (1 << (H2 % C)) = (1 << (0x8ADCAD37 % 64)) | (1 << (0x22B72 % 64))
        = (1 << 55) | (1 << 50) = 0x84000000000000

Bloom[N] & BITMASK = Bloom[0xB4] & 0x84000000000000 = 0x3EC61742383B5430 & 0x84000000000000 = 0x84000000000000

  由上面的计算可知“__gethostname_chk”对应的Bloom Filter掩码字为Bloom[0xB4]，其中的第55位和第50位都已经被设置了，说明“__gethostname_chk”可能存在于当前对象中。然后，我们通过相应的Bucket[]元素得到符号表索引/Chains[]索引：

1
2

Buckets[H1 % nBuckets] = Buckets[0x8ADCAD37 % 0x3F3] = Buckets[1] = 0xA = 10
dynstr + dynsym[10]->st_name = “putwchar”

  由此可知，当前符号表索引对应的符号并不是要查找的符号，我们接下来对Chain进行遍历：

1
2
3
4
5
6
7
8
9
10

Symndx = 10
H1 & ~1 = 0x8ADCAD37 & 0xFFFFFFFE = 0x8ADCAD36

Buckets[1](10) --> Chains[10-10](0x1E160E72) --> Chains[10-10+1](0xA6511920) --> Chains[10-10+2](0x8ADCAD37)
            |                         |                               |                               |     
            ↓                         ↓                               ↓                               ↓     
        dynsym[10]                dynsym[10]                      dynsym[10+1](不访问)             dynsym[10+2](访问)
            |                         |                               |                               |
            ↓                         ↓                               ↓                               ↓
        putwchar                  putwchar                       __strspn_c1                  __gethostname_chk

  如上可知，我们在具有相同(hash % nBuckets)的Chain中，找到最后一个，终于找到了待查找符号“__gethostname_chk”所对应的Chains[]表元素。

  我们可以使用如下命令查看符号表中符号索引与Buckets[]数组索引的对应关系：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

$ readelf -sD libc-2.23-64.so

[...]
Symbol table of `.gnu.hash' for image:
  Num Buc:    Value          Size   Type   Bind Vis      Ndx Name
   10   1: 0000000000071100   349 FUNC    GLOBAL DEFAULT  13 putwchar
   11   1: 000000000009ec20    32 FUNC    GLOBAL DEFAULT  13 __strspn_c1
   12   1: 00000000001187e0    16 FUNC    GLOBAL DEFAULT  13 __gethostname_chk
   13   2: 000000000009ec40    37 FUNC    GLOBAL DEFAULT  13 __strspn_c2
   14   3: 0000000000131c00   192 FUNC    GLOBAL DEFAULT  13 setrpcent
   15   3: 00000000000b0df0    10 FUNC    GLOBAL DEFAULT  13 __wcstod_l
   16   3: 000000000009ec70    70 FUNC    GLOBAL DEFAULT  13 __strspn_c3
   17   4: 0000000000107a10    33 FUNC    GLOBAL DEFAULT  13 epoll_create
   18   4: 00000000000ea940    33 FUNC    WEAK   DEFAULT  13 sched_get_priority_min
   19   4: 00000000001187f0    16 FUNC    GLOBAL DEFAULT  13 __getdomainname_chk
   20   5: 0000000000107c20    33 FUNC    GLOBAL DEFAULT  13 klogctl
[...]

  Num列为动态符号表(.dynsym)索引，Buc列为Buckets[]数组索引。我们可以看到有三个符号都与Buckets[1]相关联，这三个符号计算出的Hash值对nBucket求模，结果都是1。如前所述，此对象中不存在(hash % nBuckets)为0的符号，所以Buckets[0]为0。我们还可以看到一个规律，就是Num和Buc都是按顺序排列的，这是因为动态符号表(.dynsym)中的符号使用(hash % nBuckets)进行升序排序。这样就会使具有相同(hash % nBuckets)的动态符号表符号项和相应的Chains[]表表项在内存中是相邻的，查找符号时，我们只需要得到具有相同(hash % nBuckets)的动态符号表符号项的最小索引对应的符号项的指针，以及相应的Chain的头元素的指针，然后通过增加指针的值，就可以不用在Chains[]表中来回跳转。

5.3 Version Releated Sections[^14][^15]

  本部分介绍符号版本控制机制(Symbol Versioning Mechanism)。所有ELF对象都可能提供或依赖于版本化的符号(Versioned Symbols)。符号版本控制由3个节类型(Section Types)实现：SHT_GNU_versym(.gnu.version)、SHT_GNU_verdef(.gnu.version_d)和SHT_GNU_verneed(.gnu.version_r)。

  动态库定义的符号版本信息保存在.gnu.version_d节，可执行程序和动态库引用其它动态库所定义的符号版本信息保存在.gnu.version_r节。

  以下描述和代码片段中的前缀Elfxx代表“Elf32”或“Elf64”，具体取决于ELF对象运行的处理器架构。

  版本由字符串描述。用于符号版本的结构还包含一个成员，该成员保存字符串的ELF Hash值。这允许更有效的处理。

  符号的版本控制机制并没有被广泛应用，主要使用在GNU的C库中，用来提供符号的版本信息，以实现共享库的后向兼容。简单的说，一个符号可能有一个或多个版本的实现，多个实现在源码层次就有多段不同的代码，但在链接层次只向外提供一个相同的符号名，然后用版本信息(如@GLIBC_2.0，两个@表示默认版本)来区别不同的实现。至于程序执行时使用哪个版本的实现跟该程序在编译时所引用的版本有关。

  .gnu.version、.gnu.version_d和.gnu.version_r等对应的节头(Section Header)中sh_link和sh_info值的意义，如下所示：

1
2
3
4
5
6
7
8
9
10
11
12

$ readelf -S libc-2.23.so

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [...]
  [ 4] .dynsym           DYNSYM          00003f28 003f28 0096f0 10   A  5   1  4
  [ 5] .dynstr           STRTAB          0000d618 00d618 005e44 00   A  0   0  1
  [ 6] .gnu.version      VERSYM          0001345c 01345c 0012de 02   A  4   0  2
  [ 7] .gnu.version_d    VERDEF          0001473c 01473c 0004d4 00   A  5  35  4
  [ 8] .gnu.version_r    VERNEED         00014c10 014c10 000040 00   A  5   1  4
  [...]

  其中，sh_link是与此节相关联的节的索引值，如下图所示：

Table 5-2：符号版本相关节的节头中sh_link和sh_info的含义

5.3.1 .gnu.version

  具有SHT_GNU_versym节类型的特殊节.gnu.version应包含符号版本表(Symbol Version Table)。该节(Section)应与.dynsym节中的动态符号表(Dynamic Symbol Table)具有相同数量的条目，并且一一对应。

  .gnu.version节应包含一个Elfxx_Versym类型的元素数组(版本信息索引表)，每个表项的长度为sizeof(Elf32_Half)，2个字节，每个条目指定为动态符号表(Dynamic Symbol Table)中的相应符号定义(Defined)或要求(Required)的版本。

1
2
3

/* Type for version symbol information.  */
typedef Elf32_Half Elf32_Versym;
typedef Elf64_Half Elf64_Versym;

  符号版本表(Symbol Version Table)中的值特定于它们所在的对象。这些值是由Elfxx_Vernaux结构的vna_other成员或Elfxx_Verdef结构的vd_ndx成员提供的符号版本标识符，一个索引。

值0和1被保留。

• 0 - 该符号是局部的，在对象之外不可用。
• 1 - 该符号在此对象中定义并且全局可用。

  所有其他值用于标识位于其他符号版本节(Symbol Version Sections)中定义或所需的符号版本。值本身不是与符号关联的符号版本。由值标识的字符串定义了符号的版本。

Table 5-3：符号版本表内容的一些特殊值

  我们可以通过readelf命令查看此节的内容：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

$ readelf -V libc-2.23.so

Version symbols section '.gnu.version' contains 2415 entries:
 Addr: 000000000001345c  Offset: 0x01345c  Link: 4 (.dynsym)
  000:   0 (*local*)      24 (GLIBC_2.1)    25 (GLIBC_PRIVATE)  25 (GLIBC_PRIVATE)
  004:   0 (*local*)      25 (GLIBC_PRIVATE)  25 (GLIBC_PRIVATE)   0 (*local*)    
  008:  26 (GLIBC_2.3)    25 (GLIBC_PRIVATE)   7 (GLIBC_2.2)     4 (GLIBC_2.1.1)
  00c:  11 (GLIBC_2.4)     4 (GLIBC_2.1.1)   2 (GLIBC_2.0)     3 (GLIBC_2.1)  
  010:   4 (GLIBC_2.1.1)   e (GLIBC_2.3.2)   2 (GLIBC_2.0)    11 (GLIBC_2.4)  
  014:   2 (GLIBC_2.0)     3 (GLIBC_2.1)     2 (GLIBC_2.0)     2 (GLIBC_2.0)  
  018:   3 (GLIBC_2.1)     2 (GLIBC_2.0)    22 (GLIBC_PRIVATE)  22 (GLIBC_PRIVATE)
  01c:   2 (GLIBC_2.0)     2 (GLIBC_2.0)     3 (GLIBC_2.1)     2 (GLIBC_2.0)  
  020:   2h(GLIBC_2.0)     3 (GLIBC_2.1)    11 (GLIBC_2.4)     2h(GLIBC_2.0) 
[...]
  960:   2 (GLIBC_2.0)     2 (GLIBC_2.0)     2 (GLIBC_2.0)     2 (GLIBC_2.0)  
  964:   2 (GLIBC_2.0)     2 (GLIBC_2.0)     7 (GLIBC_2.2)     2 (GLIBC_2.0)  
  968:   2 (GLIBC_2.0)    12 (GLIBC_2.5)    22 (GLIBC_PRIVATE)   3 (GLIBC_2.1)  
  96c:   2 (GLIBC_2.0)    21 (GLIBC_2.23)    2 (GLIBC_2.0)  
[...]

5.3.2 .gnu.version_d

  具有SHT_GNU_verdef节类型的特殊节.gnu.version_d应包含符号版本定义(Symbol Version Definitions)。本节中的条目数应包含在动态节.dynamic的节标记为DT_VERDEFNUM的条目中。

  该节应包含一个Elfxx_Verdef结构数组，每一个Elfxx_Verdef结构，可选地后跟一个Elfxx_Verdaux结构数组。

  .gnu.version_d节只存在于动态库文件中，表示自身所定义的符号的版本信息。

  我们可以通过readelf命令查看此节的内容：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

$ readelf -V libc-2.23.so

[...]
Version definition section '.gnu.version_d' contains 35 entries:
  Addr: 0x000000000001473c  Offset: 0x01473c  Link: 5 (.dynstr)  
  000000: Rev: 1  Flags: BASE   Index: 1  Cnt: 1  Name: libc.so.6
  0x001c: Rev: 1  Flags: none  Index: 2  Cnt: 1  Name: GLIBC_2.0
  0x0038: Rev: 1  Flags: none  Index: 3  Cnt: 2  Name: GLIBC_2.1
  0x0054: Parent 1: GLIBC_2.0
  0x005c: Rev: 1  Flags: none  Index: 4  Cnt: 2  Name: GLIBC_2.1.1
  0x0078: Parent 1: GLIBC_2.1
  0x0080: Rev: 1  Flags: none  Index: 5  Cnt: 2  Name: GLIBC_2.1.2
  0x009c: Parent 1: GLIBC_2.1.1
[...]
  0x0470: Rev: 1  Flags: none  Index: 33  Cnt: 2  Name: GLIBC_2.23
  0x048c: Parent 1: GLIBC_2.22
  0x0494: Rev: 1  Flags: none  Index: 34  Cnt: 2  Name: GLIBC_PRIVATE
  0x04b0: Parent 1: GLIBC_2.23
  0x04b8: Rev: 1  Flags: none  Index: 35  Cnt: 1  Name: GCC_3.0
[...]

5.3.2.1 Elfxx_Verdef

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

typedef struct {
    Elf32_Half  vd_version;     /* Version revision */
    Elf32_Half  vd_flags;       /* Version information */
    Elf32_Half  vd_ndx;         /* Version Index */
    Elf32_Half  vd_cnt;         /* Number of associated aux entries */
    Elf32_Word  vd_hash;        /* Version name hash value */
    Elf32_Word  vd_aux;         /* Offset in bytes to verdaux array */
    Elf32_Word  vd_next;        /* Offset in bytes to next verdef entry */
} Elf32_Verdef;

typedef struct {
    Elf64_Half  vd_version;     /* Version revision */
    Elf64_Half  vd_flags;       /* Version information */
    Elf64_Half  vd_ndx;         /* Version Index */
    Elf64_Half  vd_cnt;         /* Number of associated aux entries */
    Elf64_Word  vd_hash;        /* Version name hash value */
    Elf64_Word  vd_aux;         /* Offset in bytes to verdaux array */
    Elf64_Word  vd_next;        /* Offset in bytes to next verdef entry */
} Elf64_Verdef;

• vd_version：修订版本(Version Revision)。该字段应设置为1。
• vd_flags：版本信息标志(Version Information Flag)位掩码。一般为0。
• vd_ndx：节类型为SHT_GNU_versym的节(.gnu.version)中引用的符号版本的标识符，一个索引值。与Elfxx_Vernaux结构中的vna_other含义差不多。将.gnu.version表条目与相应的版本定义相关联。
• vd_cnt：与此符号版本定义相关联的Elfxx_Verdaux结构数组条目的数量。同一符号可能有多个版本。
• vd_hash：版本名称哈希值(用ELF Hash函数计算)。与此符号版本定义相关联的Elfxx_Verdaux结构数组的第一个Elfxx_Verdaux之中的vda_name对应的版本名称的哈希值。
• vd_aux：Elfxx_Verdaux结构数组中第1个条目距当前Elfxx_Verdef结构起始的字节偏移量(一般为Elfxx_Verdef结构的字节大小)。Elfxx_Verdaux结构数组的第一个条目必须存在。此条目(Elfxx_Verdaux)包含指向此结构(Elfxx_Verdef)定义的符号版本的版本字符串。可以存在附加条目(Elfxx_Verdaux)。条目的数量由vd_cnt值给出。这些条目代表此符号版本定义(Elfxx_Verdef)的依赖关系。这些依赖项中的每一个都有自己的符号版本定义结构(Elfxx_Verdef)。
• vd_next：下一个Elfxx_Verdef结构距当前Elfxx_Verdef结构起始的偏移量(Elfxx_Verdef结构大小+vd_cnt个Elfxx_Verdaux的大小)，以字节为单位。0表示当前Elfxx_Verdef结构为最后1个。

Table 5-4：合法的vd_version值

Table 5-5：合法的vd_flags值

  当符号版本定义(Version Definitions)或符号自动缩减(Symbol Autoreduction)已应用于文件时，基本符号版本定义(Base Version Definition)始终存在。基本符号版本(Base Version)为文件保留符号提供了默认符号版本。弱符号版本定义(Weak Version Definition)没有与符号版本关联的符号。

5.3.2.2 Elfxx_Verdaux

1
2
3
4
5
6
7
8
9

typedef struct {
    Elf32_Word    vda_name;       /* Version or dependency names */
    Elf32_Word    vda_next;       /* Offset in bytes to next verdaux entry */
} Elf32_Verdaux;

typedef struct {
    Elf64_Word    vda_name;       /* Version or dependency names */
    Elf64_Word    vda_next;       /* Offset in bytes to next verdaux entry */
} Elf64_Verdaux;

• vda_name：符号版本或依赖项名称字符串的偏移量(.dynstr)，以字节为单位。GLIBC_2.2.5、libc.so.6。
• vda_next：到下一个Elfxx_Verdaux条目的偏移量(也就是Elfxx_Verdaux结构的大小)，以字节为单位。

5.3.3 .gnu.version_r

  .gnu.version_r节存在于可执行文件和动态库(动态库也会引用其他动态库中的符号)中，表示所引用的符号的版本信息。

  具有SHT_GNU_verneed节类型的特殊节.gnu.version_r应包含所需的符号版本定义(Required Symbol Version Definitions)。本节中的条目数应包含在动态节.dynamic的节标记为DT_VERNEEDNUM的条目中。

  本节通过指示这些依赖项(Dependencies)所需的版本定义(Version Definitions)来补充文件的动态依赖项要求(Dynamic Dependency Requirements)。仅当依赖项包含符号版本定义时，才会在此节进行记录。

  该节应包含一个Elfxx_Verneed结构数组，每一个Elfxx_Verneed结构可选地后跟一个Elfxx_Vernaux结构数组。

  在.gnu.version_r中，可执行文件或动态库引用了多少个其他动态库文件则有多少个Elfxx_Verneed结构体，其他动态库文件中有多少个版本信息被引用则紧随其后就有多少个Elfxx_Vernaux结构体。

  我们可以通过readelf命令查看此节的内容：

1
2
3
4
5
6
7
8
9

$ readelf -V libc-2.23.so

[...]
Version needs section '.gnu.version_r' contains 1 entries:
 Addr: 0x0000000000014c10  Offset: 0x014c10  Link: 5 (.dynstr)
  000000: Version: 1  File: ld-linux.so.2  Cnt: 3
  0x0010:   Name: GLIBC_2.3  Flags: none  Version: 38
  0x0020:   Name: GLIBC_PRIVATE  Flags: none  Version: 37
  0x0030:   Name: GLIBC_2.1  Flags: none  Version: 36

  Version为符号版本的版本标识符，一个索引值。对应于Elfxx_Verdef.vd_ndx。在同一动态库中，Elfxx_Vernaux.vna_other和Elfxx_Verdef.vd_ndx的值是连续的，并且没有重复值。

5.3.3.1 Elfxx_Verneed

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

typedef struct {
    Elf32_Half    vn_version;     /* Version of structure */
    Elf32_Half    vn_cnt;         /* Number of associated aux entries */
    Elf32_Word    vn_file;        /* Offset of filename for this dependency */
    Elf32_Word    vn_aux;         /* Offset in bytes to vernaux array */
    Elf32_Word    vn_next;        /* Offset in bytes to next verneed entry */
} Elf32_Verneed;

typedef struct {
    Elf64_Half    vn_version;     /* Version of structure */
    Elf64_Half    vn_cnt;         /* Number of associated aux entries */
    Elf64_Word    vn_file;        /* Offset of filename for this dependency */
    Elf64_Word    vn_aux;         /* Offset in bytes to vernaux array */
    Elf64_Word    vn_next;        /* Offset in bytes to next verneed entry */
} Elf64_Verneed;

• vn_version：结构的版本。此值当前设置为1，如果版本控制实现发生了不兼容的更改，则将重置该值。
• vn_cnt：与此Elfxx_Verneed结构相关联的Elfxx_Vernaux结构数组条目数。
• vn_file：此依赖项的文件名字符串的偏移量(.dynstr)，以字节为单位。此依赖项的文件名与文件中找到的.dynamic依赖项之一匹配。ld-linux-x86-64.so.2。
• vn_aux：此文件依赖项(File Dependency)所需的Elfxx_Vernaux结构版本定义数组中第1个条目距当前Elfxx_Verneed结构起始的字节偏移量(一般为Elfxx_Verneed结构的字节大小)。必须至少存在一个版本依赖项。可以存在其他版本依赖项，数量由vn_cnt值指示。
• vn_next：下一个Elfxx_Verneed结构距当前Elfxx_Verneed结构起始的偏移量(Elfxx_Verneed结构大小+vn_cnt个Elfxx_Vernaux的大小)，以字节为单位。0表示当前Elfxx_Verneed结构为最后1个。

Table 5-6：合法的vn_version值

5.3.3.2 Elfxx_Vernaux

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

typedef struct {
    Elf32_Word    vna_hash;       /* Hash value of dependency name */
    Elf32_Half    vna_flags;      /* Dependency specific information */
    Elf32_Half    vna_other;      /* Unused */
    Elf32_Word    vna_name;       /* Dependency name string offset */
    Elf32_Word    vna_next;       /* Offset in bytes to next vernaux entry */
} Elf32_Vernaux;

typedef struct {
    Elf64_Word    vna_hash;       /* Hash value of dependency name */
    Elf64_Half    vna_flags;      /* Dependency specific information */
    Elf64_Half    vna_other;      /* Unused */
    Elf64_Word    vna_name;       /* Dependency name string offset */
    Elf64_Word    vna_next;       /* Offset in bytes to next vernaux entry */
} Elf64_Vernaux;

• vna_hash：版本依赖项名称字符串的哈希值(用ELF Hash函数计算)。
• vna_flags：版本依赖信息标志(Dependency Information Flag)位掩码。通常为0。
• vna_other：在.gnu.version符号版本数组中使用的符号版本的版本标识符，一个索引值。与Elfxx_Verdef结构中的vd_ndx含义差不多。第15位控制对象是否被隐藏。如果设置了此位，对象就不能使用，静态链接器(Static Linker)将忽略该符号在对象中的存在。
• vna_name：此版本依赖项的名称字符串的偏移量(.dynstr)，以字节为单位。GLIBC_2.3。
• vna_next：从当前Elfxx_Vernaux条目开始到下一个Elfxx_Vernaux条目的偏移量(Elfxx_Vernaux结构大小)，以字节为单位。

Table 5-7：合法的vna_flags值

  弱符号版本依赖(Weak Version Dependency)表示对弱符号版本定义(Weak Version Definition)的原始绑定。

5.3.4 启动顺序(Startup Sequence)

  当加载一个可共享对象时，系统应分析来自加载对象的版本定义数据(Version Definition Data)，以确保它满足调用对象(Calling Object)的版本要求(Version Requirements)。此步骤称为定义测试(Definition Testing)。动态加载器(Dynamic Loader)应检索调用者的Elfxx_Verneed数组中的条目，并尝试在加载对象的.gnu.version_d表中找到匹配的符号版本定义信息(Definition Information)。

  应该依次测试每个对象和依赖项。如果缺少符号定义并且未设置vna_flags的VER_FLG_WEAK位，则加载器将返回错误并退出。如果在Elfxx_Vernaux条目中设置了vna_flags的VER_FLG_WEAK位，加载器将发出警告并继续操作。

  当找到被加载对象中未定义符号引用的版本时，将验证版本可用性。测试无误完成，对象应可用。

5.3.5 符号解析(Symbol Resolution)

  当在对象中使用符号版本控制(Symbol Versioning)时，重定位将定义测试(Definition Testing)扩展了符号名称字符串的简单匹配：符号名称引用的版本字符串也应等于定义的符号版本名称。

  在符号表中使用的索引也可以在节类型为SHT_GNU_versym的节中使用，然后使用该索引的值来获取名称数据。从Elfxx_Verneed数组中检索相应的需求对象文件名字符串(Requirement String)，同样，从Elfxx_Verdef表中检索相应的版本定义字符串(Definition String)。

  如果设置了符号版本的版本标识符的高位(第15位)，则无法使用该对象，静态链接器(Static Linker)应忽略该符号在对象中的存在。

  当一个带有引用(Reference)的对象和一个带有定义(Definition)的对象被链接时，以下规则将控制结果：

1、带有引用(Reference)的对象和带有定义(Definition)的对象都使用版本控制。在这种情况下处理所有描述的匹配。如果在Elfxx_Verneed条目中vn_name元素引用的对象中找不到匹配的定义，将触发致命错误。
2、带有引用(Reference)的对象不使用版本控制，而带有定义(Definition)的对象使用。在这种情况下，只有索引号为1和2的符号定义将用于引用匹配，静态链接器将其标识为基本定义。在未使用静态链接器的情况下，例如在调用dlopen()时，如果没有基本定义索引的版本是唯一定义该符号的版本，则该版本是可接受的。
3、带有引用(Reference)的对象使用版本控制，但带有定义(Definition)的对象没有指定。在这种情况下应接受匹配的符号。如果所需符号列表中的损坏隐藏了旧式的目标文件，并导致与Elfxx_Verneed条目中的目标文件名匹配，则将触发致命错误。
4、带有引用(Reference)的对象和带有定义(Definition)的对象都不使用版本控制。这种情况下的行为将默认为已存在的符号规则。

5.4 Strings Related Sections

以下是各个字符串表保存的符号的范围。

• .strtab：保存完整符号表.symtab中的符号名称。
• .dynstr：保存动态符号表.dynsym中的符号名称。
• .shstrtab：保存目标文件中拥有的节(Section)的名称。

对字符串表的引用：

• 用于保存节名(Section Name)的字符串表(.shstrtab)的节索引由ELF头的e_shstrndx字段指示。
• 许多带有字符串引用的节(Section)使用节头(Section Header)中的sh_link字段来给出它们使用的字符串表的节索引。
• 在.dynamic节中，动态字符串表(.dynstr)对于文件的偏移量位于DT_STRTAB条目中。动态字符串表(.dynstr)的大小位于DT_STRSZ条目中。

5.4.1 .strtab

  此节保存字符串，最常见的是表示与符号表(Symbol Table)条目相关联的名称的字符串。如果文件具有包含符号字符串表(Symbol String Table)的可加载段，则该段的属性将包括SHF_ALLOC位。否则，该位将不设置。此节属于SHT_STRTAB类型。

  本节介绍默认字符串表。字符串表节(String Table Sections)保存以Null字符结尾的字符序列，通常称为字符串。目标文件(Object File)使用这些字符串来表示符号(Symbol)和节名称(Section Names)。一般通过对字符串的首个字母在字符串表中的下标来索引字符串。字符串表的首尾字节都是Null，以确保所有字符串以Null终止。此外，索引为0的字符串要么没有名字(No Name)，要么就是名字为空(Null Name)，具体取决于上下文。字符串表也可以为空，相应的，它的节头的sh_size成员将为0。非0索引对于空字符串表无效。

  节头的sh_name成员的值是节头字符串表节(.shstrtab)中内容距节头字符串表节起始的偏移量/索引值(以字节为单位)，节头字符串表节(.shstrtab)在节头表中的索引由ELF头的e_shstrndx成员指定。下图显示了一个包含25个字节的字符串表以及与各种索引关联的字符串。

Figure 5-4：String Table Example

  该字符串表中的字符串与索引的关系如下：

Table 5-8：String Table Indexes

如示例所示：

• 字符串表索引可以引用该节中的任何字节。
• 一个字符串可能出现多次。
• 可以存在对子字符串的引用。
• 同一个字符串可以被引用多次。
• 字符串表中也可以存在未引用的字符串。

我们可以使用readelf对.strtab表的内容进行查看：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

$ readelf -p 30 hash
$ readelf -p .strtab hash

String dump of section '.strtab':
  [     1]  crtstuff.c
  [     c]  __JCR_LIST__
  [    19]  deregister_tm_clones
  [    2e]  __do_global_dtors_aux
  [    44]  completed.7594
  [    53]  __do_global_dtors_aux_fini_array_entry
  [    7a]  frame_dummy
  [    86]  __frame_dummy_init_array_entry
  [    a5]  hash.c
  [    ac]  __FRAME_END__
  [    ba]  __JCR_END__
  [    c6]  __init_array_end
  [    d7]  _DYNAMIC
  [    e0]  __init_array_start
  [    f3]  __GNU_EH_FRAME_HDR
  [   106]  _GLOBAL_OFFSET_TABLE_
  [   11c]  __libc_csu_fini
  [   12c]  _ITM_deregisterTMCloneTable
  [   148]  _edata
  [   14f]  printf@@GLIBC_2.2.5
  [   163]  __libc_start_main@@GLIBC_2.2.5
  [   182]  __data_start
  [   18f]  __gmon_start__
  [   19e]  __dso_handle
  [   1ab]  _IO_stdin_used
  [   1ba]  __libc_csu_init
  [   1ca]  __bss_start
  [   1d6]  main
  [   1db]  _Jv_RegisterClasses
  [   1ef]  __TMC_END__
  [   1fb]  _ITM_registerTMCloneTable
  [   215]  elf_hash

  这个节将会在使用GNU Binutils的strip命令对目标文件去除符号之后被丢弃。同样被丢弃的还有.symtab。通过去除符号，可以减小可执行文件和共享库文件的大小，也可以增加逆向的难度。

5.4.2 .dynstr

  此节包含动态链接(Dynamic Linking)所需的字符串，最常见的是表示与符号表条目关联的名称的字符串。此节属于SHT_STRTAB类型。使用的属性类型是SHF_ALLOC。此节的结构与.strtab节类似。

  我们可以使用readelf对.dynstr表的内容进行查看：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

$ readelf -p .dynstr libc-2.23.so 

String dump of section '.dynstr':
  [     1]  xdr_u_long
  [     c]  __wctomb_chk
  [    19]  getmntent
  [    23]  __freelocale
  [    30]  xdr_void
  [    39]  __rawmemchr
  [    45]  _IO_vsprintf
  [    52]  getutent
  [    5b]  rcmd_af
  [    63]  setitimer
  [    6d]  argp_usage
  [    78]  wcstoimax
  [    82]  execvp
  [    89]  pthread_setcancelstate
  [    a0]  _IO_wfile_underflow
  [    b4]  __res_maybe_init
  [    c5]  setservent
  [    d0]  setuid
  [    d7]  __wcsncat_chk
  [    e5]  argp_help
  [    ef]  __strtok_r
[...]
  [  5e0d]  GLIBC_2.18
  [  5e18]  GLIBC_2.22
  [  5e23]  GLIBC_2.23
  [  5e2e]  GLIBC_PRIVATE
  [  5e3c]  GCC_3.0

5.4.3 .shstrtab

  此节包含节名称(Section Names)。此节属于SHT_STRTAB类型。不使用任何属性类型。此节的结构与.strtab节类似。

  我们可以使用readelf对.shstrtab表的内容进行查看：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

$ readelf -p .shstrtab libc-2.23.so 

String dump of section '.shstrtab':
  [     1]  .shstrtab
  [     b]  .note.gnu.build-id
  [    1e]  .note.ABI-tag
  [    2c]  .gnu.hash
  [    36]  .dynsym
  [    3e]  .dynstr
  [    46]  .gnu.version
  [    53]  .gnu.version_d
  [    62]  .gnu.version_r
  [    71]  .rel.dyn
  [    7a]  .rel.plt
  [    83]  .plt.got
  [    8c]  .text
  [    92]  __libc_freeres_fn
  [    a4]  __libc_thread_freeres_fn
  [    bd]  .rodata
  [    c5]  .stapsdt.base
  [    d3]  .interp
  [    db]  .eh_frame_hdr
  [    e9]  .eh_frame
  [    f3]  .gcc_except_table
  [   105]  .tdata
  [   10c]  .tbss
  [   112]  .init_array
  [   11e]  __libc_subfreeres
  [   130]  __libc_atexit
  [   13e]  __libc_thread_subfreeres
  [   157]  .data.rel.ro
  [   164]  .dynamic
  [   16d]  .got.plt
  [   176]  .data
  [   17c]  .bss
  [   181]  .note.stapsdt
[...]

5.5 Symbols Related Sections

  每个目标文件都会有一个符号表，熟悉编译原理的就会知道，在编译程序时，必须有相应的结构来管理程序中的符号以便于对函数和变量进行重定位。

  此外，链接本质就是把多个不同的目标文件相互“粘”在一起，实际上，目标文件相互粘合是目标文件之间对地址的引用，即函数和变量的地址的相互引用。而在粘合的过程中，符号就是其中的粘合剂。

  目标文件中的符号表包含了一些通用的符号，这部分信息在进行了strip操作后就会消失。包括变量名和函数名。

5.5.1 .symtab

  目标文件的符号表包含定位(Locate)和重定位(Relocate)程序的符号的定义(Definitions)和引用(References)时所需的信息。符号表索引是该数组的下标。索引0既指定表中的第一个条目，又用作未定义符号索引。本节稍后将指定初始条目的内容。

Table 5-9：Index 0 of Symbol Table

  符号表表项具有以下格式(这里需要注意一点，Elf32_Sym和Elf64_Sym结构体成员的顺序不同)：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

typedef struct {
    Elf32_Word      st_name;        /* Symbol name (string tbl index) */
    Elf32_Addr      st_value;       /* Symbol value */
    Elf32_Word      st_size;        /* Symbol size */
    unsigned char   st_info;        /* Symbol type and binding */
    unsigned char   st_other;       /* Symbol visibility */
    Elf32_Section   st_shndx;       /* Section index */
} Elf32_Sym;

typedef struct {
    Elf64_Word      st_name;        /* Symbol name (string tbl index) */
    unsigned char   st_info;        /* Symbol type and binding */
    unsigned char   st_other;       /* Symbol visibility */
    Elf64_Section   st_shndx;       /* Section index */
    Elf64_Addr      st_value;       /* Symbol value */
    Elf64_Xword     st_size;        /* Symbol size */
} Elf64_Sym;

各个字段的含义如下：

• st_name：如果该值非零，该成员保存该符号的符号名字符串在相应字符串表中的节偏移量/索引，字符串表保存符号名称的字符串。否则，符号表项没有名称。注：外部C符号在C语言和目标文件的符号表中具有相同的名称。
• st_value：该成员给出相关符号的值。根据上下文，这可能是绝对值、地址等。详情见下方。
• st_size：许多符号都有相应的大小。例如，数据对象的大小是对象中包含的字节数。如果符号没有大小或大小未知，则该成员为0。
• st_info：该成员指定符号的类型(Symbol Type)和绑定属性(Binding Attributes)。
• st_other：该成员定义了符号的可见性(Visibility)。
• st_shndx：每个符号表条目都被“定义”为与某个节相关，该成员保存相关节的节头表索引。如Table 4-1和相关文本所述，一些节索引具有特殊含义。

  其中，符号表中索引为0(STN_UNDEF)的表项存储了符号表的一个元素，同时这个元素也相对比较特殊，作为所有未定义符号的索引，具体如下：

Table 5-10：Symbol Table Entry: Index 0

  我们可以使用readelf对.symtab表的内容进行查看：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

$ readelf -s hash

[...]
Symbol table '.symtab' contains 68 entries:
   Num:    Value          Size Type    Bind   Vis      Ndx Name
     0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND 
     1: 0000000000400238     0 SECTION LOCAL  DEFAULT    1 
     2: 0000000000400254     0 SECTION LOCAL  DEFAULT    2 
     3: 0000000000400274     0 SECTION LOCAL  DEFAULT    3 
     4: 0000000000400298     0 SECTION LOCAL  DEFAULT    4 
     5: 00000000004002b8     0 SECTION LOCAL  DEFAULT    5 
     6: 0000000000400318     0 SECTION LOCAL  DEFAULT    6 
     7: 0000000000400358     0 SECTION LOCAL  DEFAULT    7 
     8: 0000000000400360     0 SECTION LOCAL  DEFAULT    8 
     9: 0000000000400380     0 SECTION LOCAL  DEFAULT    9 
    10: 0000000000400398     0 SECTION LOCAL  DEFAULT   10 
    11: 00000000004003c8     0 SECTION LOCAL  DEFAULT   11 
    12: 00000000004003f0     0 SECTION LOCAL  DEFAULT   12 
    13: 0000000000400420     0 SECTION LOCAL  DEFAULT   13 
    14: 0000000000400430     0 SECTION LOCAL  DEFAULT   14 
    15: 0000000000400644     0 SECTION LOCAL  DEFAULT   15 
    16: 0000000000400650     0 SECTION LOCAL  DEFAULT   16 
    17: 0000000000400658     0 SECTION LOCAL  DEFAULT   17 
    18: 0000000000400698     0 SECTION LOCAL  DEFAULT   18 
    19: 0000000000600e10     0 SECTION LOCAL  DEFAULT   19 
    20: 0000000000600e18     0 SECTION LOCAL  DEFAULT   20 
    21: 0000000000600e20     0 SECTION LOCAL  DEFAULT   21 
    22: 0000000000600e28     0 SECTION LOCAL  DEFAULT   22 
    23: 0000000000600ff8     0 SECTION LOCAL  DEFAULT   23 
    24: 0000000000601000     0 SECTION LOCAL  DEFAULT   24 
    25: 0000000000601028     0 SECTION LOCAL  DEFAULT   25 
    26: 0000000000601038     0 SECTION LOCAL  DEFAULT   26 
    27: 0000000000000000     0 SECTION LOCAL  DEFAULT   27 
    28: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS crtstuff.c
    29: 0000000000600e20     0 OBJECT  LOCAL  DEFAULT   21 __JCR_LIST__
    30: 0000000000400460     0 FUNC    LOCAL  DEFAULT   14 deregister_tm_clones
    31: 00000000004004a0     0 FUNC    LOCAL  DEFAULT   14 register_tm_clones
    32: 00000000004004e0     0 FUNC    LOCAL  DEFAULT   14 __do_global_dtors_aux
    33: 0000000000601038     1 OBJECT  LOCAL  DEFAULT   26 completed.7594
    34: 0000000000600e18     0 OBJECT  LOCAL  DEFAULT   20 __do_global_dtors_aux_fin
    35: 0000000000400500     0 FUNC    LOCAL  DEFAULT   14 frame_dummy
    36: 0000000000600e10     0 OBJECT  LOCAL  DEFAULT   19 __frame_dummy_init_array_
[...]

5.5.1.1 st_value

不同目标文件类型的符号表条目对st_value成员的解释略有不同。

• 在可重定位文件中，st_value保存节索引为SHN_COMMON的符号的对齐约束。
• 在可重定位文件中，st_value保存已定义符号的节偏移量。也就是说，st_value是从st_shndx标识的节的开头的偏移量。
• 在可执行文件和共享目标文件中，st_value保存一个虚拟地址。为了使这些文件的符号对动态链接器(Dynamic Linker)更有用，节偏移量(文件层面解释)让位于与节号无关的虚拟地址(内存层面解释)。

  尽管st_value对于不同的目标文件具有相似的含义，但允许适当的程序高效地访问这些数据。

  如果可执行文件中包含对与其相关联的共享对象中定义的函数的引用，则该文件的符号表节将包含该符号的条目。该符号表条目的st_shndx成员将包含SHN_UNDEF。这向动态链接器(Dynamic Linker)发出信号，该函数的符号定义不包含在可执行文件本身中。如果该符号已在可执行文件中分配了一个过程链接表(Procedure Linkage Table)条目，并且该符号表条目的st_value成员不为零，则该值将包含该过程链接表条目的第一条指令的虚拟地址。否则，st_value成员为0。动态链接器(Dynamic Linker)在解析对函数地址的引用时使用此过程链接表表项的地址。

在Linux的ELF文件中，具体说明如下：

1、该符号对应着一个变量，那么st_value的值为该变量在内存中的偏移。我们可由这个值获取其文件偏移。

• a. 获取该符号对应的st_shndx，进而获取到相关的节。
• b. 根据节头成员可以获取节的内存基地址和文件基地址。
• c. st_value - 内存基地址 = 文件偏移 - 文件基地址

2、该符号对应着一个函数，那么st_value的值为该函数在文件中的偏移。

  可执行文件和与其关联的共享目标文件对函数地址的引用可能不会解析为相同的值。来自共享目标文件的引用通常由动态链接器(Dynamic Linker)解析为函数本身的虚拟地址。可执行文件中对共享目标文件中定义的函数的引用通常由链接器(Link Editor)解析为可执行文件中该函数的过程链接表(Procedure Linkage Table)条目的地址。

  为了允许函数地址的比较按预期工作，如果可执行文件引用共享目标文件中定义的函数，链接器将把该函数的过程链接表(Procedure Linkage Table)条目的地址放置在其关联的符号表条目中。动态链接器(Dynamic Linker)会特别对待此类符号表条目。如果动态链接器正在搜索一个符号，并且在可执行文件中遇到该符号的符号表条目，则它通常遵循规则如下：

• 1、如果符号表条目的st_shndx成员不是SHN_UNDEF，则动态链接器(Dynamic Linker)已找到该符号的定义，并将其的st_value成员用作该符号的地址。
• 2、如果st_shndx成员是SHN_UNDEF，并且符号是STT_FUNC类型，并且st_value成员不为0，则动态链接器(Dynamic Linker)会将此条目识别为特殊项，并使用st_value成员作为符号的地址。
• 3、否则，动态链接器(Dynamic Linker)认为该符号在可执行文件中未定义并继续处理。

5.5.1.2 st_info

  st_info指定符号类型及绑定属性。st_info的低4位表示符号类型，高4位表示绑定属性。符号类型的宏定义以STT开头，符号绑定的宏定义以STB开头。

1
2
3
4
5
6
7
8
9

/* st_info字段中符号类型和绑定属性的提取 */
#define ELF32_ST_BIND(val) (((unsigned char) (val)) >> 4)
#define ELF32_ST_TYPE(val) ((val) & 0xf)
#define ELF32_ST_INFO(bind, type) (((bind) << 4) + ((type) & 0xf))

/* Elf32_Sym和Elf64_Sym都使用相同的一字节的st_info字段 */
#define ELF64_ST_BIND(val) ELF32_ST_BIND (val)
#define ELF64_ST_TYPE(val) ELF32_ST_TYPE (val)
#define ELF64_ST_INFO(bind, type) ELF32_ST_INFO ((bind), (type))

5.5.1.2.1 Symbol Type

下面是一些合法的符号类型：

Table 5-11：Symbol Types

  共享目标文件中的函数符号(类型为STT_FUNC的符号)具有特殊意义。当另一个目标文件从共享目标文件引用一个函数时，链接器(Link Editor)会自动为被引用的符号创建一个过程链接表(Procedure Linkage Table)条目。目标文件不会通过过程链接表(Procedure Linkage Table)自动引用类型不是STT_FUNC的其它共享目标符号。

5.5.1.2.2 Symbol Binding

  符号的绑定决定了符号的链接可见性(Linkage Visibility)和行为(Behavior)。

下面是一些合法的符号绑定：

Table 5-12：Symbol Binding

  在每个符号表中，所有带有STB_LOCAL绑定的符号都位于弱符号和全局符号之前。符号的类型为关联的实体提供了一般的分类。符号表节(Symbol Table Section)的节头成员sh_info保存着符号表中第一个非局部符号的符号表索引。

全局符号和弱符号在两个主要方面有所不同：

• 当链接器(Link Editor)链接多个可重定位目标文件时，它不允许定义多个具有相同名称的STB_GLOBAL符号。另一方面，如果存在一个已定义的全局符号，则同名弱符号的存在不会导致错误。链接器(Link Editor)会优先选择全局符号定义，忽略弱符号定义。类似的，如果存在公共符号(即st_shndx字段为SHN_COMMON的符号)，同名弱符号的出现也不会导致错误。链接器(Link Editor)会优先选择公共符号(Common Symbol)定义，忽略弱符号定义。
• 当链接器(Link Editor)搜索静态库(Archive Libraries)时，它将提取包含未定义的(Undefined)和暂定的(Tentative)全局符号定义的归档成员。成员的定义可以是全局符号或弱符号。默认情况下，链接器(Link Editor)不会提取归档成员来解析未定义的弱符号。未解析的弱符号具有0值。使用“-z weakextract”会覆盖此默认行为。此选项允许链接器(Link Editor)提取归档成员来解析未定义的弱符号。

注：弱符号主要用于系统软件。不鼓励在应用程序中使用它们。

5.5.1.3 st_other

  该成员定义了符号的可见性(Visibility)。下面的代码展示了如何操作32位对象和64位对象的st_other的值。其他位设置为零，因为其不包含任何含义。

1
2
3
4
5

/* How to extract and insert information held in the st_other field. */
#define ELF32_ST_VISIBILITY(o)	((o) & 0x03)

/* For ELF64 the definitions are the same. */
#define ELF64_ST_VISIBILITY(o)	ELF32_ST_VISIBILITY (o)

  可以在可重定位对象中指定此可见性。此可见性定义了该符号成为动态对象的一部分后如何访问该符号。

下面是一些合法的符号可见性：

Table 5-13：ELF Symbol Visibility

  STV_SINGLETON可见性属性会影响链接(Link-Editing)期间可执行文件或共享目标文件中的符号解析。一个进程中的任何引用只能绑定到一个单独的(Singleton)实例。

  STV_SINGLETON可以与STV_DEFAULT可见性属性结合使用，STV_SINGLETON优先。STV_EXPORT可以与STV_DEFAULT可见性属性结合使用，STV_EXPORT优先。STV_SINGLETON或STV_EXPORT可见性不能与任何其他可见性属性结合使用。这样的事件对于链接(Link-Edit)来说是致命(Fatal)的。

  在链接(Link-Editing)期间，其他可见性属性不会影响动态对象内符号的解析。这种解析由绑定类型控制。一旦链接器选择了它的解析，这些属性就强加了两个要求。这两个要求都基于这样一个事实，即被链接的代码中的引用可能已经过优化以利用这些属性。

• 所有非默认可见性属性，当应用于符号引用时，意味着必须在被链接的对象中提供满足该引用的定义。如果这种类型的符号引用在被链接的对象中没有定义，则该引用必须具有STB_WEAK绑定。在这种情况下，该引用被解析为0。
• 如果对名称的任何引用或名称的定义是具有非默认可见性属性的符号，则可见性属性将被传递(Propagated)到正在链接的对象中的解析符号。如果为符号的不同实例指定了不同的可见性属性，则将约束(Constraining)最大的可见性属性传递到正在链接的对象中的解析符号。这些属性，从约束最少到最多排序，是STV_PROTECTED、STV_HIDDEN和 STV_INTERNAL。

5.5.1.4 st_shndx

  如果一个符号的值指向一个节中的特定位置，它的节索引成员st_shndx将保存一个节头表表项的索引。随着在重定位期间节的移动，符号的值也会发生变化，并且对符号的引用继续“指向”程序中的同一位置。一些特殊的节索引值给出了其他语义。

  ELF目标文件中的符号向链接器(Linker)和加载器(Loader)传达特定信息。

Table 5-14：Special Section Index of Symbol

  如果此成员包含SHN_XINDEX，则实际的节头表索引太大而无法放入此字段。实际值包含在类型为SHT_SYMTAB_SHNDX的相关节中。

5.5.2 .symtab_shndx

  当符号表表项Elfxx_Sym的成员st_shndx包含SHN_XINDEX(0xFFFF)时，表示实际的节头表索引太大而无法放入st_shndx字段。实际值保存在.symtab_shndx节中。本节属于SHT_SYMTAB_SHNDX类型。

  此节保存特殊符号表节索引数组，如.symtab所述。如果关联的符号表节包含SHF_ALLOC位，则该节的属性也包括SHF_ALLOC位。否则，不包括。

5.5.3 .dynsym

  本节保存动态链接符号表，与.symtab的结构相同，包含.symtab表中支持动态链接所需的符号的子集。此节属于SHT_DYNSYM类型。使用的属性是SHF_ALLOC。因此这个符号表在进程执行期间会占用内存，可以在进程的内存映像中使用。

  .dynsym表以标准的Null符号开始，然后是文件的全局符号。STT_FILE符号通常不会出现在这个符号表中。如果重定位表项需要STT_SECTION符号，则可能会出现。

  需要注意的是.dynsym表的内容是运行时所需的，ELF文件中export/import的符号信息全在这里。但是，.symtab节中存储的信息是编译时的符号信息，它们在strip之后会被删除掉。

我们主要关注动态符号表表项中的两个成员：

• st_name，该成员保存着动态符号在.dynstr表(动态字符串表)中的偏移。
• st_value，如果这个符号被导出，这个符号保存着对应的虚拟地址。

  我们可以使用readelf对.dynsym表的内容进行查看：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

$ readelf -s libc-2.23.so

Symbol table '.dynsym' contains 2415 entries:
   Num:    Value  Size Type    Bind   Vis      Ndx Name
     0: 00000000     0 NOTYPE  LOCAL  DEFAULT  UND 
     1: 00000000     0 OBJECT  GLOBAL DEFAULT  UND __libc_stack_end@GLIBC_2.1 (36)
     2: 00000000     0 OBJECT  GLOBAL DEFAULT  UND _rtld_global@GLIBC_PRIVATE (37)
     3: 00000000     0 OBJECT  GLOBAL DEFAULT  UND __libc_enable_secure@GLIBC_PRIVATE (37)
     4: 00000000     0 NOTYPE  WEAK   DEFAULT  UND _IO_stdin_used
     5: 00000000     0 OBJECT  GLOBAL DEFAULT  UND _rtld_global_ro@GLIBC_PRIVATE (37)
     6: 00000000     0 FUNC    GLOBAL DEFAULT  UND _dl_find_dso_for_object@GLIBC_PRIVATE (37)
     7: 00000000     0 NOTYPE  WEAK   DEFAULT  UND _dl_starting_up
     8: 00000000     0 FUNC    GLOBAL DEFAULT  UND ___tls_get_addr@GLIBC_2.3 (38)
     9: 00000000     0 OBJECT  GLOBAL DEFAULT  UND _dl_argv@GLIBC_PRIVATE (37)
    10: 000617b0   299 FUNC    GLOBAL DEFAULT   13 putwchar@@GLIBC_2.2
    11: 0007dea0    37 FUNC    GLOBAL DEFAULT   13 __strspn_c1@@GLIBC_2.1.1
    12: 000f6f40    48 FUNC    GLOBAL DEFAULT   13 __gethostname_chk@@GLIBC_2.4
    13: 0007ded0    54 FUNC    GLOBAL DEFAULT   13 __strspn_c2@@GLIBC_2.1.1
    14: 0010d4e0   163 FUNC    GLOBAL DEFAULT   13 setrpcent@@GLIBC_2.0
    15: 00096ac0    39 FUNC    GLOBAL DEFAULT   13 __wcstod_l@@GLIBC_2.1
    16: 0007df10    84 FUNC    GLOBAL DEFAULT   13 __strspn_c3@@GLIBC_2.1.1
[...]
  2408: 000f34c0    65 FUNC    GLOBAL DEFAULT   13 pthread_attr_getinheritsc@@GLIBC_2.0
  2409: 000f5f90    56 FUNC    GLOBAL DEFAULT   13 __readlinkat_chk@@GLIBC_2.5
  2410: 00107920   122 FUNC    GLOBAL DEFAULT   13 __nss_hosts_lookup2@@GLIBC_PRIVATE
  2411: 00111f60   119 FUNC    GLOBAL DEFAULT   13 key_decryptsession@@GLIBC_2.1
  2412: 000e4b80   297 FUNC    GLOBAL DEFAULT   13 vwarn@@GLIBC_2.0
  2413: 000dc740   282 FUNC    GLOBAL DEFAULT   13 fts64_close@@GLIBC_2.23
  2414: 00091280    46 FUNC    WEAK   DEFAULT   13 wcpcpy@@GLIBC_2.0

5.5.3.1 符号版本

  动态符号的版本信息保存在.gnu.version节中，该节(Section)应与.dynsym节中的动态符号表(Dynamic Symbol Table)具有相同数量的条目，并且一一对应。其是由Elfxx_Versym结构构成的数组，每个数组元素是一个16位的整数，这个整数是由Elfxx_Vernaux结构的vna_other成员或Elfxx_Verdef结构的vd_ndx成员提供的符号版本标识符，一个索引。

  在这样的情况下，动态链接器使用从Elfxx_Rel结构体的成员r_info中获得的下标同时作为.dynsym节和.gnu.version节的下标。这样就可以一一对应到每一个符号到底是那个版本的了。

5.7 Data Related Sections

5.7.1 .bss

  此节保存未初始化的数据(全局变量)，占用程序内存映像空间，但不占用ELF文件空间。根据定义，当程序开始运行时，系统将这些数据初始化为0，在程序执行期间可以进行赋值。由于.bss节未保存实际的数据，因此此节属于SHT_NOBITS类型。属性类型为SHF_ALLOC和SHF_WRITE。

5.7.2 .tbss

  此节保存未初始化的线程本地数据，占用程序内存映像空间，但不占用ELF文件空间。根据定义，当为每个新执行流实例化数据时，系统将这些数据初始化为0，在程序执行期间可以进行赋值。由于.tbss节未保存实际的数据，因此此节属于SHT_NOBITS类型。属性类型为SHF_ALLOC、SHF_WRITE和SHF_TLS。

5.7.3 .data & .data1

  这些节保存初始化的数据(全局变量)，占用程序内存映像空间，也占用ELF文件空间。由于其保存了程序的变量数据，因此这些节属于SHT_PROGBITS类型。属性类型为SHF_ALLOC和SHF_WRITE。

5.7.4 .tdata & .tdata1

  这些节保存初始化的线程本地数据，占用程序内存映像空间，也占用ELF文件空间。系统为每个新的执行流都实例化其内容的一个副本。由于其保存了程序的变量数据，因此这些节属于SHT_PROGBITS类型。属性类型为SHF_ALLOC、SHF_WRITE和SHF_TLS。

5.7.5 .rodata & .rodata1

  这些节保存只读数据，这些数据通常会在进程内存映像中形成不可写的段(Segment)。这些节属于SHT_PROGBITS类型。使用的属性是SHF_ALLOC。

5.8 Common Code Section[^6]

术语：
Link-Editor：链接器
  链接器ld(1)，连接(Concatenate)并解释(Interpret)来自一个或多个输入文件的数据。这些文件可以是可重定位目标文件(Relocatable Objects)、共享目标文件(Shared Objects)或静态库(Archive Libraries)。从这些输入文件创建一个输出文件。此文件可以是动态可执行文件(Dynamic Executable)、位置无关可执行文件(Position-Independent Executable)、可重定位目标文件(Relocatable Object)或共享目标文件(Shared Objects)。链接器(Link-Editor)通常作为编译环境的一部分被调用。

Runtime Linker：运行时链接器/加载器
  运行时链接器ld.so.1(1)，在运行时处理动态可执行文件(Dynamic Executable)、位置无关可执行文件(Position-Independent Executable)和共享目标文件(Shared Objects)，将可执行文件(Executable)和共享目标文件(Shared Objects)绑定在一起以创建可运行的进程。

Shared Objects：共享目标文件/共享对象/共享库
  共享目标文件(Shared Objects)是链接编辑(Link-Edit)阶段的一种输出形式。共享目标文件有时称为共享库(Shared Libraries)。共享目标文件对于创建强大、灵活的运行时环境很重要。

Object Files：目标文件/对象文件
  链接器(Link-Editor)、运行时链接器(Runtime Linker)和相关工具处理符合可执行与可链接格式(Executable and Linkable Format，也称为ELF)的文件。

5.8.1 初始化和终止节

  动态目标文件(Dynamic Objects)可以提供用于运行时初始化(Runtime Initialization)和终止处理(Termination Processing)的代码。每次在进程中加载动态目标文件时，动态目标文件的初始化代码执行一次。每次从进程卸载动态目标文件或在进程终止时，动态目标文件的终止代码执行一次。这段代码可以封装在两种节类型中的一种，函数指针数组或单个代码块。每一种节类型的节都是由输入的可重定位目标文件(Relocatable Objects)中的类似节串联(Concatenation)得到的。

  .preinit_array、.init_array和.fini_array节分别提供了运行时预初始化(Pre-Initialization)、初始化(Initialization)和终止(Termination)函数的指针数组。在创建动态目标文件(Dynamic Objects)时，链接器(Link-Editor)会相应地使用.dynamic节的DT_PREINIT_[ARRAY/ARRAYSZ]、DT_INIT_[ARRAY/ARRAYSZ]和DT_FINI_[ARRAY/ARRAYSZ]“标签对”来标识这些数组。这些标签标识相关联的节，以便运行时链接器(Runtime Linker)可以调用这些节。预初始化数组(Pre-Initialization Array)仅适用于可执行文件。

注释：分配给这些数组的函数必须由正在构建的目标文件提供。

  .init和.fini节分别提供了运行时初始化(Initialization)和终止(Termination)代码块。编译器驱动程序(Compiler Drivers)通常会为.init和.fini节提供它们添加到输入文件列表(Input File List)开头和结尾的文件。这些编译器提供的文件具有将.init和.fini节中的代码从可重定位目标文件(Relocatable Objects)封装(Encapsulating)到单个函数中的作用。

  这些函数分别由保留符号名称_init和_fini标识。在创建动态目标文件(Dynamic Objects)时，链接器(Link-Editor)会相应地使用.dynamic的DT_INIT和DT_FINI标签来标识这些符号。这些标签标识相关联的节，以便运行时链接器(Runtime Linker)可以调用它们。

  链接器(Link-Editor)可以使用“-z initarray”和“-z finiarray”选项直接执行初始化(Initialization)和终止(Termination)函数的注册。例如，以下命令将foo()的地址放在.init_array数组的元素中，将bar()的地址放在.fini_array数组的元素中。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

$ cat main.c
#include <stdio.h>

void foo()
{
    (void) printf("initializing: foo()\n");
}

void bar()
{
    (void) printf("finalizing: bar()\n");
}

void main()
{
    (void) printf("main()\n");
}

$ cc -o main -z initarray=foo -z finiarray=bar main.c
$ main
initializing: foo()
main()
finalizing: bar()

  可以使用汇编器(Assembler)直接创建初始化(Initialization)和终止(Termination)节。然而，大多数编译器提供特殊的原语(Special Primitives)来简化它们的声明。例如，可以使用以下“#pragma”定义重写前面的代码示例。这些定义导致对foo()的调用被放置在.init节，对bar()的调用被放置在.fini节。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

$ cat main.c
#include <stdio.h>

#pragma init (foo)
#pragma fini (bar)

void foo()
{
    (void) printf("initializing: foo()\n");
}

void bar()
{
    (void) printf("finalizing: bar()\n");
}

void main()
{
    (void) printf("main()\n");
}

$ cc -o main main.c
$ main
initializing: foo()
main()
finalizing: bar()