1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
|
.Dd July 31, 1999
.Dt ELF 5
.Os
.Sh NAME
.Nm elf
.Nd format of Executable and Linking Format (ELF) files
.Sh SYNOPSIS
.\" .Fd #include <elf_abi.h>
.Fd #include <elf.h>
.Sh DESCRIPTION
The header file
.\" .Aq Pa elf_abi.h
.Aq Pa elf.h
defines the format of ELF executable binary files.
Amongst these files are
normal executable files, relocatable object files, core files and shared
libraries.
.Pp
An executable file using the ELF file format consists of an ELF header,
followed by a program header table or a section header table, or both.
The ELF header is always at offset zero of the file.
The program header
table and the section header table's offset in the file are defined in the
ELF header.
The two tables describe the rest of the particularities of
the file.
.Pp
.\" Applications which wish to process ELF binary files for their native
.\" architecture only should include
.\" .Aq Pa elf_abi.h
.\" in their source code.
.\" These applications should need to refer to
.\" all the types and structures by their generic names
.\" .Dq Elf_xxx
.\" and to the macros by
.\" .Dq ELF_xxx .
.\" Applications written this way can be compiled on any architecture,
.\" regardless of whether the host is 32-bit or 64-bit.
.\" .Pp
.\" Should an application need to process ELF files of an unknown
.\" architecture, then the application needs to explicitly use either
.\" .Dq Elf32_xxx
.\" or
.\" .Dq Elf64_xxx
.\" type and structure names.
.\" Likewise, the macros need to be identified by
.\" .Dq ELF32_xxx
.\" or
.\" .Dq ELF64_xxx .
.\" .Pp
This header file describes the above mentioned headers as C structures
and also includes structures for dynamic sections, relocation sections and
symbol tables.
.Pp
The following types are used for N-bit architectures (N=32,64,
ElfN stands for Elf32 or Elf64, uintN_t stands for uint32_t or uint64_t):
.Bd -literal -offset indent
ElfN_Addr Unsigned program address, uintN_t
ElfN_Off Unsigned file offset, uintN_t
ElfN_Section Unsigned section index, uint16_t
ElfN_Versym Unsigned version symbol information, uint16_t
Elf_Byte unsigned char
ElfN_Half uint16_t
ElfN_Sword int32_t
ElfN_Word uint32_t
ElfN_Sxword int64_t
ElfN_Xword uint64_t
.\" Elf32_Size Unsigned object size
.Ed
.Pp
(Note: The *BSD terminology is a bit different. There Elf64_Half is
twice as large as Elf32_Half, and Elf64Quarter is used for uint16_t.
In order to avoid confusion these types are replaced by explicit ones
in the below.)
.Pp
All data structures that the file format defines follow the
.Dq 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, etc.
.Pp
The ELF header is described by the type Elf32_Ehdr or Elf64_Ehdr:
.Bd -literal -offset indent
#define EI_NIDENT 16
typedef struct {
unsigned char e_ident[EI_NIDENT];
uint16_t e_type;
uint16_t e_machine;
uint32_t e_version;
ElfN_Addr e_entry;
ElfN_Off e_phoff;
ElfN_Off e_shoff;
uint32_t e_flags;
uint16_t e_ehsize;
uint16_t e_phentsize;
uint16_t e_phnum;
uint16_t e_shentsize;
uint16_t e_shnum;
uint16_t e_shstrndx;
} ElfN_Ehdr;
.Ed
.Pp
The fields have the following meanings:
.Pp
String table sections hold null-terminated character sequences, commonly
called strings.
The object file uses these strings to represent symbol
and section names.
One references a string as an index into the string
table section.
The first byte, which is index zero, is defined to hold
a null character.
Similarly, a string table's last byte is defined to
hold a null character, ensuring null termination for all strings.
.Pp
An object file's symbol table holds information needed to locate and
relocate a program's symbolic definitions and references.
A symbol table
index is a subscript into this array.
.Bd -literal -offset indent
typedef struct {
uint32_t st_name;
Elf32_Addr st_value;
uint32_t st_size;
unsigned char st_info;
unsigned char st_other;
uint16_t st_shndx;
} Elf32_Sym;
.Ed
.Bd -literal -offset indent
typedef struct {
uint32_t st_name;
unsigned char st_info;
unsigned char st_other;
uint16_t st_shndx;
Elf64_Addr st_value;
uint64_t st_size;
} Elf64_Sym;
.Ed
.Pp
The 32-bit and 64-bit versions have the same members, just in a different
order.
.Bl -tag -width "st_value" -offset indent
.It Dv st_name
This member holds an index into the object file's symbol string table,
which holds character representations of the symbol names.
If the value
is non-zero, it represents a string table index that gives the symbol
name.
Otherwise, the symbol table has no name.
.It Dv st_value
This member gives the value of the associated symbol.
.It Dv st_size
Many symbols have associated sizes.
This member holds zero if the symbol
has no size or an unknown size.
.It Dv st_info
This member specifies the symbol's type and binding attributes:
.El
.Pp
Relocation is the process of connecting symbolic references with
symbolic definitions.
Relocatable files must have information that
describes how to modify their section contents, thus allowing executable
and shared object files to hold the right information for a process'
program image.
Relocation entries are these data.
.Pp
Relocation structures that do not need an addend:
.Bd -literal -offset indent
typedef struct {
Elf32_Addr r_offset;
uint32_t r_info;
} Elf32_Rel;
.Ed
.Bd -literal -offset indent
typedef struct {
Elf64_Addr r_offset;
uint64_t r_info;
} Elf64_Rel;
.Ed
.Pp
Relocation structures that need an addend:
.Bd -literal -offset indent
typedef struct {
Elf32_Addr r_offset;
uint32_t r_info;
int32_t r_addend;
} Elf32_Rela;
.Ed
.Bd -literal -offset indent
typedef struct {
Elf64_Addr r_offset;
uint64_t r_info;
int64_t r_addend;
} Elf64_Rela;
.Ed
.Sh SEE ALSO
.Xr as 1 ,
.Xr gdb 1 ,
.Xr ld 1 ,
.Xr objdump 1 ,
.Xr execve 2 ,
.Xr core 5
.Rs
.%A Hewlett-Packard
.%B Elf-64 Object File Format
.Re
.Rs
.%A Santa Cruz Operation
.%B System V Application Binary Interface
.Re
.Rs
.%A Unix System Laboratories
.%T Object Files
.%B "Executable and Linking Format (ELF)"
.Re
.Sh HISTORY
.Ox
ELF support first appeared in
.Ox 1.2 ,
although not all supported platforms use it as the native
binary file format.
ELF in itself first appeared in
.At V .
The ELF format is an adopted standard.
.Sh AUTHORS
The original version of this manual page was written by
.An Jeroen Ruigrok van der Werven
.Aq asmodai@FreeBSD.org
with inspiration from BSDi's
.Bsx
.Nm elf
manpage.
|
