Executable and Linking Format（ELF）

Executable and Linking Format（ELF）
 
一个目标文件一般包括
 
1）  关于目标文件的通用信息，如文件大小、二进制代码和数据大小以及创建这个目标文件的源文件名。
 
2）  体系结构相关的二进制指令和数据。
 
3）  符号表和符号重定位表。
 
4）  供调试者使用的调试信息。
 
这些信息在目标文件组织的方式称为目标文件格式。有了标准的目标文件格式，不同的厂商生产的开发工具（如编译器、汇编器、链接器以及调试器）之间就能很好的进行互操作。
 
这种互操作的能力意味着开发者可以选择一个厂商生产的编译器生成目标文件，而选择另一个厂商生产链接器生成可执行映像。
 
两种通用的目标文件格式分别是：通用目标文件格式（common object file format COFF）和可执行和链接格式（executable and linking format ELF）.这两种格式互不兼容。
 
我们这里主要介绍ELF格式。理解目标文件格式使得嵌入式开发者可把一个可执行映像映射到目标嵌入式系统，用于静态存储以及运行加载和执行。下面讨论下elf规范以及它是怎样和链接器关联的。
 
通过使用ELF目标文件格式，编译器把被编译的程序组织成不用的内容分组，包括系统定义和用户定义，这些内容分组叫作section.程序的二进制指令、二进制数据、符号表、重定位表和调试信息被组织存放在不同的section中。每个section有一个类型。
 
一个section也包含像加载地址、运行地址这样的重要信息。加载地址和运行地址是两个很重要的概念，它们在嵌入式系统中是可以不相等的。
 
典型的嵌入式系统有一些rom用于非易性存储。因此一些嵌入式软件可以存储在可以存储在rom中。可修改的数据必须存储在ram中。要求高执行速度的程序也在ram中执行。一般这样的程序在rom中叫做加载器，它把初始化的变量和程序代码复制到ram中，并开始在ram中执行程序。这里物理rom存储地址称为section的加载地址，section的运行地址指section执行的位置。例如，如果一个section被拷贝到ram中执行，这个section的运行地址是指加载器拷贝操作的目的地址。链接器使用程序的运行地址进行符号解析。
 
ELF文件格式有两种不同的解释。如图2.4，链接器把文件解释为由section header table描述的可链接模块，而加载器把文件解释为由program header table描述的可执行模块。列表2.1给出了section header 和 program header。
 
Listing 2.1: Section header and program header.

Section header		Program 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;		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;

 
 
section header table 是一组描述一个目标文件的section的 section header 数据结构; program header table 是一组描述一个映像的可加载segmet的program header数据结构，这个program header为加载器执行这个映像作准备。program headers 只能用于可执行映像和共享目标文件。
 
section header 结构中有一个sh_type的成员，它指定了一个section的类型。表2.1列出了一些section的类型。
 

Table 2.1: Section types.
NULL	Inactive header without a section.
PROGBITS	Code or initialized data.
SYMTAB	Symbol table for static linking.
STRTAB	String table.
RELA/REL	Relocation entries.
HASH	Run-time symbol hash table.
DYNAMIC	Information used for dynamic linking.
NOBITS	Uninitialized data.
DYNSYM	Symbol table for dynamic linking.

 
 
section header 中的sh_flags指定了一个section的属性。表2.2列出一些属性
 
 

Table 2.2: Section attributes.
WRITE	Section contains writeable data.
ALLOC	Section contains allocated data.
EXECINSTR	Section contains executable instructions.

 
一些系统创建的带有用于PROGBITS的预定义名称的默认段是.text、.sdata、.data、.sbss和.bss.程序代码和常量放在.text section中。这个section是只读的。.sbss和.bss包括未初始化的数据。.sbss section 存储small data.像一些可以适合特定大小的变量就是small data.这个大小限制是体系结构相关的。.sdata和.data包含已经初始化的数据。在.sbss中描述的small data的概念用于.sdata. 一个带有可执行代码的.text section具有EXECINSTR属性。.sdata和data section具有WRITE属性。.sbss和.bss同时具有WRITE和ALLOC属性。
 
其他通用的由系统定义的section有.symtab(包含符号表)、.strtab(包含用于程序符号的字符串表)、.shstrtab(包含用于setcion名称的字符串表)以及.relaname(包含用于某个section的重定位信息。)
 
开发者可以通过调用链接器命令.section自定义section。如，源文件中某处声明
 
.section my_section
 
链接器将创建一个名为my_section的新的section。
 
sh_addr是program section在目标内存中应该驻留的地址，p_paddr是program segment在目标内存中应该驻留的地址。sh_addr和p_paddr称为加载地址。
 
对于很多嵌入式应用程序，运行地址和加载地址是相同的。这些嵌入式应用程序被直接下载到目标系统内存中立即执行，而不需要任何从一个内存类型或位置到另一个内存类型或位置的代码或数据的传送。这个习惯在开发阶段是很普遍的。 
  
  
 

2.3 Executable and Linking Format

Typically an object file contains

• general information about the object file, such as file size, binary code and data size, and source file name from which it was created,

• machine-architecture-specific binary instructions and data

• symbol table and the symbol relocation table, and

• debug information, which the debugger uses.

