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 code and data suitable to be linked with other object files to create an executable or shared object file, 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:

e_ident

The initial bytes mark the file as an object file and provide machine-independent data with which to decode and interpret the file's contents. Complete descriptions appear in "ELF Identification".

e_type

Identifies the object file type, as listed in the following table.

Table 7-3 ELF File Identifiers

Name	Value	Meaning
ET_NONE	0	No file type
ET_REL	1	Relocatable file
ET_EXEC	2	Executable file
ET_DYN	3	Shared object file
ET_CORE	4	Core file
ET_LOPROC	0xff00	Processor-specific
ET_HIPROC	0xffff	Processor-specific

Although the core file contents are unspecified, type ET_CORE is reserved to mark the file. Values from ET_LOPROC through ET_HIPROC (inclusive) are reserved for processor-specific semantics. Other values are reserved and will be assigned to new object file types as necessary.

e_machine

Specifies the required architecture for an individual file. Relevant architectures are listed in the following table.

Table 7-4 ELF Machines

Name	Value	Meaning
EM_NONE	0	No machine
EM_SPARC	2	SPARC
EM_386	3	Intel 80386
EM_SPARC32PLUS	18	Sun SPARC 32+
EM_SPARCV9	43	SPARC V9

Other values are reserved and will be assigned to new machines as necessary (see sys/elf.h). Processor-specific ELF names use the machine name to distinguish them. For example, the flags defined in Table 7-5 use the prefix EF_. A flag named WIDGET for the EM_XYZ machine would be called EF_XYZ_WIDGET.

e_version

Identifies the object file version, as listed in the following table.

Table 7-5 ELF Versions

Name	Value	Meaning
EV_NONE	0	Invalid version
EV_CURRENT	>=1	Current version

The value 1 signifies the original file format. Extensions will create new versions with higher numbers. The value of EV_CURRENT changes as necessary to reflect the current version number.

e_entry

The virtual address to which the system first transfers control, thus starting the process. If the file has no associated entry point, this member holds zero.

e_phoff

The program header table's file offset in bytes. If the file has no program header table, this member holds zero.

e_shoff

The section header table's file offset in bytes. If the file has no section header table, this member holds zero.

e_flags

Processor-specific flags associated with the file. Flag names take the form EF_machine_flag. This member is presently zero for IA. The SPARC flags are listed in the following table.

Table 7-6 SPARC: ELF Flags

Name	Value	Meaning
EF_SPARC_EXT_MASK	0xffff00	Vendor Extension mask
EF_SPARC_32PLUS	0x000100	Generic V8+ features
EF_SPARC_SUN_US1	0x000200	Sun UltraSPARC™ 1 Extensions
EF_SPARC_HAL_R1	0x000400	HAL R1 Extensions
EF_SPARC_SUN_US3	0x000800	Sun UltraSPARC 3 Extensions
EF_SPARCV9_MM	0x3	Mask for Memory Model
EF_SPARCV9_TSO	0x0	Total Store Ordering
EF_SPARCV9_PSO	0x1	Partial Store Ordering
EF_SPARCV9_RMO	0x2	Relaxed Memory Ordering

e_ehsize

The ELF header's size in bytes.

e_phentsize

The size in bytes of one entry in the file's program header table. All entries are the same size.

e_phnum

The number of entries in the program header table. The product of e_phentsize and e_phnum gives the table's size in bytes. If a file has no program header table, e_phnum holds the value zero.

e_shentsize

A section header's size in bytes. A section header is one entry in the section header table. All entries are the same size.

e_shnum

The number of entries in the section header table. The product of e_shentsize and e_shnum gives the section header table's size in bytes. If a file has no section header table, e_shnum holds the value zero.

e_shstrndx

The section header table index of the entry that is associated with the section name string table. If the file has no section name string table, this member holds the value SHN_UNDEF.