# 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 may 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 when and if extensions are defined.

Figure 4-3: ELF Header

    #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;

`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 below in ``ELF Identification''.
`e_type`
  This member identifies the object file type.

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_LOOS` | `0xfe00` | Operating system-specific
`ET_HIOS` | `0xfeff` | Operating system-specific
`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_LOOS` through `ET_HIOS` (inclusive) are reserved for operating system-specific semantics. Values from `ET_LOPROC` through `ET_HIPROC` (inclusive) are reserved for processor-specific semantics. If meanings are specified, the processor supplement explains them. Other values are reserved and will be assigned to new object file types as necessary.

`e_machine`
  This member's value specifies the required architecture for an individual file.

Name | Value | Meaning
--- | --- | ---
`EM_NONE` | `0` | No machine
`EM_M32` | `1` | AT&T WE 32100
`EM_SPARC` | `2` | SPARC
`EM_386` | `3` | Intel 80386
`EM_68K` | `4` | Motorola 68000
`EM_88K` | `5` | Motorola 88000
reserved | `6` | Reserved for future use (was `EM_486`)
`EM_860` | `7` | Intel 80860
`EM_MIPS` | `8` | MIPS I Architecture
`EM_S370` | `9` | IBM System/370 Processor
`EM_MIPS_RS3_LE` | `10` | MIPS RS3000 Little-endian
reserved | `11-14` | Reserved for future use
`EM_PARISC` | `15` | Hewlett-Packard PA-RISC
reserved | `16` | Reserved for future use
`EM_VPP500` | `17` | Fujitsu VPP500
`EM_SPARC32PLUS` | `18` | Enhanced instruction set SPARC
`EM_960` | `19` | Intel 80960
`EM_PPC` | `20` | PowerPC
`EM_PPC64` | `21` | 64-bit PowerPC
`EM_S390` | `22` | IBM System/390 Processor
reserved | `23-35` | Reserved for future use
`EM_V800` | `36` | NEC V800
`EM_FR20` | `37` | Fujitsu FR20
`EM_RH32` | `38` | TRW RH-32
`EM_RCE` | `39` | Motorola RCE
`EM_ARM` | `40` | Advanced RISC Machines ARM
`EM_ALPHA` | `41` | Digital Alpha
`EM_SH` | `42` | Hitachi SH
`EM_SPARCV9` | `43` | SPARC Version 9
`EM_TRICORE` | `44` | Siemens TriCore embedded processor
`EM_ARC` | `45` | Argonaut RISC Core, Argonaut Technologies Inc.
`EM_H8_300` | `46` | Hitachi H8/300
`EM_H8_300H` | `47` | Hitachi H8/300H
`EM_H8S` | `48` | Hitachi H8S
`EM_H8_500` | `49` | Hitachi H8/500
`EM_IA_64` | `50` | Intel IA-64 processor architecture
`EM_MIPS_X` | `51` | Stanford MIPS-X
`EM_COLDFIRE` | `52` | Motorola ColdFire
`EM_68HC12` | `53` | Motorola M68HC12
`EM_MMA` | `54` | Fujitsu MMA Multimedia Accelerator
`EM_PCP` | `55` | Siemens PCP
`EM_NCPU` | `56` | Sony nCPU embedded RISC processor
`EM_NDR1` | `57` | Denso NDR1 microprocessor
`EM_STARCORE` | `58` | Motorola Star*Core processor
`EM_ME16` | `59` | Toyota ME16 processor
`EM_ST100` | `60` | STMicroelectronics ST100 processor
`EM_TINYJ` | `61` | Advanced Logic Corp. TinyJ embedded processor family
`EM_X86_64` | `62` | AMD x86-64 architecture
`EM_PDSP` | `63` | Sony DSP Processor
`EM_PDP10` | `64` | Digital Equipment Corp. PDP-10
`EM_PDP11` | `65` | Digital Equipment Corp. PDP-11
`EM_FX66` | `66` | Siemens FX66 microcontroller
`EM_ST9PLUS` | `67` | STMicroelectronics ST9+ 8/16 bit microcontroller
`EM_ST7` | `68` | STMicroelectronics ST7 8-bit microcontroller
`EM_68HC16` | `69` | Motorola MC68HC16 Microcontroller
`EM_68HC11` | `70` | Motorola MC68HC11 Microcontroller
`EM_68HC08` | `71` | Motorola MC68HC08 Microcontroller
`EM_68HC05` | `72` | Motorola MC68HC05 Microcontroller
`EM_SVX` | `73` | Silicon Graphics SVx
`EM_ST19` | `74` | STMicroelectronics ST19 8-bit microcontroller
`EM_VAX` | `75` | Digital VAX
`EM_CRIS` | `76` | Axis Communications 32-bit embedded processor
`EM_JAVELIN` | `77` | Infineon Technologies 32-bit embedded processor
`EM_FIREPATH` | `78` | Element 14 64-bit DSP Processor
`EM_ZSP` | `79` | LSI Logic 16-bit DSP Processor
`EM_MMIX` | `80` | Donald Knuth's educational 64-bit processor
`EM_HUANY` | `81` | Harvard University machine-independent object files
`EM_PRISM` | `82` | SiTera Prism
`EM_AVR` | `83` | Atmel AVR 8-bit microcontroller
`EM_FR30` | `84` | Fujitsu FR30
`EM_D10V` | `85` | Mitsubishi D10V
`EM_D30V` | `86` | Mitsubishi D30V
`EM_V850` | `87` | NEC v850
`EM_M32R` | `88` | Mitsubishi M32R
`EM_MN10300` | `89` | Matsushita MN10300
`EM_MN10200` | `90` | Matsushita MN10200
`EM_PJ` | `91` | picoJava
`EM_OPENRISC` | `92` | OpenRISC 32-bit embedded processor
`EM_ARC_A5` | `93` | ARC Cores Tangent-A5
`EM_XTENSA` | `94` | Tensilica Xtensa Architecture
`EM_VIDEOCORE` | `95` | Alphamosaic VideoCore processor
`EM_TMM_GPP` | `96` | Thompson Multimedia General Purpose Processor
`EM_NS32K` | `97` | National Semiconductor 32000 series
`EM_TPC` | `98` | Tenor Network TPC processor
`EM_SNP1K` | `99` | Trebia SNP 1000 processor
`EM_ST200` | `100` | STMicroelectronics (www.st.com) ST200 microcontroller

