ELF格式中文.docx

ELF格式中文.docx

《ELF格式中文.docx》由会员分享，可在线阅读，更多相关《ELF格式中文.docx（60页珍藏版）》请在冰豆网上搜索。

ELF格式中文

________________________________________________________________

EXECUTABLEANDLINKABLEFORMAT（ELF）

PortableFormatsSpecification,Version1.1

ToolInterfaceStandards（TIS）

________________________________________________________________

===========================Contents内容===========================

序言

1.OBJECT文件

导言

ELF头（ELFHeader）

Sections

String表（StringTable）

Symbol表（SymbolTable）

重定位（Relocation）

2.程序装载与动态连接

导言

Program头（ProgramHeader）

Program装载（ProgramLoading）

Dynamic连接（DynamicLinking）

3.CLIBRARY

CLibrary

________________________________________________________________

导言

________________________________________________________________

ELF:

可执行连接格式

可执行连接格式是UNIX系统实验室（USL）作为应用程序二进制接口

（ApplicationBinaryInterface（ABI）而开发和发布的。

工具接口标准委

员会（TIS）选择了正在发展中的ELF标准作为工作在32位INTEL体系上不同操

作系统之间可移植的二进制文件格式。

假定开发者定义了一个二进制接口集合，ELF标准用它来支持流线型的软件

发展。

应该减少不同执行接口的数量。

因此可以减少重新编程重新编译的

代码。

关于这片文档

这篇文档是为那些想创建目标文件或者在不同的操作系统上执行文件的开发

着准备的。

它分以下三个部分：

*第一部分,“目标文件ObjectFiles”描述了ELF目标文件格式三种主要

的类型。

*第二部分,“程序转载和动态连接”描述了目标文件的信息和系统在创建

运行时程序的行为。

*第三部分,“C语言库”列出了所有包含在libsys中的符号,标准的ANSIC

和libc的运行程序，还有libc运行程序所需的全局的数据符号。

注意:

参考的X86体系已经被改成了Intel体系。

________________________________________________________________

1.目标文件（Objectfile）

________________________________________________________________

序言

第一部分描述了iABI的object文件的格式,被称为ELF（Executable

andLinkingFormat）.在object文件中有三种主要的类型。

*一个可重定位（relocatable）文件保存着代码和适当的数据，用来和其他的

object文件一起来创建一个可执行文件或者是一个共享文件。

*一个可执行（executable）文件保存着一个用来执行的程序；该文件指出了

exec（BA_OS）如何来创建程序进程映象。

*一个共享object文件保存着代码和合适的数据，用来被下面的两个链接器

链接。

第一个是连接编辑器[请参看ld（SD_CMD）]，可以和其他的可重定位和

共享object文件来创建其他的object。

第二个是动态链接器，联合一个

可执行文件和其他的共享object文件来创建一个进程映象。

一个object文件被汇编器和联接器创建,想要在处理机上直接运行的object

文件都是以二进制来存放的。

那些需要抽象机制的程序，比如象shell脚本，

是不被接受的。

在介绍性的材料过后，第一部分主要围绕着文件的格式和关于如何建立程序。

第二部分也描述了object文件的几个组成部分，集中在执行程序所必须的信息上。

文件格式

Object文件参与程序的联接（创建一个程序）和程序的执行（运行一个程序）。

object文件格式提供了一个方便有效的方法并行的视角看待文件的内容，

在他们的活动中，反映出不同的需要。

例1-1图显示了一个object文件的

组织图。

+图1-1:

Object文件格式

一个ELF头在文件的开始，保存了路线图（roadmap），描述了该文件的组织情况。

sections保存着object文件的信息，从连接角度看：

包括指令，数据，

符号表，重定位信息等等。

特别sections的描述会出项在以后的第一部分。

第二部分讨论了段和从程序的执行角度看文件。

假如一个程序头表（programheadertable）存在，那么它告诉系统如何来创建一

个进程的内存映象。

被用来建立进程映象（执行一个程序）的文件必须要有一个程

序头表（programheadertable）；可重定位文件不需要这个头表。

一个

section头表（sectionheadertable）包含了描述文件sections的信息。

每个

section在这个表中有一个入口；每个入口给出了该section的名字，大小，

等等信息。

在联接过程中的文件必须有一个section头表；其他object文件可要

可不要这个section头表。

注意:

虽然图显示出程序头表立刻出现在一个ELF头后，section头表跟着其他

section部分出现，事实是的文件是可以不同的。

