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