exec(BA_OS)
creates a program's process image.
ld(BA_OS)]
processes the shared object file 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.
Created by the assembler and link editor, object files are binary representations of programs intended to be executed directly on a processor. Programs that require other abstract machines, such as shell scripts, are excluded.
After the introductory material, this chapter focuses on the file format and how it pertains to building programs. Chapter 5 also describes parts of the object file, concentrating on the information necessary to execute a program.
See elf_file.lem for the flags describing the various file types and predicates for testing whether a particular ELF file is relocatable, executable or linkable.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 those activities. Figure 4-1 shows an object file's organization.
|
|
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 the chapter. Chapter 5 discusses segments and the program execution view of the file. See elf_header.lem for the formalisation of the ELF header.
A program header table 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. See elf_program_header_table.lem for the formalisation of the program header table. 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. See elf_section_header_table.lem for the formalisation of the section header table.
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.
As described here, the object file format supports various processors with 8-bit bytes and either 32-bit or 64-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. See elf_types.lem and elf_types_native_uint.lem for the Lem definitions and their particular backend bindings of the types below. The two files differ in their implementations of unsigned types in the OCaml backend, one using a C library for efficient execution and the other implementing unsigned arithmetic using unbounded integers modulo.
| Name | Size | Alignment | Purpose |
|---|---|---|---|
Elf32_Addr |
4 |
4 |
Unsigned program address |
Elf32_Off |
4 |
4 |
Unsigned file offset |
Elf32_Half |
2 |
2 |
Unsigned medium integer |
Elf32_Word |
4 |
4 |
Unsigned integer |
Elf32_Sword |
4 |
4 |
Signed integer |
unsigned char |
1 |
1 |
Unsigned small integer |
64-Bit Data Types
| Name | Size | Alignment | Purpose |
|---|---|---|---|
Elf64_Addr |
8 |
8 |
Unsigned program address |
Elf64_Off |
8 |
8 |
Unsigned file offset |
Elf64_Half |
2 |
2 |
Unsigned medium integer |
Elf64_Word |
4 |
4 |
Unsigned integer |
Elf64_Sword |
4 |
4 |
Signed integer |
Elf64_Xword |
8 |
8 |
Unsigned long integer |
Elf64_Sxword |
8 |
8 |
Signed long integer |
unsigned char |
1 |
1 |
Unsigned small integer |
Elf32_Addr
member will be aligned on a 4-byte boundary within the file.
For portability reasons, ELF uses no bit-fields.