此外，sections和段（segments）

没有特别的顺序。

只有ELF头（elfheader）是在文件的固定位置。

数据表示

object文件格式支持8位、32位不同的处理器。

不过，它试图努力的在更大

或更小的体系上运行。

因此，object文件描绘一些控制数据需要用与机器

无关的格式，使它尽可能的用一般的方法甄别object文件和描述他们的内容。

在object文件中剩余的数据使用目标处理器的编码方式，不管文件是在哪台

机子上创建的。

+图1-2:

32-BitDataTypes

所有的object文件格式定义的数据结构是自然大小（naturalsize）,为相关

的类型调整指针。

如果需要，数据结构中明确的包含了确保4字节对齐的填

充字段。

来使结构大小是4的倍数。

数据从文件的开始也有适当的对齐。

例如，一个包含了Elf32_Addr成员的结构将会在文件内对齐到4字节的边界上。

因为移植性的原因，ELF不使用位字段。

ELFHeader

一些object文件的控制结构能够增长的，所以ELF头包含了他们目前的大小。

假如object文件格式改变，程序可能会碰到或大或小他们不希望的控制结构。

程序也有可能忽略额外（extra）的信息。

对待来历不明（missing）的信息依靠上下文来解释，假如扩展被定义，它们

将会被指定。

+图1-3:

ELFHeader

*e_ident

这个最初的字段标示了该文件为一个object文件，提供了一个机器无关

的数据，解释文件的内容。

在下面的ELF的鉴别（ELFIdentification）

部分有更详细的信息。

*e_type

该成员确定该object的类型。

NameValueMeaning

================

ET_NONE0Nofiletype

ET_REL1Relocatablefile

ET_EXEC2Executablefile

ET_DYN3Sharedobjectfile

ET_CORE4Corefile

ET_LOPROC0xff00Processor-specific

ET_HIPROC0xffffProcessor-specific

虽然CORE的文件内容未被指明，类型ET_CORE是保留的。

值从ET_LOPROC到ET_HIPROC（包括ET_HIPROC）是为特殊的处理器保留的。

如有需要，其他保留的变量将用在新的object文件类型上。

*e_machine

该成员变量指出了运行该程序需要的体系结构。

NameValueMeaning

================

EM_NONE0Nomachine

EM_M321AT&TWE32100

EM_SPARC2SPARC

EM_3863Intel80386

EM_68K4Motorola68000

EM_88K5Motorola88000

EM_8607Intel80860

EM_MIPS8MIPSRS3000

如有需要，其他保留的值将用到新的机器类型上。

特殊处理器名使用机器名来

区别他们。

例如，下面将要被提到的成员flags使用前缀EF_;在一台EM_XYZ机器

上，flag称为WIDGET，那么就称为EF_XYZ_WIDGET。

*e_version

这个成员确定object文件的版本。

NameValueMeaning

================

EV_NONE0Invalidversion

EV_CURRENT1Currentversion

值1表示原来的文件格式；创建新版本就用>1的数。

EV_CURRENT值（上面给

出为1）如果需要将指向当前的版本号。

*e_entry

该成员是系统第一个传输控制的虚拟地址，在那启动进程。

假如文件没有

关联的入口点，该成员就保持为0。

*e_phoff

该成员保持着程序头表（programheadertable）在文件中的偏移量（以字节计数）。

假如该文件没有程序头表的的话，该成员就保持为0。

*e_shoff

该成员保持着section头表（sectionheadertable）在文件中的偏移量（以字节

计数）。

假如该文件没有section头表的的话，该成员就保持为0。

*e_flags

该成员保存着相关文件的特定处理器标志。

flag的名字来自于EF__。

看下机器信息“MachineInformation”

部分的flag的定义。

*e_ehsize

该成员保存着ELF头大小（以字节计数）。

*e_phentsize

该成员保存着在文件的程序头表（programheadertable）中一个入口的大小

（以字节计数）。

所有的入口都是同样的大小。

*e_phnum

该成员保存着在程序头表中入口的个数。

因此，e_phentsize和e_phnum

的乘机就是表的大小（以字节计数）.假如没有程序头表（programheadertable），

e_phnum变量为0。

*e_shentsize

该成员保存着section头的大小（以字节计数）。

一个section头是在section

头表（sectionheadertable）的一个入口；所有的入口都是同样的大小。

*e_shnum

该成员保存着在sectionheadertable中的入口数目。

因此，e_shentsize和

