ELF Identification

ELF provides an object file framework to support multiple processors, multiple data encoding, and multiple classes of machines. To support this object file family, the initial bytes of the file specify how to interpret the file. These bytes are independent of the processor on which the inquiry is made and independent of the file's remaining contents.

The initial bytes of an ELF header and an object file correspond to the e_ident member.

Table 7-7 ELF Identification Index

These indexes access bytes that hold the values described below.

EI_MAG0 - EI_MAG3

A 4-byte magic number, identifying the file as an ELF object file, as listed in the following table.

Table 7-8 ELF Magic Number

Name	Value	Position
ELFMAG0	0x7f	e_ident[EI_MAG0]
ELFMAG1	'E'	e_ident[EI_MAG1]
ELFMAG2	'L'	e_ident[EI_MAG2]
ELFMAG3	'F'	e_ident[EI_MAG3]

EI_CLASS

Byte e_ident[EI_CLASS] identifies the file's class, or capacity, as listed in the following table.

Table 7-9 ELF File Class

Name	Value	Meaning
ELFCLASSNONE	0	Invalid class
ELFCLASS32	1	32-bit objects
ELFCLASS64	2	64-bit objects

The file format is designed to be portable among machines of various sizes, without imposing the sizes of the largest machine on the smallest. The class of the file defines the basic types used by the data structures of the object file container itself. The data contained in object file sections may follow a different programming model.

Class ELFCLASS32 supports machines with files and virtual address spaces up to 4 gigabytes. It uses the basic types defined in Table 7-1.

Class ELFCLASS64 is reserved for 64-bit architectures such as SPARC. It uses the basic types defined in Table 7-2.

EI_DATA

Byte e_ident[EI_DATA] specifies the data encoding of the processor-specific data in the object file, as listed in the following table.

Table 7-10 ELF Data Encoding

Name	Value	Meaning
ELFDATANONE	0	Invalid data encoding
ELFDATA2LSB	1	See Figure 7-2.
ELFDATA2MSB	2	See Figure 7-3.

More information on these encodings appears in the section "Data Encoding". Other values are reserved and will be assigned to new encodings as necessary.

EI_VERSION

Byte e_ident[EI_VERSION] specifies the ELF header version number. Currently, this value must be EV_CURRENT.

EI_OSABI

Byte e_ident[EI_OSABI] identifies the operating system and ABI to which the object is targeted. Some fields in other ELF structures have flags and values that have operating system or ABI specific meanings. The interpretation of those fields is determined by the value of this byte.

EI_ABIVERSION

Byte e_ident[EI_ABIVERSION] identifies the version of the ABI to which the object is targeted. This field is used to distinguish among incompatible versions of an ABI. The interpretation of this version number is dependent on the ABI identified by the EI_OSABI field. If no values are specified for the EI_OSABI field for the processor, or no version values are specified for the ABI determined by a particular value of the EI_OSABI byte, the value 0 is used to indicate unspecified.

EI_PAD

This value marks the beginning of the unused bytes in e_ident. These bytes are reserved and set to zero. Programs that read object files should ignore them. The value of EI_PAD will change in the future if currently unused bytes are given meanings.

Data Encoding

A file's data encoding specifies how to interpret the basic objects in a file. Class ELFCLASS32 files use objects that occupy 1, 2, and 4 bytes. Class ELFCLASS64 files use objects that occupy 1, 2, 4, and 8 bytes. Under the defined encodings, objects are represented as shown below. Byte numbers appear in the upper left corners.

Encoding ELFDATA2LSB specifies 2's complement values, with the least significant byte occupying the lowest address.

Figure 7-2 Data Encoding ELFDATA2LSB

Encoding ELFDATA2MSB specifies 2's complement values, with the most significant byte occupying the lowest address.

Figure 7-3 Data Encoding ELFDATA2MSB

Sections

An object file's section header table helps you locate all of the sections of the file. The section header table is an array of Elf32_Shdr or Elf64_Shdr structures, as described below. A section header table index is a subscript into this array. The ELF header's e_shoff member gives the byte offset from the beginning of the file to the section header table; e_shnum tells how many entries the section header table contains; e_shentsize gives the size in bytes of each entry.

Some section header table indexes are reserved; an object file does not have sections for these special indexes.

Table 7-11 ELF Special Section Indexes

Note - Although index 0 is reserved as the undefined value, the section header table contains an entry for index 0. That is, if the e_shnum member of the ELF header says a file has 6 entries in the section header table, they have the indexes 0 through 5. The contents of the initial entry are specified later in this section.

SHN_UNDEF

An undefined, missing, irrelevant, or otherwise meaningless section reference. For example, a symbol defined relative to section number SHN_UNDEF is an undefined symbol.

SHN_LORESERVE

The lower boundary of the range of reserved indexes.

SHN_LOPROC - SHN_HIPROC

Values in this inclusive range are reserved for processor-specific semantics.

SHN_BEFORE, SHN_AFTER

Provide for initial and final section ordering in conjunction with the SHF_LINK_ORDER and SHF_ORDERED section flags, listed in Table 7-14.

SHN_ABS

Absolute values for the corresponding reference. For example, symbols defined relative to section number SHN_ABS have absolute values and are not affected by relocation.

SHN_COMMON

Symbols defined relative to this section are common symbols, such as FORTRAN COMMON or unallocated C external variables. These symbols are sometimes referred to as tentative.

SHN_HIRESERVE

The upper boundary of the range of reserved indexes. The system reserves indexes between SHN_LORESERVE and SHN_HIRESERVE, inclusive. The values do not reference the section header table. The section header table does not contain entries for the reserved indexes.

Sections contain all information in an object file except the ELF header, the program header table, and the section header table. Moreover, the sections in object files satisfy several conditions:

• Every section in an object file has exactly one section header describing it. Section headers can exist that do not have a section.

• Each section occupies one contiguous, possibly empty, sequence of bytes within a file.

• Sections in a file cannot overlap. No byte in a file resides in more than one section.

• An object file can have inactive space. The various headers and the sections might not cover every byte in an object file. The contents of the inactive data are unspecified.

A section header has the following structure, defined in sys/elf.h:

typedef struct {
        Elf32_Word      sh_name;
        Elf32_Word      sh_type;
        Elf32_Word      sh_flags;
        Elf32_Addr      sh_addr;
        Elf32_Off       sh_offset;
        Elf32_Word      sh_size;
        Elf32_Word      sh_link;
        Elf32_Word      sh_info;
        Elf32_Word      sh_addralign;
        Elf32_Word      sh_entsize;
} Elf32_Shdr;

typedef struct {
        Elf64_Word      sh_name;
        Elf64_Word      sh_type;
        Elf64_Xword     sh_flags;
        Elf64_Addr      sh_addr;
        Elf64_Off       sh_offset;
        Elf64_Xword     sh_size;
        Elf64_Word      sh_link;
        Elf64_Word      sh_info;
        Elf64_Xword     sh_addralign;
        Elf64_Xword     sh_entsize;
} Elf64_Shdr;