3. 页标题的内容和文章的页脚已经在开始的时候被换掉了。
4. 文章的排版也已经修正过了。
5. 如果必要，不同的字体已经被忽略了。大部分地方，这片文档能让你
充分的理解。然而，很小的地方，原始的文档使用了斜体字来指出文
章中的字符变量。在那种情况下，本文使用<尖括号>。在原始的文档
中没有出现尖括号。
6. 原始的文档有三个错误，如果你是不经意读它的话，是不会明显
就能找出的。但是在这里，明确的被鉴别出来了。
我很冒昧的纠正了那些错误。在他们的位置用一个{*}做上了标记。
可能还有其他我没有看出来的的错误。
如果有如何其他的区别都是我的责任。这样的错误请
mailto:breadbox@https://www.doczj.com/doc/6516175333.html,.
Brian Raiter
[Last edited Fri Jul 23 1999]
________________________________________________________________
EXECUTABLE AND LINKABLE FORMAT (ELF)
Portable Formats Specification, Version 1.1
Tool Interface Standards (TIS)
________________________________________________________________
=========================== Contents 内容===========================
序言
1. OBJECT文件
导言
ELF头(ELF Header)
Sections
String表(String Table)
Symbol表(Symbol Table)
重定位(Relocation)
2. 程序装载与动态连接
导言
Program头(Program Header)
Program装载(Program Loading)
Dynamic连接(Dynamic Linking)
3. C LIBRARY
C Library
________________________________________________________________
导言
________________________________________________________________ ELF: 可执行连接格式
可执行连接格式是UNIX系统实验室(USL)作为应用程序二进制接口(Application Binary Interface(ABI)而开发和发布的。工具接口标准委
员会(TIS)选择了正在发展中的ELF标准作为工作在32位INTEL体系上不同操作系统之间可移植的二进制文件格式。
假定开发者定义了一个二进制接口集合，ELF标准用它来支持流线型的软件
发展。应该减少不同执行接口的数量。因此可以减少重新编程重新编译的
代码。
关于这片文档
这篇文档是为那些想创建目标文件或者在不同的操作系统上执行文件的开发
着准备的。它分以下三个部分：
* 第一部分, “目标文件Object Files”描述了ELF目标文件格式三种主要
的类型。
* 第二部分, “程序转载和动态连接”描述了目标文件的信息和系统在创建
运行时程序的行为。
* 第三部分, “C 语言库”列出了所有包含在libsys中的符号,标准的ANSI C
和libc的运行程序，还有libc运行程序所需的全局的数据符号。
注意: 参考的X86体系已经被改成了Intel体系。
________________________________________________________________
1. 目标文件(Object file)
________________________________________________________________
========================= 序言=========================
第一部分描述了iABI的object文件的格式, 被称为ELF(Executable
and Linking Format). 在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 视角
============ ==============
ELF header ELF header
Program header table (optional) Program header table
Section 1 Segment 1
... Segment 2
Section n ...
Section header table Section header table (optional)
一个ELF头在文件的开始，保存了路线图(road map)，描述了该文件的组织情况。sections保存着object 文件的信息，从连接角度看：包括指令，数据，
符号表，重定位信息等等。特别sections的描述会出项在以后的第一部分。
第二部分讨论了段和从程序的执行角度看文件。
假如一个程序头表（program header table）存在，那么它告诉系统如何来创建一
个进程的内存映象。被用来建立进程映象(执行一个程序)的文件必须要有一个程序头表（program header table）；可重定位文件不需要这个头表。一个
section头表（section header table）包含了描述文件sections的信息。每个
section在这个表中有一个入口；每个入口给出了该section的名字，大小，
等等信息。在联接过程中的文件必须有一个section头表；其他object文件可要
可不要这个section头表。
注意: 虽然图显示出程序头表立刻出现在一个ELF头后，section头表跟着其他section部分出现，事实是的文件是可以不同的。此外，sections和段(segments)
没有特别的顺序。只有ELF头（elf header）是在文件的固定位置。
数据表示
object文件格式支持8位、32位不同的处理器。不过，它试图努力的在更大
或更小的体系上运行。因此，object文件描绘一些控制数据需要用与机器
无关的格式，使它尽可能的用一般的方法甄别object文件和描述他们的内容。
在object文件中剩余的数据使用目标处理器的编码方式，不管文件是在哪台
机子上创建的。
+ 图1-2: 32-Bit Data Types
Name Size Alignment Purpose
==== ==== ========= =======
Elf32_Addr 4 4 Unsigned program address
Elf32_Half 2 2 Unsigned medium integer
Elf32_Off 4 4 Unsigned file offset
Elf32_Sword 4 4 Signed large integer
Elf32_Word 4 4 Unsigned large integer
unsigned char 1 1 Unsigned small integer
所有的object文件格式定义的数据结构是自然大小(natural size),为相关
的类型调整指针。如果需要，数据结构中明确的包含了确保4字节对齐的填
充字段。来使结构大小是4的倍数。数据从文件的开始也有适当的对齐。
例如，一个包含了Elf32_Addr成员的结构将会在文件内对齐到4字节的边界上。因为移植性的原因，ELF不使用位字段。
========================== ELF Header ==========================
一些object文件的控制结构能够增长的，所以ELF头包含了他们目前的大小。假如object文件格式改变，程序可能会碰到或大或小他们不希望的控制结构。程序也有可能忽略额外（extra）的信息。
对待来历不明(missing)的信息依靠上下文来解释，假如扩展被定义，它们
将会被指定。
+ 图1-3: ELF Header
#define EI_NIDENT 16
typedef struct {
unsigned char e_ident[EI_NIDENT];
Elf32_Half e_type;
Elf32_Half e_machine;
Elf32_Word e_version;
Elf32_Addr e_entry;
Elf32_Off e_phoff;
Elf32_Off e_shoff;
Elf32_Word e_flags;
Elf32_Half e_ehsize;
Elf32_Half e_phentsize;
Elf32_Half e_phnum;
Elf32_Half e_shentsize;
Elf32_Half e_shnum;
Elf32_Half e_shstrndx;
} Elf32_Ehdr;
* e_ident
这个最初的字段标示了该文件为一个object文件，提供了一个机器无关
的数据，解释文件的内容。在下面的ELF的鉴别（ELF Identification）
部分有更详细的信息。
* e_type
该成员确定该object的类型。
Name Value Meaning
==== ===== =======
ET_NONE 0 No file type
ET_REL 1 Relocatable file
ET_EXEC 2 Executable file
ET_DYN 3 Shared object file
ET_CORE 4 Core file
ET_LOPROC 0xff00 Processor-specific
ET_HIPROC 0xffff Processor-specific
虽然CORE的文件内容未被指明，类型ET_CORE是保留的。
值从ET_LOPROC 到ET_HIPROC(包括ET_HIPROC)是为特殊的处理器保留的。如有需要，其他保留的变量将用在新的object文件类型上。
* e_machine
该成员变量指出了运行该程序需要的体系结构。
Name Value Meaning
==== ===== =======
EM_NONE 0 No machine
EM_M32 1 AT&T WE 32100
EM_SPARC 2 SPARC
EM_386 3 Intel 80386
EM_68K 4 Motorola 68000
EM_88K 5 Motorola 88000
EM_860 7 Intel 80860
EM_MIPS 8 MIPS RS3000
如有需要，其他保留的值将用到新的机器类型上。特殊处理器名使用机器名来
区别他们。例如，下面将要被提到的成员flags使用前缀EF_;在一台EM_XYZ机器上，flag称为WIDGET，那么就称为EF_XYZ_WIDGET。
* e_version
这个成员确定object文件的版本。
Name Value Meaning
==== ===== =======
EV_NONE 0 Invalid version
EV_CURRENT 1 Current version
值1表示原来的文件格式；创建新版本就用>1的数。EV_CURRENT值(上面给
出为1)如果需要将指向当前的版本号。
* e_entry
该成员是系统第一个传输控制的虚拟地址，在那启动进程。假如文件没有
如何关联的入口点，该成员就保持为0。
* e_phoff
该成员保持着程序头表（program header table）在文件中的偏移量(以字节计数)。假如该文件没有程序头表的的话，该成员就保持为0。
* e_shoff
该成员保持着section头表（section header table）在文件中的偏移量(以字节
计数)。假如该文件没有section头表的的话，该成员就保持为0。
* e_flags
该成员保存着相关文件的特定处理器标志。
flag的名字来自于EF_
部分的flag的定义。
* e_ehsize
该成员保存着ELF头大小(以字节计数)。
* e_phentsize
该成员保存着在文件的程序头表（program header table）中一个入口的大小
(以字节计数)。所有的入口都是同样的大小。
* e_phnum
该成员保存着在程序头表中入口的个数。因此，e_phentsize和e_phnum
的乘机就是表的大小(以字节计数).假如没有程序头表（program header table），
e_phnum变量为0。
* e_shentsize
该成员保存着section头的大小(以字节计数)。一个section头是在section
头表(section header table)的一个入口；所有的入口都是同样的大小。
* e_shnum
该成员保存着在section header table中的入口数目。因此，e_shentsize和
e_shnum的乘积就是section头表的大小(以字节计数)。
假如文件没有section头表，e_shnum值为0。
* e_shstrndx
该成员保存着跟section名字字符表相关入口的section头表(section header table)索引。假如文件中没有section名字字符表，该变量值为SHN_UNDEF。
更详细的信息看下面“Sections”和字符串表(“String Table”) 。
ELF 鉴别(Identification)
在上面提到的，ELF提供了一个object文件的框架结构来支持多种处理机，多样的数据编码方式，多种机器类型。为了支持这个object文件家族，最初的几个字节指定用来说明如何解释该文件，独立于处理器，与文件剩下的内容无关。
ELF头(也就是object文件)最初的几个字节与成员e_ident相一致。
+ 图1-4: e_ident[] Identification Indexes
Name Value Purpose
==== ===== =======
EI_MAG0 0 File identification
EI_MAG1 1 File identification
EI_MAG2 2 File identification
EI_MAG3 3 File identification
EI_CLASS 4 File class
EI_DA TA 5 Data encoding
EI_VERSION 6 File version
EI_PAD 7 Start of padding bytes
EI_NIDENT 16 Size of e_ident[]
通过索引访问字节，以下的变量被定义。
* EI_MAG0 to EI_MAG3
文件的前4个字符保存着一个魔术数(magic number)，用来确定该文件是否
为ELF的目标文件。
Name Value Position
==== ===== ========
ELFMAG0 0x7f e_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]，用来确定文件的类型或者说是能力。
Name Value Meaning
==== ===== =======
ELFCLASSNONE 0 Invalid class
ELFCLASS32 1 32-bit objects
ELFCLASS64 2 64-bit objects
文件格式被设计成在不同大小机器中可移植的，在小型机上的不用大型机上
的尺寸。类型ELFCLASS32支持虚拟地址空间最大可达4GB的机器；使用上面定义过的基本类型。
类型ELFCLASS64为64位体系的机器保留。它的出现表明了object文件可能
改变，但是64位的格式还没有被定义。如果需要，其他类型将被定义，会
有不同的类型和不同大小的数据尺寸。
* EI_DATA
字节e_ident[EI_DA TA]指定了在object文件中特定处理器数据的编码
方式。当前定义了以下编码方式。
Name Value Meaning
==== ===== =======
ELFDATANONE 0 Invalid data encoding
ELFDATA2LSB 1 See below
ELFDATA2MSB 2 See below
更多的关于编码的信息出现在下面。其他值保留，将被分配一个新的编码
方式，当然如果必要的话。
* 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: Data Encoding ELFDATA2LSB
0------+
0x0102 | 01 |
+------+
0------1------+
0x010204 | 02 | 01 |
+------+------+
0------1------2------3------+
0x01020304 | 04 | 03 | 02 | 01 |
+------+------+------+------+
ELFDATA2LSB编码指定了2的补数值。
最大有意义的字节占有最低的地址。
+ 图1-6: Data Encoding ELFDATA2MSB
0------+
0x0102 | 01 |
+------+
0------1------+
0x010204 | 01 | 02 |
+------+------+
0------1------2------3------+
0x01020304 | 01 | 02 | 03 | 04 |
+------+------+------+------+
机器信息
为了确定文件，32位Intel体系结构的需要以下的变量。
+ 图1-7: 32-bit Intel Architecture Identification, e_ident
Position Value
======== =====
e_ident[EI_CLASS] ELFCLASS32
e_ident[EI_DATA] ELFDATA2LSB
处理器确认ELF头里的e_machine成员，该成员必须为EM_386。
ELF报头里的e_flags成员保存了和文件相关的位标记。32位Intel体系上未
定义该标记；所以这个成员应该为0；
=========================== Sections ===========================
一个object文件的section header table可以让我们定位所有的sections。section header table是个Elf32_Shdr结构的数组(下面描述)。一个section
报头表(section header table)索引是这个数组的下标。ELF header table
的e_shoff成员给出了section报头表的偏移量(从文件开始的计数)。e_shnum
告诉我们section报头表中包含了多少个入口；e_shentsize 给出了每个
入口的大小。
一些section报头表索引是保留的；那些特别的索引在一个object文件中
将没有与之对应sections。
+ 图1-8: Special Section Indexes
Name Value
==== =====
SHN_UNDEF 0
SHN_LORESERVE 0xff00
SHN_LOPROC 0xff00
SHN_HIPROC 0xff1f
SHN_ABS 0xfff1
SHN_COMMON 0xfff2
SHN_HIRESERVE 0xffff
* SHN_UNDEF
该值表明没有定义，缺少，不相关的或者其他涉及到的无意义的section。
例如，标号“defined”相对于section索引号SHN_UNDEF是一个没有被
定义的标号。
注意: 虽然索引0保留作为未定义的值，section报头表包含了一个索引0的
入口。因此，假如ELF报头说一个文件的section报头表中有6个section入口的话，e_shnum的值应该是从0到5。最初的入口的内容以后在这个section中被指定。
* SHN_LORESERVE
该值指定保留的索引范围的最小值。
* SHN_LOPROC through SHN_HIPROC
该值包含了特定处理器语意的保留范围。
* SHN_ABS
该变量是相对于相应参考的绝对地址。
例如，section号的标号是绝对地址，不被重定位影响。
* SHN_COMMON
该section的标号是一个公共(common)的标号，就象FORTRAN COMMON
或者不允许的C扩展变量。
* SHN_HIRESERVE
该值指定保留的索引范围的上限。系统保留的索引值是从SHN_LORESERVE 到SHN_HIRESERVE；该变量不涉及到section报头表（section header table）。因此，section报头表不为保留的索引值包含入口。
sections包含了在一个object文件中的所有信息，除了ELF报头，程序报头
表(program header table)，和section报头表(section header table)。
此外，object文件的sections满足几天条件：
* 每个在object文件中的section都有自己的一个section的报头来描述它。section头可能存在但section可以不存在。
* 每个section在文件中都占有一个连续顺序的空间(但可能是空的)。
* 文件中的Sections不可能重复。文件中没有一个字节既在这个section中
又在另外的一个section中。
* object文件可以有"非活动的"空间。不同的报头和sections可以不覆盖到object文件中的每个字节。"非活动"数据内容是未指定的。
一个section头有如下的结构。
+ 图1-9: Section Header
typedef struct {
Elf32_Word sh_name;
Elf32_Word sh_type;
Elf32_Word sh_flags;
Elf32_Addr sh_addr;
Elf32_Off sh_offset;
Elf32_Word sh_size;
Elf32_Word sh_link;
Elf32_Word sh_info;
Elf32_Word sh_addralign;
Elf32_Word sh_entsize;
} Elf32_Shdr;
* sh_name
该成员指定了这个section的名字。它的值是section报头字符表section的
索引。[看以下的“String Table”], 以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: Section Types, sh_type
Name Value
==== =====
SHT_NULL 0
SHT_PROGBITS 1
SHT_SYMTAB 2
SHT_STRTAB 3
SHT_RELA 4
SHT_HASH 5
SHT_DYNAMIC 6
SHT_NOTE 7
SHT_NOBITS 8
SHT_REL 9
SHT_SHLIB 10
SHT_DYNSYM 11
SHT_LOPROC 0x70000000
SHT_HIPROC 0x7fffffff
SHT_LOUSER 0x80000000
SHT_HIUSER 0xffffffff
* SHT_NULL
该值表明该section头是无效的；它没有相关的section。
该section的其他成员的值都是未定义的。
* SHT_PROGBITS
该section保存被程序定义了的一些信息，它的格式和意义取决于程序本身。
* SHT_SYMTAB and SHT_DYNSYM
那些sections保存着一个符号表（symbol table）。一般情况下，一个
object文件每个类型section仅有一个，但是，在将来，这个约束可能被放宽。
典型的是，SHT_SYMTAB为连接器提供标号，当然它也有可能被动态连接时使用。作为一个完整的符号表，它可能包含了一些动态连接时不需要的标号。
因此，一个object文件可能也包含了一个SHT_DYNSYM的section，它保存着
一个动态连接时所需最小的标号集合来节省空间。
看下面符号表“Symbol Table”的细节。
* SHT_STRTAB
该section保存着一个字符串表。一个object文件可以包含多个字符串表的section。看下面字符串表“String Table”的细节。
* SHT_RELA
该section保存着具有明确加数的重定位入口。就象object文件32位的
Elf32_Rela类型。一个object文件可能有多个重定位的sections。具体细节
看重定位``Relocation''部分。
* SHT_HASH
该标号保存着一个标号的哈希(hash)表。所有的参与动态连接的object
一定包含了一个标号哈希表（hash table）。当前的，一个object文件
可能只有一个哈希表。详细细节看第二部分的哈希表"Hash Table"。
* SHT_DYNAMIC
该section保存着动态连接的信息。当前的，一个object可能只有一个动态
的section，但是，将来这个限制可能被取消。详细细节看第二部分的动态
section(“Dynamic Section”)。
* SHT_NOTE
该section保存着其他的一些标志文件的信息。详细细节看第二部分的“Note Section” 。
* SHT_NOBITS
该类型的section在文件中不占空间，但是类似SHT_PROGBITS。尽管该section 不包含字节，sh_offset成员包含了概念上的文件偏移量。
* SHT_REL
该section保存着具有明确加数的重定位的入口。
就象object文件32位类型Elf32_Rel类型。一个object文件可能有多个
重定位的sections。具体细节看重定位``Relocation''部分。
* SHT_SHLIB
该section类型保留但语意没有指明。包含这个类型的section的程序
是不符合ABI的。
* SHT_LOPROC through SHT_HIPROC
在这范围之间的值为特定处理器语意保留的。
* SHT_LOUSER
该变量为应用程序保留的索引范围的最小边界。
* SHT_HIUSER
该变量为应用程序保留的索引范围的最大边界。在SHT_LOUSER和HIUSER的section类型可能被应用程序使用，这和当前或者将来系统定义的section
类型是不矛盾的。
其他section类型的变量是保留的。前面提到过，索引0(SHN_UNDEF)的section 头存在的，甚至索引标记的是未定义的section引用。这个入口保存着以下的
信息。
+ 图1-11: Section Header Table Entry: Index 0
Name Value Note
==== ===== ====
sh_name 0 No name
sh_type SHT_NULL Inactive
sh_flags 0 No flags
sh_addr 0 No address
sh_offset 0 No file offset
sh_size 0 No size
sh_link SHN_UNDEF No link information
sh_info 0 No auxiliary information
sh_addralign 0 No alignment
sh_entsize 0 No entries
一个section报头（section header table）的sh_flags成员保存着1位标记，
用来描述section的属性。以下是定义的值；其他的值保留。
+ 图1-12: Section Attribute Flags, sh_flags
Name Value
==== =====
SHF_WRITE 0x1
SHF_ALLOC 0x2
SHF_EXECINSTR 0x4
SHF_MASKPROC 0xf0000000
假如在sh_flags中的一个标记位被设置，该section相应的属性也被打开。
否则，该属性没有被应用。未明的属性就设为0。
* SHF_WRITE
该section包含了在进程执行过程中可被写的数据。
* SHF_ALLOC
该section在进程执行过程中占据着内存。一些控制section不存在一个object文件的内存映象中；对于这些sections，这个属性应该关掉。
* SHF_EXECINSTR
该section包含了可执行的机器指令。
* SHF_MASKPROC
所有的包括在这掩码中的位为特定处理语意保留的。
在section报头中，两个成员sh_link和sh_info的解释依靠该section的类型。
+ 图1-13: sh_link and sh_info Interpretation
sh_type sh_link sh_info
======= ======= =======
SHT_DYNAMIC The section header index of 0
the string table used by
entries in the section.
SHT_HASH The section header index of 0
the symbol table to which the
hash table applies.
SHT_REL, The section header index of The section header index of
SHT_RELA the associated symbol table. the section to which the
relocation applies.
SHT_SYMTAB, The section header index of One greater than the symbol
SHT_DYNSYM the associated string table. table index of the last local
symbol (binding STB_LOCAL).
other SHN_UNDEF 0
Special Sections 特殊的Sections
不同的sections保存着程序和控制信息。下面列表中的section被系统使用，指示了类型和属性。
+ 图1-14: Special Sections
Name Type Attributes
==== ==== ==========
.bss SHT_NOBITS SHF_ALLOC+SHF_WRITE
.comment SHT_PROGBITS none
.data SHT_PROGBITS SHF_ALLOC+SHF_WRITE
.data1 SHT_PROGBITS SHF_ALLOC+SHF_WRITE
.debug SHT_PROGBITS none
.dynamic SHT_DYNAMIC see below
.dynstr SHT_STRTAB SHF_ALLOC
.dynsym SHT_DYNSYM SHF_ALLOC
.fini SHT_PROGBITS SHF_ALLOC+SHF_EXECINSTR
.got SHT_PROGBITS see below
.hash SHT_HASH SHF_ALLOC
.init SHT_PROGBITS SHF_ALLOC+SHF_EXECINSTR
.interp SHT_PROGBITS see below
.line SHT_PROGBITS none
.note SHT_NOTE none
.plt SHT_PROGBITS see below
.rel
.rela
.rodata SHT_PROGBITS SHF_ALLOC
.rodata1 SHT_PROGBITS SHF_ALLOC
.shstrtab SHT_STRTAB none
.strtab SHT_STRTAB see below
.symtab SHT_SYMTAB see below
.text SHT_PROGBITS SHF_ALLOC+SHF_EXECINSTR
* .bss
该sectiopn保存着未初始化的数据，这些数据存在于程序内存映象中。
通过定义，当程序开始运行，系统初始化那些数据为0。该section不占
文件空间，正如它的section类型SHT_NOBITS指示的一样。
* .comment
该section保存着版本控制信息。
* .data and .data1
这些sections保存着初始化了的数据，那些数据存在于程序内存映象中。
* .debug
该section保存着为标号调试的信息。该内容是未指明的。
* .dynamic
该section保存着动态连接的信息。该section的属性将包括SHF_ALLOC位。是否需要SHF_WRITE是跟处理器有关。第二部分有更详细的信息。
* .dynstr
该section保存着动态连接时需要的字符串，一般情况下，名字字符串关联着符号表的入口。第二部分有更详细的信息。
* .dynsym
该section保存着动态符号表，如“Symbol Table”的描述。第二部分有更
详细的信息。
* .fini
该section保存着可执行指令，它构成了进程的终止代码。
因此，当一个程序正常退出时，系统安排执行这个section的中的代码。
* .got
该section保存着全局的偏移量表。看第一部分的“Special Sections”和
第二部分的“Global Offset Table”获得更多的信息。
* .hash
该section保存着一个标号的哈希表。看第二部分的“Hash Table”获得更多
的信息。
* .init
该section保存着可执行指令，它构成了进程的初始化代码。
因此，当一个程序开始运行时，在main函数被调用之前(c语言称为main)，
系统安排执行这个section的中的代码。
* .interp
该section保存了程序的解释程序(interpreter)的路径。假如在这个section
中有一个可装载的段，那么该section的属性的SHF_ALLOC位将被设置；否则，该位不会被设置。看第二部分获得更多的信息。
* .line
该section包含编辑字符的行数信息,它描述源程序与机器代码之间的对于
关系。该section内容不明确的。
* .note
该section保存一些信息，使用“Note Section”(在第二部分)中提到的格式。
* .plt
该section保存着过程连接表（Procedure Linkage Table）。看第一部分的
``Special Sections''和第二部分的“Procedure Linkage Table”。
* .rel
这些section保存着重定位的信息，看下面的``Relocation''描述。
假如文件包含了一个可装载的段，并且这个段是重定位的，那么该section的
属性将设置SHF_ALLOC位；否则该位被关闭。按照惯例，
就为.rel.text或者是.rela.text。
* .rodata and .rodata1
这些section保存着只读数据，在进程映象中构造不可写的段。看第二部分的
PE文件格式详解（一）――基础知识 什么是PE文件格式： 我们知道所有文件都是一些连续（当然实际存储在磁盘上的时候不一定是连续的）的数据组织起来的，不同类型的文件肯定组织形式也各不相同；PE文件格式便是一种文件组织形式，它是32位Wind ow系统中的可执行文件EXE以及动态连接库文件DLL的组织形式。为什么我们双击一个EXE文件之后它就会被Window运行，而我们双击一个DOC文件就会被Word打开并显示其中的内容；这说明文件中肯定除了存在那些文件的主体内容（比如EXE文件中的代码，数据等，DOC文件中的文件内容等）之外还存在其他一些重要的信息。这些信息是给文件的使用者看的，比如说EXE文件的使用者就是Window，而DOC文件的使用者就是Word。Window可以根据这些信息知道把文件加载到地址空间的那个位置，知道从哪个地址开始执行；加载到内存后如何修正一些指令中的地址等等。那么PE文件中的这些重要信息都是由谁加入的呢？是由编译器和连接器完成的，针对不同的编译器和连接器通常会提供不同的选项让我们在编译和 联结生成PE文件的时候对其中的那些Window需要的信息进行设定；当然也可以按照默认的方式编译连接生成Window中默认的信息。例如：WindowNT默认的程序加载基址是0x40000；你可以在用VC连接生成EXE文件的时候使用选项更改这个地址值。在不同的操作系统中可执行文件的格式是不同的，比如在Linux上就有一种流行的ELF格式；当然它是由在Linux上的编译器和连接器生成的，
所以编译器、连接器是针对不同的CPU架构和不同的操作系统而涉及出来的。在嵌入式领域中我们经常提到交叉编译器一词，它的作用就是在一种平台下编译出能在另一个平台下运行的程序；例如，我们可以使用交叉编译器在跑Linux的X86机器上编译出能在Arm上运行的程序。 程序是如何运行起来的： 一个程序从编写出来到运行一共需要那些工具，他们都对程序作了些什么呢？里面都涉及哪些知识需要学习呢？先说工具：编辑器－》编译器－》连接器－》加载器；首先我们使用编辑器编辑源文件；然后使用编译器编译程目标文件OBJ，这里面涉及到编译原理的知识；连接器把OBJ文件和其他一些库文件和资源文件连接起来生成EXE文件，这里面涉及到不同的连接器的知识，连接器根据OS的需要生成EXE文件保存着磁盘上；当我们运行EXE文件的时候有W indow的加载器负责把EXE文件加载到线性地址空间，加载的时候便是根据上一节中说到的PE文件格式中的哪些重要信息。然后生成一个进程，如果进程中涉及到多个线程还要生成一个主线程；此后进程便开始运行；这里面涉及的东西很多，包括：PE文件格式的内容；内存管理（CPU内存管理的硬件环境以及在此基础上的OS内存管理方式）；模块，进程，线程的知识；只有把这些都弄清楚之后才能比较清楚的了解这整个过程。下面就让我们先来学习PE文件格式吧。
第1章文件格式 1.1 Executable and Linking Format (ELF) 1.1.1整体结构 ELF对象格式用于目标文件(.o扩展名)和执行文件. 有些信息只出现在目标文件或执行文件中. ELF文件由下列部件构成. ELF header必须放在文件的开始;其他部件可以随便排放(ELF header给出了其他部件的偏移量). 1.1.2ELF头[ELF Header] ELF头包含目标文件的一般信息;具有如下结构(from elf.h): #define EI_NIDENT 16 typedef struct { unsigned char e_ident[EI_NIDENT]; Elf32_Half e_e_type; Elf32_Half e_machine; Elf32_Word e_version; Elf32_Addr e_entry; Elf32_Off e_phoff; Elf32_Off e_shoff; Elf32_Word e_flags; Elf32_Half e_ehsize; Elf32_Half e_phentsize; Elf32_Half e_phnum; Elf32_Half e_shentsize; Elf32_Half e_shnum; Elf32_Half e_shstrndx; }; ELF头域描述:
1.1.3程序头[Program Header] 程序头为一结构数组,每个元素描述执行文件的一个可载入段. 元素结构如下(from elf.h): typedef struct { Elf32_Word p_type; Elf32_Off p_offset; Elf32_Addr p_vaddr; Elf32_Addr p_paddr; Elf32_Word p_filesz; Elf32_Word p_memsz; Elf32_Word p_flags; Elf32_Word p_align; } Elf32_Phdr;
ARM-ELF文件格式与GNU ARM Linker机制 作者:admin 日期:2008-10-13 字体大小: 小中大
里面除了二进制的机器代码，还有一些可用于进行重定位的信息。它主要是作为LINKER(ld)的输入，LINKER将跟据这些信息，将需要重定位的符号重定位，进而产生可执行的OBJECT 文件。ELF格式的可重定位OBJECT文件由header与section 组成。 Header 包括ELF header 与 section header. ELF header 位于文件的头部，用于存储目标机器的架构，大小端配置，ELF header 大小，object文件类型，section header 在文件中的偏移，section header 的大小，section header 中的项目数等信息。Section header 则定义了文件中每个section 的类型，位置，大小等信息。Linker就是通过查找ELF header，找到 section header 的入口，再在section header 中找到相应的section 入口，进而定位到目标section 的。 Section 包括 .text ：经过编译的机器代码。 .rodata ：只读的数据，例如printf(“hello!”)中的字符串hello。.data ：已初始化的全局变量，局部变量将在运行时被存放在堆栈中，不会在.data或 .bss段中出现。 .bss ：未初始化的全局变量，在这里只是一个占位符，在object 文件中并没有实际的存储空间。 .symtab ：符号表，用于存放程序中被定义的或被引用到的全局变量和函数的信息。
3. 页标题的容和文章的页脚已经在开始的时候被换掉了。 4. 文章的排版也已经修正过了。 5. 如果必要，不同的字体已经被忽略了。大部分地方，这片文档能让你 充分的理解。然而，很小的地方，原始的文档使用了斜体字来指出文 章中的字符变量。在那种情况下，本文使用<尖括号>。在原始的文档 中没有出现尖括号。 6. 原始的文档有三个错误，如果你是不经意读它的话，是不会明显 就能找出的。但是在这里，明确的被鉴别出来了。 我很冒昧的纠正了那些错误。在他们的位置用一个{*}做上了标记。 可能还有其他我没有看出来的的错误。 如果有如何其他的区别都是我的责任。这样的错误请 mailto:breadboxmuppetlabs.. Brian Raiter [Last edited Fri Jul 23 1999] ________________________________________________________________ EXECUTABLE AND LINKABLE FORMAT (ELF) Portable Formats Specification, Version 1.1 Tool Interface Standards (TIS) ________________________________________________________________ =========================== Contents 容=========================== 序言 1. OBJECT文件 导言 ELF头(ELF Header) Sections String表(String Table) Symbol表(Symbol Table) 重定位(Relocation) 2. 程序装载与动态连接 导言 Program头(Program Header)
现代Linux采用ELF(Executable and Linking Format)做为其可连接和可执行文件的格式，因此ELF格式也向我们透出了一点Linux核内的情景，就像戏台维幕留下的一条未拉严的缝。 PC世界32仍是主流，但64位的脚步却已如此的逼近。如果你对Windows比较熟悉，本文还将时时把你带回到PE中，在它们的相似之处稍做比较。ELF文件以“ELF 头”开始，后面可选择的跟随着程序头和节头。地理学用等高线与等温线分别展示同一地区的地势和气候，程序头和节头则分别从加载与连接角度来描述EFL文件的组织方式。 ELF头 ------------------------------------------------ ELF头也叫ELF文件头，它位于文件中最开始的地方。 /usr/src/linux/include/linux/elf.h typedef struct elf32_hdr{ unsigned char e_ident[EI_NIDENT]; Elf32_Half e_type; Elf32_Half e_machine; Elf32_Word e_version; Elf32_Addr e_entry; /* Entry point */ Elf32_Off e_phoff;
Elf32_Off e_shoff; Elf32_Word e_flags; Elf32_Half e_ehsize; Elf32_Half e_phentsize; Elf32_Half e_phnum; Elf32_Half e_shentsize; Elf32_Half e_shnum; Elf32_Half e_shstrndx; } Elf32_Ehdr; #define EI_NIDENT 16 ELF头中每个字段的含意如下： Elf32_Ehdr->e_ident[] (Magic) 这个字段是ELF头结构中的第一个字段，在elf.h中EI_NIDENT被定义为16，因此它占用16个字节。e_ident的前四个字节顺次应该是0x7f、 0x45、 0x4c、 0x46，也就是"\177ELF"。这是ELF文件的标志，任何一个ELF文件这四个字节都完全相同。 16进制 8进制字母 0x7f 0177 0x45 E 0x4c L
目标文件格式分析工具: ar,nm,objdump,objcopy,readelf 如果普通编程不需要了解这些东西，如果想精确控制你的目标文件的格式或者你想查看一下文件里的内容以便作出某种判断，那么你可以看一下下面的工具：ar,nm,objdump,objcopy。具体用法请参考man在线手册。 ar基本用法 ar命令可以用来创建、修改库，也可以从库中提出单个模块。库是一单独的文件，里面包含了按照特定的结构组织起来的其它的一些文件（称做此库文件的member）。原始文件的内容、模式、时间戳、属主、组等属性都保留在库文件中。 下面是ar命令的格式： ar [-]{dmpqrtx}[abcfilNoPsSuvV] [membername] [count] archive files... 例如我们可以用ar rv libtest.a hello.o hello1.o来生成一个库，库名字是test，链接时可以用-ltest链接。该库中存放了两个模块hello.o和hello1.o。选项前可以有‘-'字符，也可以没有。下面我们来看看命令的操作选项和任选项。现在我们把{dmpqrtx}部分称为操作选项，而[abcfilNoPsSuvV]部分称为任选项。 {dmpqrtx}中的操作选项在命令中只能并且必须使用其中一个，它们的含义如下： ?d：从库中删除模块。按模块原来的文件名指定要删除的模块。如果使用了任选项v 则列出被删除的每个模块。 ?m：该操作是在一个库中移动成员。当库中如果有若干模块有相同的符号定义(如函数定义)，则成员的位置顺序很重要。如果没有指定任选项，任何指定的成员将移到库的最后。也可以使用'a'，'b'，或'I'任选项移动到指定的位置。 ?p：显示库中指定的成员到标准输出。如果指定任选项v，则在输出成员的内容前，将显示成员的名字。如果没有指定成员的名字，所有库中的文件将显示出来。 ?q：快速追加。增加新模块到库的结尾处。并不检查是否需要替换。'a'，'b'，或'I'任选项对此操作没有影响，模块总是追加的库的结尾处。如果使用了任选项v则列出每个模块。 这时，库的符号表没有更新，可以用'ar s'或ranlib来更新库的符号表索引。 ?r：在库中插入模块(替换)。当插入的模块名已经在库中存在，则替换同名的模块。 如果若干模块中有一个模块在库中不存在，ar显示一个错误消息，并不替换其他同名模块。默认的情况下，新的成员增加在库的结尾处，可以使用其他任选项来改变增加的位置。 ?t：显示库的模块表清单。一般只显示模块名。 ?x：从库中提取一个成员。如果不指定要提取的模块，则提取库中所有的模块。 下面在看看可与操作选项结合使用的任选项： ?a：在库的一个已经存在的成员后面增加一个新的文件。如果使用任选项a，则应该为命令行中membername参数指定一个已经存在的成员名。
西北工业大学操作系统实验实验报告 一、实验目的 熟悉可执行链接文件（ELF）的结构，了解GeekOS将ELF格式的可执行程序加载到内存，建立内核线程并运行的实现技术。 二、实验要求 1.修改Project1项目中的/GeekOS/elf.c文件：在函数Parse_ELF_Executable()中添加代码，分析ELF格式的可执行文件（包括分析得出ELF文件头、程序头），获取可执行文件长度、代码段、数据段等信息，并打印输出。并且，填充Exe_Format 数据结构中的值域。 2.掌握GeekOS在核心态运行可执行程序的原理，绘制出可执行程序在内核中加载、运行的流程图（需反映关键函数的调用关系）。 3.回答实验讲义P125页的思考题。 三、实验过程及结果 1、修改Project1项目中的/GeekOS/elf.c文件：在函数Parse_ELF_Executable()中添加代码，分析ELF格式的可执行文件（包括分析得出ELF文件头、程序头），获取可执行文件长度、代码段、数据段等信息，并打印输出。并且，填充Exe_Format 数据结构中的值域。 答：修改Project1项目中的/GeekOS/elf.c文件：在函数Parse_ELF_Executable()中添加代码，如下： ==============elf.c=================== int Parse_ELF_Executable(char *exeFileData, ulong_t exeFileLength, struct Exe_Format *exeFormat) { int i; elfHeader *head=(elfHeader*)exeFileData; programHeader *proHeader=(programHeader *)(exeFileData+head->phoff); KASSERT(exeFileData!=NULL); KASSERT(exeFileLength>head->ehsize+head->phentsize*head->phnum); KASSERT(head->entry%4==0); exeFormat->numSegments=head->phnum;
________________________________________________________________ EXECUTABLE AND LINKABLE FORMAT (ELF) Portable Formats Specification, Version 1.1 Tool Interface Standards (TIS) ________________________________________________________________ =========================== Contents 内容=========================== 序言 1. OBJECT文件 导言 ELF头(ELF Header) Sections String表(String Table) Symbol表(Symbol Table) 重定位(Relocation) 2. 程序装载与动态连接 导言 Program头(Program Header) Program装载(Program Loading) Dynamic连接(Dynamic Linking) 3. C LIBRARY C Library ________________________________________________________________ 导言 ________________________________________________________________ ELF: 可执行连接格式 可执行连接格式是UNIX系统实验室(USL)作为应用程序二进制接口 (Application Binary Interface(ABI)而开发和发布的。工具接口标准委 员会(TIS)选择了正在发展中的ELF标准作为工作在32位INTEL体系上不同操 作系统之间可移植的二进制文件格式。
Linux ELF 运行时内存详解 4/22/2012 前一段时间做ROP （return-oriented programming ）的东西，想要系统的了解Linux 中程序的内存格式（memory layout ），网上有很多文章，却没有一个深入完整的介绍。所以花了些时间做深入的了解，不放过一个细节。由于最初写的是英文文档，所以文中的图都是用英文标识的，不过应该不影响阅读。 本文详细解释了Linux ELF 文件的虚拟地址空间。另外本文也大概介绍了ASLR (Address Space Layout Randomization)技术对ELF 虚拟地址空间的影响。作者的测试系统是Linux Ubuntu 2.6.32-24和Vmware Workstation 7。另外所有的分析都基于Intel x86架构。 虚拟地址空间 当代的操作系统中每个进程都有自己的独立虚拟地址空间。在32位系统上，该虚拟地址空间有4G 大小。为了将虚拟地址转换为物理地址，Linux 内核使用了一个两级（事实上是三级，但是中间一级没有任何实质操作）分页机制，即页目录表和页表。分页机制与MMU （Memory Management Unit ）合作将虚拟地址转换为物理地址。当操作系统引入虚拟地址后，所有的用户操作系统和内核线程（事实上Linux 只有进程概念而没有线程概念，Linux 通过页表机制来模拟实现内核线程）都将运行于虚拟地址模式。 另外Linux （以及Windows ）使用了CPU 提供的权限机制。内核代码将运行于ring 0而用户程序运行于ring 3。 因此为了适应该分级机制以及适应多任务机制，Linux 的虚拟地址空间被分为两部分，如图1所示： 0xffff ffff 0x0Linux Virtual Address Split 0xffff ffff 0x0 Windows Virtual Address Split 图1. Linux/Windows 虚拟地址空间的内核部分和用户部分。 Linux 中，内核空间为0xc0000000到0xffffffff 的地址，因此内核代码将被映射到区域。而在Windows 中，默认的分割方式为内核与用户各占2GB 。本文仅详细分析Linux 的地址空间而不再涉及Windows 。下面分两部分介绍Linux 地址空间，首先是内核地址空间然后再介绍用户地址空间。 1. 内核地址空间 黑 客防线 a c k e r .c o m .c n 明出处
Linux系统下的ELF文件分析 摘要：随着linux系统的发展，elf成了十分重要的可执行文件格式。本文介绍了eIf文件的格式，并在此基础上分析出eIf文件的特性。关键词：elf文件：平台相关PIC 1.引言 ELF(Executable and Linkable Format)IN可执行连接文件格式．是LinuxSVR4和Solaris2，0默认的目标文件格式，目前标准接口委员会TIS已将ELF标准化为一种可移植的目标文件格式，运行于32一bitIntel体系微机上，可与多种操作系统兼容。分析elf文件有助于理解一些重要的系统概念，例如程序的编译和链接，程序的加载和运行等 2.ELF文件格式 2．1 ELF文件的类型ELF文件主要有三种类型 (1)可重定位文件包含了代码和数据.可与其它ELF文件建立一个可执行或共享的文件： (2)可执行文件时可直接执行的程序： (3)共享目标文件包括代码和数据，可以在两个地方链接。第一，连接器可以把它和其它可重定位文件和共享文件一起处理以建立另一个ELF文件；第二，动态链接器把它和一个可执行文件和其它共享文件结合在一起建立一个进程映像。 2．2 ELF文件的组织 ELF文件参与程序的连接(建立一个程序)和程序的执行(运行一个程序)，编译器和链接器将其视为节头表(section headertable)描述的一些节(section)的集合，而加载器则将其视为程序头表(program header table)描述的段(segment)的集合，通常一个段可以包含多个节。可重定位文件都包含一个节头表．可执行文件都包含一个程序头表。共享文件两者都包含有。为此，ELF文件格式同时提供了两种看待文件内容的方式，反映了不同行为的不同要求。
3. 页标题的内容和文章的页脚已经在开始的时候被换掉了。 4. 文章的排版也已经修正过了。 5. 如果必要，不同的字体已经被忽略了。大部分地方，这片文档能让你 充分的理解。然而，很小的地方，原始的文档使用了斜体字来指出文 章中的字符变量。在那种情况下，本文使用<尖括号>。在原始的文档 中没有出现尖括号。 6. 原始的文档有三个错误，如果你是不经意读它的话，是不会明显 就能找出的。但是在这里，明确的被鉴别出来了。 我很冒昧的纠正了那些错误。在他们的位置用一个{*}做上了标记。 可能还有其他我没有看出来的的错误。 如果有如何其他的区别都是我的责任。这样的错误请 mailto:breadbox@https://www.doczj.com/doc/6516175333.html,. Brian Raiter [Last edited Fri Jul 23 1999] ________________________________________________________________ EXECUTABLE AND LINKABLE FORMAT (ELF) Portable Formats Specification, Version 1.1 Tool Interface Standards (TIS) ________________________________________________________________ =========================== Contents 内容=========================== 序言 1. OBJECT文件 导言 ELF头(ELF Header) Sections String表(String Table) Symbol表(Symbol Table) 重定位(Relocation) 2. 程序装载与动态连接 导言 Program头(Program Header)
可执行文件（ELF）格式的理解 ELF(Executable and Linking Format)是一种对象文件的格式，用于定义不同类型的对象文件(Object files)中都放了什么东西、以及都以什么样的格式去放这些东西。它自最早在System V 系统上出现后，被xNIX 世界所广泛接受，作为缺省的二进制文件格式来使用。可以说，ELF是构成众多xNIX系统的基础之一，所以作为嵌入式Linux系统乃至内核驱动程序开发人员，你最好熟悉并掌握它。 其实，关于ELF这个主题，网络上已经有相当多的文章存在，但是其介绍的内容比较分散，使得初学者不太容易从中得到一个系统性的认识。为了帮助大家学习，我这里打算写一系列连贯的文章来介绍ELF以及相关的应用。这是这个系列中的第一篇文章，主要是通过不同工具的使用来熟悉ELF文件的内部结构以及相关的基本概念。后面的文章，我们会介绍很多高级的概念和应用，比方动态链接和加载，动态库的开发，C语言Main函数是被谁以及如何被调用的，ELF格式在内核中的支持，Linux内核中对ELF section的扩展使用等等。 好的，开始我们的第一篇文章。在详细进入正题之前，先给大家介绍一点ELF文件格式的参考资料。在ELF 格式出来之后，TISC(Tool Interface Standard Committee)委员会定义了一套ELF标准。你可以从这里(https://www.doczj.com/doc/6516175333.html,/elf/)找到详细的标准文档。TISC委员会前后出了两个版本，v1.1和v1.2。两个版本内容上差不多，但就可读性上来讲，我还是推荐你读v1.2的。因为在v1.2版本中，TISC重新组织原本在v1.1版本中的内容，将它们分成为三个部分(books)： a) Book I 介绍了通用的适用于所有32位架构处理器的ELF相关内容 b) Book II 介绍了处理器特定的ELF相关内容，这里是以Intel x86 架构处理器作为例子介绍 c) Book III 介绍了操作系统特定的ELF相关内容，这里是以运行在x86上面的UNIX System V.4 作为例子介绍 值得一说的是，虽然TISC是以x86为例子介绍ELF规范的，但是如果你是想知道非x86下面的ELF实现情况，那也可以在https://www.doczj.com/doc/6516175333.html,/elf/中找到特定处理器相关的Supplment文档。比方ARM相关的，或者MIPS相关的等等。另外，相比较UNIX系统的另外一个分支BSD Unix，Linux系统更靠近System V 系统。所以关于操作系统特定的ELF内容，你可以直接参考v1.2标准中的内容。 这里多说些废话：别忘了Linus 在实现Linux的第一个版本的时候，就是看了介绍Unix内部细节的书：《The of the Unix Operating System》，得到很多启发。这本书对应的操作系统是System V 的第二个Release。这本书介绍了操作系统的很多设计观念，并且行文简单易懂。所以虽然现在的Linux也吸取了其他很多Unix 变种的设计理念，但是如果你想研究学习Linux内核，那还是以看这本书作为开始为好。这本书也是我在接触Linux内核之前所看的第一本介绍操作系统的书，所以我极力向大家推荐。(在学校虽然学过操作系统原理，但学的也是很糟糕最后导致期末考试才四十来分，记忆仿佛还在昨天:)) 好了，还是回来开始我们第一篇ELF主题相关的文章吧。这篇文章主要是通过使用不同的工具来分析对象文
详情参考<<程序员的自我修养>> 几个特殊的sections说明： 1. .bss，该section包含了在内存中的程序的未初始化的数据，当程序开始运行时，系统将用0来初始化该区域。该section不占用文件空间，该section type = SHT_NOBITS； 2. .comment，该section包含了版本控制信息； 3. .data和.data1，该section包含了在内存中的程序的初始化数据； 4. .debug，该section包含了符号调试信息，其中内容没有硬性规定； 5. .dynamic，该section包含了动态链接信息，该section属性将包含SHF_ALLOC比特位，而SHF_WRITE比特位是否为1取决于处理器； 6. .dynstr，该section包含了用于动态链接的字符串，通常是符号表项名称字符串； 7. .dynsym，该section包含了动态链接符号表； 8. .fini，该section包含了用于终止进程可执行指令代码； 9. .got，该section包含了全局偏移表； 10. .hash，该section包含了符号hash表； 11. .init，该section包含了用于初始化进程的可执行代码，也就是说，当一个程序开始运行的时候，系统将会执行在该section中的代码，然后才会调用程序的入口点（对于C程序而言就是main）； 12. .interp，该section包含了程序解释其的路径； 13. .line，该section包含了符号调试信息的行号，其用于描述程序源代码和机器码之间的相应关系； 14. .note，该section包含了供应商及程序兼容信息等； 15. .plt，该section包含了程序链接表； 16. .relname和.relaname，该section包含了relocation信息，该section的属性包括了SHF_ALLOC比特位，通常，name为将要被重组的section的名称，例如如果要重组.text，那么名称就为.rel.text或者.rela.text； 17. .rodata和.rodata1，该section包含了只读数据，通常进程中的不可写段，例如Program Header； 18. .shstrtab，该section包含了section名称； 19. .strtab，该section包含了符号表项名称字符串，如果文件包含了一个可加载的并且包含了符号字符串表的segment，则section的SHF_ALLOC比特位属性将被设置； 20. .symtab，该section包含了符号表，如果文件包含了一个可加载的并且包含了符号表的segment，则section的SHF_ALLOC比特位属性将被设置； 21. .text，该section包含了程序的可执行指令。 虽然上面的例子文件中，对于text和data段而言，文件偏移和逻辑地址取模4KB后都是相等的。但是： 1. text的第一个页面包含了ELF header，program header table以及其他的信息； 2. text的最后一个页面包含了data的开始部分数据的拷贝； 3. data的第一个页面包含了text的末尾数据的拷贝； 4. data的最后一个页面也许包含了和运行进程不相关的文件信息； 理论上讲，系统对待每个段的内存权限都是相互独立的。段地址不得不调整来确保地址空间中的每个逻辑页面都有自己的权限；在上面的例子中，包含了text结尾和data开始的区域将要被映射两次：一次就是包含了text和data开始部分，另一个就是text末尾部分和data；data段的末尾还需要对为初始化数据的特殊处理，系统通常将其清零。
FLT文件格式 [摘要] 本文首先对FLT文件格式进行了简单的介绍，然后以一个简单的例子说明FLT文件的生成及加载过程。 [正文] Linux系统支持ELF文件格式，利用虚拟内存机制，在编译时即可确定程序运行时的地址；而uClinux是针对无MMU的系统设计的，所以它没有虚拟内存机制，运行时的地址就是物理地址。由于程序被加载到的物理地址是不确定的，在uClinux中，程序在被加载时必须引入一种重定位机制进行地址重定位，ELF文件格式已经不能满足这种需求。在这种情况下，uClinux引入了一种新的文件格式——FLT文件格式。 一个简单的FLT文件结构如下： Reloc info Data Text Flat header FLT文件就像是一个进程的内存映像，text段和data段是连续的，reloc info段位于文件的末尾，它包含了FLT文件的重定位信息。 FLT文件的头部定义如下： struct flat_hdr{ char magic[4]; unsigned long rev;/*version(as above)*/ unsigned long entry;/*Offset of first executable instruction with text segment from beginning of file*/ unsigned long data_start;/*Offset of data segment from beginning of file*/ unsigned long data_end;/*Offset of end of data segment from beginning of file*/ unsigned long bss_end;/*Offset of end of bss segment from beginning of file*/ /*(It is assumed that data_end through bss_end forms the bss segment.)*/ unsigned long stack_size;/*Size of stack,in bytes*/ unsigned long reloc_start;/*Offset of relocation records from
hex,bin,axf,elf文件格式的区别 (2012-08-24 15:50:34) 转载▼ 分类：STM32 标签： 设置 杂谈 hex,bin,axf,elf的区别 一、HEX 和 BIN Hex文件,这里指的是Intel标准的十六进制文件,也就是机器代码的十六进制形式,并且是用一定文件格式的ASCII码来表示.具体格式介绍如下: Intel hex 文件格式 Intel hex 文件常用来保存单片机或其他处理器的目标程序代码。它保存物理程序存储区中的目标代码映象。一般的编程器都支持这种格式。Intel hex 文件全部由可打印的ASCII字符组成，如下例所示： :2000000012014c75a800e4f508f509780a7a78e4f608dafcd283fcfded240af9a7050dbd81 :2000200000010ced2488ec34ff50edc283e4fcfded240af9e76d7013ed33e43c700d0dbd2a :2000400000010ced2488ec34ff50e50509e50970020508e50924a8e50834fd50aee4f50874 Intel hex 由一条或多条记录组成，每条记录都由一个冒号“:”打头，其格式如下： :CCAAAARR...ZZ 其中： CC 本条记录中的数据字节数 AAAA 本条记录中的数据在存储区中的起始地址 RR 记录类型： 00 数据记录 (data record) 01 结束记录 (end record) 02 段记录 (paragraph record) 03 转移地址记录 (transfer address record) ... 数据域 ZZ
1 Executable and Linkable Format(ELF)初稿，图请参考ELF_Format手册 1.1 Preface ELF-可执行链接格式最初是由UNIX系统实验室(USL)作为应用程序二进制接口(ABI)开发和发行。工具接口标准委员会TIS已经将ELF作为运行在Intel32位架构之上的各类型操作系统的可导出对象文件格式标准。ELF标准为开发者提供了一组横跨多运行环境的二进制接口定义来组织软件开发。 1.2 对象文件$leads................ 1.2.1 介绍 本部分描述了iABI对象文件格式，也称之为ELF。有三种主要类型的对象文件： 1. 可重组(relocatable)文件包含了适合用来链接其他对象文件的代码和数据，从而创建出可执行或可共享的对象文件； 2. 可执行(executable)文件包含了用于执行的程序，该文件规定了exec如何创建一个程序的进程映像； 3. 可共享对象(shared object)文件包含了用来在两个上下文之间链接的代码和数据。首先，链接器ld将该文件和其他的可重组文件或可共享对象文件进行处理后，创建出新对象文件，其次，动态链接器将该新对象文件与可执行文件或共享对象组合，来共同创建一个进程映像；经过汇编器以及链接器创建成的对象文件，其是在处理器上可直接执行的程序的二进制代表。本部分主要描述文件格式以及其如何用来构建程序。后一部分也描述了对象文件，集中在程序执行所必须的信息上。 1.2.1.1 文件格式 在程序链接和程序执行过程都涉及到对象文件。出于方便和效率，对象文件格式图从链接和运行两个视角来展示文件的内容。 ELF header位于文件的开始处，其用来描述文件的组织结构。Section包含了大量的对象文件信息，从链接的视角来看就是指令、数据、符号表、重组信息等等。Segment和Program 是从程序执行视角来观看的，这将在下部分讲解。 如果存在Program Header table的话，其将告诉操作系统如何创建进程映像。用来创建进程映像（执行程序）的文件必须包含program header table。可重组(relocatable)文件可以没有该信息。Section header table包含了用来描述文件section的信息。每个section在该表中都有一个对应的表项，每个表项给出了诸如section名称、尺寸等等信息。用于链接的文件必须有section header table，其他的对象文件可有可无。 这里需要注意的是，虽然图中Program header table紧接着ELF header，section header table 紧接着sections，实际的文件中并不一定是这样。而且，sections和segments也可以不按次序排放，只有ELF header是固定在文件的首部。 1.2.1.2 数据的表示 对象文件格式支持8位、32位等架构的大量处理器。然而，为了保证其容易扩展到更多的体系架构，因此对象文件提供了一些机器独立的控制数据，用来按照统一的方式标明和解释对象文件的内容。对象文件中其余的数据都是按照目标处理器硬编码的，当然不用考虑该文件是在哪个文件上创建的。 对象文件格式中定义的所有数据结构定义都沿守自然尺寸以及对齐原则。必要时，数据结构可以包含填补内容来保证4字节对象的4字节对齐。数据也可以相对于文件起始位置对齐，例如，包含Elf32_Addr成员的数据结构在文件中将会按照4字节对齐。为了保证可移植性，
ELF英文全程为：Executable Linkable Format，ELF属于Linux平台下可执行文件。ELF文件格式与Windows下的PE（Portable Executable）文件格式相似，都是属于COFF（Common File Format）文件格式变种。谷歌的Android操作系统内核采用Linux内核框架实现，所以Android平台原生文件格式与Linux可执行文件格式完全相似，同属于ELF类型文件。 Android平台下游戏逻辑通常使用C、C++语言实现，编译之后的可执行文件属于ELF文件格式，ELF文件格式整体布局如下图所示： 谷歌的Android NDK提供工具方便开发者查看ELF文件格式，对应工具名为：arm-linux-androideabi-readelf，工具所在NDK根目录的相对路径为：android-ndk- r9c\toolchains\arm-linux-androideabi-4.6\prebuilt\windows-x86_64\bin\，arm-linux-androideabi-readelf工具部分使用说明如下图所示：
本章使用“libTest.so”文件作为实例介绍ELF格式信息。下面将详细讲解ELF文件格式，以便让读者对Android平台原生程序的文件格式有较好理解。 1.1.1文件头信息 ELF文件头描述文件基本属性信息，包括ELF文件版本号、目标机器型号、程序入口、段表描述信息等信息。ELF文件头数据大小为0x34字节，实例文件的ELF文件头信息二进制数据如下所示： 上图中标为蓝色的数据为ELF文件头二进制内存数据，最右边可明显看出有“ELF”字符串，读者也许已猜到数据对应ELF文件标志，即判断是否为ELF文件表示。arm-linux-androideabi-readelf工具可方便查看ELF文件头信息。 利用arm-linux-androideabi-readelf工具查看ELF文件头信息命令如下： arm-linux-androideabi-readelf.exe -h libTest.so 对应获取的文件头信息如下：
elf文件格式与动态链接库(非常之好) 机器执行的是机器指令，而机器指令就是一堆二进制的数字。高 级语言编写的程序之所以可以在不同的机器上移植就因为有为不同 机器设计的编译器的存在。高级语言的编译器就是把高级语言写的 程序转换成某个机器能直接执行的二进制代码。以上的知识在我们 学习CS(Computer Science)的初期，老师都会这么对我们讲。但是我 就产生疑问了：既然机器都是执行的二进制代码，那么是不是说只 要硬件相互兼容，不同操作系统下的可执行文件可以互相运行呢？ 答案肯定是不行。这就要谈到可执行文件的格式问题。 每个操作系统都会有自己的可执行文件的格式，比如以前的Unix?是用a.out格式的，现代的Unix?类系统使用elf格式，WindowsNT?是使用基于COFF格式的可执行文件。那么最简单的格式应该是DOS的可执行格式，严格来说DOS的可执行文件没有什么格式可言，就是把二进制代码安顺序放在文件里，运行时DOS操作系统就把所 有控制计算机的权力都给了这个程序。这种方式的不足之处是显而 易见的，所以现代的操作系统都有一种更好的方式来定义可执行文 件的格式。一种常见的方法就是为可执行文件分段，一般来说把程 序指令的内容放在.t e x t段中，把程序中的数据内容放在.d a t a段中，把程序中未初始化的数据放在.b s s段中。这种做法的好处有很多， 可以让操作系统内核来检查程序防止有严重错误的程序破坏整个运 行环境。比如：某个程序想要修改.text段中的内容，那么操作系统
就会认为这段程序有误而立即终止它的运行，因为系统会把.t e x t段的内存标记为只读。在.b s s段中的数据还没有初始化，就没有必要在可执行文件中浪费储存空间。在.bss中只是表明某个变量要使用多少的内存空间，等到程序加载的时候在由内核把这段未初始化的内存空间初始化为0。这些就是分段储存可执行文件的内容的好处。 下面谈一下Unix系统里的两种重要的格式：a.out和elf （Executable and Linking Format）。这两种格式中都有符号表（symbol table），其中包括所有的符号（程序的入口点还有变量的地址等等）。在e l f格式中符号表的内容会比a.o u t格式的丰富的多。但是这些符号表可以用s t r i p工具去除，这样的话这个文件就无法让debug程序跟踪了，但是会生成比较小的可执行文件。a.o u t文件中的符号表可以被完全去除，但是elf中的在加载运行时起着重要的作用，所以用strip永远不可能完全去除elf格式文件中的符号表。但是用strip 命令不是完全安全的，比如对未连接的目标文件来说如果用strip去掉符号表的话，会导致连接器无法连接。例如： 代码: $:gcc -c hello.c $:ls hello.c hello.o 用gcc把hello.c编译成目标文件hello.o 代码: $:strip hello.o