e_shnum的乘积就是section头表的大小（以字节计数）。

假如文件没有section头表，e_shnum值为0。

*e_shstrndx

该成员保存着跟section名字字符表相关入口的section头表（sectionheader

table）索引。

假如文件中没有section名字字符表，该变量值为SHN_UNDEF。

更详细的信息看下面“Sections”和字符串表（“StringTable”）。

ELF鉴别（Identification）

在上面提到的，ELF提供了一个object文件的框架结构来支持多种处理机，多

样的数据编码方式，多种机器类型。

为了支持这个object文件家族，最初的几

个字节指定用来说明如何解释该文件，独立于处理器，与文件剩下的内容无关。

ELF头（也就是object文件）最初的几个字节与成员e_ident相一致。

+图1-4:

e_ident[]IdentificationIndexes

NameValuePurpose

================

EI_MAG00Fileidentification

EI_MAG11Fileidentification

EI_MAG22Fileidentification

EI_MAG33Fileidentification

EI_CLASS4Fileclass

EI_DATA5Dataencoding

EI_VERSION6Fileversion

EI_PAD7Startofpaddingbytes

EI_NIDENT16Sizeofe_ident[]

通过索引访问字节，以下的变量被定义。

*EI_MAG0toEI_MAG3

文件的前4个字符保存着一个魔术数（magicnumber），用来确定该文件是否

为ELF的目标文件。

*EI_CLASS

接下来的字节是e_ident[EI_CLASS]，用来确定文件的类型或者说是能力。

文件格式被设计成在不同大小机器中可移植的，在小型机上的不用大型机上

的尺寸。

类型ELFCLASS32支持虚拟地址空间最大可达4GB的机器；使用上面

定义过的基本类型。

类型ELFCLASS64为64位体系的机器保留。

它的出现表明了object文件可能

改变，但是64位的格式还没有被定义。

如果需要，其他类型将被定义，会

有不同的类型和不同大小的数据尺寸。

*EI_DATA

字节e_ident[EI_DATA]指定了在object文件中特定处理器数据的编码

方式。

当前定义了以下编码方式。

（LSB大端/MSB小端）

更多的关于编码的信息出现在下面。

其他值保留，将被分配一个新的编码

方式，当然如果必要的话。

*EI_VERSION

字节e_ident[EI_VERSION]表明了ELF头的版本号。

现在这个变量的是一定要设为EV_CURRENT，作为上面e_version的解释。

*EI_PAD

该变量标识了在e_ident中开始的未使用的字节。

那些字节保留并被设置为

0；程序把它们从object文件中读出但应该忽略。

假如当前未被使用的字节

有了新的定义，EI_PAD变量将来会被改变。

一个文件的数据编码指出了如何来解释一个基本的object文件。

在上述的

描述中，类型ELFCLAS32文件使用占用1，2和4字节的目标文件。

下面定义的

编码方式，用下面的图来描绘。

数据出现在左上角。

ELFDATA2LSB编码指定了2的补数值。

最小有意义的字节占有最低的地址。

+图1-5:

DataEncodingELFDATA2LSB

ELFDATA2LSB编码指定了2的补数值。

最大有意义的字节占有最低的地址。

+图1-6:

DataEncodingELFDATA2MSB

机器信息

机器信息

为了确定文件，32位Intel体系结构的需要以下的变量。

+图1-7:

32-bitIntelArchitectureIdentification,e_ident

处理器确认ELF头里的e_machine成员，该成员必须为EM_386。

ELF节头里的e_flags成员保存了和文件相关的位标记。

32位Intel体系上未

定义该标记；所以这个成员应该为0；

节

一个object文件的sectionheadertable可以让我们定位所有的sections。

sectionheadertable是个Elf32_Shdr结构的数组（下面描述）。

一个section

节头表（sectionheadertable）索引是这个数组的下标。

ELFheadertable

的e_shoff成员给出了section节头表的偏移量（从文件开始的计数）。

e_shnum

告诉我们section节头表中包含了多少个入口；e_shentsize给出了每个

入口的大小。

一些section节头表索引是保留的；那些特别的索引在一个object文件中

将没有与之对应sections。

+图1-8:

SpecialSectionIndexes

*SHN_UNDEF

该值表明没有定义，缺少，不相关的或者其他涉及到的无意义的section。

例如，标号“defined”相对于section索引号SHN_UNDEF是一个没有被

定义的标号。

注意:

