1ELF(5) File Formats 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 de‐
20 fined in the ELF header. The two tables describe the rest of the par‐
21 ticularities 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
77 This array of bytes specifies how to interpret the file, inde‐
78 pendent of the processor or the file's remaining contents.
79 Within this array everything is named by macros, which start
80 with the prefix EI_ and may contain values which start with the
81 prefix ELF. The following macros are defined:
82 EI_MAG0
84 The first byte of the magic number. It must be filled
85 with ELFMAG0. (0: 0x7f)
86 EI_MAG1
88 The second byte of the magic number. It must be filled
89 with ELFMAG1. (1: 'E')
90 EI_MAG2
92 The third byte of the magic number. It must be filled
93 with ELFMAG2. (2: 'L')
94 EI_MAG3
96 The fourth byte of the magic number. It must be filled
97 with ELFMAG3. (3: 'F')
98 EI_CLASS
100 The fifth byte identifies the architecture for this bi‐
101 nary:
102 ELFCLASSNONE This class is invalid.
104 ELFCLASS32 This defines the 32-bit architecture. It
105 supports machines with files and virtual
106 address spaces up to 4 Gigabytes.
107 ELFCLASS64 This defines the 64-bit architecture.
108 EI_DATA
110 The sixth byte specifies the data encoding of the proces‐
111 sor-specific data in the file. Currently, these encod‐
112 ings are supported:
113 ELFDATANONE Unknown data format.
115 ELFDATA2LSB Two's complement, little-endian.
116 ELFDATA2MSB Two's complement, big-endian.
117 EI_VERSION
119 The seventh byte is the version number of the ELF speci‐
120 fication:
121 EV_NONE Invalid version.
123 EV_CURRENT Current version.
124 EI_OSABI
126 The eighth byte identifies the operating system and ABI
127 to which the object is targeted. Some fields in other
128 ELF structures have flags and values that have platform-
129 specific meanings; the interpretation of those fields is
130 determined by the value of this byte. For example:
131 ELFOSABI_NONE Same as ELFOSABI_SYSV
133 ELFOSABI_SYSV UNIX System V ABI
134 ELFOSABI_HPUX HP-UX ABI
135 ELFOSABI_NETBSD NetBSD ABI
136 ELFOSABI_LINUX Linux ABI
137 ELFOSABI_SOLARIS Solaris ABI
138 ELFOSABI_IRIX IRIX ABI
139 ELFOSABI_FREEBSD FreeBSD ABI
140 ELFOSABI_TRU64 TRU64 UNIX ABI
141 ELFOSABI_ARM ARM architecture ABI
142 ELFOSABI_STANDALONE Stand-alone (embedded) ABI
143 EI_ABIVERSION
145 The ninth byte identifies the version of the ABI to which
146 the object is targeted. This field is used to distin‐
147 guish among incompatible versions of an ABI. The inter‐
148 pretation of this version number is dependent on the ABI
149 identified by the EI_OSABI field. Applications conform‐
150 ing to this specification use the value 0.
151 EI_PAD Start of padding. These bytes are reserved and set to
153 zero. Programs which read them should ignore them. The
154 value for EI_PAD will change in the future if currently
155 unused bytes are given meanings.
156 EI_NIDENT
158 The size of the e_ident array.
159 e_type This member of the structure identifies the object file type:
161 ET_NONE An unknown type.
163 ET_REL A relocatable file.
164 ET_EXEC An executable file.
165 ET_DYN A shared object.
166 ET_CORE A core file.
167 e_machine
169 This member specifies the required architecture for an individ‐
170 ual file. For example:
171 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 e_version
193 This member identifies the file version:
194 EV_NONE Invalid version
196 EV_CURRENT Current version
197 e_entry
199 This member gives the virtual address to which the system first
200 transfers control, thus starting the process. If the file has
201 no associated entry point, this member holds zero.
202 e_phoff
204 This member holds the program header table's file offset in
205 bytes. If the file has no program header table, this member
206 holds zero.
207 e_shoff
209 This member holds the section header table's file offset in
210 bytes. If the file has no section header table, this member
211 holds zero.
212 e_flags
214 This member holds processor-specific flags associated with the
215 file. Flag names take the form EF_`machine_flag'. Currently,
216 no flags have been defined.
217 e_ehsize
219 This member holds the ELF header's size in bytes.
220 e_phentsize
222 This member holds the size in bytes of one entry in the file's
223 program header table; all entries are the same size.
224 e_phnum
226 This member holds the number of entries in the program header
227 table. Thus the product of e_phentsize and e_phnum gives the
228 table's size in bytes. If a file has no program header, e_phnum
229 holds the value zero.
230 If the number of entries in the program header table is larger
232 than or equal to PN_XNUM (0xffff), this member holds PN_XNUM
233 (0xffff) and the real number of entries in the program header
234 table is held in the sh_info member of the initial entry in sec‐
235 tion header table. Otherwise, the sh_info member of the initial
236 entry contains the value zero.
237 PN_XNUM
239 This is defined as 0xffff, the largest number e_phnum can
240 have, specifying where the actual number of program head‐
241 ers is assigned.
242 e_shentsize
244 This member holds a sections header's size in bytes. A section
245 header is one entry in the section header table; all entries are
246 the same size.
247 e_shnum
249 This member holds the number of entries in the section header
250 table. Thus the product of e_shentsize and e_shnum gives the
251 section header table's size in bytes. If a file has no section
252 header table, e_shnum holds the value of zero.
253 If the number of entries in the section header table is larger
255 than or equal to SHN_LORESERVE (0xff00), e_shnum holds the value
256 zero and the real number of entries in the section header table
257 is held in the sh_size member of the initial entry in section
258 header table. Otherwise, the sh_size member of the initial en‐
259 try in the section header table holds the value zero.
260 e_shstrndx
262 This member holds the section header table index of the entry
263 associated with the section name string table. If the file has
264 no section name string table, this member holds the value
265 SHN_UNDEF.
266 If the index of section name string table section is larger than
268 or equal to SHN_LORESERVE (0xff00), this member holds SHN_XINDEX
269 (0xffff) and the real index of the section name string table
270 section is held in the sh_link member of the initial entry in
271 section header table. Otherwise, the sh_link member of the ini‐
272 tial entry in section header table contains the value zero.
273 Program header (Phdr)
275 An executable or shared object file's program header table is an array
276 of structures, each describing a segment or other information the sys‐
277 tem needs to prepare the program for execution. An object file segment
278 contains one or more sections. Program headers are meaningful only for
279 executable and shared object files. A file specifies its own program
280 header size with the ELF header's e_phentsize and e_phnum members. The
281 ELF program header is described by the type Elf32_Phdr or Elf64_Phdr
282 depending on the architecture:
283 typedef struct {
285 uint32_t p_type;
286 Elf32_Off p_offset;
287 Elf32_Addr p_vaddr;
288 Elf32_Addr p_paddr;
289 uint32_t p_filesz;
290 uint32_t p_memsz;
291 uint32_t p_flags;
292 uint32_t p_align;
293 } Elf32_Phdr;
294 typedef struct {
296 uint32_t p_type;
297 uint32_t p_flags;
298 Elf64_Off p_offset;
299 Elf64_Addr p_vaddr;
300 Elf64_Addr p_paddr;
301 uint64_t p_filesz;
302 uint64_t p_memsz;
303 uint64_t p_align;
304 } Elf64_Phdr;
305 The main difference between the 32-bit and the 64-bit program header
307 lies in the location of the p_flags member in the total struct.
308 p_type This member of the structure indicates what kind of segment this
310 array element describes or how to interpret the array element's
311 information.
312 PT_NULL
314 The array element is unused and the other members'
315 values are undefined. This lets the program header
316 have ignored entries.
317 PT_LOAD
319 The array element specifies a loadable segment, de‐
320 scribed by p_filesz and p_memsz. The bytes from the
321 file are mapped to the beginning of the memory seg‐
322 ment. If the segment's memory size p_memsz is larger
323 than the file size p_filesz, the "extra" bytes are de‐
324 fined to hold the value 0 and to follow the segment's
325 initialized area. The file size may not be larger
326 than the memory size. Loadable segment entries in the
327 program header table appear in ascending order, sorted
328 on the p_vaddr member.
329 PT_DYNAMIC
331 The array element specifies dynamic linking informa‐
332 tion.
333 PT_INTERP
335 The array element specifies the location and size of a
336 null-terminated pathname to invoke as an interpreter.
337 This segment type is meaningful only for executable
338 files (though it may occur for shared objects). How‐
339 ever it may not occur more than once in a file. If it
340 is present, it must precede any loadable segment en‐
341 try.
342 PT_NOTE
344 The array element specifies the location of notes
345 (ElfN_Nhdr).
346 PT_SHLIB
348 This segment type is reserved but has unspecified se‐
349 mantics. Programs that contain an array element of
350 this type do not conform to the ABI.
351 PT_PHDR
353 The array element, if present, specifies the location
354 and size of the program header table itself, both in
355 the file and in the memory image of the program. This
356 segment type may not occur more than once in a file.
357 Moreover, it may occur only if the program header ta‐
358 ble is part of the memory image of the program. If it
359 is present, it must precede any loadable segment en‐
360 try.
361 PT_LOPROC, PT_HIPROC
363 Values in the inclusive range [PT_LOPROC, PT_HIPROC]
364 are reserved for processor-specific semantics.
365 PT_GNU_STACK
367 GNU extension which is used by the Linux kernel to
368 control the state of the stack via the flags set in
369 the p_flags member.
370 p_offset
372 This member holds the offset from the beginning of the file at
373 which the first byte of the segment resides.
374 p_vaddr
376 This member holds the virtual address at which the first byte of
377 the segment resides in memory.
378 p_paddr
380 On systems for which physical addressing is relevant, this mem‐
381 ber is reserved for the segment's physical address. Under BSD
382 this member is not used and must be zero.
383 p_filesz
385 This member holds the number of bytes in the file image of the
386 segment. It may be zero.
387 p_memsz
389 This member holds the number of bytes in the memory image of the
390 segment. It may be zero.
391 p_flags
393 This member holds a bit mask of flags relevant to the segment:
394 PF_X An executable segment.
396 PF_W A writable segment.
397 PF_R A readable segment.
398 A text segment commonly has the flags PF_X and PF_R . A data
400 segment commonly has PF_W and PF_R.
401 p_align
403 This member holds the value to which the segments are aligned in
404 memory and in the file. Loadable process segments must have
405 congruent values for p_vaddr and p_offset, modulo the page size.
406 Values of zero and one mean no alignment is required. Other‐
407 wise, p_align should be a positive, integral power of two, and
408 p_vaddr should equal p_offset, modulo p_align.
409 Section header (Shdr)
411 A file's section header table lets one locate all the file's sections.
412 The section header table is an array of Elf32_Shdr or Elf64_Shdr struc‐
413 tures. The ELF header's e_shoff member gives the byte offset from the
414 beginning of the file to the section header table. e_shnum holds the
415 number of entries the section header table contains. e_shentsize holds
416 the size in bytes of each entry.
417 A section header table index is a subscript into this array. Some sec‐
419 tion header table indices are reserved: the initial entry and the in‐
420 dices between SHN_LORESERVE and SHN_HIRESERVE. The initial entry is
421 used in ELF extensions for e_phnum, e_shnum, and e_shstrndx; in other
422 cases, each field in the initial entry is set to zero. An object file
423 does not have sections for these special indices:
424 SHN_UNDEF
426 This value marks an undefined, missing, irrelevant, or otherwise
427 meaningless section reference.
428 SHN_LORESERVE
430 This value specifies the lower bound of the range of reserved
431 indices.
432 SHN_LOPROC, SHN_HIPROC
434 Values greater in the inclusive range [SHN_LOPROC, SHN_HIPROC]
435 are reserved for processor-specific semantics.
436 SHN_ABS
438 This value specifies the absolute value for the corresponding
439 reference. For example, a symbol defined relative to section
440 number SHN_ABS has an absolute value and is not affected by re‐
441 location.
442 SHN_COMMON
444 Symbols defined relative to this section are common symbols,
445 such as FORTRAN COMMON or unallocated C external variables.
446 SHN_HIRESERVE
448 This value specifies the upper bound of the range of reserved
449 indices. The system reserves indices between SHN_LORESERVE and
450 SHN_HIRESERVE, inclusive. The section header table does not
451 contain entries for the reserved indices.
452 The section header has the following structure:
454 typedef struct {
456 uint32_t sh_name;
457 uint32_t sh_type;
458 uint32_t sh_flags;
459 Elf32_Addr sh_addr;
460 Elf32_Off sh_offset;
461 uint32_t sh_size;
462 uint32_t sh_link;
463 uint32_t sh_info;
464 uint32_t sh_addralign;
465 uint32_t sh_entsize;
466 } Elf32_Shdr;
467 typedef struct {
469 uint32_t sh_name;
470 uint32_t sh_type;
471 uint64_t sh_flags;
472 Elf64_Addr sh_addr;
473 Elf64_Off sh_offset;
474 uint64_t sh_size;
475 uint32_t sh_link;
476 uint32_t sh_info;
477 uint64_t sh_addralign;
478 uint64_t sh_entsize;
479 } Elf64_Shdr;
480 No real differences exist between the 32-bit and 64-bit section head‐
482 ers.
483 sh_name
485 This member specifies the name of the section. Its value is an
486 index into the section header string table section, giving the
487 location of a null-terminated string.
488 sh_type
490 This member categorizes the section's contents and semantics.
491 SHT_NULL
493 This value marks the section header as inactive. It does
494 not have an associated section. Other members of the
495 section header have undefined values.
496 SHT_PROGBITS
498 This section holds information defined by the program,
499 whose format and meaning are determined solely by the
500 program.
501 SHT_SYMTAB
503 This section holds a symbol table. Typically, SHT_SYMTAB
504 provides symbols for link editing, though it may also be
505 used for dynamic linking. As a complete symbol table, it
506 may contain many symbols unnecessary for dynamic linking.
507 An object file can also contain a SHT_DYNSYM section.
508 SHT_STRTAB
510 This section holds a string table. An object file may
511 have multiple string table sections.
512 SHT_RELA
514 This section holds relocation entries with explicit ad‐
515 dends, such as type Elf32_Rela for the 32-bit class of
516 object files. An object may have multiple relocation
517 sections.
518 SHT_HASH
520 This section holds a symbol hash table. An object par‐
521 ticipating in dynamic linking must contain a symbol hash
522 table. An object file may have only one hash table.
523 SHT_DYNAMIC
525 This section holds information for dynamic linking. An
526 object file may have only one dynamic section.
527 SHT_NOTE
529 This section holds notes (ElfN_Nhdr).
530 SHT_NOBITS
532 A section of this type occupies no space in the file but
533 otherwise resembles SHT_PROGBITS. Although this section
534 contains no bytes, the sh_offset member contains the con‐
535 ceptual file offset.
536 SHT_REL
538 This section holds relocation offsets without explicit
539 addends, such as type Elf32_Rel for the 32-bit class of
540 object files. An object file may have multiple reloca‐
541 tion sections.
542 SHT_SHLIB
544 This section is reserved but has unspecified semantics.
545 SHT_DYNSYM
547 This section holds a minimal set of dynamic linking sym‐
548 bols. An object file can also contain a SHT_SYMTAB sec‐
549 tion.
550 SHT_LOPROC, SHT_HIPROC
552 Values in the inclusive range [SHT_LOPROC, SHT_HIPROC]
553 are reserved for processor-specific semantics.
554 SHT_LOUSER
556 This value specifies the lower bound of the range of in‐
557 dices reserved for application programs.
558 SHT_HIUSER
560 This value specifies the upper bound of the range of in‐
561 dices reserved for application programs. Section types
562 between SHT_LOUSER and SHT_HIUSER may be used by the ap‐
563 plication, without conflicting with current or future
564 system-defined section types.
565 sh_flags
567 Sections support one-bit flags that describe miscellaneous at‐
568 tributes. If a flag bit is set in sh_flags, the attribute is
569 "on" for the section. Otherwise, the attribute is "off" or does
570 not apply. Undefined attributes are set to zero.
571 SHF_WRITE
573 This section contains data that should be writable during
574 process execution.
575 SHF_ALLOC
577 This section occupies memory during process execution.
578 Some control sections do not reside in the memory image
579 of an object file. This attribute is off for those sec‐
580 tions.
581 SHF_EXECINSTR
583 This section contains executable machine instructions.
584 SHF_MASKPROC
586 All bits included in this mask are reserved for proces‐
587 sor-specific semantics.
588 sh_addr
590 If this section appears in the memory image of a process, this
591 member holds the address at which the section's first byte
592 should reside. Otherwise, the member contains zero.
593 sh_offset
595 This member's value holds the byte offset from the beginning of
596 the file to the first byte in the section. One section type,
597 SHT_NOBITS, occupies no space in the file, and its sh_offset
598 member locates the conceptual placement in the file.
599 sh_size
601 This member holds the section's size in bytes. Unless the sec‐
602 tion type is SHT_NOBITS, the section occupies sh_size bytes in
603 the file. A section of type SHT_NOBITS may have a nonzero size,
604 but it occupies no space in the file.
605 sh_link
607 This member holds a section header table index link, whose in‐
608 terpretation depends on the section type.
609 sh_info
611 This member holds extra information, whose interpretation de‐
612 pends on the section type.
613 sh_addralign
615 Some sections have address alignment constraints. If a section
616 holds a doubleword, the system must ensure doubleword alignment
617 for the entire section. That is, the value of sh_addr must be
618 congruent to zero, modulo the value of sh_addralign. Only zero
619 and positive integral powers of two are allowed. The value 0 or
620 1 means that the section has no alignment constraints.
621 sh_entsize
623 Some sections hold a table of fixed-sized entries, such as a
624 symbol table. For such a section, this member gives the size in
625 bytes for each entry. This member contains zero if the section
626 does not hold a table of fixed-size entries.
627 Various sections hold program and control information:
629 .bss This section holds uninitialized data that contributes to the
631 program's memory image. By definition, the system initializes
632 the data with zeros when the program begins to run. This sec‐
633 tion is of type SHT_NOBITS. The attribute types are SHF_ALLOC
634 and SHF_WRITE.
635 .comment
637 This section holds version control information. This section is
638 of type SHT_PROGBITS. No attribute types are used.
639 .ctors This section holds initialized pointers to the C++ constructor
641 functions. This section is of type SHT_PROGBITS. The attribute
642 types are SHF_ALLOC and SHF_WRITE.
643 .data This section holds initialized data that contribute to the pro‐
645 gram's memory image. This section is of type SHT_PROGBITS. The
646 attribute types are SHF_ALLOC and SHF_WRITE.
647 .data1 This section holds initialized data that contribute to the pro‐
649 gram's memory image. This section is of type SHT_PROGBITS. The
650 attribute types are SHF_ALLOC and SHF_WRITE.
651 .debug This section holds information for symbolic debugging. The con‐
653 tents are unspecified. This section is of type SHT_PROGBITS.
654 No attribute types are used.
655 .dtors This section holds initialized pointers to the C++ destructor
657 functions. This section is of type SHT_PROGBITS. The attribute
658 types are SHF_ALLOC and SHF_WRITE.
659 .dynamic
661 This section holds dynamic linking information. The section's
662 attributes will include the SHF_ALLOC bit. Whether the
663 SHF_WRITE bit is set is processor-specific. This section is of
664 type SHT_DYNAMIC. See the attributes above.
665 .dynstr
667 This section holds strings needed for dynamic linking, most com‐
668 monly the strings that represent the names associated with sym‐
669 bol table entries. This section is of type SHT_STRTAB. The at‐
670 tribute type used is SHF_ALLOC.
671 .dynsym
673 This section holds the dynamic linking symbol table. This sec‐
674 tion is of type SHT_DYNSYM. The attribute used is SHF_ALLOC.
675 .fini This section holds executable instructions that contribute to
677 the process termination code. When a program exits normally the
678 system arranges to execute the code in this section. This sec‐
679 tion is of type SHT_PROGBITS. The attributes used are SHF_ALLOC
680 and SHF_EXECINSTR.
681 .gnu.version
683 This section holds the version symbol table, an array of
684 ElfN_Half elements. This section is of type SHT_GNU_versym.
685 The attribute type used is SHF_ALLOC.
686 .gnu.version_d
688 This section holds the version symbol definitions, a table of
689 ElfN_Verdef structures. This section is of type SHT_GNU_verdef.
690 The attribute type used is SHF_ALLOC.
691 .gnu.version_r
693 This section holds the version symbol needed elements, a table
694 of ElfN_Verneed structures. This section is of type
695 SHT_GNU_versym. The attribute type used is SHF_ALLOC.
696 .got This section holds the global offset table. This section is of
698 type SHT_PROGBITS. The attributes are processor-specific.
699 .hash This section holds a symbol hash table. This section is of type
701 SHT_HASH. The attribute used is SHF_ALLOC.
702 .init This section holds executable instructions that contribute to
704 the process initialization code. When a program starts to run
705 the system arranges to execute the code in this section before
706 calling the main program entry point. This section is of type
707 SHT_PROGBITS. The attributes used are SHF_ALLOC and SHF_EXECIN‐
708 STR.
709 .interp
711 This section holds the pathname of a program interpreter. If
712 the file has a loadable segment that includes the section, the
713 section's attributes will include the SHF_ALLOC bit. Otherwise,
714 that bit will be off. This section is of type SHT_PROGBITS.
715 .line This section holds line number information for symbolic debug‐
717 ging, which describes the correspondence between the program
718 source and the machine code. The contents are unspecified.
719 This section is of type SHT_PROGBITS. No attribute types are
720 used.
721 .note This section holds various notes. This section is of type
723 SHT_NOTE. No attribute types are used.
724 .note.ABI-tag
726 This section is used to declare the expected run-time ABI of the
727 ELF image. It may include the operating system name and its
728 run-time versions. This section is of type SHT_NOTE. The only
729 attribute used is SHF_ALLOC.
730 .note.gnu.build-id
732 This section is used to hold an ID that uniquely identifies the
733 contents of the ELF image. Different files with the same build
734 ID should contain the same executable content. See the
735 --build-id option to the GNU linker (ld (1)) for more details.
736 This section is of type SHT_NOTE. The only attribute used is
737 SHF_ALLOC.
738 .note.GNU-stack
740 This section is used in Linux object files for declaring stack
741 attributes. This section is of type SHT_PROGBITS. The only at‐
742 tribute used is SHF_EXECINSTR. This indicates to the GNU linker
743 that the object file requires an executable stack.
744 .note.openbsd.ident
746 OpenBSD native executables usually contain this section to iden‐
747 tify themselves so the kernel can bypass any compatibility ELF
748 binary emulation tests when loading the file.
749 .plt This section holds the procedure linkage table. This section is
751 of type SHT_PROGBITS. The attributes are processor-specific.
752 .relNAME
754 This section holds relocation information as described below.
755 If the file has a loadable segment that includes relocation, the
756 section's attributes will include the SHF_ALLOC bit. Otherwise,
757 the bit will be off. By convention, "NAME" is supplied by the
758 section to which the relocations apply. Thus a relocation sec‐
759 tion for .text normally would have the name .rel.text. This
760 section is of type SHT_REL.
761 .relaNAME
763 This section holds relocation information as described below.
764 If the file has a loadable segment that includes relocation, the
765 section's attributes will include the SHF_ALLOC bit. Otherwise,
766 the bit will be off. By convention, "NAME" is supplied by the
767 section to which the relocations apply. Thus a relocation sec‐
768 tion for .text normally would have the name .rela.text. This
769 section is of type SHT_RELA.
770 .rodata
772 This section holds read-only data that typically contributes to
773 a nonwritable segment in the process image. This section is of
774 type SHT_PROGBITS. The attribute used is SHF_ALLOC.
775 .rodata1
777 This section holds read-only data that typically contributes to
778 a nonwritable segment in the process image. This section is of
779 type SHT_PROGBITS. The attribute used is SHF_ALLOC.
780 .shstrtab
782 This section holds section names. This section is of type
783 SHT_STRTAB. No attribute types are used.
784 .strtab
786 This section holds strings, most commonly the strings that rep‐
787 resent the names associated with symbol table entries. If the
788 file has a loadable segment that includes the symbol string ta‐
789 ble, the section's attributes will include the SHF_ALLOC bit.
790 Otherwise, the bit will be off. This section is of type
791 SHT_STRTAB.
792 .symtab
794 This section holds a symbol table. If the file has a loadable
795 segment that includes the symbol table, the section's attributes
796 will include the SHF_ALLOC bit. Otherwise, the bit will be off.
797 This section is of type SHT_SYMTAB.
798 .text This section holds the "text", or executable instructions, of a
800 program. This section is of type SHT_PROGBITS. The attributes
801 used are SHF_ALLOC and SHF_EXECINSTR.
802 String and symbol tables
804 String table sections hold null-terminated character sequences, com‐
805 monly called strings. The object file uses these strings to represent
806 symbol and section names. One references a string as an index into the
807 string table section. The first byte, which is index zero, is defined
808 to hold a null byte ('\0'). Similarly, a string table's last byte is
809 defined to hold a null byte, ensuring null termination for all strings.
810 An object file's symbol table holds information needed to locate and
812 relocate a program's symbolic definitions and references. A symbol ta‐
813 ble index is a subscript into this array.
814 typedef struct {
816 uint32_t st_name;
817 Elf32_Addr st_value;
818 uint32_t st_size;
819 unsigned char st_info;
820 unsigned char st_other;
821 uint16_t st_shndx;
822 } Elf32_Sym;
823 typedef struct {
825 uint32_t st_name;
826 unsigned char st_info;
827 unsigned char st_other;
828 uint16_t st_shndx;
829 Elf64_Addr st_value;
830 uint64_t st_size;
831 } Elf64_Sym;
832 The 32-bit and 64-bit versions have the same members, just in a differ‐
834 ent order.
835 st_name
837 This member holds an index into the object file's symbol string
838 table, which holds character representations of the symbol
839 names. If the value is nonzero, it represents a string table
840 index that gives the symbol name. Otherwise, the symbol has no
841 name.
842 st_value
844 This member gives the value of the associated symbol.
845 st_size
847 Many symbols have associated sizes. This member holds zero if
848 the symbol has no size or an unknown size.
849 st_info
851 This member specifies the symbol's type and binding attributes:
852 STT_NOTYPE
854 The symbol's type is not defined.
855 STT_OBJECT
857 The symbol is associated with a data object.
858 STT_FUNC
860 The symbol is associated with a function or other exe‐
861 cutable code.
862 STT_SECTION
864 The symbol is associated with a section. Symbol table
865 entries of this type exist primarily for relocation and
866 normally have STB_LOCAL bindings.
867 STT_FILE
869 By convention, the symbol's name gives the name of the
870 source file associated with the object file. A file sym‐
871 bol has STB_LOCAL bindings, its section index is SHN_ABS,
872 and it precedes the other STB_LOCAL symbols of the file,
873 if it is present.
874 STT_LOPROC, STT_HIPROC
876 Values in the inclusive range [STT_LOPROC, STT_HIPROC]
877 are reserved for processor-specific semantics.
878 STB_LOCAL
880 Local symbols are not visible outside the object file
881 containing their definition. Local symbols of the same
882 name may exist in multiple files without interfering with
883 each other.
884 STB_GLOBAL
886 Global symbols are visible to all object files being com‐
887 bined. One file's definition of a global symbol will
888 satisfy another file's undefined reference to the same
889 symbol.
890 STB_WEAK
892 Weak symbols resemble global symbols, but their defini‐
893 tions have lower precedence.
894 STB_LOPROC, STB_HIPROC
896 Values in the inclusive range [STB_LOPROC, STB_HIPROC]
897 are reserved for processor-specific semantics.
898 There are macros for packing and unpacking the binding and type
900 fields:
901 ELF32_ST_BIND(info), ELF64_ST_BIND(info)
903 Extract a binding from an st_info value.
904 ELF32_ST_TYPE(info), ELF64_ST_TYPE(info)
906 Extract a type from an st_info value.
907 ELF32_ST_INFO(bind, type), ELF64_ST_INFO(bind, type)
909 Convert a binding and a type into an st_info value.
910 st_other
912 This member defines the symbol visibility.
913 STV_DEFAULT
915 Default symbol visibility rules. Global and weak symbols
916 are available to other modules; references in the local
917 module can be interposed by definitions in other modules.
918 STV_INTERNAL
919 Processor-specific hidden class.
920 STV_HIDDEN
921 Symbol is unavailable to other modules; references in the
922 local module always resolve to the local symbol (i.e.,
923 the symbol can't be interposed by definitions in other
924 modules).
925 STV_PROTECTED
926 Symbol is available to other modules, but references in
927 the local module always resolve to the local symbol.
928 There are macros for extracting the visibility type:
930 ELF32_ST_VISIBILITY(other) or ELF64_ST_VISIBILITY(other)
932 st_shndx
934 Every symbol table entry is "defined" in relation to some sec‐
935 tion. This member holds the relevant section header table in‐
936 dex.
937 Relocation entries (Rel & Rela)
939 Relocation is the process of connecting symbolic references with sym‐
940 bolic definitions. Relocatable files must have information that de‐
941 scribes how to modify their section contents, thus allowing executable
942 and shared object files to hold the right information for a process's
943 program image. Relocation entries are these data.
944 Relocation structures that do not need an addend:
946 typedef struct {
948 Elf32_Addr r_offset;
949 uint32_t r_info;
950 } Elf32_Rel;
951 typedef struct {
953 Elf64_Addr r_offset;
954 uint64_t r_info;
955 } Elf64_Rel;
956 Relocation structures that need an addend:
958 typedef struct {
960 Elf32_Addr r_offset;
961 uint32_t r_info;
962 int32_t r_addend;
963 } Elf32_Rela;
964 typedef struct {
966 Elf64_Addr r_offset;
967 uint64_t r_info;
968 int64_t r_addend;
969 } Elf64_Rela;
970 r_offset
972 This member gives the location at which to apply the relocation
973 action. For a relocatable file, the value is the byte offset
974 from the beginning of the section to the storage unit affected
975 by the relocation. For an executable file or shared object, the
976 value is the virtual address of the storage unit affected by the
977 relocation.
978 r_info This member gives both the symbol table index with respect to
980 which the relocation must be made and the type of relocation to
981 apply. Relocation types are processor-specific. When the text
982 refers to a relocation entry's relocation type or symbol table
983 index, it means the result of applying ELF[32|64]_R_TYPE or
984 ELF[32|64]_R_SYM, respectively, to the entry's r_info member.
985 r_addend
987 This member specifies a constant addend used to compute the
988 value to be stored into the relocatable field.
989 Dynamic tags (Dyn)
991 The .dynamic section contains a series of structures that hold relevant
992 dynamic linking information. The d_tag member controls the interpreta‐
993 tion of d_un.
994 typedef struct {
996 Elf32_Sword d_tag;
997 union {
998 Elf32_Word d_val;
999 Elf32_Addr d_ptr;
1000 } d_un;
1001 } Elf32_Dyn;
1002 extern Elf32_Dyn _DYNAMIC[];
1003 typedef struct {
1005 Elf64_Sxword d_tag;
1006 union {
1007 Elf64_Xword d_val;
1008 Elf64_Addr d_ptr;
1009 } d_un;
1010 } Elf64_Dyn;
1011 extern Elf64_Dyn _DYNAMIC[];
1012 d_tag This member may have any of the following values:
1014 DT_NULL Marks end of dynamic section
1016 DT_NEEDED String table offset to name of a needed library
1018 DT_PLTRELSZ Size in bytes of PLT relocation entries
1020 DT_PLTGOT Address of PLT and/or GOT
1022 DT_HASH Address of symbol hash table
1024 DT_STRTAB Address of string table
1026 DT_SYMTAB Address of symbol table
1028 DT_RELA Address of Rela relocation table
1030 DT_RELASZ Size in bytes of the Rela relocation table
1032 DT_RELAENT Size in bytes of a Rela relocation table entry
1034 DT_STRSZ Size in bytes of string table
1036 DT_SYMENT Size in bytes of a symbol table entry
1038 DT_INIT Address of the initialization function
1040 DT_FINI Address of the termination function
1042 DT_SONAME String table offset to name of shared object
1044 DT_RPATH String table offset to library search path (depre‐
1046 cated)
1047 DT_SYMBOLIC Alert linker to search this shared object before the
1049 executable for symbols
1050 DT_REL Address of Rel relocation table
1052 DT_RELSZ Size in bytes of Rel relocation table
1054 DT_RELENT Size in bytes of a Rel table entry
1056 DT_PLTREL Type of relocation entry to which the PLT refers
1058 (Rela or Rel)
1059 DT_DEBUG Undefined use for debugging
1061 DT_TEXTREL Absence of this entry indicates that no relocation
1063 entries should apply to a nonwritable segment
1064 DT_JMPREL Address of relocation entries associated solely with
1066 the PLT
1067 DT_BIND_NOW Instruct dynamic linker to process all relocations
1069 before transferring control to the executable
1070 DT_RUNPATH String table offset to library search path
1072 DT_LOPROC, DT_HIPROC
1074 Values in the inclusive range [DT_LOPROC, DT_HIPROC]
1075 are reserved for processor-specific semantics
1076 d_val This member represents integer values with various interpreta‐
1078 tions.
1079 d_ptr This member represents program virtual addresses. When inter‐
1081 preting these addresses, the actual address should be computed
1082 based on the original file value and memory base address. Files
1083 do not contain relocation entries to fixup these addresses.
1084 _DYNAMIC
1086 Array containing all the dynamic structures in the .dynamic sec‐
1087 tion. This is automatically populated by the linker.
1088 Notes (Nhdr)
1090 ELF notes allow for appending arbitrary information for the system to
1091 use. They are largely used by core files (e_type of ET_CORE), but many
1092 projects define their own set of extensions. For example, the GNU tool
1093 chain uses ELF notes to pass information from the linker to the C li‐
1094 brary.
1095 Note sections contain a series of notes (see the struct definitions be‐
1097 low). Each note is followed by the name field (whose length is defined
1098 in n_namesz) and then by the descriptor field (whose length is defined
1099 in n_descsz) and whose starting address has a 4 byte alignment. Nei‐
1100 ther field is defined in the note struct due to their arbitrary
1101 lengths.
1102 An example for parsing out two consecutive notes should clarify their
1104 layout in memory:
1105 void *memory, *name, *desc;
1107 Elf64_Nhdr *note, *next_note;
1108 /* The buffer is pointing to the start of the section/segment. */
1110 note = memory;
1111 /* If the name is defined, it follows the note. */
1113 name = note->n_namesz == 0 ? NULL : memory + sizeof(*note);
1114 /* If the descriptor is defined, it follows the name
1116 (with alignment). */
1117 desc = note->n_descsz == 0 ? NULL :
1119 memory + sizeof(*note) + ALIGN_UP(note->n_namesz, 4);
1120 /* The next note follows both (with alignment). */
1122 next_note = memory + sizeof(*note) +
1123 ALIGN_UP(note->n_namesz, 4) +
1124 ALIGN_UP(note->n_descsz, 4);
1125 Keep in mind that the interpretation of n_type depends on the namespace
1127 defined by the n_namesz field. If the n_namesz field is not set (e.g.,
1128 is 0), then there are two sets of notes: one for core files and one for
1129 all other ELF types. If the namespace is unknown, then tools will usu‐
1130 ally fallback to these sets of notes as well.
1131 typedef struct {
1133 Elf32_Word n_namesz;
1134 Elf32_Word n_descsz;
1135 Elf32_Word n_type;
1136 } Elf32_Nhdr;
1137 typedef struct {
1139 Elf64_Word n_namesz;
1140 Elf64_Word n_descsz;
1141 Elf64_Word n_type;
1142 } Elf64_Nhdr;
1143 n_namesz
1145 The length of the name field in bytes. The contents will imme‐
1146 diately follow this note in memory. The name is null termi‐
1147 nated. For example, if the name is "GNU", then n_namesz will be
1148 set to 4.
1149 n_descsz
1151 The length of the descriptor field in bytes. The contents will
1152 immediately follow the name field in memory.
1153 n_type Depending on the value of the name field, this member may have
1155 any of the following values:
1156 Core files (e_type = ET_CORE)
1158 Notes used by all core files. These are highly operating
1159 system or architecture specific and often require close co‐
1160 ordination with kernels, C libraries, and debuggers. These
1161 are used when the namespace is the default (i.e., n_namesz
1162 will be set to 0), or a fallback when the namespace is un‐
1163 known.
1164 NT_PRSTATUS prstatus struct
1166 NT_FPREGSET fpregset struct
1167 NT_PRPSINFO prpsinfo struct
1168 NT_PRXREG prxregset struct
1169 NT_TASKSTRUCT task structure
1170 NT_PLATFORM String from sysinfo(SI_PLATFORM)
1171 NT_AUXV auxv array
1172 NT_GWINDOWS gwindows struct
1173 NT_ASRS asrset struct
1174 NT_PSTATUS pstatus struct
1175 NT_PSINFO psinfo struct
1176 NT_PRCRED prcred struct
1177 NT_UTSNAME utsname struct
1178 NT_LWPSTATUS lwpstatus struct
1179 NT_LWPSINFO lwpinfo struct
1180 NT_PRFPXREG fprxregset struct
1181 NT_SIGINFO siginfo_t (size might increase over
1182 time)
1183 NT_FILE Contains information about mapped
1184 files
1185 NT_PRXFPREG user_fxsr_struct
1186 NT_PPC_VMX PowerPC Altivec/VMX registers
1187 NT_PPC_SPE PowerPC SPE/EVR registers
1188 NT_PPC_VSX PowerPC VSX registers
1189 NT_386_TLS i386 TLS slots (struct user_desc)
1190 NT_386_IOPERM x86 io permission bitmap (1=deny)
1191 NT_X86_XSTATE x86 extended state using xsave
1192 NT_S390_HIGH_GPRS s390 upper register halves
1193 NT_S390_TIMER s390 timer register
1194 NT_S390_TODCMP s390 time-of-day (TOD) clock compara‐
1195 tor register
1196 NT_S390_TODPREG s390 time-of-day (TOD) programmable
1197 register
1198 NT_S390_CTRS s390 control registers
1199 NT_S390_PREFIX s390 prefix register
1200 NT_S390_LAST_BREAK s390 breaking event address
1201 NT_S390_SYSTEM_CALL s390 system call restart data
1202 NT_S390_TDB s390 transaction diagnostic block
1203 NT_ARM_VFP ARM VFP/NEON registers
1204 NT_ARM_TLS ARM TLS register
1205 NT_ARM_HW_BREAK ARM hardware breakpoint registers
1206 NT_ARM_HW_WATCH ARM hardware watchpoint registers
1207 NT_ARM_SYSTEM_CALL ARM system call number
1208 n_name = GNU
1210 Extensions used by the GNU tool chain.
1211 NT_GNU_ABI_TAG
1213 Operating system (OS) ABI information. The desc
1214 field will be 4 words:
1215 [0] OS descriptor (ELF_NOTE_OS_LINUX,
1217 ELF_NOTE_OS_GNU, and so on)`
1218 [1] major version of the ABI
1219 [2] minor version of the ABI
1220 [3] subminor version of the ABI
1221 NT_GNU_HWCAP
1223 Synthetic hwcap information. The desc field begins
1224 with two words:
1225 [0] number of entries
1227 [1] bit mask of enabled entries
1228 Then follow variable-length entries, one byte fol‐
1230 lowed by a null-terminated hwcap name string. The
1231 byte gives the bit number to test if enabled, (1U <<
1232 bit) & bit mask.
1233 NT_GNU_BUILD_ID
1235 Unique build ID as generated by the GNU ld(1)
1236 --build-id option. The desc consists of any nonzero
1237 number of bytes.
1238 NT_GNU_GOLD_VERSION
1240 The desc contains the GNU Gold linker version used.
1241 Default/unknown namespace (e_type != ET_CORE)
1243 These are used when the namespace is the default (i.e.,
1244 n_namesz will be set to 0), or a fallback when the name‐
1245 space is unknown.
1246 NT_VERSION A version string of some sort.
1248 NT_ARCH Architecture information.
1249
1251 ELF first appeared in System V. The ELF format is an adopted standard.
1252 The extensions for e_phnum, e_shnum, and e_shstrndx respectively are
1254 Linux extensions. Sun, BSD, and AMD64 also support them; for further
1255 information, look under SEE ALSO.
1256
1258 as(1), elfedit(1), gdb(1), ld(1), nm(1), objcopy(1), objdump(1),
1259 patchelf(1), readelf(1), size(1), strings(1), strip(1), execve(2),
1260 dl_iterate_phdr(3), core(5), ld.so(8)
1261 Hewlett-Packard, Elf-64 Object File Format.
1263 Santa Cruz Operation, System V Application Binary Interface.
1265 UNIX System Laboratories, "Object Files", Executable and Linking Format
1267 (ELF).
1268 Sun Microsystems, Linker and Libraries Guide.
1270 AMD64 ABI Draft, System V Application Binary Interface AMD64 Architec‐
1272 ture Processor Supplement.
1273Linux man-pages 6.05 2023-05-03 ELF(5)