工具接口标准(TIS)可执行链接格式(ELF)规范-卷I-介绍

本文是对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）包含适用的代码和数据用于与其它对象文件链接，生成可执行文件或共享文件；
可执行文件包含适合执行的程序；
共享文件包含适合链接的代码和数据，用于两种情况。第一，链接编辑器可以将其与其它可重定位及共享对象文件进行处理，生成另外的对象文件；第二，动态链接器将其与可执行文件以及其它共享对象组合，用于创建进程映像。

Created by the assembler and link editor, object files are binary representations of programs intended to execute directly on a processor. Programs that require other abstract machines are excluded.

打算在处理器上直接执行的程序都是二进制格式表现的，由汇编器和链接编辑器创建。需要其它的抽象机器指令的程序不能直接在处理器上执行。

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）

An ELF header resides at the beginning and holds a "road map'' describing the file's organization. Sections hold the bulk of object file information for the linking view: instructions, data, symbol table, relocation information, and so on. Descriptions of special
sections appear later in this section. Chapter 2 also describes segments and the program execution view of the file.

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。然而，没有使用命名规范的早期已存在的处理器扩展，也应该被支持。