elf文件资料格式中文版.docx
- 文档编号:28885734
- 上传时间:2023-07-20
- 格式:DOCX
- 页数:77
- 大小:48.69KB
elf文件资料格式中文版.docx
《elf文件资料格式中文版.docx》由会员分享,可在线阅读,更多相关《elf文件资料格式中文版.docx(77页珍藏版)》请在冰豆网上搜索。
elf文件资料格式中文版
3.页标题的容和文章的页脚已经在开始的时候被换掉了。
4.文章的排版也已经修正过了。
5.如果必要,不同的字体已经被忽略了。
大部分地方,这片文档能让你
充分的理解。
然而,很小的地方,原始的文档使用了斜体字来指出文
章中的字符变量。
在那种情况下,本文使用<尖括号>。
在原始的文档
中没有出现尖括号。
6.原始的文档有三个错误,如果你是不经意读它的话,是不会明显
就能找出的。
但是在这里,明确的被鉴别出来了。
我很冒昧的纠正了那些错误。
在他们的位置用一个{*}做上了标记。
可能还有其他我没有看出来的的错误。
如果有如何其他的区别都是我的责任。
这样的错误请
mailto:
breadboxmuppetlabs..
BrianRaiter
[LasteditedFriJul231999]
________________________________________________________________
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文件格式
Linking视角Execution视角
==========================
ELFheaderELFheader
Programheadertable(optional)Programheadertable
Section1Segment1
...Segment2
Sectionn...
SectionheadertableSectionheadertable(optional)
一个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
NameSizeAlignmentPurpose
========================
Elf32_Addr44Unsignedprogramaddress
Elf32_Half22Unsignedmediuminteger
Elf32_Off44Unsignedfileoffset
Elf32_Sword44Signedlargeinteger
Elf32_Word44Unsignedlargeinteger
unsignedchar11Unsignedsmallinteger
所有的object文件格式定义的数据结构是自然大小(naturalsize),为相关
的类型调整指针。
如果需要,数据结构中明确的包含了确保4字节对齐的填
充字段。
来使结构大小是4的倍数。
数据从文件的开始也有适当的对齐。
例如,一个包含了Elf32_Addr成员的结构将会在文件对齐到4字节的边界上。
因为移植性的原因,ELF不使用位字段。
==========================ELFHeader==========================
一些object文件的控制结构能够增长的,所以ELF头包含了他们目前的大小。
假如object文件格式改变,程序可能会碰到或大或小他们不希望的控制结构。
程序也有可能忽略额外(extra)的信息。
对待来历不明(missing)的信息依靠上下文来解释,假如扩展被定义,它们
将会被指定。
+图1-3:
ELFHeader
#defineEI_NIDENT16
typedefstruct{
unsignedchare_ident[EI_NIDENT];
Elf32_Halfe_type;
Elf32_Halfe_machine;
Elf32_Worde_version;
Elf32_Addre_entry;
Elf32_Offe_phoff;
Elf32_Offe_shoff;
Elf32_Worde_flags;
Elf32_Halfe_ehsize;
Elf32_Halfe_phentsize;
Elf32_Halfe_phnum;
Elf32_Halfe_shentsize;
Elf32_Halfe_shnum;
Elf32_Halfe_shstrndx;
}Elf32_Ehdr;
*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的目标文件。
NameValuePosition
=================
ELFMAG00x7fe_ident[EI_MAG0]
ELFMAG1'E'e_ident[EI_MAG1]
ELFMAG2'L'e_ident[EI_MAG2]
ELFMAG3'F'e_ident[EI_MAG3]
*EI_CLASS
接下来的字节是e_ident[EI_CLASS],用来确定文件的类型或者说是能力。
NameValueMeaning
================
ELFCLASSNONE0Invalidclass
ELFCLASS32132-bitobjects
ELFCLASS64264-bitobjects
文件格式被设计成在不同大小机器中可移植的,在小型机上的不用大型机上
的尺寸。
类型ELFCLASS32支持虚拟地址空间最大可达4GB的机器;使用上面
定义过的基本类型。
类型ELFCLASS64为64位体系的机器保留。
它的出现表明了object文件可能
改变,但是64位的格式还没有被定义。
如果需要,其他类型将被定义,会
有不同的类型和不同大小的数据尺寸。
*EI_DATA
字节e_ident[EI_DATA]指定了在object文件中特定处理器数据的编码
方式。
当前定义了以下编码方式。
NameValueMeaning
================
ELFDATANONE0Invaliddataencoding
ELFDATA2LSB1Seebelow
ELFDATA2MSB2Seebelow
更多的关于编码的信息出现在下面。
其他值保留,将被分配一个新的编码
方式,当然如果必要的话。
*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
0------+
0x0102|01|
+------+
0------1------+
0x010204|02|01|
+------+------+
0------1------2------3------+
0x01020304|04|03|02|01|
+------+------+------+------+
ELFDATA2LSB编码指定了2的补数值。
最大有意义的字节占有最低的地址。
+图1-6:
DataEncodingELFDATA2MSB
0------+
0x0102|01|
+------+
0------1------+
0x010204|01|02|
+------+------+
0------1------2------3------+
0x01020304|01|02|03|04|
+------+------+------+------+
机器信息
为了确定文件,32位Intel体系结构的需要以下的变量。
+图1-7:
32-bitIntelArchitectureIdentification,e_ident
PositionValue
=============
e_ident[EI_CLASS]ELFCLASS32
e_ident[EI_DATA]ELFDATA2LSB
处理器确认ELF头里的e_machine成员,该成员必须为EM_386。
ELF报头里的e_flags成员保存了和文件相关的位标记。
32位Intel体系上未
定义该标记;所以这个成员应该为0;
===========================Sections===========================
一个object文件的sectionheadertable可以让我们定位所有的sections。
sectionheadertable是个Elf32_Shdr结构的数组(下面描述)。
一个section
报头表(sectionheadertable)索引是这个数组的下标。
ELFheadertable
的e_shoff成员给出了section报头表的偏移量(从文件开始的计数)。
e_shnum
告诉我们section报头表中包含了多少个入口;e_shentsize给出了每个
入口的大小。
一些section报头表索引是保留的;那些特别的索引在一个object文件中
将没有与之对应sections。
+图1-8:
SpecialSectionIndexes
NameValue
=========
SHN_UNDEF0
SHN_LORESERVE0xff00
SHN_LOPROC0xff00
SHN_HIPROC0xff1f
SHN_ABS0xfff1
SHN_COMMON0xfff2
SHN_HIRESERVE0xffff
*SHN_UNDEF
该值表明没有定义,缺少,不相关的或者其他涉及到的无意义的section。
例如,标号“defined”相对于se
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- elf 文件 资料 格式 中文版