Other values are reserved and will be assigned to new machines as necessary. Processor-specific ELF names use the machine name to distinguish them. For example, the flags mentioned below use the prefix `EF_`; a flag named `WIDGET` for the `EM_XYZ` machine would be called `EF_XYZ_WIDGET`.

`e_version`
  This member identifies the object file version.

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. Although the value of `EV_CURRENT` is shown as `1` in the previous table, it will change as necessary to reflect the current version number.

`e_entry`
  This member gives 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`
  This member holds the program header table's file offset in bytes. If the file has no program header table, this member holds zero.
`e_shoff`
  This member holds the section header table's file offset in bytes. If the file has no section header table, this member holds zero.
`e_flags`
  This member holds processor-specific flags associated with the file. Flag names take the form `EF_`machine_flag.
`e_ehsize`
  This member holds the ELF header's size in bytes.
`e_phentsize`
  This member holds the size in bytes of one entry in the file's program header table; all entries are the same size.
`e_phnum`
  This member holds the number of entries in the program header table. Thus 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`
  This member holds 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`
  This member holds the number of entries in the section header table. Thus 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.

  If the number of sections is greater than or equal to `SHN_LORESERVE` (`0xff00`), this member has the value zero and the actual number of section header table entries is contained in the `sh_size` field of the section header at index `0`. (Otherwise, the `sh_size` member of the initial entry contains `0`.)

`e_shstrndx`
  This member holds the section header table index of the entry associated with the section name string table. If the file has no section name string table, this member holds the value `SHN_UNDEF`. See ``Sections'' and ``String Table'' below for more information.

  If the section name string table section index is greater than or equal to `SHN_LORESERVE` (`0xff00`), this member has the value `SHN_XINDEX` (`0xffff`) and the actual index of the section name string table section is contained in the `sh_link` field of the section header at index `0`. (Otherwise, the `sh_link` member of the initial entry contains `0`.)

## ELF Identification

As mentioned above, ELF provides an object file framework to support multiple processors, multiple data encodings, and multiple classes of machines. To support this object file family, the initial bytes of the file specify how to interpret the file, 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.

Figure 4-4: `e_ident[]` Identification Indexes

Name | Value | Purpose
--- | --- | ---
`EI_MAG0` | `0` | File identification
`EI_MAG1` | `1` | File identification
`EI_MAG2` | `2` | File identification
`EI_MAG3` | `3` | File identification
`EI_CLASS` | `4` | File class
`EI_DATA` | `5` | Data encoding
`EI_VERSION` | `6` | File version
`EI_OSABI` | `7` | Operating system/ABI identification
`EI_ABIVERSION` | `8` | ABI version
`EI_PAD` | `9` | Start of padding bytes
`EI_NIDENT` | `16` | Size of `e_ident[]`

These indexes access bytes that hold the following values.

`EI_MAG0` to `EI_MAG3`
  A file's first 4 bytes hold a ``magic number,'' identifying the file as an ELF object file.

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`
  The next byte, `e_ident[EI_CLASS]`, identifies the file's class, or capacity.

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. If so, the processor supplement describes the model used.

Class `ELFCLASS32` supports machines with 32-bit architectures. It uses the basic types defined in the table labeled ``32-Bit Data Types.''

Class `ELFCLASS64` supports machines with 64-bit architectures. It uses the basic types defined in the table labeled ``64-Bit Data Types.''

Other classes will be defined as necessary, with different basic types and sizes for object file data.

`EI_DATA`
  Byte `e_ident[EI_DATA]` specifies the encoding of both the data structures used by object file container and data contained in object file sections. The following encodings are currently defined.

Name | Value | Meaning
--- | --- | ---
`ELFDATANONE` | `0` | Invalid data encoding
`ELFDATA2LSB` | `1` | See below
`ELFDATA2MSB` | `2` | See below

Other values are reserved and will be assigned to new encodings as necessary.

Primarily for the convenience of code that looks at the ELF file at runtime, the ELF data structures are intended to have the same byte order as that of the running program.

`EI_VERSION`
  Byte `e_ident[EI_VERSION]` specifies the ELF header version number. Currently, this value must be `EV_CURRENT`, as explained above for `e_version`.

`EI_OSABI`
  Byte `e_ident[EI_OSABI]` identifies the OS- or ABI-specific ELF extensions used by this file. Some fields in other ELF structures have flags and values that have operating system and/or ABI specific meanings; the interpretation of those fields is determined by the value of this byte. If the object file does not use any extensions, it is recommended that this byte be set to `0`. If the value for this byte is `64` through `255`, its meaning depends on the value of the `e_machine` header member. The ABI processor supplement for an architecture can define its own associated set of values for this byte in this range. If the processor supplement does not specify a set of values, one of the following values shall be used, where `0` can also be taken to mean unspecified.

  Name | Value | Meaning
  --- | --- | ---
  `ELFOSABI_NONE` | `0` | No extensions or unspecified
  `ELFOSABI_HPUX` | `1` | Hewlett-Packard HP-UX
  `ELFOSABI_NETBSD` | `2` | NetBSD
  `ELFOSABI_LINUX` | `3` | Linux
  `ELFOSABI_SOLARIS` | `6` | Sun Solaris
  `ELFOSABI_AIX` | `7` | AIX
  `ELFOSABI_IRIX` | `8` | IRIX
  `ELFOSABI_FREEBSD` | `9` | FreeBSD
  `ELFOSABI_TRU64` | `10` | Compaq TRU64 UNIX
  `ELFOSABI_MODESTO` | `11` | Novell Modesto
  `ELFOSABI_OPENBSD` | `12` | Open BSD
  `ELFOSABI_OPENVMS` | `13` | Open VMS
  `ELFOSABI_NSK` | `14` | Hewlett-Packard Non-Stop Kernel
  | `64-255` | Architecture-specific value range

`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 by the processor supplement or no version values are specified for the ABI determined by a particular value of the `EI_OSABI` byte, the value `0` shall be used for the `EI_ABIVERSION` byte; it indicates 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.

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.

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

Figure 4-5: Data Encoding `ELFDATA2LSB`, byte address zero on the left

01
0x01

02 | 01
0x0102

04 | 03 | 02 | 01
0x01020304

08 | 07 | 06 | 05 | 04 | 03 | 02 | 01
0x0102030405060708

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

Figure 4-6: Data Encoding `ELFDATA2MSB`, byte address zero on the left

01
0x01

01 | 02
0x0102

01 | 02 | 03 | 04
0x01020304

01 | 02 | 03 | 04 | 05 | 06 | 07 | 08
0x0102030405060708

## Machine Information (Processor-Specific)

This section requires processor-specific information. The ABI supplement for the desired processor describes the details.

© 1997, 1998, 1999, 2000, 2001 The Santa Cruz Operation, Inc. All rights reserved. © 2002 Caldera International. All rights reserved.