虽然索引0保留作为未定义的值，section节头表包含了一个索引0的

入口。

因此，假如ELF节头说一个文件的section节头表中有6个section入口

的话，e_shnum的值应该是从0到5。

最初的入口的内容以后在这个section中

被指定。

*SHN_LORESERVE

该值指定保留的索引范围的最小值。

*SHN_LOPROCthroughSHN_HIPROC

该值包含了特定处理器语意的保留范围。

*SHN_ABS

该变量是相对于相应参考的绝对地址。

索引为SHN_ABS的section的地址是绝对地址，不被重定位影响。

*SHN_COMMON

该section的标号是一个公共（common）的标号，就象FORTRANCOMMON

或者不允许的C扩展变量。

*SHN_HIRESERVE

该值指定保留的索引范围的上限。

系统保留的索引值是从SHN_LORESERVE

到SHN_HIRESERVE；该变量不涉及到section节头表（sectionheadertable）。

因此，section节头表不为保留的索引值包含入口。

sections包含了在一个object文件中的所有信息，除了ELF节头，程序节头

表（programheadertable），和section节头表（sectionheadertable）。

此外，object文件的sections满足几个条件：

*每个在object文件中的section都有自己的一个section的节头来描述它。

section头可能存在但section可以不存在。

*每个section在文件中都占有一个连续顺序的空间（但可能是空的）。

*文件中的Sections不可能重复。

文件中没有一个字节既在这个section中

又在另外的一个section中。

*object文件可以有"非活动的"空间。

不同的节头和sections可以不覆盖到

object文件中的每个字节。

"非活动"数据内容是未指定的。

一个section头有如下的结构。

+图1-9:

SectionHeader

*sh_name

该成员指定了这个section的名字。

它的值是section节头字符表section的

索引。

[看以下的“StringTable”],以NULL空字符结束。

*sh_type

该成员把sections按内容和意义分类。

section的类型和他们的描述在下面。

*sh_flags

sections支持位的标记，用来描述多个属性。

Flag定义出现在下面。

*sh_addr

假如该section将出现在进程的内存映象空间里，该成员给出了一个该section

在内存中的位置。

否则，该变量为0。

*sh_offset

该成员变量给出了该section的字节偏移量（从文件开始计数）。

SHT_NOBITS

类型的section（下面讨论）在文件中不占空间，它的sh_offset成员定位在

文件中的概念上的位置。

*sh_size

该成员给你了section的字节大小。

除非这个section的类型为SHT_NOBITS，

否则该section将在文件中将占有sh_size个字节。

SHT_NOBITS类型的section

可能为非0的大小，但是不占文件空间。

*sh_link

该成员保存了一个section节头表的索引连接，它的解释依靠该section的

类型。

以下一个表描述了这些值。

*sh_info

该成员保存着额外的信息，它的解释依靠该section的类型。

以下一个表描

述了这些值。

*sh_addralign

一些sections有地址对齐的约束。

例如，假如一个section保存着双字，系统

就必须确定整个section是否双字对齐。

所以sh_addr的值以sh_addralign的值

作为模，那么一定为0。

当然的，仅仅0和正的2的次方是允许的。

值0和1意味

着该section没有对齐要求。

*sh_entsize

一些sections保存着一张固定大小入口的表，就象符号表。

对于这样一个

section来说，该成员给出了每个入口的字节大小。

如果该section没有

保存着一张固定大小入口的表，该成员就为0。

section头成员sh_type指出了section的语意。

+图1-10:

SectionTypes,sh_type

*SHT_NULL

该值表明该section头是无效的；它没有相关的section。

该section的其他成员的值都是未定义的。

*SHT_PROGBITS

该section保存被程序定义了的一些信息，它的格式和意义取决于程序本身。

*SHT_SYMTABandSHT_DYNSYM

那些sections保存着一个符号表（symboltable）。

一般情况下，一个

object文件每个类型section仅有一个，但是，在将来，这个约束可能被放宽。

典型的是，SHT_SYMTAB为连接器提供标号，当然它也有可能被动态连接时使用。

作为一个完整的符号表，它可能包含了一些动态连接时不需要的标号。

因此，一个object文件可能也包含了一个SHT_DYNSYM的section，它保存着

一个动态连接时所需最小的标号集合来节省空间。

看下面符号表“SymbolTable”的细节。

*SHT_STRTAB

该section保存着一个字符串表。

一个object文件可以包含多个字符串表的

section。

看下面字符串表“StringTable”的细节。