本文是對Tool Interface Standard (TIS) Executable and Linking Format (ELF) Specification Version 1.2的翻譯
工具接口標準(TIS)可執行鏈接格式(ELF)規範版本 1.2
翻譯以中英對照方式，英語水平有限，如有翻譯不當的地方，請諒解。
Introduction
介紹
This chapter describes the object file format, called ELF (Executable and Linking Format). There are three main types of object files.
• A relocatable file holds code and data suitable for linking with other object files to create an executable or a shared object file.
• An executable file holds a program suitable for execution.
• A shared object file holds code and data suitable for linking in two contexts. First, the link editor may process it with other relocatable and shared object files to create another object file. Second, the dynamic linker combines it with an executable file
and other shared objects to create a process image.
本章節描述ELF對象格式，ELF對象文件有三種類型。
- 可重定位文件（relocatable file）包含適用的代碼和數據用於與其它對象文件鏈接，生成可執行文件或共享文件；
- 可執行文件包含適合執行的程序；
- 共享文件包含適合鏈接的代碼和數據，用於兩種情況。第一，鏈接編輯器可以將其與其它可重定位及共享對象文件進行處理，生成另外的對象文件；第二，動態鏈接器將其與可執行文件以及其它共享對象組合，用於創建進程映像。
打算在處理器上直接執行的程序都是二進制格式表現的，由彙編器和鏈接編輯器創建。需要其它的抽象機器指令的程序不能直接在處理器上執行。
After the introductory material, this chapter focuses on the file format and how it pertains to building programs. Chapter 2 also describes parts of the object file, concentrating on the information necessary to execute a program.
在介紹材料後，本章關注文件格式及其如何在建立程序時的從屬。章節2也會介紹一部分對象文件，關注於執行程序時需要的信息。
File Format
文件格式
Object files participate in program linking (building a program) and program execution (running a program). For convenience and efficiency, the object file format provides parallel views of a file's contents, reflecting the differing needs of these activities.
Figure 1-1 shows an object file's organization.
對象文件參與程序鏈接（建立一個城）和程序執行（運行一個程序）。爲了方便和有效，對象文件格式提供並行的文件內容視圖，反射不同的需求。圖1-1展示了一個對象文件的組織。
Figure1-1. Object File Format
圖1-1.對象文件格式
鏈接視圖（Linking View） 執行視圖（Execution View）
|
ELF頭（ELF Header） |
|
ELF頭（ELF Header） |
|
程序頭表（Program Header Table） 可選（Optional） |
|
程序頭表（Program Header Table） |
|
分節1（Section 1） |
|
分段1（Segment 1） |
|
... |
|
|
|
分節n（Section n） |
|
分段n（Segment n） |
|
... |
|
|
|
... |
|
|
|
分節頭表（Section Header Table） |
|
分節頭表（Section Header Table） 可選（Optional） |
ELF頭位於文件開始，通過“路線圖”描述文件的組織結構。分節包含對象文件用於鏈接的大部分信息：指令（instructions）、數據（data）、符號表（symbol table）、重定位信息（relocation information）等。特殊分節會在本章稍後進行描述。章節2會描述分段及程序文件的執行視圖。
A program header table, if present, tells the system how to create a process image. Files used to build a process image (execute a program) must have a program header table; relocatable files do not need one. A section header table contains information describing the file's sections. Every section has an entry in the table; each entry gives information such as the section name, the section size, and so on. Files used during linking must have a section header table; other object files may or may not have one.
如果存在程序頭表，其告訴系統如何創建一個進程映像。用於建立程序映像的文件必須包含程序頭表；重定位文件不需要程序頭表。分節頭表包含文件分節信息描述。在此表中每個分節都有一個入口；每個入口都有以下信息：分節名（section name）、分節大小（section size）等。用於鏈接的文件必須包含一個分節頭表；其它的對象文件不一定有。
NOTE. Although the figure shows the program header table immediately after the ELF header, and the section header table following the sections, actual files may differ. Moreover, sections and segments have no specified order. Only the ELF header has a fixed position in the file.
注意：雖然在圖1-1中顯示程序頭表緊接着ELF頭，分節頭表緊接着分節，實際文件可能不一致。另外，分節和分段沒有特殊順序。指頭ELF頭在文件中有固定的位置。
Data Representation
數據表示
As described here, the object file format supports various processors with 8-bit bytes and 32-bit architectures. Nevertheless, it is intended to be extensible to larger (or smaller) architectures. Object files therefore represent some control data with a machine-independent
format, making it possible to identify object files and interpret their contents in a common way. Remaining data in an object file use the encoding of the target processor, regardless of the machine on which the file was created.
如上所述，對象文件支持不同的處理器如8位和32位架構。不過，爲了貨站支持更大或更小的架構、對象文件使用機器無關的格式表達一些控制數據，使其能夠標識對象文件以及用一種通用的方法解釋內容。對象文件中剩下的數據使用目標處理器的方式編碼，不管文件是在哪臺機器上創建的。
Figure 1-2. 32-Bit Data Types
圖1-2.32位數據類型
|
名字（Name） |
大小（Size） |
對齊（Alignment） |
目的（Purpose） |
|
Elf32_Addr |
4 |
4 |
無符號程序地址 |
|
Elf32_Half |
2 |
2 |
無符號中間整數 |
|
Elf32_Off |
4 |
4 |
無符號文件偏移 |
|
Elf32_Sword |
4 |
4 |
有符號大整數 |
|
Elf32_Word |
4 |
4 |
無符號大整數 |
|
unsigned char |
1 |
2 |
無符號小整數 |
All data structures that the object file format defines follow the "natural'' size and alignment guidelines for the relevant class. If necessary, data structures contain explicit padding to ensure 4-byte alignment for 4-byte objects, to force structure sizes to a multiple of 4, and so on. Data also have suitable alignment from the beginning of the file. Thus, for example, a structure containing an Elf32_Addr member will be aligned on a 4-byte boundary within the file. For portability reasons, ELF uses no bit fields.
對象文件格式中所有的相關類的數據結構格式定義都遵循自然大小及對齊指引。如果必要，數據結構應該對4字節對象包含明確的4字節填充，從而強制結構大小是4的整數倍。文件開始的數據也有合適的對齊。從而，例如，一個包含Elf32_Addr類型結構的成員在文件內部則應該以4字節對齊。由於可移植的原因，ELF不適用位字段。
Character Representations
字符表示
This section describes the default ELF character representation and defines the standard character set used for external files that should be portable among systems. Several external file formats represent control information with characters. These single-byte
characters use the 7-bit ASCII character set. In other words, when the ELF interface document mentions character constants, such as, ‘/’ or ‘\n’ their numerical values should follow the 7-bit ASCII guidelines. For the previous character constants, the single-byte
values would be 47 and 10, respectively.
本小節描述默認的ELF字符表示並定義標準的系統間可移植的外部字符集。一些外部文件格式用字符表示控制信息。這些單字節字符使用7位ASCII字符集。換句話說，當ELF接口文檔提到字符常量時，比如，’/’或’\n’的數值應該符合7位ASCII指引。前述的字符常量，單字節數值應該分別是47和10。
Character values outside the range of 0 to 127 may occupy one or more bytes, according to the character encoding. Applications can control their own character sets, using different character set extensions for different languages as appropriate. Although TIS-conformance
does not restrict the character sets, they generally should follow some simple guidelines.
• Character values between 0 and 127 should correspond to the 7-bit ASCII code. That is, character sets with encodings above 127 should include the 7-bit ASCII code as a subset.
• Multibyte character encodings with values above 127 should contain only bytes with values outside the range of 0 to 127. That is, a character set that uses more than one byte per character should not "embed'' a byte resembling a 7-bit ASCII character within
a multibyte, non-ASCII character.
• Multibyte characters should be self-identifying. That allows, for example, any multibyte character to be inserted between any pair of multibyte characters, without changing the characters' interpretations.
These cautions are particularly relevant for multilingual applications.
超出0到127的字符值應該根據字符編碼佔據1個或多個字節。應用程序能夠控制它們自己的字符集，在適當的時候爲不同的語言使用不同的字符集擴展。雖然TIS一致性不限制字符集，但總體來說應該遵循一些簡單的指引。
- 字符值在0到127之間的相當於7位ASCII碼，換句換說，大於127的字符集編碼應該將7位ASCII碼作爲一個子集；
- 多字節字符編碼值超過127以上的則應該只包含0到127以外的值，從而，一個使用多字節的字符集，裏面的字符不應該有7位ASCII碼的字符；
- 多字節字符應該能自識別。例如，在不改變字符解釋的前提下，任意的多字節字符在任意位置能夠插入任意多字節字符。
NOTE. There are naming conventions for ELF constants that have processor ranges specified. Names such as DT_, PT_, for processor specific extensions, incorporate the name of the processor: DT_M32_SPECIAL, for example. However, pre-existing processor extensions not using this convention will be supported.
注意：這些ELF常量定義與處理器範圍相關。比如DT_、PT_的命名，例如，爲了處理器相關的擴展，組合處理器名：DT_M32_SPECIAL。然而，沒有使用命名規範的早期已存在的處理器擴展，也應該被支持。
