1ELF(5) BSD File Formats Manual ELF(5)
2
4 elf — format of Executable and Linking Format (ELF) files
5
7 #include <elf.h>
8
10 The header file ⟨elf.h⟩ defines the format of ELF executable binary
11 files. Amongst these files are normal executable files, relocatable
12 object files, core files and shared libraries.
13
14 An executable file using the ELF file format consists of an ELF header,
15 followed by a program header table or a section header table, or both.
16 The ELF header is always at offset zero of the file. The program header
17 table and the section header table's offset in the file are defined in
18 the ELF header. The two tables describe the rest of the particularities
19 of the file.
20
21 This header file describes the above mentioned headers as C structures
22 and also includes structures for dynamic sections, relocation sections
23 and symbol tables.
24
25 The following types are used for N-bit architectures (N=32,64, ElfN
26 stands for Elf32 or Elf64, uintN_t stands for uint32_t or uint64_t):
27
28 ElfN_Addr Unsigned program address, uintN_t
29 ElfN_Off Unsigned file offset, uintN_t
30 ElfN_Section Unsigned section index, uint16_t
31 ElfN_Versym Unsigned version symbol information, uint16_t
32 Elf_Byte unsigned char
33 ElfN_Half uint16_t
34 ElfN_Sword int32_t
35 ElfN_Word uint32_t
36 ElfN_Sxword int64_t
37 ElfN_Xword uint64_t
38
39 (Note: The *BSD terminology is a bit different. There Elf64_Half is twice
40 as large as Elf32_Half, and Elf64Quarter is used for uint16_t. In order
41 to avoid confusion these types are replaced by explicit ones in the
42 below.)
43
44 All data structures that the file format defines follow the “natural”
45 size and alignment guidelines for the relevant class. If necessary, data
46 structures contain explicit padding to ensure 4-byte alignment for 4-byte
47 objects, to force structure sizes to a multiple of 4, etc.
48
49 The ELF header is described by the type Elf32_Ehdr or Elf64_Ehdr:
50
51 #define EI_NIDENT 16
52
53 typedef struct {
54 unsigned char e_ident[EI_NIDENT];
55 uint16_t e_type;
56 uint16_t e_machine;
57 uint32_t e_version;
58 ElfN_Addr e_entry;
59 ElfN_Off e_phoff;
60 ElfN_Off e_shoff;
61 uint32_t e_flags;
62 uint16_t e_ehsize;
63 uint16_t e_phentsize;
64 uint16_t e_phnum;
65 uint16_t e_shentsize;
66 uint16_t e_shnum;
67 uint16_t e_shstrndx;
68 } ElfN_Ehdr;
69
70 The fields have the following meanings:
71
72 e_ident This array of bytes specifies to interpret the file,
73 independent of the processor or the file's remaining
74 contents. Within this array everything is named by
75 macros, which start with the prefix EI_ and may con‐
76 tain values which start with the prefix ELF. The fol‐
77 lowing macros are defined:
78
79 EI_MAG0 The first byte of the magic number. It
80 must be filled with ELFMAG0. (0: 0x7f)
81
82 EI_MAG1 The second byte of the magic number. It
83 must be filled with ELFMAG1. (1: 'E')
84
85 EI_MAG2 The third byte of the magic number. It
86 must be filled with ELFMAG2. (2: 'L')
87
88 EI_MAG3 The fourth byte of the magic number. It
89 must be filled with ELFMAG3. (3: 'F')
90
91 EI_CLASS The fifth byte identifies the architecture
92 for this binary:
93
94 ELFCLASSNONE This class is invalid.
95 ELFCLASS32 This defines the 32-bit
96 architecture. It supports
97 machines with files and vir‐
98 tual address spaces up to 4
99 Gigabytes.
100 ELFCLASS64 This defines the 64-bit
101 architecture.
102
103 EI_DATA The sixth byte specifies the data encoding
104 of the processor-specific data in the
105 file. Currently these encodings are sup‐
106 ported:
107
108 ELFDATANONE Unknown data format.
109 ELFDATA2LSB Two's complement, little-
110 endian.
111 ELFDATA2MSB Two's complement, big-endian.
112
113 EI_VERSION The version number of the ELF specifica‐
114 tion:
115
116 EV_NONE Invalid version.
117 EV_CURRENT Current version.
118
119 EI_OSABI This byte identifies the operating system
120 and ABI to which the object is targeted.
121 Some fields in other ELF structures have
122 flags and values that have platform spe‐
123 cific meanings; the interpretation of
124 those fields is determined by the value of
125 this byte. E.g.:
126
127 ELFOSABI_NONE Same as ELFOSABI_SYSV
128 ELFOSABI_SYSV UNIX System V ABI.
129 ELFOSABI_HPUX HP-UX ABI.
130 ELFOSABI_NETBSD NetBSD ABI.
131 ELFOSABI_LINUX Linux ABI.
132 ELFOSABI_SOLARIS Solaris ABI.
133 ELFOSABI_IRIX IRIX ABI.
134 ELFOSABI_FREEBSD FreeBSD ABI.
135 ELFOSABI_TRU64 TRU64 UNIX ABI.
136 ELFOSABI_ARM ARM architecture ABI.
137 ELFOSABI_STANDALONE Stand-alone (embed‐
138 ded) ABI.
139
140 EI_ABIVERSION
141 This byte identifies the version of the
142 ABI to which the object is targeted. This
143 field is used to distinguish among incom‐
144 patible versions of an ABI. The interpre‐
145 tation of this version number is dependent
146 on the ABI identified by the EI_OSABI
147 field. Applications conforming to this
148 specification use the value 0.
149
150 EI_PAD Start of padding. These bytes are
151 reserved and set to zero. Programs which
152 read them should ignore them. The value
153 for EI_PAD will change in the future if
154 currently unused bytes are given meanings.
155
156 EI_BRAND Start of architecture identification.
157
158 EI_NIDENT The size of the e_ident array.
159
160 e_type This member of the structure identifies the object
161 file type:
162
163 ET_NONE An unknown type.
164 ET_REL A relocatable file.
165 ET_EXEC An executable file.
166 ET_DYN A shared object.
167 ET_CORE A core file.
168
169 e_machine This member specifies the required architecture for an
170 individual file. E.g.:
171
172 EM_NONE An unknown machine.
173 EM_M32 AT&T WE 32100.
174 EM_SPARC Sun Microsystems SPARC.
175 EM_386 Intel 80386.
176 EM_68K Motorola 68000.
177 EM_88K Motorola 88000.
178 EM_860 Intel 80860.
179 EM_MIPS MIPS RS3000 (big-endian only).
180 EM_PARISC HP/PA.
181 EM_SPARC32PLUS SPARC with enhanced instruction set.
182 EM_PPC PowerPC.
183 EM_PPC64 PowerPC 64-bit.
184 EM_S390 IBM S/390
185 EM_ARM Advanced RISC Machines
186 EM_SH Renesas SuperH
187 EM_SPARCV9 SPARC v9 64-bit.
188 EM_IA_64 Intel Itanium
189 EM_X86_64 AMD x86-64
190 EM_VAX DEC Vax.
191
192 e_version This member identifies the file version:
193
194 EV_NONE Invalid version.
195 EV_CURRENT Current version.
196
197 e_entry This member gives the virtual address to which the
198 system first transfers control, thus starting the
199 process. If the file has no associated entry point,
200 this member holds zero.
201
202 e_phoff This member holds the program header table's file off‐
203 set in bytes. If the file has no program header ta‐
204 ble, this member holds zero.
205
206 e_shoff This member holds the section header table's file off‐
207 set in bytes. If the file has no section header table
208 this member holds zero.
209
210 e_flags This member holds processor-specific flags associated
211 with the file. Flag names take the form
212 EF_`machine_flag'. Currently no flags have been
213 defined.
214
215 e_ehsize This member holds the ELF header's size in bytes.
216
217 e_phentsize This member holds the size in bytes of one entry in
218 the file's program header table; all entries are the
219 same size.
220
221 e_phnum This member holds the number of entries in the program
222 header table. Thus the product of e_phentsize and
223 e_phnum gives the table's size in bytes. If a file
224 has no program header, e_phnum holds the value zero.
225
226 e_shentsize This member holds a sections header's size in bytes.
227 A section header is one entry in the section header
228 table; all entries are the same size.
229
230 e_shnum This member holds the number of entries in the section
231 header table. Thus the product of e_shentsize and
232 e_shnum gives the section header table's size in
233 bytes. If a file has no section header table, e_shnum
234 holds the value of zero.
235
236 e_shstrndx This member holds the section header table index of
237 the entry associated with the section name string ta‐
238 ble. If the file has no section name string table,
239 this member holds the value SHN_UNDEF.
240
241 SHN_UNDEF This value marks an undefined, missing,
242 irrelevant, or otherwise meaningless
243 section reference. For example, a sym‐
244 bol “defined” relative to section num‐
245 ber SHN_UNDEF is an undefined symbol.
246
247 SHN_LORESERVE This value specifies the lower bound of
248 the range of reserved indices.
249
250 SHN_LOPROC Values greater than or equal to
251 SHN_HIPROC are reserved for processor-
252 specific semantics.
253
254 SHN_HIPROC Values less than or equal to SHN_LOPROC
255 are reserved for processor-specific
256 semantics.
257
258 SHN_ABS This value specifies absolute values
259 for the corresponding reference. For
260 example, symbols defined relative to
261 section number SHN_ABS have absolute
262 values and are not affected by reloca‐
263 tion.
264
265 SHN_COMMON Symbols defined relative to this sec‐
266 tion are common symbols, such as For‐
267 tran COMMON or unallocated C external
268 variables.
269
270 SHN_HIRESERVE This value specifies the upper bound of
271 the range of reserved indices between
272 SHN_LORESERVE and SHN_HIRESERVE, inclu‐
273 sive; the values do not reference the
274 section header table. That is, the
275 section header table does not contain
276 entries for the reserved indices.
277
278 An executable or shared object file's program header table is an array of
279 structures, each describing a segment or other information the system
280 needs to prepare the program for execution. An object file segment con‐
281 tains one or more sections. Program headers are meaningful only for exe‐
282 cutable and shared object files. A file specifies its own program header
283 size with the ELF header's e_phentsize and e_phnum members. The ELF pro‐
284 gram header is described by the type Elf32_Phdr or Elf64_Phdr depending
285 on the architecture:
286
287 typedef struct {
288 uint32_t p_type;
289 Elf32_Off p_offset;
290 Elf32_Addr p_vaddr;
291 Elf32_Addr p_paddr;
292 uint32_t p_filesz;
293 uint32_t p_memsz;
294 uint32_t p_flags;
295 uint32_t p_align;
296 } Elf32_Phdr;
297
298 typedef struct {
299 uint32_t p_type;
300 uint32_t p_flags;
301 Elf64_Off p_offset;
302 Elf64_Addr p_vaddr;
303 Elf64_Addr p_paddr;
304 uint64_t p_filesz;
305 uint64_t p_memsz;
306 uint64_t p_align;
307 } Elf64_Phdr;
308
309 The main difference between the 32-bit and the 64-bit program header lies
310 in the location of the p_flags member in the total struct.
311
312 p_type This member of the Phdr struct tells what kind of segment
313 this array element describes or how to interpret the
314 array element's information.
315
316 PT_NULL The array element is unused and the other
317 members' values are undefined. This lets the
318 program header have ignored entries.
319
320 PT_LOAD The array element specifies a loadable seg‐
321 ment, described by p_filesz and p_memsz. The
322 bytes from the file are mapped to the begin‐
323 ning of the memory segment. If the segment's
324 memory size (p_memsz) is larger than the file
325 size (p_filesz), the “extra” bytes are
326 defined to hold the value 0 and to follow the
327 segment's initialized area. The file size
328 may not be larger than the memory size.
329 Loadable segment entries in the program
330 header table appear in ascending order,
331 sorted on the p_vaddr member.
332
333 PT_DYNAMIC The array element specifies dynamic linking
334 information.
335
336 PT_INTERP The array element specifies the location and
337 size of a null-terminated pathname to invoke
338 as an interpreter. This segment type is
339 meaningful only for executable files (though
340 it may occur for shared objects). However it
341 may not occur more than once in a file. If
342 it is present, it must precede any loadable
343 segment entry.
344
345 PT_NOTE The array element specifies the location and
346 size for auxiliary information.
347
348 PT_SHLIB This segment type is reserved but has unspec‐
349 ified semantics. Programs that contain an
350 array element of this type do not conform to
351 the ABI.
352
353 PT_PHDR The array element, if present, specifies the
354 location and size of the program header table
355 itself, both in the file and in the memory
356 image of the program. This segment type may
357 not occur more than once in a file. More‐
358 over, it may only occur if the program header
359 table is part of the memory image of the pro‐
360 gram. If it is present, it must precede any
361 loadable segment entry.
362
363 PT_LOPROC Values greater than or equal to PT_HIPROC are
364 reserved for processor-specific semantics.
365
366 PT_HIPROC Values less than or equal to PT_LOPROC are
367 reserved for processor-specific semantics.
368
369 p_offset This member holds the offset from the beginning of the
370 file at which the first byte of the segment resides.
371
372 p_vaddr This member holds the virtual address at which the first
373 byte of the segment resides in memory.
374
375 p_paddr On systems for which physical addressing is relevant,
376 this member is reserved for the segment's physical
377 address. Under BSD this member is not used and must be
378 zero.
379
380 p_filesz This member holds the number of bytes in the file image
381 of the segment. It may be zero.
382
383 p_memsz This member holds the number of bytes in the memory image
384 of the segment. It may be zero.
385
386 p_flags This member holds flags relevant to the segment:
387
388 PF_X An executable segment.
389 PF_W A writable segment.
390 PF_R A readable segment.
391
392 A text segment commonly has the flags PF_X and PF_R. A
393 data segment commonly has PF_X, PF_W and PF_R.
394
395 p_align This member holds the value to which the segments are
396 aligned in memory and in the file. Loadable process seg‐
397 ments must have congruent values for p_vaddr and
398 p_offset, modulo the page size. Values of zero and one
399 mean no alignment is required. Otherwise, p_align should
400 be a positive, integral power of two, and p_vaddr should
401 equal p_offset, modulo p_align.
402
403 A file's section header table lets one locate all the file's sections.
404 The section header table is an array of Elf32_Shdr or Elf64_Shdr struc‐
405 tures. The ELF header's e_shoff member gives the byte offset from the
406 beginning of the file to the section header table. e_shnum holds the
407 number of entries the section header table contains. e_shentsize holds
408 the size in bytes of each entry.
409
410 A section header table index is a subscript into this array. Some sec‐
411 tion header table indices are reserved. An object file does not have
412 sections for these special indices:
413
414 SHN_UNDEF This value marks an undefined, missing, irrelevant or oth‐
415 erwise meaningless section reference.
416
417 SHN_LORESERVE This value specifies the lower bound of the range of
418 reserved indices.
419
420 SHN_LOPROC Values greater than or equal to SHN_HIPROC are reserved
421 for processor-specific semantics.
422
423 SHN_HIPROC Values less than or equal to SHN_LOPROC are reserved for
424 processor-specific semantics.
425
426 SHN_ABS This value specifies the absolute value for the corre‐
427 sponding reference. For example, a symbol defined rela‐
428 tive to section number SHN_ABS has an absolute value and
429 is not affected by relocation.
430
431 SHN_COMMON Symbols defined relative to this section are common sym‐
432 bols, such as FORTRAN COMMON or unallocated C external
433 variables.
434
435 SHN_HIRESERVE This value specifies the upper bound of the range of
436 reserved indices. The system reserves indices between
437 SHN_LORESERVE and SHN_HIRESERVE, inclusive. The section
438 header table does not contain entries for the reserved
439 indices.
440
441 The section header has the following structure:
442
443 typedef struct {
444 uint32_t sh_name;
445 uint32_t sh_type;
446 uint32_t sh_flags;
447 Elf32_Addr sh_addr;
448 Elf32_Off sh_offset;
449 uint32_t sh_size;
450 uint32_t sh_link;
451 uint32_t sh_info;
452 uint32_t sh_addralign;
453 uint32_t sh_entsize;
454 } Elf32_Shdr;
455
456 typedef struct {
457 uint32_t sh_name;
458 uint32_t sh_type;
459 uint64_t sh_flags;
460 Elf64_Addr sh_addr;
461 Elf64_Off sh_offset;
462 uint64_t sh_size;
463 uint32_t sh_link;
464 uint32_t sh_info;
465 uint64_t sh_addralign;
466 uint64_t sh_entsize;
467 } Elf64_Shdr;
468
469 No real differences exist between the 32-bit and 64-bit section headers.
470
471 sh_name This member specifies the name of the section. Its
472 value is an index into the section header string ta‐
473 ble section, giving the location of a null-terminated
474 string.
475
476 sh_type This member categorizes the section's contents and
477 semantics.
478
479 SHT_NULL This value marks the section header as
480 inactive. It does not have an associ‐
481 ated section. Other members of the
482 section header have undefined values.
483
484 SHT_PROGBITS This section holds information defined
485 by the program, whose format and mean‐
486 ing are determined solely by the pro‐
487 gram.
488
489 SHT_SYMTAB This section holds a symbol table.
490 Typically, SHT_SYMTAB provides symbols
491 for link editing, though it may also be
492 used for dynamic linking. As a com‐
493 plete symbol table, it may contain many
494 symbols unnecessary for dynamic link‐
495 ing. An object file can also contain a
496 SHT_DYNSYM section.
497
498 SHT_STRTAB This section holds a string table. An
499 object file may have multiple string
500 table sections.
501
502 SHT_RELA This section holds relocation entries
503 with explicit addends, such as type
504 Elf32_Rela for the 32-bit class of
505 object files. An object may have mul‐
506 tiple relocation sections.
507
508 SHT_HASH This section holds a symbol hash table.
509 An object participating in dynamic
510 linking must contain a symbol hash ta‐
511 ble. An object file may have only one
512 hash table.
513
514 SHT_DYNAMIC This section holds information for
515 dynamic linking. An object file may
516 have only one dynamic section.
517
518 SHT_NOTE This section holds information that
519 marks the file in some way.
520
521 SHT_NOBITS A section of this type occupies no
522 space in the file but otherwise resem‐
523 bles SHT_PROGBITS. Although this sec‐
524 tion contains no bytes, the sh_offset
525 member contains the conceptual file
526 offset.
527
528 SHT_REL This section holds relocation offsets
529 without explicit addends, such as type
530 Elf32_Rel for the 32-bit class of
531 object files. An object file may have
532 multiple relocation sections.
533
534 SHT_SHLIB This section is reserved but has
535 unspecified semantics.
536
537 SHT_DYNSYM This section holds a minimal set of
538 dynamic linking symbols. An object
539 file can also contain a SHT_SYMTAB sec‐
540 tion.
541
542 SHT_LOPROC This value up to and including
543 SHT_HIPROC is reserved for processor-
544 specific semantics.
545
546 SHT_HIPROC This value down to and including
547 SHT_LOPROC is reserved for processor-
548 specific semantics.
549
550 SHT_LOUSER This value specifies the lower bound of
551 the range of indices reserved for
552 application programs.
553
554 SHT_HIUSER This value specifies the upper bound of
555 the range of indices reserved for
556 application programs. Section types
557 between SHT_LOUSER and SHT_HIUSER may
558 be used by the application, without
559 conflicting with current or future sys‐
560 tem-defined section types.
561
562 sh_flags Sections support one-bit flags that describe miscel‐
563 laneous attributes. If a flag bit is set in
564 sh_flags, the attribute is “on” for the section.
565 Otherwise, the attribute is “off” or does not apply.
566 Undefined attributes are set to zero.
567
568 SHF_WRITE This section contains data that should
569 be writable during process execution.
570 SHF_ALLOC This section occupies memory during
571 process execution. Some control sec‐
572 tions do not reside in the memory
573 image of an object file. This
574 attribute is off for those sections.
575 SHF_EXECINSTR This section contains executable
576 machine instructions.
577 SHF_MASKPROC All bits included in this mask are
578 reserved for processor-specific seman‐
579 tics.
580
581 sh_addr If this section appears in the memory image of a
582 process, this member holds the address at which the
583 section's first byte should reside. Otherwise, the
584 member contains zero.
585
586 sh_offset This member's value holds the byte offset from the
587 beginning of the file to the first byte in the sec‐
588 tion. One section type, SHT_NOBITS, occupies no
589 space in the file, and its sh_offset member locates
590 the conceptual placement in the file.
591
592 sh_size This member holds the section's size in bytes.
593 Unless the section type is SHT_NOBITS, the section
594 occupies sh_size bytes in the file. A section of
595 type SHT_NOBITS may have a non-zero size, but it
596 occupies no space in the file.
597
598 sh_link This member holds a section header table index link,
599 whose interpretation depends on the section type.
600
601 sh_info This member holds extra information, whose interpre‐
602 tation depends on the section type.
603
604 sh_addralign Some sections have address alignment constraints. If
605 a section holds a doubleword, the system must ensure
606 doubleword alignment for the entire section. That
607 is, the value of sh_addr must be congruent to zero,
608 modulo the value of sh_addralign. Only zero and pos‐
609 itive integral powers of two are allowed. Values of
610 zero or one mean the section has no alignment con‐
611 straints.
612
613 sh_entsize Some sections hold a table of fixed-sized entries,
614 such as a symbol table. For such a section, this
615 member gives the size in bytes for each entry. This
616 member contains zero if the section does not hold a
617 table of fixed-size entries.
618
619 Various sections hold program and control information:
620
621 .bss This section holds uninitialized data that contributes
622 to the program's memory image. By definition, the sys‐
623 tem initializes the data with zeros when the program
624 begins to run. This section is of type SHT_NOBITS. The
625 attribute types are SHF_ALLOC and SHF_WRITE.
626
627 .comment This section holds version control information. This
628 section is of type SHT_PROGBITS. No attribute types are
629 used.
630
631 .ctors This section holds initialized pointers to the C++ con‐
632 structor functions. This section is of type
633 SHT_PROGBITS. The attribute types are SHF_ALLOC and
634 SHF_WRITE.
635
636 .data This section holds initialized data that contribute to
637 the program's memory image. This section is of type
638 SHT_PROGBITS. The attribute types are SHF_ALLOC and
639 SHF_WRITE.
640
641 .data1 This section holds initialized data that contribute to
642 the program's memory image. This section is of type
643 SHT_PROGBITS. The attribute types are SHF_ALLOC and
644 SHF_WRITE.
645
646 .debug This section holds information for symbolic debugging.
647 The contents are unspecified. This section is of type
648 SHT_PROGBITS. No attribute types are used.
649
650 .dtors This section holds initialized pointers to the C++
651 destructor functions. This section is of type
652 SHT_PROGBITS. The attribute types are SHF_ALLOC and
653 SHF_WRITE.
654
655 .dynamic This section holds dynamic linking information. The
656 section's attributes will include the SHF_ALLOC bit.
657 Whether the SHF_WRITE bit is set is processor-specific.
658 This section is of type SHT_DYNAMIC. See the attributes
659 above.
660
661 .dynstr This section holds strings needed for dynamic linking,
662 most commonly the strings that represent the names asso‐
663 ciated with symbol table entries. This section is of
664 type SHT_STRTAB. The attribute type used is SHF_ALLOC.
665
666 .dynsym This section holds the dynamic linking symbol table.
667 This section is of type SHT_DYNSYM. The attribute used
668 is SHF_ALLOC.
669
670 .fini This section holds executable instructions that contrib‐
671 ute to the process termination code. When a program
672 exits normally the system arranges to execute the code
673 in this section. This section is of type SHT_PROGBITS.
674 The attributes used are SHF_ALLOC and SHF_EXECINSTR.
675
676 .got This section holds the global offset table. This sec‐
677 tion is of type SHT_PROGBITS. The attributes are pro‐
678 cessor-specific.
679
680 .hash This section holds a symbol hash table. This section is
681 of type SHT_HASH. The attribute used is SHF_ALLOC.
682
683 .init This section holds executable instructions that contrib‐
684 ute to the process initialization code. When a program
685 starts to run the system arranges to execute the code in
686 this section before calling the main program entry
687 point. This section is of type SHT_PROGBITS. The
688 attributes used are SHF_ALLOC and SHF_EXECINSTR.
689
690 .interp This section holds the pathname of a program inter‐
691 preter. If the file has a loadable segment that
692 includes the section, the section's attributes will
693 include the SHF_ALLOC bit. Otherwise, that bit will be
694 off. This section is of type SHT_PROGBITS.
695
696 .line This section holds line number information for symbolic
697 debugging, which describes the correspondence between
698 the program source and the machine code. The contents
699 are unspecified. This section is of type SHT_PROGBITS.
700 No attribute types are used.
701
702 .note This section holds information in the “Note Section”
703 format described below. This section is of type
704 SHT_NOTE. No attribute types are used. OpenBSD native
705 executables usually contain a .note.openbsd.ident sec‐
706 tion to identify themselves, for the kernel to bypass
707 any compatibility ELF binary emulation tests when load‐
708 ing the file.
709
710 .plt This section holds the procedure linkage table. This
711 section is of type SHT_PROGBITS. The attributes are
712 processor-specific.
713
714 .relNAME This section holds relocation information as described
715 below. If the file has a loadable segment that includes
716 relocation, the section's attributes will include the
717 SHF_ALLOC bit. Otherwise the bit will be off. By con‐
718 vention, “NAME” is supplied by the section to which the
719 relocations apply. Thus a relocation section for .text
720 normally would have the name .rel.text. This section is
721 of type SHT_REL.
722
723 .relaNAME This section holds relocation information as described
724 below. If the file has a loadable segment that includes
725 relocation, the section's attributes will include the
726 SHF_ALLOC bit. Otherwise the bit will be off. By con‐
727 vention, “NAME” is supplied by the section to which the
728 relocations apply. Thus a relocation section for .text
729 normally would have the name .rela.text. This section
730 is of type SHT_RELA.
731
732 .rodata This section holds read-only data that typically con‐
733 tributes to a non-writable segment in the process image.
734 This section is of type SHT_PROGBITS. The attribute
735 used is SHF_ALLOC.
736
737 .rodata1 This section holds read-only data that typically con‐
738 tributes to a non-writable segment in the process image.
739 This section is of type SHT_PROGBITS. The attribute
740 used is SHF_ALLOC.
741
742 .shstrtab This section holds section names. This section is of
743 type SHT_STRTAB. No attribute types are used.
744
745 .strtab This section holds strings, most commonly the strings
746 that represent the names associated with symbol table
747 entries. If the file has a loadable segment that
748 includes the symbol string table, the section's
749 attributes will include the SHF_ALLOC bit. Otherwise
750 the bit will be off. This section is of type
751 SHT_STRTAB.
752
753 .symtab This section holds a symbol table. If the file has a
754 loadable segment that includes the symbol table, the
755 section's attributes will include the SHF_ALLOC bit.
756 Otherwise the bit will be off. This section is of type
757 SHT_SYMTAB.
758
759 .text This section holds the “text”, or executable instruc‐
760 tions, of a program. This section is of type
761 SHT_PROGBITS. The attributes used are SHF_ALLOC and
762 SHF_EXECINSTR.
763
764 String table sections hold null-terminated character sequences, commonly
765 called strings. The object file uses these strings to represent symbol
766 and section names. One references a string as an index into the string
767 table section. The first byte, which is index zero, is defined to hold a
768 null byte ('\0'). Similarly, a string table's last byte is defined to
769 hold a null byte, ensuring null termination for all strings.
770
771 An object file's symbol table holds information needed to locate and
772 relocate a program's symbolic definitions and references. A symbol table
773 index is a subscript into this array.
774
775 typedef struct {
776 uint32_t st_name;
777 Elf32_Addr st_value;
778 uint32_t st_size;
779 unsigned char st_info;
780 unsigned char st_other;
781 uint16_t st_shndx;
782 } Elf32_Sym;
783
784 typedef struct {
785 uint32_t st_name;
786 unsigned char st_info;
787 unsigned char st_other;
788 uint16_t st_shndx;
789 Elf64_Addr st_value;
790 uint64_t st_size;
791 } Elf64_Sym;
792
793 The 32-bit and 64-bit versions have the same members, just in a different
794 order.
795
796 st_name This member holds an index into the object file's symbol
797 string table, which holds character representations of
798 the symbol names. If the value is non-zero, it repre‐
799 sents a string table index that gives the symbol name.
800 Otherwise, the symbol table has no name.
801
802 st_value This member gives the value of the associated symbol.
803
804 st_size Many symbols have associated sizes. This member holds
805 zero if the symbol has no size or an unknown size.
806
807 st_info This member specifies the symbol's type and binding
808 attributes:
809
810 STT_NOTYPE The symbol's type is not defined.
811
812 STT_OBJECT The symbol is associated with a data object.
813
814 STT_FUNC The symbol is associated with a function or
815 other executable code.
816
817 STT_SECTION The symbol is associated with a section.
818 Symbol table entries of this type exist pri‐
819 marily for relocation and normally have
820 STB_LOCAL bindings.
821
822 STT_FILE By convention, the symbol's name gives the
823 name of the source file associated with the
824 object file. A file symbol has STB_LOCAL
825 bindings, its section index is SHN_ABS, and
826 it precedes the other STB_LOCAL symbols of
827 the file, if it is present.
828
829 STT_LOPROC This value up to and including STT_HIPROC is
830 reserved for processor-specific semantics.
831
832 STT_HIPROC This value down to and including STT_LOPROC
833 is reserved for processor-specific seman‐
834 tics.
835
836 STB_LOCAL Local symbols are not visible outside the
837 object file containing their definition.
838 Local symbols of the same name may exist in
839 multiple files without interfering with each
840 other.
841
842 STB_GLOBAL Global symbols are visible to all object
843 files being combined. One file's definition
844 of a global symbol will satisfy another
845 file's undefined reference to the same sym‐
846 bol.
847
848 STB_WEAK Weak symbols resemble global symbols, but
849 their definitions have lower precedence.
850
851 STB_LOPROC This value up to and including STB_HIPROC is
852 reserved for processor-specific semantics.
853
854 STB_HIPROC This value down to and including STB_LOPROC
855 is reserved for processor-specific semantics.
856
857 There are macros for packing and unpacking
858 the binding and type fields:
859
860 ELF32_ST_BIND(info) or ELF64_ST_BIND(info)
861 extract a binding from an st_info value.
862
863 ELF32_ST_TYPE(info) or ELF64_ST_TYPE(info)
864 extract a type from an st_info value.
865
866 ELF32_ST_INFO(bind, type) or
867 ELF64_ST_INFO(bind, type)
868 convert a binding and a type into an st_info
869 value.
870
871 st_other This member currently holds zero and has no defined mean‐
872 ing.
873
874 st_shndx Every symbol table entry is “defined” in relation to some
875 section. This member holds the relevant section header
876 table index.
877
878 Relocation is the process of connecting symbolic references with symbolic
879 definitions. Relocatable files must have information that describes how
880 to modify their section contents, thus allowing executable and shared
881 object files to hold the right information for a process' program image.
882 Relocation entries are these data.
883
884 Relocation structures that do not need an addend:
885
886 typedef struct {
887 Elf32_Addr r_offset;
888 uint32_t r_info;
889 } Elf32_Rel;
890
891 typedef struct {
892 Elf64_Addr r_offset;
893 uint64_t r_info;
894 } Elf64_Rel;
895
896 Relocation structures that need an addend:
897
898 typedef struct {
899 Elf32_Addr r_offset;
900 uint32_t r_info;
901 int32_t r_addend;
902 } Elf32_Rela;
903
904 typedef struct {
905 Elf64_Addr r_offset;
906 uint64_t r_info;
907 int64_t r_addend;
908 } Elf64_Rela;
909
910 r_offset This member gives the location at which to apply the
911 relocation action. For a relocatable file, the value is
912 the byte offset from the beginning of the section to the
913 storage unit affected by the relocation. For an exe‐
914 cutable file or shared object, the value is the virtual
915 address of the storage unit affected by the relocation.
916
917 r_info This member gives both the symbol table index with
918 respect to which the relocation must be made and the type
919 of relocation to apply. Relocation types are processor-
920 specific. When the text refers to a relocation entry's
921 relocation type or symbol table index, it means the
922 result of applying ELF_[32|64]_R_TYPE or
923 ELF[32|64]_R_SYM, respectively, to the entry's r_info
924 member.
925
926 r_addend This member specifies a constant addend used to compute
927 the value to be stored into the relocatable field.
928
929 The .dynamic section contains a series of structures that hold relevant
930 dynamic linking information. The d_tag member controls the interpreta‐
931 tion of d_un.
932
933 typedef struct {
934 Elf32_Sword d_tag;
935 union {
936 Elf32_Word d_val;
937 Elf32_Addr d_ptr;
938 } d_un;
939 } Elf32_Dyn;
940 extern Elf32_Dyn _DYNAMIC[];
941
942 typedef struct {
943 Elf64_Sxword d_tag;
944 union {
945 Elf64_Xword d_val;
946 Elf64_Addr d_ptr;
947 } d_un;
948 } Elf64_Dyn;
949 extern Elf64_Dyn _DYNAMIC[];
950
951 d_tag This member may have any of the following values:
952
953 DT_NULL Marks end of dynamic section
954
955 DT_NEEDED String table offset to name of a needed library
956
957 DT_PLTRELSZ Size in bytes of PLT relocs
958
959 DT_PLTGOT Address of PLT and/or GOT
960
961 DT_HASH Address of symbol hash table
962
963 DT_STRTAB Address of string table
964
965 DT_SYMTAB Address of symbol table
966
967 DT_RELA Address of Rela relocs table
968
969 DT_RELASZ Size in bytes of Rela table
970
971 DT_RELAENT Size in bytes of a Rela table entry
972
973 DT_STRSZ Size in bytes of string table
974
975 DT_SYMENT Size in bytes of a symbol table entry
976
977 DT_INIT Address of the initialization function
978
979 DT_FINI Address of the termination function
980
981 DT_SONAME String table offset to name of shared object
982
983 DT_RPATH String table offset to library search path
984 (deprecated)
985
986 DT_SYMBOLIC Alert linker to search this shared object
987 before the executable for symbols
988
989 DT_REL Address of Rel relocs table
990
991 DT_RELSZ Size in bytes of Rel table
992
993 DT_RELENT Size in bytes of a Rel table entry
994
995 DT_PLTREL Type of reloc the PLT refers (Rela or Rel)
996
997 DT_DEBUG Undefined use for debugging
998
999 DT_TEXTREL Absence of this indicates no relocs should
1000 apply to a non-writable segment
1001
1002 DT_JMPREL Address of reloc entries solely for the PLT
1003
1004 DT_BIND_NOW Instruct dynamic linker to process all relocs
1005 before transferring control to the executable
1006
1007 DT_RUNPATH String table offset to library search path
1008
1009 DT_LOPROC Start of processor-specific semantics
1010
1011 DT_HIPROC End of processor-specific semantics
1012
1013 d_val This member represents integer values with various interpre‐
1014 tations.
1015
1016 d_ptr This member represents program virtual addresses. When
1017 interpreting these addresses, the actual address should be
1018 computed based on the original file value and memory base
1019 address. Files do not contain relocation entries to fixup
1020 these addresses.
1021
1022 _DYNAMIC
1023 Array containing all the dynamic structures in the .dynamic
1024 section. This is automatically populated by the linker.
1025
1027 as(1), gdb(1), ld(1), objdump(1), execve(2), core(5)
1028
1029 Hewlett-Packard, Elf-64 Object File Format.
1030
1031 Santa Cruz Operation, System V Application Binary Interface.
1032
1033 Unix System Laboratories, "Object Files", Executable and Linking Format
1034 (ELF).
1035
1037 OpenBSD ELF support first appeared in OpenBSD 1.2, although not all sup‐
1038 ported platforms use it as the native binary file format. ELF in itself
1039 first appeared in AT&T System V UNIX. The ELF format is an adopted stan‐
1040 dard.
1041
1043 The original version of this manual page was written by Jeroen Ruigrok
1044 van der Werven ⟨asmodai@FreeBSD.org⟩ with inspiration from BSDi's BSD/OS
1045 elf manpage.
1046
1047BSD July 31, 1999 BSD