elf文件格式--
另一文本方式的elf文檔
write by breadbox Email:breadbox@muppetlabs.com
譯:alert7 < alert7@21cn.com > from m4in security team
http://www.patching.net
isearthling < isearthling@163.net >
19:45 2001-5-16
譯者註：
由於翻譯者水平有限（包括技術水平和翻譯水平:(），所以
有些地方或許比較難懂，可能還有理解錯誤的地方，如果有
任何的問題，歡迎email:alert7@21cn.com
我們會虛心接受的，會在以後的修訂中更正過來。
（總不能誤導後來的讀者,所以如果你英文比較好的話，還
是看原版吧:),不要丟雞蛋啊^_^）
這份文檔和原始的那份ELF文件格式的文檔有以下一個不同：
1. 忽略了分頁記數 。
2. 因為上述原因，在這篇內容目錄中去掉了頁號，索引完全被忽略。
(不象Postscript文檔，txt文本可以用來搜索)
3. 頁標題的內容和文章的頁腳已經在開始的時候被換掉了。
4. 文章的排版也已經修正過了。
5. 如果必要，不同的字體已經被忽略了。大部分地方，這片文檔能讓你
充分的理解。然而，很小的地方，原始的文檔使用了斜體字來指出文
章中的字元變數。在那種情況下，本文使用<尖括弧>。在原始的文檔
中沒有出現尖括弧。
6. 原始的文檔有三個錯誤，如果你是不經意讀它的話，是不會明顯
就能找出的。但是在這裡，明確的被鑒別出來了。
我很冒昧的糾正了那些錯誤。在他們的位置用一個{*}做上了標記。
可能還有其他我沒有看出來的的錯誤。
如果有如何其他的區別都是我的責任。這樣的錯誤請
mailto:breadbox@muppetlabs.com.
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_<machine>_<flag>。看下機器信息「Machine Information」
部分的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_DATA 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_DATA]指定了在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<name> SHT_REL see below
.rela<name> SHT_RELA see below
.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<name> and .rela<name>
這些section保存著重定位的信息，看下面的``Relocation『『描述。
假如文件包含了一個可裝載的段，並且這個段是重定位的，那麼該section的
屬性將設置SHF_ALLOC位；否則該位被關閉。按照慣例，<name>由重定位適用
的section來提供。因此，一個重定位的section適用的是.text，那麼該名字
就為.rel.text或者是.rela.text。
* .rodata and .rodata1
這些section保存著只讀數據，在進程映象中構造不可寫的段。看第二部分的
``Program Header『『獲得更多的資料。
* .shstrtab
該section保存著section名稱。
* .strtab
該section保存著字元串，一般地，描述名字的字元串和一個標號的入口相關
聯。假如文件有一個可裝載的段，並且該段包括了符號字元串表，那麼section
的SHF_ALLOC屬性將被設置；否則不設置。
* .symtab
該section保存著一個符號表，正如在這個section里``Symbol Table『『的
描述。假如文件有一個可裝載的段，並且該段包含了符號表，那麼section
的SHF_ALLOC屬性將被設置；否則不設置。
* .text
該section保存著程序的``text『『或者說是可執行指令。
前綴是點(.)的section名是系統保留的，儘管應用程序可以用那些保留的
section名。應用程序可以使用不帶前綴的名字以避免和系統的sections
衝突。object文件格式可以讓一個定義的section部分不出現在上面的列
表中。一個object文件可以有多個同樣名字的section。
為處理器體系保留的section名的形成是通過置換成一個體系名的縮寫。
該名字應該取自體系名，e_machine使用的就是。例如，.Foo.psect就是
在FOO體系上定義的名字。
現存的擴展名是歷史遺留下來的。
Pre-existing Extensions
=======================
.sdata .tdesc
.sbss .lit4
.lit8 .reginfo
.gptab .liblist
.conflict
