ELF(5) BSD Programmer's Manual ELF(5)NAMEelf - format of ELF binary files
SYNOPSIS
#include <sys/elf.h>
DESCRIPTION
The header file <sys/elf.h> defines the format of ELF executable binary
files. These files include ordinary executable files, relocatable object
files, core files and shared libraries.
ELF files contain an ELF header, plus a program header table or a section
header table, or both. The ELF header appears at the beginning of the
file and provides information about the entire file; the tables appear in
other locations in the file (specified in the ELF header) and describe
specific pieces of the file.
The headers are defined as C structures that contain members with specif-
ic defined types. The 32-bit ELF specification uses the following types:
Elf32_Addr Program addresses.
Elf32_Half Halfword fields.
Elf32_Off File offsets.
Elf32_Sword Signed integers.
Elf32_Word Fields or unsigned integers.
The ELF header is described by the type Elf32_Ehdr:
typedef {
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;
The fields have the following meanings:
e_ident A machine-independent prologue, represented in an array of
bytes. The rest of the ELF file uses the byte order and
word size specified by e_ident values. Bytes in e_ident
are named by macros (EI_*), and have values that are also
encoded by macros (ELF*). The bytes have the following
names and values:
EI_MAG0 The first byte of the magic number; it
must have the value ELFMAG0.
EI_MAG1 The second byte, with value ELFMAG1.
EI_MAG2 The third byte, with value ELFMAG2.
EI_MAG3 The fourth byte, with value ELFMAG3.
EI_CLASS The architecture that corresponds to this
binary:
ELFCLASS32 A 32-bit architecture.
ELFCLASS64 A 64-bit architecture. A
64-bit ELF specification is
under development; this
class is reserved.
EI_DATA The byte order or data configuration that
corresponds to this binary:
ELFDATA2LSB 2's-complement, little-endi-
an.
ELFDATA2MSB 2's-complement, big-endian.
EI_VERSION The version number of the ELF specifica-
tion; it must have the value EV_CURRENT.
e_type The type of the ELF file:
ET_REL A relocatable object file.
ET_EXEC An executable file.
ET_DYN A dynamically linked shared library
(`shared object').
ET_CORE A core file.
e_machine The instruction architecture. Some examples:
EM_SPARC The Sun SPARC architecture.
EM_386 The Intel x86 architecture.
EM_PPC The PowerPC architecture.
e_version Must be EV_CURRENT.
e_entry The virtual address of the entry point, if the file type
is ET_EXEC or ET_DYN; otherwise zero.
e_phoff The file offset of the program header table.
e_shoff The file offset of the section header table.
e_flags Machine-specific flag bits (EF_*). Not used on the x86 ar-
chitecture, and many others.
e_ehsize The ELF header size in bytes.
e_phentsize The size of a program header, in bytes.
e_phnum The number of program headers in the program header table.
e_shentsize The size of a section header, in bytes.
e_shnum The number of section headers in the section header table.
e_shstrndx The index of the section header in the section header
table that contains the section name string table.
The program header table describes the mapping from the contents of an
ELF file onto virtual memory. For example, when the system runs a pro-
gram, it reads the program header table to locate the text, data and oth-
er segments in the executable file and to find out where to load them in-
to memory. In a core file, the program header table describes the loca-
tions and protections of the segments of the dead process, in the file
and in memory. The program header table is mandatory except in relocat-
able object files. Program headers have the type Elf32_Phdr:
typedef {
Elf32_Word p_type;
Elf32_Off p_offset;
Elf32_Addr p_vaddr;
Elf32_Addr p_paddr;
Elf32_Word p_filesz;
Elf32_Word p_memsz;
Elf32_Word p_flags;
Elf32_Word p_align;
} Elf32_Phdr;
The fields have the following meanings:
p_type The type of the information described by this header:
PT_NULL A placeholder entry. The contents are ig-
nored.
PT_LOAD A loadable segment. This header describes
a part of the file that corresponds to
memory contents in a process, such as a
text or data segment. Only loadable seg-
ments are considered when the system loads
a program into memory. Program headers
for loadable segments are ordered by vir-
tual address, and the segments don't over-
lap. The other segments don't have these
restrictions.
PT_DYNAMIC Dynamic linking information. The dynamic
linking structures are intricate and var-
ied, and are beyond the scope of this man-
ual page.
PT_INTERP The name of an interpreter program. The
system loads interpreted programs with the
interpreter and passes control to the in-
terpreter at start-up; the interpreter is
responsible for any remaining loading or
relocation that must be performed before
the program may run. The typical inter-
preter is the dynamic linker, /shlib/ld-
bsdi.so.
PT_NOTE Miscellaneous run-time information. This
includes material such as `brands', which
describe the operating system environment
that the program requires. Core notes are
described in core(5).
PT_PHDR The program header table itself. Some
programs, such as the dynamic linker, need
to access information in the program head-
er table at run time.
p_offset The byte offset in the ELF file at which the segment
starts.
p_vaddr The virtual address where the segment is or was loaded.
p_paddr An unused field; must be zero.
p_filesz The extent of the segment in the executable file, in
bytes.
p_memsz The extent of the segment in memory, in bytes. If p_memsz
is greater than p_filesz, the `missing' data is filled
with zeroes in memory.
p_flags Protection bits:
PF_X An executable segment.
PF_W A writable segment.
PF_R A readable segment.
p_align If nonzero, the alignment in bytes of the segment; it must
be a power of two, and the p_vaddr field must match this
alignment modulo the page size. If zero, the segment need
not be aligned.
A section header table describes the file from the linker's point of
view. A section header table is mandatory in relocatable objects and
shared objects, and is optional in other ELF files. The linker ld(1) us-
es the section header table to determine how to combine ELF files. Sec-
tions of the same name are merged in the linking process; for example,
all sections named `.text' are relocated and concatenated into a single
text segment. Different sections that have similar protections are sort-
ed and merged into common segments. The first section (index 0) in the
section header table is reserved as a `null' section. Section headers
have the type Elf32_Shdr:
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;
The fields have the following meanings:
sh_name The name of the section, given as a byte offset into the
section header string table. The index of the section
header string table in the section header table is provid-
ed in the ELF header (e_shstrndx).
sh_type The type of the contents:
SHT_NULL An unused section header.
SHT_PROGBITS Information specific to this ELF file.
Typically, text or data from a program.
SHT_SYMTAB A symbol table (see below).
SHT_STRTAB A string table (see below).
SHT_RELA A table of relocations with addends.
SHT_HASH A symbol hash table; usually used to speed
up dynamic linking. Not described here.
SHT_DYNAMIC Dynamic linking information.
SHT_NOTE Miscellaneous information about the file.
SHT_NOBITS Like SHT_PROGBITS, but for zero-filled
memory; the section occupies no space in
the file. It is typically used for bss in
a program.
SHT_REL A table of relocations that don't require
addends.
SHT_DYNSYM A reduced symbol table for dynamic link-
ing.
sh_flags Protection bits:
SHF_WRITE A writable section. Sections are readable
by default.
SHF_ALLOC A section that corresponds to virtual mem-
ory; typically, part of a loadable seg-
ment.
SHF_EXECINSTR An executable section; typically, program
text.
sh_addr The address of the section in virtual memory, if it has
one; otherwise 0.
sh_offset The byte offset of the section in the file.
sh_size The length in bytes of the section.
sh_link A section header index that means something different de-
pending on the type of the section. It is defined to be
SHN_UNDEF for those sections that don't use it. For
SHT_DYNAMIC, SHT_SYMTAB and SHT_DYNSYM sections, it is the
index of the corresponding string table. For SHT_HASH,
SHT_REL and SHT_RELA sections, it is the index of the cor-
responding symbol table.
sh_info A cookie that holds a value specific to certain sections.
Sections that don't use it give it as 0. For SHT_SYMTAB
and SHT_DYNSYM sections, it contains the symbol table in-
dex of the first non-local symbol table entry, or one
greater than the index of the last entry if all entries
are local (STB_LOCAL). For SHT_REL and SHT_RELA sections,
it contains the section header index of the section to
which these relocations apply.
sh_addralign The maximum alignment of the section, given in bytes. It
must be a power of two, or zero to indicate no alignment
requirements.
sh_entsize The size of the elements in this section, if they all have
the same size. For example, in a symbol table section,
this field would give the size of a symbol table entry.
There are several sections that have standard names. These include the
.text section, the .data section and the .bss section, which respectively
contain machine instructions, initialized data and uninitialized (zero-
filled) data. There are read-only data sections, debugging sections and
dynamic linking sections as well; the details will not be described here.
Sections typically do not have a fixed virtual address. The linker as-
signs a final virtual address to a section only after all sections have
been linked. Symbols are strings that serve to identify information in
sections; they stand in for addresses until the linker assigns final ad-
dresses. For example, a global variable name or a function name in C
typically becomes a symbol name in an ELF file.
Symbols are described by their name, which appears in a string table, and
by a structure called a symbol table entry. An ELF symbol table entry has
the type Elf32_Shdr:
typedef {
Elf32_Word st_name;
Elf32_Addr st_value;
Elf32_Word st_size;
unsigned char st_info;
unsigned char st_other;
Elf32_Half st_shndx;
} Elf32_Sym;
The fields have the following meanings:
st_name The index of the nul-terminated symbol name string in the
corresponding string table.
st_value The value of the symbol. This is typically an offset
within a section that contains the data corresponding to
the symbol, but it may be any arbitrary number. The
st_shndx field controls the interpretation (see below).
st_size The size of the object that the symbol describes, if the
object has a size and that size is known; otherwise 0.
st_info A cookie that encodes the binding (scope) and type
(format) of the object that the symbol references. Bind-
ings and types are numbers, as opposed to bits. The
available bindings are:
STB_LOCAL A local symbol. Local symbols have file
scope -- symbols in other files in a link
may have the same name.
STB_GLOBAL A global symbol. All instances of a given
global symbol in a link refer to the same
object. There must be at most one defini-
tion of the global symbol across all files
in the link; other occurrences of the sym-
bol must be `undefined' references (see
st_shndx below).
STB_WEAK A `weak' symbol. A weak symbol is similar
to a global symbol, but with lower prece-
dence. There are two cases: a weak symbol
definition, and an undefined weak symbol.
Weak symbol definitions have global scope,
but there may be more than one definition
of a weak symbol in a link, and a weak
symbol definition may duplicate a global
symbol definition. If a global definition
of a symbol is found during a link, the
linker ignores all weak definitions. In
the absence of a global definition, the
first weak definition in the link wins. A
weak undefined symbol is like a global un-
defined symbol, but it is not an error if
a definition for that symbol does not ap-
pear in the link. Also, the linker won't
extract an object file from an archive
merely to satisfy an undefined weak sym-
bol. Unresolved weak symbols have the
value 0. A global or weak definition is
sufficient to resolve an undefined weak
symbol.
The available types are:
STT_NOTYPE No type information was provided.
STT_OBJECT A data object, such as a variable or a
structure.
STT_FUNC A function.
STT_SECTION A section. These symbols have local bind-
ing and are used for relocation.
STT_FILE A file name. Symbols with this type con-
ventionally appear first in the symbol
table; they have local binding and abso-
lute linkage.
There are macros for packing and unpacking the binding and
type fields:
ELF32_ST_INFO (bind, type)
Convert a binding and a type into an
st_info value.
ELF32_ST_BIND (info)
Extract a binding from an st_info value.
ELF32_ST_TYPE (info)
Extract a type from an st_info value.
st_other An unused field.
st_shndx The section header index. In most cases, this refers to a
section header in the section header table, in which case
the location of the object to which the symbol refers is
st_value bytes from the start of that section. There are
three reserved pseudo-indexes:
SHN_UNDEF Symbols in this pseudo-section are
undefined. The linker must locate a defi-
nition in some other file. The linker re-
ports an error if it cannot find a defini-
tion (except for weak symbols).
SHN_ABS These symbols have absolute addresses.
The value in the st_value field is not
modified by the linker; it is effectively
a constant.
SHN_COMMON These symbols are similar to undefined
symbols, but if at the end of the link, no
definition has been found, then the linker
allocates zero-filled space in the bss
segment for a definition. The object that
the linker creates will have the maximum
size and alignment found among the common
symbols with this name.
A string table section stores the names of symbols or sections. A symbol
or a section header will provide a byte offset into a string table, or
zero to indicate a null string. All strings in the string table are nul-
terminated. (Thus, the first byte of a non-empty string table is always
a nul.) Strings may overlap; they also need not be unique.
A note section contains miscellaneous information that is of interest to
the system or to the compiler tools. It is structured into 12-byte,
32-bit aligned headers, each of which may be followed by note-specific
data. The data is in turn structured into two 32-bit aligned sections.
The first two header words give the sizes of the two data sections in
bytes, not including any padding for alignment; the third word provides
an integer type value. Conventionally, the first section of data holds a
nul-terminated name of an operating system or vendor; the length includes
the nul byte. The second section and the type word have any value that
the vendor cares to give them.
Relocation and dynamic sections are beyond the scope of this document.
See the System V Application Binary Interface for details.
SEE ALSOld(1), ld.so(8), execve(2), core(5)HISTORY
ELF first appeared in Unix System V. It is a published standard.
BUGS
Many tools on the system are still oriented toward a.out(5) format binary
files, even when they support ELF internally.
BSDI BSD/OS December 9, 1997 7
