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 objects.
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 Basic types
28 The following types are used for N-bit architectures (N=32,64, ElfN
29 stands for Elf32 or Elf64, uintN_t stands for uint32_t or uint64_t):
30 ElfN_Addr Unsigned program address, uintN_t
32 ElfN_Off Unsigned file offset, uintN_t
33 ElfN_Section Unsigned section index, uint16_t
34 ElfN_Versym Unsigned version symbol information, uint16_t
35 Elf_Byte unsigned char
36 ElfN_Half uint16_t
37 ElfN_Sword int32_t
38 ElfN_Word uint32_t
39 ElfN_Sxword int64_t
40 ElfN_Xword uint64_t
41 (Note: the *BSD terminology is a bit different. There, Elf64_Half is
43 twice as large as Elf32_Half, and Elf64Quarter is used for uint16_t.
44 In order to avoid confusion these types are replaced by explicit ones
45 in the below.)
46 All data structures that the file format defines follow the "natural"
48 size and alignment guidelines for the relevant class. If necessary,
49 data structures contain explicit padding to ensure 4-byte alignment for
50 4-byte objects, to force structure sizes to a multiple of 4, and so on.
51 ELF header (Ehdr)
53 The ELF header is described by the type Elf32_Ehdr or Elf64_Ehdr:
54 #define EI_NIDENT 16
56 typedef struct {
58 unsigned char e_ident[EI_NIDENT];
59 uint16_t e_type;
60 uint16_t e_machine;
61 uint32_t e_version;
62 ElfN_Addr e_entry;
63 ElfN_Off e_phoff;
64 ElfN_Off e_shoff;
65 uint32_t e_flags;
66 uint16_t e_ehsize;
67 uint16_t e_phentsize;
68 uint16_t e_phnum;
69 uint16_t e_shentsize;
70 uint16_t e_shnum;
71 uint16_t e_shstrndx;
72 } ElfN_Ehdr;
73 The fields have the following meanings:
75 e_ident This array of bytes specifies how to interpret the file,
77 independent of the processor or the file's remaining con‐
78 tents. Within this array everything is named by macros,
79 which start with the prefix EI_ and may contain values which
80 start with the prefix ELF. The following macros are defined:
81 EI_MAG0 The first byte of the magic number. It must be
83 filled with ELFMAG0. (0: 0x7f)
84 EI_MAG1 The second byte of the magic number. It must be
86 filled with ELFMAG1. (1: 'E')
87 EI_MAG2 The third byte of the magic number. It must be
89 filled with ELFMAG2. (2: 'L')
90 EI_MAG3 The fourth byte of the magic number. It must be
92 filled with ELFMAG3. (3: 'F')
93 EI_CLASS The fifth byte identifies the architecture for this
95 binary:
96 ELFCLASSNONE This class is invalid.
98 ELFCLASS32 This defines the 32-bit architecture.
99 It supports machines with files and
100 virtual address spaces up to 4 Giga‐
101 bytes.
102 ELFCLASS64 This defines the 64-bit architecture.
103 EI_DATA The sixth byte specifies the data encoding of the
105 processor-specific data in the file. Currently,
106 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
113 The seventh byte is the version number of the ELF
114 specification:
115 EV_NONE Invalid version.
117 EV_CURRENT Current version.
118 EI_OSABI The eighth byte identifies the operating system and
120 ABI to which the object is targeted. Some fields in
121 other ELF structures have flags and values that have
122 platform-specific meanings; the interpretation of
123 those fields is determined by the value of this
124 byte. For example:
125 ELFOSABI_NONE Same as ELFOSABI_SYSV
127 ELFOSABI_SYSV UNIX System V ABI
128 ELFOSABI_HPUX HP-UX ABI
129 ELFOSABI_NETBSD NetBSD ABI
130 ELFOSABI_LINUX Linux ABI
131 ELFOSABI_SOLARIS Solaris ABI
132 ELFOSABI_IRIX IRIX ABI
133 ELFOSABI_FREEBSD FreeBSD ABI
134 ELFOSABI_TRU64 TRU64 UNIX ABI
135 ELFOSABI_ARM ARM architecture ABI
136 ELFOSABI_STANDALONE Stand-alone (embedded) ABI
137 EI_ABIVERSION
139 The ninth byte identifies the version of the ABI to
140 which the object is targeted. This field is used to
141 distinguish among incompatible versions of an ABI.
142 The interpretation of this version number is depen‐
143 dent on the ABI identified by the EI_OSABI field.
144 Applications conforming to this specification use
145 the value 0.
146 EI_PAD Start of padding. These bytes are reserved and set
148 to zero. Programs which read them should ignore
149 them. The value for EI_PAD will change in the
150 future if currently unused bytes are given meanings.
151 EI_NIDENT
153 The size of the e_ident array.
154 e_type This member of the structure identifies the object file 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 indi‐
164 vidual file. For example:
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 SPARC with enhanced instruction set
176 EM_PPC PowerPC
177 EM_PPC64 PowerPC 64-bit
178 EM_S390 IBM S/390
179 EM_ARM Advanced RISC Machines
180 EM_SH Renesas SuperH
181 EM_SPARCV9 SPARC v9 64-bit
182 EM_IA_64 Intel Itanium
183 EM_X86_64 AMD x86-64
184 EM_VAX DEC Vax
185 e_version This member identifies the file version:
187 EV_NONE Invalid version
189 EV_CURRENT Current version
190 e_entry This member gives the virtual address to which the system
192 first transfers control, thus starting the process. If the
193 file has no associated entry point, this member holds zero.
194 e_phoff This member holds the program header table's file offset in
196 bytes. If the file has no program header table, this member
197 holds zero.
198 e_shoff This member holds the section header table's file offset in
200 bytes. If the file has no section header table, this member
201 holds zero.
202 e_flags This member holds processor-specific flags associated with
204 the file. Flag names take the form EF_`machine_flag'. Cur‐
205 rently, no flags have been defined.
206 e_ehsize This member holds the ELF header's size in bytes.
208 e_phentsize
210 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 header
214 table. Thus the product of e_phentsize and e_phnum gives the
215 table's size in bytes. If a file has no program header,
216 e_phnum holds the value zero.
217 If the number of entries in the program header table is
219 larger than or equal to PN_XNUM (0xffff), this member holds
220 PN_XNUM [22m(0xffff) and the real number of entries in the pro‐
221 gram header table is held in the sh_info member of the ini‐
222 tial entry in section header table. Otherwise, the sh_info
223 member of the initial entry contains the value zero.
224 PN_XNUM This is defined as 0xffff, the largest number
226 e_phnum can have, specifying where the actual number
227 of program headers is assigned.
228 e_shentsize
230 This member holds a sections header's size in bytes. A sec‐
231 tion header is one entry in the section header table; all
232 entries are the same size.
233 e_shnum This member holds the number of entries in the section header
235 table. Thus the product of e_shentsize and e_shnum gives the
236 section header table's size in bytes. If a file has no sec‐
237 tion header table, e_shnum holds the value of zero.
238 If the number of entries in the section header table is
240 larger than or equal to SHN_LORESERVE (0xff00), e_shnum holds
241 the value zero and the real number of entries in the section
242 header table is held in the sh_size member of the initial
243 entry in section header table. Otherwise, the sh_size member
244 of the initial entry in the section header table holds the
245 value zero.
246 e_shstrndx
248 This member holds the section header table index of the entry
249 associated with the section name string table. If the file
250 has no section name string table, this member holds the value
251 SHN_UNDEF.
252 If the index of section name string table section is larger
254 than or equal to SHN_LORESERVE (0xff00), this member holds
255 SHN_XINDEX (0xffff) and the real index of the section name
256 string table section is held in the sh_link member of the
257 initial entry in section header table. Otherwise, the
258 sh_link member of the initial entry in section header table
259 contains the value zero.
260 Program header (Phdr)
262 An executable or shared object file's program header table is an array
263 of structures, each describing a segment or other information the sys‐
264 tem needs to prepare the program for execution. An object file segment
265 contains one or more sections. Program headers are meaningful only for
266 executable and shared object files. A file specifies its own program
267 header size with the ELF header's e_phentsize and e_phnum members. The
268 ELF program header is described by the type Elf32_Phdr or Elf64_Phdr
269 depending on the architecture:
270 typedef struct {
272 uint32_t p_type;
273 Elf32_Off p_offset;
274 Elf32_Addr p_vaddr;
275 Elf32_Addr p_paddr;
276 uint32_t p_filesz;
277 uint32_t p_memsz;
278 uint32_t p_flags;
279 uint32_t p_align;
280 } Elf32_Phdr;
281 typedef struct {
283 uint32_t p_type;
284 uint32_t p_flags;
285 Elf64_Off p_offset;
286 Elf64_Addr p_vaddr;
287 Elf64_Addr p_paddr;
288 uint64_t p_filesz;
289 uint64_t p_memsz;
290 uint64_t p_align;
291 } Elf64_Phdr;
292 The main difference between the 32-bit and the 64-bit program header
294 lies in the location of the p_flags member in the total struct.
295 p_type This member of the structure indicates what kind of segment
297 this array element describes or how to interpret the array
298 element's information.
299 PT_NULL The array element is unused and the other mem‐
301 bers' values are undefined. This lets the pro‐
302 gram header have ignored entries.
303 PT_LOAD The array element specifies a loadable segment,
305 described by p_filesz and p_memsz. The bytes
306 from the file are mapped to the beginning of the
307 memory segment. If the segment's memory size
308 p_memsz is larger than the file size p_filesz,
309 the "extra" bytes are defined to hold the value 0
310 and to follow the segment's initialized area.
311 The file size may not be larger than the memory
312 size. Loadable segment entries in the program
313 header table appear in ascending order, sorted on
314 the p_vaddr member.
315 PT_DYNAMIC The array element specifies dynamic linking
317 information.
318 PT_INTERP The array element specifies the location and size
320 of a null-terminated pathname to invoke as an
321 interpreter. This segment type is meaningful
322 only for executable files (though it may occur
323 for shared objects). However it may not occur
324 more than once in a file. If it is present, it
325 must precede any loadable segment entry.
326 PT_NOTE The array element specifies the location of notes
328 (ElfN_Nhdr).
329 PT_SHLIB This segment type is reserved but has unspecified
331 semantics. Programs that contain an array ele‐
332 ment of this type do not conform to the ABI.
333 PT_PHDR The array element, if present, specifies the
335 location and size of the program header table
336 itself, both in the file and in the memory image
337 of the program. This segment type may not occur
338 more than once in a file. Moreover, it may occur
339 only if the program header table is part of the
340 memory image of the program. If it is present,
341 it must precede any loadable segment entry.
342 PT_LOPROC, PT_HIPROC
344 Values in the inclusive range [PT_LOPROC,
345 PT_HIPROC] are reserved for processor-specific
346 semantics.
347 PT_GNU_STACK
349 GNU extension which is used by the Linux kernel
350 to control the state of the stack via the flags
351 set in the p_flags member.
352 p_offset This member holds the offset from the beginning of the file
354 at which the first byte of the segment resides.
355 p_vaddr This member holds the virtual address at which the first byte
357 of the segment resides in memory.
358 p_paddr On systems for which physical addressing is relevant, this
360 member is reserved for the segment's physical address. Under
361 BSD this member is not used and must be zero.
362 p_filesz This member holds the number of bytes in the file image of
364 the segment. It may be zero.
365 p_memsz This member holds the number of bytes in the memory image of
367 the segment. It may be zero.
368 p_flags This member holds a bit mask of flags relevant to the seg‐
370 ment:
371 PF_X An executable segment.
373 PF_W A writable segment.
374 PF_R A readable segment.
375 A text segment commonly has the flags PF_X and PF_R. A data
377 segment commonly has PF_X, PF_W, and PF_R.
378 p_align This member holds the value to which the segments are aligned
380 in memory and in the file. Loadable process segments must
381 have congruent values for p_vaddr and p_offset, modulo the
382 page size. Values of zero and one mean no alignment is
383 required. Otherwise, p_align should be a positive, integral
384 power of two, and p_vaddr should equal p_offset, modulo
385 p_align.
386 Section header (Shdr)
388 A file's section header table lets one locate all the file's sections.
389 The section header table is an array of Elf32_Shdr or Elf64_Shdr struc‐
390 tures. The ELF header's e_shoff member gives the byte offset from the
391 beginning of the file to the section header table. e_shnum holds the
392 number of entries the section header table contains. e_shentsize holds
393 the size in bytes of each entry.
394 A section header table index is a subscript into this array. Some sec‐
396 tion header table indices are reserved: the initial entry and the
397 indices between SHN_LORESERVE and SHN_HIRESERVE. The initial entry is
398 used in ELF extensions for e_phnum, e_shnum and e_strndx; in other
399 cases, each field in the initial entry is set to zero. An object file
400 does not have sections for these special indices:
401 SHN_UNDEF
403 This value marks an undefined, missing, irrelevant, or otherwise
404 meaningless section reference.
405 SHN_LORESERVE
407 This value specifies the lower bound of the range of reserved
408 indices.
409 SHN_LOPROC, SHN_HIPROC
411 Values greater in the inclusive range [SHN_LOPROC, SHN_HIPROC]
412 are reserved for processor-specific semantics.
413 SHN_ABS
415 This value specifies the absolute value for the corresponding
416 reference. For example, a symbol defined relative to section
417 number SHN_ABS has an absolute value and is not affected by
418 relocation.
419 SHN_COMMON
421 Symbols defined relative to this section are common symbols,
422 such as FORTRAN COMMON or unallocated C external variables.
423 SHN_HIRESERVE
425 This value specifies the upper bound of the range of reserved
426 indices. The system reserves indices between SHN_LORESERVE and
427 SHN_HIRESERVE, inclusive. The section header table does not
428 contain entries for the reserved 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 notes (ElfN_Nhdr).
502 SHT_NOBITS A section of this type occupies no space in
504 the file but otherwise resembles SHT_PROGBITS.
505 Although this section contains no bytes, the
506 sh_offset member contains the conceptual file
507 offset.
508 SHT_REL This section holds relocation offsets without
510 explicit addends, such as type Elf32_Rel for
511 the 32-bit class of object files. An object
512 file may have multiple relocation sections.
513 SHT_SHLIB This section is reserved but has unspecified
515 semantics.
516 SHT_DYNSYM This section holds a minimal set of dynamic
518 linking symbols. An object file can also con‐
519 tain a SHT_SYMTAB section.
520 SHT_LOPROC, SHT_HIPROC
522 Values in the inclusive range [SHT_LOPROC,
523 SHT_HIPROC] are reserved for processor-spe‐
524 cific semantics.
525 SHT_LOUSER This value specifies the lower bound of the
527 range of indices reserved for application pro‐
528 grams.
529 SHT_HIUSER This value specifies the upper bound of the
531 range of indices reserved for application pro‐
532 grams. Section types between SHT_LOUSER and
533 SHT_HIUSER may be used by the application,
534 without conflicting with current or future
535 system-defined section types.
536 sh_flags Sections support one-bit flags that describe miscellaneous
538 attributes. If a flag bit is set in sh_flags, the attribute
539 is "on" for the section. Otherwise, the attribute is "off"
540 or does not apply. Undefined attributes are set to zero.
541 SHF_WRITE This section contains data that should be
543 writable during process execution.
544 SHF_ALLOC This section occupies memory during process
546 execution. Some control sections do not
547 reside in the memory image of an object file.
548 This attribute is off for those sections.
549 SHF_EXECINSTR This section contains executable machine
551 instructions.
552 SHF_MASKPROC All bits included in this mask are reserved
554 for processor-specific semantics.
555 sh_addr If this section appears in the memory image of a process,
557 this member holds the address at which the section's first
558 byte should reside. Otherwise, the member contains zero.
559 sh_offset This member's value holds the byte offset from the beginning
561 of the file to the first byte in the section. One section
562 type, SHT_NOBITS, occupies no space in the file, and its
563 sh_offset member locates the conceptual placement in the
564 file.
565 sh_size This member holds the section's size in bytes. Unless the
567 section type is SHT_NOBITS, the section occupies sh_size
568 bytes in the file. A section of type SHT_NOBITS may have a
569 nonzero size, but it occupies no space in the file.
570 sh_link This member holds a section header table index link, whose
572 interpretation depends on the section type.
573 sh_info This member holds extra information, whose interpretation
575 depends on the section type.
576 sh_addralign
578 Some sections have address alignment constraints. If a sec‐
579 tion holds a doubleword, the system must ensure doubleword
580 alignment for the entire section. That is, the value of
581 sh_addr must be congruent to zero, modulo the value of
582 sh_addralign. Only zero and positive integral powers of two
583 are allowed. The value 0 or 1 means that the section has no
584 alignment constraints.
585 sh_entsize
587 Some sections hold a table of fixed-sized entries, such as a
588 symbol table. For such a section, this member gives the size
589 in bytes for each entry. This member contains zero if the
590 section does not hold a table of fixed-size entries.
591 Various sections hold program and control information:
593 .bss This section holds uninitialized data that contributes to the
595 program's memory image. By definition, the system initial‐
596 izes the data with zeros when the program begins to run.
597 This section is of type SHT_NOBITS. The attribute types are
598 SHF_ALLOC and SHF_WRITE.
599 .comment This section holds version control information. This section
601 is of type SHT_PROGBITS. No attribute types are used.
602 .ctors This section holds initialized pointers to the C++ construc‐
604 tor functions. This section is of type SHT_PROGBITS. The
605 attribute types are SHF_ALLOC and SHF_WRITE.
606 .data This section holds initialized data that contribute to the
608 program's memory image. This section is of type SHT_PROG‐
609 BITS. The attribute types are SHF_ALLOC and SHF_WRITE.
610 .data1 This section holds initialized data that contribute to the
612 program's memory image. This section is of type SHT_PROG‐
613 BITS. The attribute types are SHF_ALLOC and SHF_WRITE.
614 .debug This section holds information for symbolic debugging. The
616 contents are unspecified. This section is of type SHT_PROG‐
617 BITS. No attribute types are used.
618 .dtors This section holds initialized pointers to the C++ destructor
620 functions. This section is of type SHT_PROGBITS. The
621 attribute types are SHF_ALLOC and SHF_WRITE.
622 .dynamic This section holds dynamic linking information. The sec‐
624 tion's attributes will include the SHF_ALLOC bit. Whether
625 the SHF_WRITE bit is set is processor-specific. This section
626 is of type SHT_DYNAMIC. See the attributes above.
627 .dynstr This section holds strings needed for dynamic linking, most
629 commonly the strings that represent the names associated with
630 symbol table entries. This section is of type SHT_STRTAB.
631 The attribute type used is SHF_ALLOC.
632 .dynsym This section holds the dynamic linking symbol table. This
634 section is of type SHT_DYNSYM. The attribute used is
635 SHF_ALLOC.
636 .fini This section holds executable instructions that contribute to
638 the process termination code. When a program exits normally
639 the system arranges to execute the code in this section.
640 This section is of type SHT_PROGBITS. The attributes used
641 are SHF_ALLOC and SHF_EXECINSTR.
642 .gnu.version
644 This section holds the version symbol table, an array of
645 ElfN_Half elements. This section is of type SHT_GNU_versym.
646 The attribute type used is SHF_ALLOC.
647 .gnu.version_d
649 This section holds the version symbol definitions, a table of
650 ElfN_Verdef structures. This section is of type
651 SHT_GNU_verdef. The attribute type used is SHF_ALLOC.
652 .gnu.version_r
654 This section holds the version symbol needed elements, a ta‐
655 ble of ElfN_Verneed structures. This section is of type
656 SHT_GNU_versym. The attribute type used is SHF_ALLOC.
657 .got This section holds the global offset table. This section is
659 of type SHT_PROGBITS. The attributes are processor-specific.
660 .hash This section holds a symbol hash table. This section is of
662 type SHT_HASH. The attribute used is SHF_ALLOC.
663 .init This section holds executable instructions that contribute to
665 the process initialization code. When a program starts to
666 run the system arranges to execute the code in this section
667 before calling the main program entry point. This section is
668 of type SHT_PROGBITS. The attributes used are SHF_ALLOC and
669 SHF_EXECINSTR.
670 .interp This section holds the pathname of a program interpreter. If
672 the file has a loadable segment that includes the section,
673 the section's attributes will include the SHF_ALLOC bit.
674 Otherwise, that bit will be off. This section is of type
675 SHT_PROGBITS.
676 .line This section holds line number information for symbolic
678 debugging, which describes the correspondence between the
679 program source and the machine code. The contents are
680 unspecified. This section is of type SHT_PROGBITS. No
681 attribute types are used.
682 .note This section holds various notes. This section is of type
684 SHT_NOTE. No attribute types are used.
685 .note.ABI-tag
687 This section is used to declare the expected runtime ABI of
688 the ELF image. It may include the operating system name and
689 its runtime versions. This section is of type SHT_NOTE. The
690 only attribute used is SHF_ALLOC.
691 .note.gnu.build-id
693 This section is used to hold an ID that uniquely identifies
694 the contents of the ELF image. Different files with the same
695 build ID should contain the same executable content. See the
696 --build-id option to the GNU linker (ld [22m(1)) for more
697 details. This section is of type SHT_NOTE. The only
698 attribute used is SHF_ALLOC.
699 .note.GNU-stack
701 This section is used in Linux object files for declaring
702 stack attributes. This section is of type SHT_PROGBITS. The
703 only attribute used is SHF_EXECINSTR. This indicates to the
704 GNU linker that the object file requires an executable stack.
705 .note.openbsd.ident
707 OpenBSD native executables usually contain this section to
708 identify themselves so the kernel can bypass any compatibil‐
709 ity ELF binary emulation tests when loading the file.
710 .plt This section holds the procedure linkage table. This section
712 is of type SHT_PROGBITS. The attributes are processor-spe‐
713 cific.
714 .relNAME This section holds relocation information as described below.
716 If the file has a loadable segment that includes relocation,
717 the section's attributes will include the SHF_ALLOC bit.
718 Otherwise, the bit will be off. By convention, "NAME" is
719 supplied by the section to which the relocations apply. Thus
720 a relocation section for .text normally would have the name
721 .rel.text. This section is of type SHT_REL.
722 .relaNAME This section holds relocation information as described below.
724 If the file has a loadable segment that includes relocation,
725 the section's attributes will include the SHF_ALLOC bit.
726 Otherwise, the bit will be off. By convention, "NAME" is
727 supplied by the section to which the relocations apply. Thus
728 a relocation section for .text normally would have the name
729 .rela.text. This section is of type SHT_RELA.
730 .rodata This section holds read-only data that typically contributes
732 to a nonwritable segment in the process image. This section
733 is of type SHT_PROGBITS. The attribute used is SHF_ALLOC.
734 .rodata1 This section holds read-only data that typically contributes
736 to a nonwritable segment in the process image. This section
737 is of type SHT_PROGBITS. The attribute used is SHF_ALLOC.
738 .shstrtab This section holds section names. This section is of type
740 SHT_STRTAB. No attribute types are used.
741 .strtab This section holds strings, most commonly the strings that
743 represent the names associated with symbol table entries. If
744 the file has a loadable segment that includes the symbol
745 string table, the section's attributes will include the
746 SHF_ALLOC bit. Otherwise, the bit will be off. This section
747 is of type SHT_STRTAB.
748 .symtab This section holds a symbol table. If the file has a load‐
750 able segment that includes the symbol table, the section's
751 attributes will include the SHF_ALLOC bit. Otherwise, the
752 bit will be off. This section is of type SHT_SYMTAB.
753 .text This section holds the "text", or executable instructions, of
755 a program. This section is of type SHT_PROGBITS. The
756 attributes used are SHF_ALLOC and SHF_EXECINSTR.
757 String and symbol tables
759 String table sections hold null-terminated character sequences, com‐
760 monly called strings. The object file uses these strings to represent
761 symbol and section names. One references a string as an index into the
762 string table section. The first byte, which is index zero, is defined
763 to hold a null byte ('\0'). Similarly, a string table's last byte is
764 defined to hold a null byte, ensuring null termination for all strings.
765 An object file's symbol table holds information needed to locate and
767 relocate a program's symbolic definitions and references. A symbol ta‐
768 ble index is a subscript into this array.
769 typedef struct {
771 uint32_t st_name;
772 Elf32_Addr st_value;
773 uint32_t st_size;
774 unsigned char st_info;
775 unsigned char st_other;
776 uint16_t st_shndx;
777 } Elf32_Sym;
778 typedef struct {
780 uint32_t st_name;
781 unsigned char st_info;
782 unsigned char st_other;
783 uint16_t st_shndx;
784 Elf64_Addr st_value;
785 uint64_t st_size;
786 } Elf64_Sym;
787 The 32-bit and 64-bit versions have the same members, just in a differ‐
789 ent order.
790 st_name This member holds an index into the object file's symbol
792 string table, which holds character representations of the
793 symbol names. If the value is nonzero, it represents a
794 string table index that gives the symbol name. Otherwise,
795 the symbol has no name.
796 st_value This member gives the value of the associated symbol.
798 st_size Many symbols have associated sizes. This member holds zero
800 if the symbol has no size or an unknown size.
801 st_info This member specifies the symbol's type and binding
803 attributes:
804 STT_NOTYPE The symbol's type is not defined.
806 STT_OBJECT The symbol is associated with a data object.
808 STT_FUNC The symbol is associated with a function or other
810 executable code.
811 STT_SECTION The symbol is associated with a section. Symbol
813 table entries of this type exist primarily for
814 relocation and normally have STB_LOCAL bindings.
815 STT_FILE By convention, the symbol's name gives the name
817 of the source file associated with the object
818 file. A file symbol has STB_LOCAL bindings, its
819 section index is SHN_ABS, and it precedes the
820 other STB_LOCAL symbols of the file, if it is
821 present.
822 STT_LOPROC, STT_HIPROC
824 Values in the inclusive range [STT_LOPROC,
825 STT_HIPROC] are reserved for processor-specific
826 semantics.
827 STB_LOCAL Local symbols are not visible outside the object
829 file containing their definition. Local symbols
830 of the same name may exist in multiple files
831 without interfering with each other.
832 STB_GLOBAL Global symbols are visible to all object files
834 being combined. One file's definition of a
835 global symbol will satisfy another file's unde‐
836 fined reference to the same symbol.
837 STB_WEAK Weak symbols resemble global symbols, but their
839 definitions have lower precedence.
840 STB_LOPROC, STB_HIPROC
842 Values in the inclusive range [STB_LOPROC,
843 STB_HIPROC] are reserved for processor-specific
844 semantics.
845 There are macros for packing and unpacking the binding and
847 type fields:
848 ELF32_ST_BIND(info), ELF64_ST_BIND(info)
850 Extract a binding from an st_info value.
851 ELF32_ST_TYPE(info), ELF64_ST_TYPE(info)
853 Extract a type from an st_info value.
854 ELF32_ST_INFO(bind, type), ELF64_ST_INFO(bind, type)
856 Convert a binding and a type into an st_info value.
857 st_other This member defines the symbol visibility.
859 STV_DEFAULT Default symbol visibility rules. Global and
861 weak symbols are available to other modules;
862 references in the local module can be inter‐
863 posed by definitions in other modules.
864 STV_INTERNAL Processor-specific hidden class.
865 STV_HIDDEN Symbol is unavailable to other modules; ref‐
866 erences in the local module always resolve to
867 the local symbol (i.e., the symbol can't be
868 interposed by definitions in other modules).
869 STV_PROTECTED Symbol is available to other modules, but
870 references in the local module always resolve
871 to the local symbol.
872 There are macros for extracting the visibility type:
874 ELF32_ST_VISIBILITY(other) or ELF64_ST_VISIBILITY(other)
876 st_shndx Every symbol table entry is "defined" in relation to some
878 section. This member holds the relevant section header table
879 index.
880 Relocation entries (Rel & Rela)
882 Relocation is the process of connecting symbolic references with sym‐
883 bolic definitions. Relocatable files must have information that
884 describes how to modify their section contents, thus allowing exe‐
885 cutable and shared object files to hold the right information for a
886 process's program image. Relocation entries are these data.
887 Relocation structures that do not need an addend:
889 typedef struct {
891 Elf32_Addr r_offset;
892 uint32_t r_info;
893 } Elf32_Rel;
894 typedef struct {
896 Elf64_Addr r_offset;
897 uint64_t r_info;
898 } Elf64_Rel;
899 Relocation structures that need an addend:
901 typedef struct {
903 Elf32_Addr r_offset;
904 uint32_t r_info;
905 int32_t r_addend;
906 } Elf32_Rela;
907 typedef struct {
909 Elf64_Addr r_offset;
910 uint64_t r_info;
911 int64_t r_addend;
912 } Elf64_Rela;
913 r_offset This member gives the location at which to apply the reloca‐
915 tion action. For a relocatable file, the value is the byte
916 offset from the beginning of the section to the storage unit
917 affected by the relocation. For an executable file or shared
918 object, the value is the virtual address of the storage unit
919 affected by the relocation.
920 r_info This member gives both the symbol table index with respect to
922 which the relocation must be made and the type of relocation
923 to apply. Relocation types are processor-specific. When the
924 text refers to a relocation entry's relocation type or symbol
925 table index, it means the result of applying
926 ELF[32|64]_R_TYPE or ELF[32|64]_R_SYM, respectively, to the
927 entry's r_info member.
928 r_addend This member specifies a constant addend used to compute the
930 value to be stored into the relocatable field.
931 Dynamic tags (Dyn)
933 The .dynamic section contains a series of structures that hold relevant
934 dynamic linking information. The d_tag member controls the interpreta‐
935 tion of d_un.
936 typedef struct {
938 Elf32_Sword d_tag;
939 union {
940 Elf32_Word d_val;
941 Elf32_Addr d_ptr;
942 } d_un;
943 } Elf32_Dyn;
944 extern Elf32_Dyn _DYNAMIC[];
945 typedef struct {
947 Elf64_Sxword d_tag;
948 union {
949 Elf64_Xword d_val;
950 Elf64_Addr d_ptr;
951 } d_un;
952 } Elf64_Dyn;
953 extern Elf64_Dyn _DYNAMIC[];
954 d_tag This member may have any of the following values:
956 DT_NULL Marks end of dynamic section
958 DT_NEEDED String table offset to name of a needed library
960 DT_PLTRELSZ Size in bytes of PLT relocation entries
962 DT_PLTGOT Address of PLT and/or GOT
964 DT_HASH Address of symbol hash table
966 DT_STRTAB Address of string table
968 DT_SYMTAB Address of symbol table
970 DT_RELA Address of Rela relocation table
972 DT_RELASZ Size in bytes of the Rela relocation table
974 DT_RELAENT Size in bytes of a Rela relocation table entry
976 DT_STRSZ Size in bytes of string table
978 DT_SYMENT Size in bytes of a symbol table entry
980 DT_INIT Address of the initialization function
982 DT_FINI Address of the termination function
984 DT_SONAME String table offset to name of shared object
986 DT_RPATH String table offset to library search path (dep‐
988 recated)
989 DT_SYMBOLIC Alert linker to search this shared object before
991 the executable for symbols
992 DT_REL Address of Rel relocation table
994 DT_RELSZ Size in bytes of Rel relocation table
996 DT_RELENT Size in bytes of a Rel table entry
998 DT_PLTREL Type of relocation entry to which the PLT refers
1000 (Rela or Rel)
1001 DT_DEBUG Undefined use for debugging
1003 DT_TEXTREL Absence of this entry indicates that no reloca‐
1005 tion entries should apply to a nonwritable seg‐
1006 ment
1007 DT_JMPREL Address of relocation entries associated solely
1009 with the PLT
1010 DT_BIND_NOW Instruct dynamic linker to process all reloca‐
1012 tions before transferring control to the exe‐
1013 cutable
1014 DT_RUNPATH String table offset to library search path
1016 DT_LOPROC, DT_HIPROC
1018 Values in the inclusive range [DT_LOPROC,
1019 DT_HIPROC] are reserved for processor-specific
1020 semantics
1021 d_val This member represents integer values with various interpre‐
1023 tations.
1024 d_ptr This member represents program virtual addresses. When
1026 interpreting these addresses, the actual address should be
1027 computed based on the original file value and memory base
1028 address. Files do not contain relocation entries to fixup
1029 these addresses.
1030 _DYNAMIC Array containing all the dynamic structures in the .dynamic
1032 section. This is automatically populated by the linker.
1033 Notes (Nhdr)
1035 ELF notes allow for appending arbitrary information for the system to
1036 use. They are largely used by core files (e_type of ET_CORE), but many
1037 projects define their own set of extensions. For example, the GNU tool
1038 chain uses ELF notes to pass information from the linker to the C
1039 library.
1040 Note sections contain a series of notes (see the struct definitions
1042 below). Each note is followed by the name field (whose length is
1043 defined in n_namesz) and then by the descriptor field (whose length is
1044 defined in n_descsz) and whose starting address has a 4 byte alignment.
1045 Neither field is defined in the note struct due to their arbitrary
1046 lengths.
1047 An example for parsing out two consecutive notes should clarify their
1049 layout in memory:
1050 void *memory, *name, *desc;
1052 Elf64_Nhdr *note, *next_note;
1053 /* The buffer is pointing to the start of the section/segment */
1055 note = memory;
1056 /* If the name is defined, it follows the note */
1058 name = note->n_namesz == 0 ? NULL : memory + sizeof(*note);
1059 /* If the descriptor is defined, it follows the name
1061 (with alignment) */
1062 desc = note->n_descsz == 0 ? NULL :
1064 memory + sizeof(*note) + ALIGN_UP(note->n_namesz, 4);
1065 /* The next note follows both (with alignment) */
1067 next_note = memory + sizeof(*note) +
1068 ALIGN_UP(note->n_namesz, 4) +
1069 ALIGN_UP(note->n_descsz, 4);
1070 Keep in mind that the interpretation of n_type depends on the namespace
1072 defined by the n_namesz field. If the n_namesz field is not set (e.g.,
1073 is 0), then there are two sets of notes: one for core files and one for
1074 all other ELF types. If the namespace is unknown, then tools will usu‐
1075 ally fallback to these sets of notes as well.
1076 typedef struct {
1078 Elf32_Word n_namesz;
1079 Elf32_Word n_descsz;
1080 Elf32_Word n_type;
1081 } Elf32_Nhdr;
1082 typedef struct {
1084 Elf64_Word n_namesz;
1085 Elf64_Word n_descsz;
1086 Elf64_Word n_type;
1087 } Elf64_Nhdr;
1088 n_namesz The length of the name field in bytes. The contents will
1090 immediately follow this note in memory. The name is null
1091 terminated. For example, if the name is "GNU", then n_namesz
1092 will be set to 4.
1093 n_descsz The length of the descriptor field in bytes. The contents
1095 will immediately follow the name field in memory.
1096 n_type Depending on the value of the name field, this member may
1098 have any of the following values:
1099 Core files (e_type = ET_CORE)
1101 Notes used by all core files. These are highly operat‐
1102 ing system or architecture specific and often require
1103 close coordination with kernels, C libraries, and debug‐
1104 gers. These are used when the namespace is the default
1105 (i.e., n_namesz will be set to 0), or a fallback when
1106 the namespace is unknown.
1107 NT_PRSTATUS prstatus struct
1109 NT_FPREGSET fpregset struct
1110 NT_PRPSINFO prpsinfo struct
1111 NT_PRXREG prxregset struct
1112 NT_TASKSTRUCT task structure
1113 NT_PLATFORM String from sysinfo(SI_PLATFORM)
1114 NT_AUXV auxv array
1115 NT_GWINDOWS gwindows struct
1116 NT_ASRS asrset struct
1117 NT_PSTATUS pstatus struct
1118 NT_PSINFO psinfo struct
1119 NT_PRCRED prcred struct
1120 NT_UTSNAME utsname struct
1121 NT_LWPSTATUS lwpstatus struct
1122 NT_LWPSINFO lwpinfo struct
1123 NT_PRFPXREG fprxregset struct
1124 NT_SIGINFO siginfo_t (size might increase over
1125 time)
1126 NT_FILE Contains information about mapped
1127 files
1128 NT_PRXFPREG user_fxsr_struct
1129 NT_PPC_VMX PowerPC Altivec/VMX registers
1130 NT_PPC_SPE PowerPC SPE/EVR registers
1131 NT_PPC_VSX PowerPC VSX registers
1132 NT_386_TLS i386 TLS slots (struct user_desc)
1133 NT_386_IOPERM x86 io permission bitmap (1=deny)
1134 NT_X86_XSTATE x86 extended state using xsave
1135 NT_S390_HIGH_GPRS s390 upper register halves
1136 NT_S390_TIMER s390 timer register
1137 NT_S390_TODCMP s390 time-of-day (TOD) clock com‐
1138 parator register
1139 NT_S390_TODPREG s390 time-of-day (TOD) programmable
1140 register
1141 NT_S390_CTRS s390 control registers
1142 NT_S390_PREFIX s390 prefix register
1143 NT_S390_LAST_BREAK s390 breaking event address
1144 NT_S390_SYSTEM_CALL s390 system call restart data
1145 NT_S390_TDB s390 transaction diagnostic block
1146 NT_ARM_VFP ARM VFP/NEON registers
1147 NT_ARM_TLS ARM TLS register
1148 NT_ARM_HW_BREAK ARM hardware breakpoint registers
1149 NT_ARM_HW_WATCH ARM hardware watchpoint registers
1150 NT_ARM_SYSTEM_CALL ARM system call number
1151 n_name = GNU
1153 Extensions used by the GNU tool chain.
1154 NT_GNU_ABI_TAG
1156 Operating system (OS) ABI information. The desc
1157 field will be 4 words:
1158 · word 0: OS descriptor (ELF_NOTE_OS_LINUX,
1160 ELF_NOTE_OS_GNU, and so on)`
1161 · word 1: major version of the ABI
1162 · word 2: minor version of the ABI
1163 · word 3: subminor version of the ABI
1164 NT_GNU_HWCAP
1166 Synthetic hwcap information. The desc field
1167 begins with two words:
1168 · word 0: number of entries
1170 · word 1: bit mask of enabled entries
1171 Then follow variable-length entries, one byte
1173 followed by a null-terminated hwcap name string.
1174 The byte gives the bit number to test if enabled,
1175 (1U << bit) & bit mask.
1176 NT_GNU_BUILD_ID
1178 Unique build ID as generated by the GNU ld(1)
1179 --build-id option. The desc consists of any
1180 nonzero number of bytes.
1181 NT_GNU_GOLD_VERSION
1183 The desc contains the GNU Gold linker version
1184 used.
1185 Default/unknown namespace (e_type != ET_CORE)
1187 These are used when the namespace is the default (i.e.,
1188 n_namesz will be set to 0), or a fallback when the
1189 namespace is unknown.
1190 NT_VERSION A version string of some sort.
1192 NT_ARCH Architecture information.
1193
1195 ELF first appeared in System V. The ELF format is an adopted standard.
1196 The extensions for e_phnum, e_shnum and e_strndx respectively are Linux
1198 extensions. Sun, BSD and AMD64 also support them; for further informa‐
1199 tion, look under SEE ALSO.
1200
1202 as(1), elfedit(1), gdb(1), ld(1), nm(1), objdump(1), readelf(1),
1203 size(1), strings(1), strip(1), execve(2), dl_iterate_phdr(3), core(5)
1204 Hewlett-Packard, Elf-64 Object File Format.
1206 Santa Cruz Operation, System V Application Binary Interface.
1208 UNIX System Laboratories, "Object Files", Executable and Linking Format
1210 (ELF).
1211 Sun Microsystems, Linker and Libraries Guide.
1213 AMD64 ABI Draft, System V Application Binary Interface AMD64 Architec‐
1215 ture Processor Supplement.
1216
1218 This page is part of release 4.15 of the Linux man-pages project. A
1219 description of the project, information about reporting bugs, and the
1220 latest version of this page, can be found at
1221 https://www.kernel.org/doc/man-pages/.
1222Linux 2017-09-15 ELF(5)