Object File Format

This chapter describes the executable and linking format (ELF) of the object files produced by the assembler and link-editor. There are three main types of object files:

• A relocatable file holds sections containing code and data. These files are suitable to be linked with other object files to create executable files, shared object files, or another relocatable object.

• An executable file holds a program that is ready to execute. The file specifies how exec(2) creates a program's process image.

• A shared object file holds code and data suitable to be linked in two contexts. First, the link-editor can process this file with other relocatable and shared object files to create other object files. Second, the runtime linker combines this file with a dynamic executable file and other shared objects to create a process image.

The first section in this chapter, File Format, focuses on the format of object files and how that pertains to creating programs. The second section, Dynamic Linking, focuses on how the format pertains to loading programs.

Programs manipulate object files with the functions contained in the ELF access library, libelf. Refer to the elf(3ELF) man page for a description of libelf contents. Sample source code that uses libelf is provided in the SUNWosdem package under the /usr/demo/ELF directory.

File Format

Object files participate in both program linking and program execution. For convenience and efficiency, the object file format provides parallel views of a file's contents, reflecting the differing needs of these activities. The following figure shows an object file's organization.

Figure 7-1 Object File Format

An ELF header resides at the beginning of an object file and holds a road map describing the file's organization.

Note - Only the ELF header has a fixed position in the file. The flexibility of the ELF format requires no specified order for header tables, sections or segments. However, this figure is typical of the layout used in Solaris.

Sections represent the smallest indivisible units that can be processed within an ELF file. Segments are a collection of sections that represent the smallest individual units that can be mapped to a memory image by exec(2) or by the runtime linker.

Sections hold the bulk of object file information for the linking view: instructions, data, symbol table, relocation information, and so on. Descriptions of sections appear in the first part of this chapter. The second part of this chapter discusses segments and the program execution view of the file.

A program header table, if present, tells the system how to create a process image. Files used to generate a process image, executables and shared objects, must have a program header table; relocatable objects do not need such a 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 forth. Files used in link-editing must have a section header table; other object files might or might not have one.

Data Representation

The object file format supports various processors with 8-bit bytes, 32-bit and 64-bit architectures. Nevertheless, it is intended to be extensible to larger (or smaller) architectures. Table 7-1 and Table 7-2 list the 32-bit and 64-bit data types.

Object files represent some control data with a machine-independent format. making it possible to identify object files and interpret their contents in a common way. The remaining data in an object file use the encoding of the target processor, regardless of the machine on which the file was created.

Table 7-1 ELF 32-Bit Data Types

Table 7-2 ELF 64-Bit Data Types

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 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, and a structure containing an Elf64_Addr member will be aligned on an 8-byte boundary.

Note - For portability, ELF uses no bit-fields.

ELF Header

Some object file control structures can grow because the ELF header contains their actual sizes. If the object file format changes, a program can encounter control structures that are larger or smaller than expected. Programs might therefore ignore extra information. The treatment of missing information depends on context and will be specified if and when extensions are defined.

The ELF header has the following structure, defined in sys/elf.h:

#define EI_NIDENT       16
 
typedef struct {
        unsigned char   e_ident[EI_NIDENT]; 
        Elf32_Half      e_type;
        Elf32_Half      e_machine;
        Elf32_Word      e_version;
        Elf32_Addr      e_entry;
        Elf32_Off       e_phoff;
        Elf32_Off       e_shoff;
        Elf32_Word      e_flags;
        Elf32_Half      e_ehsize;
        Elf32_Half      e_phentsize;
        Elf32_Half      e_phnum;
        Elf32_Half      e_shentsize;
        Elf32_Half      e_shnum;
        Elf32_Half      e_shstrndx;
} Elf32_Ehdr;

typedef struct {
        unsigned char   e_ident[EI_NIDENT]; 
        Elf64_Half      e_type;
        Elf64_Half      e_machine;
        Elf64_Word      e_version;
        Elf64_Addr      e_entry;
        Elf64_Off       e_phoff;
        Elf64_Off       e_shoff;
        Elf64_Word      e_flags;
        Elf64_Half      e_ehsize;
        Elf64_Half      e_phentsize;
        Elf64_Half      e_phnum;
        Elf64_Half      e_shentsize;
        Elf64_Half      e_shnum;
        Elf64_Half      e_shstrndx;
} Elf64_Ehdr;

The elements of this structure are: