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_shtrndx;
} 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_shtrndx;
} 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 |
EM_860 |
7 |
Intel 80860 |
EM_MIPS |
8 |
MIPS I Architecture |
RESERVED |
9 |
Reserved for future use |
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 |
Power PC |
RESERVED |
21-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 MercedTM Processor |
EM_MIPS_X |
51 |
Stanford MIPS-X |
EM_COLDFIRE |
52 |
Motorola Coldfire |
EM_68HC12 |
53 |
Motorola M68HC12 |
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.
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.
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 32-bit architectures. It
uses the basic types defined in the table
labelled ``32-Bit Data Types.''
Class ELFCLASS64 supports machines with 64-bit
architectures. It uses the basic types defined in the table
labelled ``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 inteneded 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
operating system and ABI to which the object is targeted.
Some fields in other ELF structures have flags and values
that have platform specific meanings; the interpretation
of those fields is determined by the value of this byte.
The following values are currently defined.
| Name |
Value |
Meaning |
ELFOSABI_SYSV |
0 |
UNIX System V ABI (this specification) |
ELFOSABI_HPUX |
1 |
HP-UX operating system |
ELFOSABI_STANDALONE |
255 |
Standalone (embedded) application |
Other values are reserved and will be assigned new meanings
as necessary.
EI_ABIVERSION- Byte
e_ident[EI_ABIVERSION] identifies the
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. Applications conforming to this specification use
the value 0.
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
| 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 |
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 The Santa Cruz Operation, Inc. All rights reserved.