The Executable and Linking Format (ELF)
The executable and linking format (ELF) was originally developed by Unix System Laboratories and is rapidly becoming the standard in file formats[8]. The ELF standard is growing in popularity because it has greater power and flexibility than the a.out and COFF binary formats[3]. ELF now appears as the default binary format on operating systems such as Linux, Solaris 2.x, and SVR4. Some of the capabilities of ELF are dynamic linking, dynamic loading, imposing runtime control on a program, and an improved method for creating shared libraries[3]. The ELF representation of control data in an object file is platform independent, an additional improvement over previous binary formats. The ELF representation permits object files to be identified, parsed, and interpreted similarly, making the ELF object files compatible across multiple platforms and architectures of different size.
The three main types of ELF files are executable, relocatable, and shared object files. These file types hold the code, data, and information about the program that the operating system and/or link editor need to perform the appropriate actions on these files. The three types of files are summarized as follows:
- An executable file supplies information necessary for the operating system to create a process image suitable for executing the code and accessing the data contained within the file.
- A relocatable file describes how it should be linked with other object files to create an executable file or shared library.
- A shared object file contains information needed in both static and dynamic linking.
In the next section we overview the ELF file format including a detailed description of each of the five section types that an ELF file might include. These five types are (1) the ELF header, (2) the program header table, (3) the section header table, (4) the ELF sections, and (5) the ELF segments. In Section 2.4.2, we describe the representation of data in an ELF file. The interested reader may consult reference [8] for additional information about the ELF format.
The ELF File Format
 |
 |
There are two views for each of the three file types described in the previous section. These views support both the linking and execution of a program. The two views are summarized in Figure 2.5 where the view on the left of the figure is the link view and the view on the right of the figure is the execution view. The link view of the ELF object file is partitioned by sections and the execution view of the ELF object file is partitioned by segments. Thus, the programmer interested in obtaining section information about the program items such as symbol tables, relocation, specific executable code or dynamic linking information will use the link view; the programmer interested in obtaining segment information such as the location of the text segment or data segment will use the execution view. The ELF access library, libelf, provides a programmer with tools to extract and manipulate ELF object file contents for either view. The ELF header describes the layout of the rest of the object file. It provides information on where and how to access the other sections. The Section Header Table gives the location and description of the sections and is mostly used in linking. The Program Header Table provides the location and description of segments and is mostly used in creating a programs' process image. Both sections and segments hold the majority of data in an object file including: instructions, data, symbol table, relocation information, and dynamic linking information.
The ELF Header
The ELF Header is the only section that has a fixed position in the object file. It is always the first section of the file. The other sections are not guaranteed to be in any order or to even be present. The ELF Header describes the type of the object file (relocatable, executable, shared, core), its target architecture, and the version of ELF it is using. The location of the Program Header table, Section Header table, and String table along with associated number and size of entries for each table are also given. Lastly, the ELF Header contains the location of the first executable instruction. The specific fields along with their size requirements that are present in the ELF header are shown in Figure 2.6.
| |
The Program Header Table
Program headers are only important in executable and shared object files. The program header table is an array of entries where each entry is a structure describing a segment in the object file or other information needed to create an executable process image. The size of an entry in the table and the number of entries in the table are given in the ELF header (See Figure 2.6). Each entry in the program header table (see Figure 2.7) contains the type, file offset, physical address, virtual address, file size, memory image size, and alignment for a segment in the program. The program header is crucial to creating a process image for the object file. The operating system copies the segment (if it is loadable, i.e., if p_type is PT_LOAD) into memory according to the location and size information. The p_type field is shown in Figure 2.7 as the first item in the struct.
| |
The Section Header Table
All sections in object files can be found using the Section header table. The section header, similar to the program header, is an array of structures. Each entry correlates to a section in the file. The entry provides the name, type, memory image starting address (if loadable), file offset, the section’s size in bytes, alignment, and how the information in the section should be interpreted. Figure 2.8 details the specific fields of the structure. The name provided in the structure is actually an index into the string table (a section in the object file) where the actual string representation of the name of the section exists. Sections will be discussed further below.
| |
ELF Sections
There are a number of types of sections described by entries in the section header table. Sections can hold executable code, data, dynamic linking information, debugging data, symbol tables, relocation information, comments, string tables, and notes. Some sections are loaded into the process image and some provide information needed in the building of a process image while still others are used only in linking object files. Figure 2.9 displays a list of special sections along with a brief description.
ELF Segments
Segments are a way of grouping related sections. For example, the text segment groups executable code, the data segment groups the program data, and the dynamic segment groups information relevant to dynamic loading. Each segment consists of one or more sections. A process image is created by loading and interpreting segments. The operating system logically copies a file’s segment to a virtual memory segment according to the information provided in the program header table. The OS can also use segments to create a shared memory resource. Figure 2.9 summarizes the sections that might be included in a segment.
| |
ELF Data Representation
The ELF control data is represented in a machine-independent format so that it can be accessed and interpreted seamlessly across machines. Figure 2.10 lists the definitions for the storage classes of the ELF control data. The remaining data in the object file, the data other than the control data, can be encoded to agree with the byte order, in the way necessary for the target machine. All data structures that the object file format defines follow the size and alignment guidelines for the relevant storage class[ 8]. If necessary, data structures are padded to ensure alignment; for example, a data structure might contain explicit padding to ensure 4-byte alignment for 4-byte objects, to force structure sizes to be a multiple of 4[ 8]. Alignment information is also included in the structures for sections and segments so that these structures, when placed in memory, can be properly aligned. In order to maintain a high level of portability, data fields in structures are expressed in bytes rather than bits since bit manipulation can be machine dependent. The cost of this portability is some wasted space.