File format
The ELF object file format provides two views of
a file's contents:
------------------------------------------------ | Linking view Execution view | |---------------------|--|----------------------| | ELF header | | ELF header | |---------------------| | ---------------------| | Program header table| | Program header table| | (optional) | | | |---------------------| | ---------------------| | Section 1 | | Segment 1 | |---------------------| | | |---------------------| | ---------------------| | Section n | | Segment 2 | |---------------------| | | | . . . | | | |---------------------| | ---------------------| | . . . | | . . . | |---------------------| | ---------------------| | Section header table| | Section header table| | | | (optional) | |---------------------|--|----------------------|
Figure 8-1 Object file format
Common to both views is an ELF header that resides at the beginning and holds a ``road map'' describing the file's organization.
In the linking view, sections hold the bulk of object file information which includes instructions, data, symbol table, and relocation information.
A program header table tells the system how to create a process image from the ELF object. In the program execution view, 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 forth. Files used during linking must have a section header table; other object files may or may not have one.
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.
Table 8-1 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 integerAll 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 forth. 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.