The manner in which this information is organized in the object file is the object file format. The idea behind a standard object file format is to allow development tools which might be produced by different vendors-such as a compiler, assembler, linker, and debugger that conform to the well-defined standard-to interoperate with each other.

This interoperability means a developer can choose a compiler from vendor A to produce object code used to form a final executable image by a linker from vendor B. This concept gives the end developer great flexibility in choice for development tools because the developer can select a tool based on its functional strength rather than its vendor.

Two common object file formats are the common object file format (COFF) and the executable and linking format (ELF). These file formats are incompatible with each other; therefore, be sure to select the tools, including the debugger, that recognize the format chosen for development.

We focus our discussion on ELF because it supersedes COFF. Understanding the object file format allows the embedded developer to map an executable image into the target embedded system for static storage, as well as for runtime loading and execution. To do so, we need to discuss the specifics of ELF, as well as how it relates to the linker.

Using the ELF object file format, the compiler organizes the compiled program into various system-defined, as well as user-defined, content groupings called sections. The program's binary instructions, binary data, symbol table, relocation table, and debug information are organized and contained in various sections. Each section has a type. Content is placed into a section if the section type matches the type of the content being stored.

A section also contains important information such as the load address and the run address. The concept of load address versus run address is important because the run address and the load address can be different in embedded systems. This knowledge can also be helpful in understanding embedded system loader and link loader concepts introduced in Chapter 3.

Chapter 1 discusses the idea that embedded systems typically have some form of ROM for non-volatile storage and that the software for an embedded system can be stored in ROM. Modifiable data must reside in RAM. Programs that require fast execution speed also execute out of RAM. Commonly therefore, a small program in ROM, called a loader, copies the initialized variables into RAM, transfers the program code into RAM, and begins program execution out of RAM. This physical ROM storage address is referred to as the section's load address. The section's run address refers to the location where the section is at the time of execution. For example, if a section is copied into RAM for execution, the section's run address refers to an address in RAM, which is the destination address of the loader copy operation. The linker uses the program's run address for symbol resolutions.

The ELF file format has two different interpretations, as shown in Figure 2.4. The linker interprets the file as a linkable module described by the section header table, while the loader interprets the file as an executable module described by the program header table.

Figure 2.4: Executable and linking format.

Listing 2.1 shows both the section header and the program header, as represented in C programming structures. We describe the relevant fields during the course of this discussion.

Listing 2.1: Section header and program header.

Section header	Program 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;	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;

A section header table is an array of section header structures describing the sections of an object file. A program header table is an array of program header structures describing a loadable segment of an image that allows the loader to prepare the image for execution. Program headers are applied only to executable images and shared object files.

One of the fields in the section header structure is sh_type, which specifies the type of a section. Table 2.1 lists some section types.

Table 2.1: Section types.

NULL	Inactive header without a section.
PROGBITS	Code or initialized data.
SYMTAB	Symbol table for static linking.
STRTAB	String table.
RELA/REL	Relocation entries.
HASH	Run-time symbol hash table.
DYNAMIC	Information used for dynamic linking.
NOBITS	Uninitialized data.
DYNSYM	Symbol table for dynamic linking.

The sh_flags field in the section header specifies the attribute of a section. Table 2.2 lists some of these attributes.

Table 2.2: Section attributes.

WRITE	Section contains writeable data.
ALLOC	Section contains allocated data.
EXECINSTR	Section contains executable instructions.

Some common system-created default sections with predefined names for the PROGBITS are .text, .sdata, .data, .sbss, and .bss. Program code and constant data are contained in the .text section. This section is read-only because code and constant data are not expected to change during the lifetime of the program execution. The .sbss and .bss sections contain uninitialized data. The .sbss section stores small data, which is the data such as variables with sizes that fit into a specific size. This size limit is architecture-dependent. The result is that the compiler and the assembler can generate smaller and more efficient code to access these data items. The .sdata and .data sections contain initialized data items. The small data concept described for .sbss applies to .sdata. A .text section with executable code has the EXECINSTR attribute. The .sdata and .data sections have the WRITE attribute. The .sbss and .bss sections have both the WRITE and the ALLOC attributes.

Other common system-defined sections are .symtab containing the symbol table, .strtab containing the string table for the program symbols, .shstrtab containing the string table for the section names, and .relaname containing the relocation information for the section named name. We have discussed the role of the symbol table (SYMTAB) previously. In Figure 2.3, the symbol name is shown as part of the symbol table. In practice, each entry in the symbol table contains a reference to the string table (STRTAB) where the character representation of the name is stored.

The developer can define custom sections by invoking the linker command .section. For example, where the source files states

.section my_section

the linker creates a new section called my_section. The reasons for creating custom named sections are explained shortly.

The sh_addr is the address where the program section should reside in the target memory. The p_paddr is the address where the program segment should reside in the target memory. The sh_addr and the p_paddr fields refer to the load addresses. The loader uses the load address field from the section header as the starting address for the image transfer from non-volatile memory to RAM.

For many embedded applications, the run address is the same as the load address. These embedded applications are directly downloaded into the target system memory for immediate execution without the need for any code or data transfer from one memory type or location to another. This practice is common during the development phase. We revisit this topic in Chapter 3, which covers the topic of image transfer from the host system to the target system.