diff options
Diffstat (limited to 'man5/elf.5')
| -rw-r--r-- | man5/elf.5 | 2213 |
1 files changed, 0 insertions, 2213 deletions
diff --git a/man5/elf.5 b/man5/elf.5 deleted file mode 100644 index 84c7f27..0000000 --- a/man5/elf.5 +++ /dev/null @@ -1,2213 +0,0 @@ -.\" $OpenBSD: elf.5,v 1.12 2003/10/27 20:23:58 jmc Exp $ -.\"Copyright (c) 1999 Jeroen Ruigrok van der Werven -.\"All rights reserved. -.\" -.\" %%%LICENSE_START(PERMISSIVE_MISC) -.\"Redistribution and use in source and binary forms, with or without -.\"modification, are permitted provided that the following conditions -.\"are met: -.\"1. Redistributions of source code must retain the above copyright -.\" notice, this list of conditions and the following disclaimer. -.\"2. Redistributions in binary form must reproduce the above copyright -.\" notice, this list of conditions and the following disclaimer in the -.\" documentation and/or other materials provided with the distribution. -.\" -.\"THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND -.\"ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE -.\"IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE -.\"ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE -.\"FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL -.\"DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS -.\"OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) -.\"HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT -.\"LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY -.\"OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF -.\"SUCH DAMAGE. -.\" %%%LICENSE_END -.\" -.\" $FreeBSD: src/share/man/man5/elf.5,v 1.21 2001/10/01 16:09:23 ru Exp $ -.\" -.\" Slightly adapted - aeb, 2004-01-01 -.\" 2005-07-15, Mike Frysinger <vapier@gentoo.org>, various fixes -.\" 2007-10-11, Mike Frysinger <vapier@gentoo.org>, various fixes -.\" 2007-12-08, mtk, Converted from mdoc to man macros -.\" -.TH ELF 5 2024-02-25 "Linux man-pages 6.7" -.SH NAME -elf \- format of Executable and Linking Format (ELF) files -.SH SYNOPSIS -.nf -.\" .B #include <elf_abi.h> -.B #include <elf.h> -.fi -.SH DESCRIPTION -The header file -.I <elf.h> -defines the format of ELF executable binary files. -Amongst these files are -normal executable files, relocatable object files, core files, and shared -objects. -.P -An executable file using the ELF file format consists of an ELF header, -followed by a program header table or a section header table, or both. -The ELF header is always at offset zero of the file. -The program header -table and the section header table's offset in the file are defined in the -ELF header. -The two tables describe the rest of the particularities of -the file. -.P -.\" Applications which wish to process ELF binary files for their native -.\" architecture only should include -.\" .I <elf_abi.h> -.\" in their source code. -.\" These applications should need to refer to -.\" all the types and structures by their generic names -.\" "Elf_xxx" -.\" and to the macros by -.\" ELF_xxx". -.\" Applications written this way can be compiled on any architecture, -.\" regardless of whether the host is 32-bit or 64-bit. -.\" .P -.\" Should an application need to process ELF files of an unknown -.\" architecture, then the application needs to explicitly use either -.\" "Elf32_xxx" -.\" or -.\" "Elf64_xxx" -.\" type and structure names. -.\" Likewise, the macros need to be identified by -.\" "ELF32_xxx" -.\" or -.\" "ELF64_xxx". -.\" .P -This header file describes the above mentioned headers as C structures -and also includes structures for dynamic sections, relocation sections and -symbol tables. -.\" -.SS Basic types -The following types are used for N-bit architectures (N=32,64, -.I ElfN -stands for -.I Elf32 -or -.IR Elf64 , -.I uintN_t -stands for -.I uint32_t -or -.IR uint64_t ): -.P -.in +4n -.EX -ElfN_Addr Unsigned program address, uintN_t -ElfN_Off Unsigned file offset, uintN_t -ElfN_Section Unsigned section index, uint16_t -ElfN_Versym Unsigned version symbol information, uint16_t -Elf_Byte unsigned char -ElfN_Half uint16_t -ElfN_Sword int32_t -ElfN_Word uint32_t -ElfN_Sxword int64_t -ElfN_Xword uint64_t -.\" Elf32_Size Unsigned object size -.EE -.in -.P -(Note: the *BSD terminology is a bit different. -There, -.I Elf64_Half -is -twice as large as -.IR Elf32_Half , -and -.I Elf64Quarter -is used for -.IR uint16_t . -In order to avoid confusion these types are replaced by explicit ones -in the below.) -.P -All data structures that the file format defines follow the -"natural" -size and alignment guidelines for the relevant class. -If necessary, -data structures contain explicit padding to ensure 4-byte alignment -for 4-byte objects, to force structure sizes to a multiple of 4, and so on. -.\" -.SS ELF header (Ehdr) -The ELF header is described by the type -.I Elf32_Ehdr -or -.IR Elf64_Ehdr : -.P -.in +4n -.EX -#define EI_NIDENT 16 -\& -typedef struct { - unsigned char e_ident[EI_NIDENT]; - uint16_t e_type; - uint16_t e_machine; - uint32_t e_version; - ElfN_Addr e_entry; - ElfN_Off e_phoff; - ElfN_Off e_shoff; - uint32_t e_flags; - uint16_t e_ehsize; - uint16_t e_phentsize; - uint16_t e_phnum; - uint16_t e_shentsize; - uint16_t e_shnum; - uint16_t e_shstrndx; -} ElfN_Ehdr; -.EE -.in -.P -The fields have the following meanings: -.\" -.\" -.TP -.I e_ident -This array of bytes specifies how to interpret the file, -independent of the processor or the file's remaining contents. -Within this array everything is named by macros, which start with -the prefix -.B EI_ -and may contain values which start with the prefix -.BR ELF . -The following macros are defined: -.RS -.TP -.B EI_MAG0 -The first byte of the magic number. -It must be filled with -.BR ELFMAG0 . -(0: 0x7f) -.TP -.B EI_MAG1 -The second byte of the magic number. -It must be filled with -.BR ELFMAG1 . -(1: \[aq]E\[aq]) -.TP -.B EI_MAG2 -The third byte of the magic number. -It must be filled with -.BR ELFMAG2 . -(2: \[aq]L\[aq]) -.TP -.B EI_MAG3 -The fourth byte of the magic number. -It must be filled with -.BR ELFMAG3 . -(3: \[aq]F\[aq]) -.TP -.B EI_CLASS -The fifth byte identifies the architecture for this binary: -.RS -.TP 14 -.PD 0 -.B ELFCLASSNONE -This class is invalid. -.TP -.B ELFCLASS32 -This defines the 32-bit architecture. -It supports machines with files -and virtual address spaces up to 4 Gigabytes. -.TP -.B ELFCLASS64 -This defines the 64-bit architecture. -.PD -.RE -.TP -.B EI_DATA -The sixth byte specifies the data encoding of the processor-specific -data in the file. -Currently, these encodings are supported: -.RS 9 -.TP 14 -.PD 0 -.B ELFDATANONE -Unknown data format. -.TP -.B ELFDATA2LSB -Two's complement, little-endian. -.TP -.B ELFDATA2MSB -Two's complement, big-endian. -.PD -.RE -.TP -.B EI_VERSION -The seventh byte is the version number of the ELF specification: -.IP -.PD 0 -.RS -.TP 14 -.B EV_NONE -Invalid version. -.TP -.B EV_CURRENT -Current version. -.PD -.RE -.\".El -.TP -.B EI_OSABI -The eighth byte identifies the operating system -and ABI to which the object is targeted. -Some fields in other ELF structures have flags -and values that have platform-specific meanings; -the interpretation of those fields is determined by the value of this byte. -For example: -.RS -.TP 21 -.PD 0 -.B ELFOSABI_NONE -Same as ELFOSABI_SYSV -.\" 0 -.TP -.B ELFOSABI_SYSV -UNIX System V ABI -.\" 0 -.\" synonym: ELFOSABI_NONE -.TP -.B ELFOSABI_HPUX -HP-UX ABI -.\" 1 -.TP -.B ELFOSABI_NETBSD -NetBSD ABI -.\" 2 -.TP -.B ELFOSABI_LINUX -Linux ABI -.\" 3 -.\" .TP -.\" .BR ELFOSABI_HURD -.\" Hurd ABI -.\" 4 -.\" .TP -.\" .BR ELFOSABI_86OPEN -.\" 86Open Common IA32 ABI -.\" 5 -.TP -.B ELFOSABI_SOLARIS -Solaris ABI -.\" 6 -.\" .TP -.\" .BR ELFOSABI_MONTEREY -.\" Monterey project ABI -.\" Now replaced by -.\" ELFOSABI_AIX -.\" 7 -.TP -.B ELFOSABI_IRIX -IRIX ABI -.\" 8 -.TP -.B ELFOSABI_FREEBSD -FreeBSD ABI -.\" 9 -.TP -.B ELFOSABI_TRU64 -TRU64 UNIX ABI -.\" 10 -.\" ELFOSABI_MODESTO -.\" 11 -.\" ELFOSABI_OPENBSD -.\" 12 -.TP -.B ELFOSABI_ARM -ARM architecture ABI -.\" 97 -.TP -.B ELFOSABI_STANDALONE -Stand-alone (embedded) ABI -.\" 255 -.PD -.RE -.TP -.B EI_ABIVERSION -The ninth byte identifies the version of the ABI -to which the object is targeted. -This field is used to distinguish among incompatible versions of an ABI. -The interpretation of this version number -is dependent on the ABI identified by the -.B EI_OSABI -field. -Applications conforming to this specification use the value 0. -.TP -.B EI_PAD -Start of padding. -These bytes are reserved and set to zero. -Programs -which read them should ignore them. -The value for -.B EI_PAD -will change in -the future if currently unused bytes are given meanings. -.\" As reported by Yuri Kozlov and confirmed by Mike Frysinger, EI_BRAND is -.\" not in GABI (http://www.sco.com/developers/gabi/latest/ch4.eheader.html) -.\" It looks to be a BSDism -.\" .TP -.\" .BR EI_BRAND -.\" Start of architecture identification. -.TP -.B EI_NIDENT -The size of the -.I e_ident -array. -.RE -.TP -.I e_type -This member of the structure identifies the object file type: -.RS -.TP 16 -.PD 0 -.B ET_NONE -An unknown type. -.TP -.B ET_REL -A relocatable file. -.TP -.B ET_EXEC -An executable file. -.TP -.B ET_DYN -A shared object. -.TP -.B ET_CORE -A core file. -.PD -.RE -.TP -.I e_machine -This member specifies the required architecture for an individual file. -For example: -.RS -.TP 16 -.PD 0 -.B EM_NONE -An unknown machine -.\" 0 -.TP -.B EM_M32 -AT&T WE 32100 -.\" 1 -.TP -.B EM_SPARC -Sun Microsystems SPARC -.\" 2 -.TP -.B EM_386 -Intel 80386 -.\" 3 -.TP -.B EM_68K -Motorola 68000 -.\" 4 -.TP -.B EM_88K -Motorola 88000 -.\" 5 -.\" .TP -.\" .BR EM_486 -.\" Intel 80486 -.\" 6 -.TP -.B EM_860 -Intel 80860 -.\" 7 -.TP -.B EM_MIPS -MIPS RS3000 (big-endian only) -.\" 8 -.\" EM_S370 -.\" 9 -.\" .TP -.\" .BR EM_MIPS_RS4_BE -.\" MIPS RS4000 (big-endian only). Deprecated -.\" 10 -.\" EM_MIPS_RS3_LE (MIPS R3000 little-endian) -.\" 10 -.TP -.B EM_PARISC -HP/PA -.\" 15 -.TP -.B EM_SPARC32PLUS -SPARC with enhanced instruction set -.\" 18 -.TP -.B EM_PPC -PowerPC -.\" 20 -.TP -.B EM_PPC64 -PowerPC 64-bit -.\" 21 -.TP -.B EM_S390 -IBM S/390 -.\" 22 -.TP -.B EM_ARM -Advanced RISC Machines -.\" 40 -.TP -.B EM_SH -Renesas SuperH -.\" 42 -.TP -.B EM_SPARCV9 -SPARC v9 64-bit -.\" 43 -.TP -.B EM_IA_64 -Intel Itanium -.\" 50 -.TP -.B EM_X86_64 -AMD x86-64 -.\" 62 -.TP -.B EM_VAX -DEC Vax -.\" 75 -.\" EM_CRIS -.\" 76 -.\" .TP -.\" .BR EM_ALPHA -.\" Compaq [DEC] Alpha -.\" .TP -.\" .BR EM_ALPHA_EXP -.\" Compaq [DEC] Alpha with enhanced instruction set -.PD -.RE -.TP -.I e_version -This member identifies the file version: -.RS -.TP 16 -.PD 0 -.B EV_NONE -Invalid version -.TP -.B EV_CURRENT -Current version -.PD -.RE -.TP -.I e_entry -This member gives the virtual address to which the system first transfers -control, thus starting the process. -If the file has no associated entry -point, this member holds zero. -.TP -.I e_phoff -This member holds the program header table's file offset in bytes. -If -the file has no program header table, this member holds zero. -.TP -.I e_shoff -This member holds the section header table's file offset in bytes. -If the -file has no section header table, this member holds zero. -.TP -.I e_flags -This member holds processor-specific flags associated with the file. -Flag names take the form EF_`machine_flag'. -Currently, no flags have been defined. -.TP -.I e_ehsize -This member holds the ELF header's size in bytes. -.TP -.I e_phentsize -This member holds the size in bytes of one entry in the file's -program header table; all entries are the same size. -.TP -.I e_phnum -This member holds the number of entries in the program header -table. -Thus the product of -.I e_phentsize -and -.I e_phnum -gives the table's size -in bytes. -If a file has no program header, -.I e_phnum -holds the value zero. -.IP -If the number of entries in the program header table is -larger than or equal to -.\" This is a Linux extension, added in Linux 2.6.34. -.B PN_XNUM -(0xffff), this member holds -.B PN_XNUM -(0xffff) and the real number of entries in the program header table is held -in the -.I sh_info -member of the initial entry in section header table. -Otherwise, the -.I sh_info -member of the initial entry contains the value zero. -.RS -.TP -.B PN_XNUM -This is defined as 0xffff, the largest number -.I e_phnum -can have, specifying where the actual number of program headers is assigned. -.PD -.RE -.TP -.I e_shentsize -This member holds a sections header's size in bytes. -A section header is one -entry in the section header table; all entries are the same size. -.TP -.I e_shnum -This member holds the number of entries in the section header table. -Thus -the product of -.I e_shentsize -and -.I e_shnum -gives the section header table's size in bytes. -If a file has no section -header table, -.I e_shnum -holds the value of zero. -.IP -If the number of entries in the section header table is -larger than or equal to -.B SHN_LORESERVE -(0xff00), -.I e_shnum -holds the value zero and the real number of entries in the section header -table is held in the -.I sh_size -member of the initial entry in section header table. -Otherwise, the -.I sh_size -member of the initial entry in the section header table holds -the value zero. -.TP -.I e_shstrndx -This member holds the section header table index of the entry associated -with the section name string table. -If the file has no section name string -table, this member holds the value -.BR SHN_UNDEF . -.IP -If the index of section name string table section is -larger than or equal to -.B SHN_LORESERVE -(0xff00), this member holds -.B SHN_XINDEX -(0xffff) and the real index of the section name string table section -is held in the -.I sh_link -member of the initial entry in section header table. -Otherwise, the -.I sh_link -member of the initial entry in section header table contains the value zero. -.\" -.SS Program header (Phdr) -An executable or shared object file's program header table is an array of -structures, each describing a segment or other information the system needs -to prepare the program for execution. -An object file -.I segment -contains one or more -.IR sections . -Program headers are meaningful only for executable and shared object files. -A file specifies its own program header size with the ELF header's -.I e_phentsize -and -.I e_phnum -members. -The ELF program header is described by the type -.I Elf32_Phdr -or -.I Elf64_Phdr -depending on the architecture: -.P -.in +4n -.EX -typedef struct { - uint32_t p_type; - Elf32_Off p_offset; - Elf32_Addr p_vaddr; - Elf32_Addr p_paddr; - uint32_t p_filesz; - uint32_t p_memsz; - uint32_t p_flags; - uint32_t p_align; -} Elf32_Phdr; -.EE -.in -.P -.in +4n -.EX -typedef struct { - uint32_t p_type; - uint32_t p_flags; - Elf64_Off p_offset; - Elf64_Addr p_vaddr; - Elf64_Addr p_paddr; - uint64_t p_filesz; - uint64_t p_memsz; - uint64_t p_align; -} Elf64_Phdr; -.EE -.in -.P -The main difference between the 32-bit and the 64-bit program header lies -in the location of the -.I p_flags -member in the total struct. -.TP -.I p_type -This member of the structure indicates what kind of segment this array -element describes or how to interpret the array element's information. -.RS 10 -.TP -.B PT_NULL -The array element is unused and the other members' values are undefined. -This lets the program header have ignored entries. -.TP -.B PT_LOAD -The array element specifies a loadable segment, described by -.I p_filesz -and -.IR p_memsz . -The bytes from the file are mapped to the beginning of the memory -segment. -If the segment's memory size -.I p_memsz -is larger than the file size -.IR p_filesz , -the -"extra" -bytes are defined to hold the value 0 and to follow the segment's -initialized area. -The file size may not be larger than the memory size. -Loadable segment entries in the program header table appear in ascending -order, sorted on the -.I p_vaddr -member. -.TP -.B PT_DYNAMIC -The array element specifies dynamic linking information. -.TP -.B PT_INTERP -The array element specifies the location and size of a null-terminated -pathname to invoke as an interpreter. -This segment type is meaningful -only for executable files (though it may occur for shared objects). -However it may not occur more than once in a file. -If it is present, it must precede any loadable segment entry. -.TP -.B PT_NOTE -The array element specifies the location of notes (ElfN_Nhdr). -.TP -.B PT_SHLIB -This segment type is reserved but has unspecified semantics. -Programs that -contain an array element of this type do not conform to the ABI. -.TP -.B PT_PHDR -The array element, if present, -specifies the location and size of the program header table itself, -both in the file and in the memory image of the program. -This segment type may not occur more than once in a file. -Moreover, it may -occur only if the program header table is part of the memory image of the -program. -If it is present, it must precede any loadable segment entry. -.TP -.B PT_LOPROC -.TQ -.B PT_HIPROC -Values in the inclusive range -.RB [ PT_LOPROC , -.BR PT_HIPROC ] -are reserved for processor-specific semantics. -.TP -.B PT_GNU_STACK -GNU extension which is used by the Linux kernel to control the state of the -stack via the flags set in the -.I p_flags -member. -.RE -.TP -.I p_offset -This member holds the offset from the beginning of the file at which -the first byte of the segment resides. -.TP -.I p_vaddr -This member holds the virtual address at which the first byte of the -segment resides in memory. -.TP -.I p_paddr -On systems for which physical addressing is relevant, this member is -reserved for the segment's physical address. -Under -BSD -this member is -not used and must be zero. -.TP -.I p_filesz -This member holds the number of bytes in the file image of the segment. -It may be zero. -.TP -.I p_memsz -This member holds the number of bytes in the memory image of the segment. -It may be zero. -.TP -.I p_flags -This member holds a bit mask of flags relevant to the segment: -.RS -.TP -.PD 0 -.B PF_X -An executable segment. -.TP -.B PF_W -A writable segment. -.TP -.B PF_R -A readable segment. -.PD -.RE -.IP -A text segment commonly has the flags -.B PF_X -and -.BR PF_R . -A data segment commonly has -.B PF_W -and -.BR PF_R . -.TP -.I p_align -This member holds the value to which the segments are aligned in memory -and in the file. -Loadable process segments must have congruent values for -.I p_vaddr -and -.IR p_offset , -modulo the page size. -Values of zero and one mean no alignment is required. -Otherwise, -.I p_align -should be a positive, integral power of two, and -.I p_vaddr -should equal -.IR p_offset , -modulo -.IR p_align . -.\" -.SS Section header (Shdr) -A file's section header table lets one locate all the file's sections. -The -section header table is an array of -.I Elf32_Shdr -or -.I Elf64_Shdr -structures. -The -ELF header's -.I e_shoff -member gives the byte offset from the beginning of the file to the section -header table. -.I e_shnum -holds the number of entries the section header table contains. -.I e_shentsize -holds the size in bytes of each entry. -.P -A section header table index is a subscript into this array. -Some section -header table indices are reserved: -the initial entry and the indices between -.B SHN_LORESERVE -and -.BR SHN_HIRESERVE . -The initial entry is used in ELF extensions for -.IR e_phnum , -.IR e_shnum , -and -.IR e_shstrndx ; -in other cases, each field in the initial entry is set to zero. -An object file does not have sections for -these special indices: -.TP -.B SHN_UNDEF -This value marks an undefined, missing, irrelevant, -or otherwise meaningless section reference. -.TP -.B SHN_LORESERVE -This value specifies the lower bound of the range of reserved indices. -.TP -.B SHN_LOPROC -.TQ -.B SHN_HIPROC -Values greater in the inclusive range -.RB [ SHN_LOPROC , -.BR SHN_HIPROC ] -are reserved for processor-specific semantics. -.TP -.B SHN_ABS -This value specifies the absolute value for the corresponding reference. -For -example, a symbol defined relative to section number -.B SHN_ABS -has an absolute value and is not affected by relocation. -.TP -.B SHN_COMMON -Symbols defined relative to this section are common symbols, -such as FORTRAN COMMON or unallocated C external variables. -.TP -.B SHN_HIRESERVE -This value specifies the upper bound of the range of reserved indices. -The -system reserves indices between -.B SHN_LORESERVE -and -.BR SHN_HIRESERVE , -inclusive. -The section header table does not contain entries for the -reserved indices. -.P -The section header has the following structure: -.P -.in +4n -.EX -typedef struct { - uint32_t sh_name; - uint32_t sh_type; - uint32_t sh_flags; - Elf32_Addr sh_addr; - Elf32_Off sh_offset; - uint32_t sh_size; - uint32_t sh_link; - uint32_t sh_info; - uint32_t sh_addralign; - uint32_t sh_entsize; -} Elf32_Shdr; -.EE -.in -.P -.in +4n -.EX -typedef struct { - uint32_t sh_name; - uint32_t sh_type; - uint64_t sh_flags; - Elf64_Addr sh_addr; - Elf64_Off sh_offset; - uint64_t sh_size; - uint32_t sh_link; - uint32_t sh_info; - uint64_t sh_addralign; - uint64_t sh_entsize; -} Elf64_Shdr; -.EE -.in -.P -No real differences exist between the 32-bit and 64-bit section headers. -.TP -.I sh_name -This member specifies the name of the section. -Its value is an index -into the section header string table section, giving the location of -a null-terminated string. -.TP -.I sh_type -This member categorizes the section's contents and semantics. -.RS -.TP -.B SHT_NULL -This value marks the section header as inactive. -It does not -have an associated section. -Other members of the section header -have undefined values. -.TP -.B SHT_PROGBITS -This section holds information defined by the program, whose -format and meaning are determined solely by the program. -.TP -.B SHT_SYMTAB -This section holds a symbol table. -Typically, -.B SHT_SYMTAB -provides symbols for link editing, though it may also be used -for dynamic linking. -As a complete symbol table, it may contain -many symbols unnecessary for dynamic linking. -An object file can -also contain a -.B SHT_DYNSYM -section. -.TP -.B SHT_STRTAB -This section holds a string table. -An object file may have multiple -string table sections. -.TP -.B SHT_RELA -This section holds relocation entries with explicit addends, such -as type -.I Elf32_Rela -for the 32-bit class of object files. -An object may have multiple -relocation sections. -.TP -.B SHT_HASH -This section holds a symbol hash table. -An object participating in -dynamic linking must contain a symbol hash table. -An object file may -have only one hash table. -.TP -.B SHT_DYNAMIC -This section holds information for dynamic linking. -An object file may -have only one dynamic section. -.TP -.B SHT_NOTE -This section holds notes (ElfN_Nhdr). -.TP -.B SHT_NOBITS -A section of this type occupies no space in the file but otherwise -resembles -.BR SHT_PROGBITS . -Although this section contains no bytes, the -.I sh_offset -member contains the conceptual file offset. -.TP -.B SHT_REL -This section holds relocation offsets without explicit addends, such -as type -.I Elf32_Rel -for the 32-bit class of object files. -An object file may have multiple -relocation sections. -.TP -.B SHT_SHLIB -This section is reserved but has unspecified semantics. -.TP -.B SHT_DYNSYM -This section holds a minimal set of dynamic linking symbols. -An -object file can also contain a -.B SHT_SYMTAB -section. -.TP -.B SHT_LOPROC -.TQ -.B SHT_HIPROC -Values in the inclusive range -.RB [ SHT_LOPROC , -.BR SHT_HIPROC ] -are reserved for processor-specific semantics. -.TP -.B SHT_LOUSER -This value specifies the lower bound of the range of indices reserved for -application programs. -.TP -.B SHT_HIUSER -This value specifies the upper bound of the range of indices reserved for -application programs. -Section types between -.B SHT_LOUSER -and -.B SHT_HIUSER -may be used by the application, without conflicting with current or future -system-defined section types. -.RE -.TP -.I sh_flags -Sections support one-bit flags that describe miscellaneous attributes. -If a flag bit is set in -.IR sh_flags , -the attribute is -"on" -for the section. -Otherwise, the attribute is -"off" -or does not apply. -Undefined attributes are set to zero. -.RS -.TP -.B SHF_WRITE -This section contains data that should be writable during process -execution. -.TP -.B SHF_ALLOC -This section occupies memory during process execution. -Some control -sections do not reside in the memory image of an object file. -This -attribute is off for those sections. -.TP -.B SHF_EXECINSTR -This section contains executable machine instructions. -.TP -.B SHF_MASKPROC -All bits included in this mask are reserved for processor-specific -semantics. -.RE -.TP -.I sh_addr -If this section appears in the memory image of a process, this member -holds the address at which the section's first byte should reside. -Otherwise, the member contains zero. -.TP -.I sh_offset -This member's value holds the byte offset from the beginning of the file -to the first byte in the section. -One section type, -.BR SHT_NOBITS , -occupies no space in the file, and its -.I sh_offset -member locates the conceptual placement in the file. -.TP -.I sh_size -This member holds the section's size in bytes. -Unless the section type -is -.BR SHT_NOBITS , -the section occupies -.I sh_size -bytes in the file. -A section of type -.B SHT_NOBITS -may have a nonzero size, but it occupies no space in the file. -.TP -.I sh_link -This member holds a section header table index link, whose interpretation -depends on the section type. -.TP -.I sh_info -This member holds extra information, whose interpretation depends on the -section type. -.TP -.I sh_addralign -Some sections have address alignment constraints. -If a section holds a -doubleword, the system must ensure doubleword alignment for the entire -section. -That is, the value of -.I sh_addr -must be congruent to zero, modulo the value of -.IR sh_addralign . -Only zero and positive integral powers of two are allowed. -The value 0 or 1 means that the section has no alignment constraints. -.TP -.I sh_entsize -Some sections hold a table of fixed-sized entries, such as a symbol table. -For such a section, this member gives the size in bytes for each entry. -This member contains zero if the section does not hold a table of -fixed-size entries. -.P -Various sections hold program and control information: -.TP -.I .bss -This section holds uninitialized data that contributes to the program's -memory image. -By definition, the system initializes the data with zeros -when the program begins to run. -This section is of type -.BR SHT_NOBITS . -The attribute types are -.B SHF_ALLOC -and -.BR SHF_WRITE . -.TP -.I .comment -This section holds version control information. -This section is of type -.BR SHT_PROGBITS . -No attribute types are used. -.TP -.I .ctors -This section holds initialized pointers to the C++ constructor functions. -This section is of type -.BR SHT_PROGBITS . -The attribute types are -.B SHF_ALLOC -and -.BR SHF_WRITE . -.TP -.I .data -This section holds initialized data that contribute to the program's -memory image. -This section is of type -.BR SHT_PROGBITS . -The attribute types are -.B SHF_ALLOC -and -.BR SHF_WRITE . -.TP -.I .data1 -This section holds initialized data that contribute to the program's -memory image. -This section is of type -.BR SHT_PROGBITS . -The attribute types are -.B SHF_ALLOC -and -.BR SHF_WRITE . -.TP -.I .debug -This section holds information for symbolic debugging. -The contents -are unspecified. -This section is of type -.BR SHT_PROGBITS . -No attribute types are used. -.TP -.I .dtors -This section holds initialized pointers to the C++ destructor functions. -This section is of type -.BR SHT_PROGBITS . -The attribute types are -.B SHF_ALLOC -and -.BR SHF_WRITE . -.TP -.I .dynamic -This section holds dynamic linking information. -The section's attributes -will include the -.B SHF_ALLOC -bit. -Whether the -.B SHF_WRITE -bit is set is processor-specific. -This section is of type -.BR SHT_DYNAMIC . -See the attributes above. -.TP -.I .dynstr -This section holds strings needed for dynamic linking, most commonly -the strings that represent the names associated with symbol table entries. -This section is of type -.BR SHT_STRTAB . -The attribute type used is -.BR SHF_ALLOC . -.TP -.I .dynsym -This section holds the dynamic linking symbol table. -This section is of type -.BR SHT_DYNSYM . -The attribute used is -.BR SHF_ALLOC . -.TP -.I .fini -This section holds executable instructions that contribute to the process -termination code. -When a program exits normally the system arranges to -execute the code in this section. -This section is of type -.BR SHT_PROGBITS . -The attributes used are -.B SHF_ALLOC -and -.BR SHF_EXECINSTR . -.TP -.I .gnu.version -This section holds the version symbol table, an array of -.I ElfN_Half -elements. -This section is of type -.BR SHT_GNU_versym . -The attribute type used is -.BR SHF_ALLOC . -.TP -.I .gnu.version_d -This section holds the version symbol definitions, a table of -.I ElfN_Verdef -structures. -This section is of type -.BR SHT_GNU_verdef . -The attribute type used is -.BR SHF_ALLOC . -.TP -.I .gnu.version_r -This section holds the version symbol needed elements, a table of -.I ElfN_Verneed -structures. -This section is of -type -.BR SHT_GNU_versym . -The attribute type used is -.BR SHF_ALLOC . -.TP -.I .got -This section holds the global offset table. -This section is of type -.BR SHT_PROGBITS . -The attributes are processor-specific. -.TP -.I .hash -This section holds a symbol hash table. -This section is of type -.BR SHT_HASH . -The attribute used is -.BR SHF_ALLOC . -.TP -.I .init -This section holds executable instructions that contribute to the process -initialization code. -When a program starts to run the system arranges to execute -the code in this section before calling the main program entry point. -This section is of type -.BR SHT_PROGBITS . -The attributes used are -.B SHF_ALLOC -and -.BR SHF_EXECINSTR . -.TP -.I .interp -This section holds the pathname of a program interpreter. -If the file has -a loadable segment that includes the section, the section's attributes will -include the -.B SHF_ALLOC -bit. -Otherwise, that bit will be off. -This section is of type -.BR SHT_PROGBITS . -.TP -.I .line -This section holds line number information for symbolic debugging, -which describes the correspondence between the program source and -the machine code. -The contents are unspecified. -This section is of type -.BR SHT_PROGBITS . -No attribute types are used. -.TP -.I .note -This section holds various notes. -This section is of type -.BR SHT_NOTE . -No attribute types are used. -.TP -.I .note.ABI\-tag -This section is used to declare the expected run-time ABI of the ELF image. -It may include the operating system name and its run-time versions. -This section is of type -.BR SHT_NOTE . -The only attribute used is -.BR SHF_ALLOC . -.TP -.I .note.gnu.build\-id -This section is used to hold an ID that uniquely identifies -the contents of the ELF image. -Different files with the same build ID should contain the same executable -content. -See the -.B \-\-build\-id -option to the GNU linker (\fBld\fR (1)) for more details. -This section is of type -.BR SHT_NOTE . -The only attribute used is -.BR SHF_ALLOC . -.TP -.I .note.GNU\-stack -This section is used in Linux object files for declaring stack attributes. -This section is of type -.BR SHT_PROGBITS . -The only attribute used is -.BR SHF_EXECINSTR . -This indicates to the GNU linker that the object file requires an -executable stack. -.TP -.I .note.openbsd.ident -OpenBSD native executables usually contain this section -to identify themselves so the kernel can bypass any compatibility -ELF binary emulation tests when loading the file. -.TP -.I .plt -This section holds the procedure linkage table. -This section is of type -.BR SHT_PROGBITS . -The attributes are processor-specific. -.TP -.I .relNAME -This section holds relocation information as described below. -If the file -has a loadable segment that includes relocation, the section's attributes -will include the -.B SHF_ALLOC -bit. -Otherwise, the bit will be off. -By convention, -"NAME" -is supplied by the section to which the relocations apply. -Thus a relocation -section for -.B .text -normally would have the name -.BR .rel.text . -This section is of type -.BR SHT_REL . -.TP -.I .relaNAME -This section holds relocation information as described below. -If the file -has a loadable segment that includes relocation, the section's attributes -will include the -.B SHF_ALLOC -bit. -Otherwise, the bit will be off. -By convention, -"NAME" -is supplied by the section to which the relocations apply. -Thus a relocation -section for -.B .text -normally would have the name -.BR .rela.text . -This section is of type -.BR SHT_RELA . -.TP -.I .rodata -This section holds read-only data that typically contributes to a -nonwritable segment in the process image. -This section is of type -.BR SHT_PROGBITS . -The attribute used is -.BR SHF_ALLOC . -.TP -.I .rodata1 -This section holds read-only data that typically contributes to a -nonwritable segment in the process image. -This section is of type -.BR SHT_PROGBITS . -The attribute used is -.BR SHF_ALLOC . -.TP -.I .shstrtab -This section holds section names. -This section is of type -.BR SHT_STRTAB . -No attribute types are used. -.TP -.I .strtab -This section holds strings, most commonly the strings that represent the -names associated with symbol table entries. -If the file has a loadable -segment that includes the symbol string table, the section's attributes -will include the -.B SHF_ALLOC -bit. -Otherwise, the bit will be off. -This section is of type -.BR SHT_STRTAB . -.TP -.I .symtab -This section holds a symbol table. -If the file has a loadable segment -that includes the symbol table, the section's attributes will include -the -.B SHF_ALLOC -bit. -Otherwise, the bit will be off. -This section is of type -.BR SHT_SYMTAB . -.TP -.I .text -This section holds the -"text", -or executable instructions, of a program. -This section is of type -.BR SHT_PROGBITS . -The attributes used are -.B SHF_ALLOC -and -.BR SHF_EXECINSTR . -.\" -.SS String and symbol tables -String table sections hold null-terminated character sequences, commonly -called strings. -The object file uses these strings to represent symbol -and section names. -One references a string as an index into the string -table section. -The first byte, which is index zero, is defined to hold -a null byte (\[aq]\e0\[aq]). -Similarly, a string table's last byte is defined to -hold a null byte, ensuring null termination for all strings. -.P -An object file's symbol table holds information needed to locate and -relocate a program's symbolic definitions and references. -A symbol table -index is a subscript into this array. -.P -.in +4n -.EX -typedef struct { - uint32_t st_name; - Elf32_Addr st_value; - uint32_t st_size; - unsigned char st_info; - unsigned char st_other; - uint16_t st_shndx; -} Elf32_Sym; -.EE -.in -.P -.in +4n -.EX -typedef struct { - uint32_t st_name; - unsigned char st_info; - unsigned char st_other; - uint16_t st_shndx; - Elf64_Addr st_value; - uint64_t st_size; -} Elf64_Sym; -.EE -.in -.P -The 32-bit and 64-bit versions have the same members, just in a different -order. -.TP -.I st_name -This member holds an index into the object file's symbol string table, -which holds character representations of the symbol names. -If the value -is nonzero, it represents a string table index that gives the symbol -name. -Otherwise, the symbol has no name. -.TP -.I st_value -This member gives the value of the associated symbol. -.TP -.I st_size -Many symbols have associated sizes. -This member holds zero if the symbol -has no size or an unknown size. -.TP -.I st_info -This member specifies the symbol's type and binding attributes: -.RS -.TP -.B STT_NOTYPE -The symbol's type is not defined. -.TP -.B STT_OBJECT -The symbol is associated with a data object. -.TP -.B STT_FUNC -The symbol is associated with a function or other executable code. -.TP -.B STT_SECTION -The symbol is associated with a section. -Symbol table entries of -this type exist primarily for relocation and normally have -.B STB_LOCAL -bindings. -.TP -.B STT_FILE -By convention, the symbol's name gives the name of the source file -associated with the object file. -A file symbol has -.B STB_LOCAL -bindings, its section index is -.BR SHN_ABS , -and it precedes the other -.B STB_LOCAL -symbols of the file, if it is present. -.TP -.B STT_LOPROC -.TQ -.B STT_HIPROC -Values in the inclusive range -.RB [ STT_LOPROC , -.BR STT_HIPROC ] -are reserved for processor-specific semantics. -.TP -.B STB_LOCAL -Local symbols are not visible outside the object file containing their -definition. -Local symbols of the same name may exist in multiple files -without interfering with each other. -.TP -.B STB_GLOBAL -Global symbols are visible to all object files being combined. -One file's -definition of a global symbol will satisfy another file's undefined -reference to the same symbol. -.TP -.B STB_WEAK -Weak symbols resemble global symbols, but their definitions have lower -precedence. -.TP -.B STB_LOPROC -.TQ -.B STB_HIPROC -Values in the inclusive range -.RB [ STB_LOPROC , -.BR STB_HIPROC ] -are reserved for processor-specific semantics. -.RE -.IP -There are macros for packing and unpacking the binding and type fields: -.RS -.TP -.BI ELF32_ST_BIND( info ) -.TQ -.BI ELF64_ST_BIND( info ) -Extract a binding from an -.I st_info -value. -.TP -.BI ELF32_ST_TYPE( info ) -.TQ -.BI ELF64_ST_TYPE( info ) -Extract a type from an -.I st_info -value. -.TP -.BI ELF32_ST_INFO( bind ", " type ) -.TQ -.BI ELF64_ST_INFO( bind ", " type ) -Convert a binding and a type into an -.I st_info -value. -.RE -.TP -.I st_other -This member defines the symbol visibility. -.RS -.TP -.PD 0 -.B STV_DEFAULT -Default symbol visibility rules. -Global and weak symbols are available to other modules; -references in the local module can be interposed -by definitions in other modules. -.TP -.B STV_INTERNAL -Processor-specific hidden class. -.TP -.B STV_HIDDEN -Symbol is unavailable to other modules; -references in the local module always resolve to the local symbol -(i.e., the symbol can't be interposed by definitions in other modules). -.TP -.B STV_PROTECTED -Symbol is available to other modules, -but references in the local module always resolve to the local symbol. -.PD -.P -There are macros for extracting the visibility type: -.P -.BR ELF32_ST_VISIBILITY (other) -or -.BR ELF64_ST_VISIBILITY (other) -.RE -.TP -.I st_shndx -Every symbol table entry is -"defined" -in relation to some section. -This member holds the relevant section -header table index. -.\" -.SS Relocation entries (Rel & Rela) -Relocation is the process of connecting symbolic references with -symbolic definitions. -Relocatable files must have information that -describes how to modify their section contents, thus allowing executable -and shared object files to hold the right information for a process's -program image. -Relocation entries are these data. -.P -Relocation structures that do not need an addend: -.P -.in +4n -.EX -typedef struct { - Elf32_Addr r_offset; - uint32_t r_info; -} Elf32_Rel; -.EE -.in -.P -.in +4n -.EX -typedef struct { - Elf64_Addr r_offset; - uint64_t r_info; -} Elf64_Rel; -.EE -.in -.P -Relocation structures that need an addend: -.P -.in +4n -.EX -typedef struct { - Elf32_Addr r_offset; - uint32_t r_info; - int32_t r_addend; -} Elf32_Rela; -.EE -.in -.P -.in +4n -.EX -typedef struct { - Elf64_Addr r_offset; - uint64_t r_info; - int64_t r_addend; -} Elf64_Rela; -.EE -.in -.TP -.I r_offset -This member gives the location at which to apply the relocation action. -For a relocatable file, the value is the byte offset from the beginning -of the section to the storage unit affected by the relocation. -For an -executable file or shared object, the value is the virtual address of -the storage unit affected by the relocation. -.TP -.I r_info -This member gives both the symbol table index with respect to which the -relocation must be made and the type of relocation to apply. -Relocation -types are processor-specific. -When the text refers to a relocation -entry's relocation type or symbol table index, it means the result of -applying -.B ELF[32|64]_R_TYPE -or -.BR ELF[32|64]_R_SYM , -respectively, to the entry's -.I r_info -member. -.TP -.I r_addend -This member specifies a constant addend used to compute the value to be -stored into the relocatable field. -.\" -.SS Dynamic tags (Dyn) -The -.I .dynamic -section contains a series of structures that hold relevant -dynamic linking information. -The -.I d_tag -member controls the interpretation -of -.IR d_un . -.P -.in +4n -.EX -typedef struct { - Elf32_Sword d_tag; - union { - Elf32_Word d_val; - Elf32_Addr d_ptr; - } d_un; -} Elf32_Dyn; -extern Elf32_Dyn _DYNAMIC[]; -.EE -.in -.P -.in +4n -.EX -typedef struct { - Elf64_Sxword d_tag; - union { - Elf64_Xword d_val; - Elf64_Addr d_ptr; - } d_un; -} Elf64_Dyn; -extern Elf64_Dyn _DYNAMIC[]; -.EE -.in -.TP -.I d_tag -This member may have any of the following values: -.RS -.TP 12 -.B DT_NULL -Marks end of dynamic section -.TP -.B DT_NEEDED -String table offset to name of a needed library -.TP -.B DT_PLTRELSZ -Size in bytes of PLT relocation entries -.TP -.B DT_PLTGOT -Address of PLT and/or GOT -.TP -.B DT_HASH -Address of symbol hash table -.TP -.B DT_STRTAB -Address of string table -.TP -.B DT_SYMTAB -Address of symbol table -.TP -.B DT_RELA -Address of Rela relocation table -.TP -.B DT_RELASZ -Size in bytes of the Rela relocation table -.TP -.B DT_RELAENT -Size in bytes of a Rela relocation table entry -.TP -.B DT_STRSZ -Size in bytes of string table -.TP -.B DT_SYMENT -Size in bytes of a symbol table entry -.TP -.B DT_INIT -Address of the initialization function -.TP -.B DT_FINI -Address of the termination function -.TP -.B DT_SONAME -String table offset to name of shared object -.TP -.B DT_RPATH -String table offset to library search path (deprecated) -.TP -.B DT_SYMBOLIC -Alert linker to search this shared object before the executable for symbols -.TP -.B DT_REL -Address of Rel relocation table -.TP -.B DT_RELSZ -Size in bytes of Rel relocation table -.TP -.B DT_RELENT -Size in bytes of a Rel table entry -.TP -.B DT_PLTREL -Type of relocation entry to which the PLT refers (Rela or Rel) -.TP -.B DT_DEBUG -Undefined use for debugging -.TP -.B DT_TEXTREL -Absence of this entry indicates that no relocation entries should -apply to a nonwritable segment -.TP -.B DT_JMPREL -Address of relocation entries associated solely with the PLT -.TP -.B DT_BIND_NOW -Instruct dynamic linker to process all relocations before -transferring control to the executable -.TP -.B DT_RUNPATH -String table offset to library search path -.TP -.B DT_LOPROC -.TQ -.B DT_HIPROC -Values in the inclusive range -.RB [ DT_LOPROC , -.BR DT_HIPROC ] -are reserved for processor-specific semantics -.RE -.TP -.I d_val -This member represents integer values with various interpretations. -.TP -.I d_ptr -This member represents program virtual addresses. -When interpreting -these addresses, the actual address should be computed based on the -original file value and memory base address. -Files do not contain -relocation entries to fixup these addresses. -.TP -.I _DYNAMIC -Array containing all the dynamic structures in the -.I .dynamic -section. -This is automatically populated by the linker. -.\" GABI ELF Reference for Note Sections: -.\" http://www.sco.com/developers/gabi/latest/ch5.pheader.html#note_section -.\" -.\" Note that it implies the sizes and alignments of notes depend on the ELF -.\" size (e.g. 32-bit ELFs have three 4-byte words and use 4-byte alignment -.\" while 64-bit ELFs use 8-byte words & alignment), but that is not the case -.\" in the real world. Notes always have three 4-byte words as can be seen -.\" in the source links below (remember that Elf64_Word is a 32-bit quantity). -.\" glibc: https://sourceware.org/git/?p=glibc.git;a=blob;f=elf/elf.h;h=9e59b3275917549af0cebe1f2de9ded3b7b10bf2#l1173 -.\" binutils: https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=binutils/readelf.c;h=274ddd17266aef6e4ad1f67af8a13a21500ff2af#l15943 -.\" Linux: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/elf.h?h=v4.8#n422 -.\" Solaris: https://docs.oracle.com/cd/E23824_01/html/819-0690/chapter6-18048.html -.\" FreeBSD: https://svnweb.freebsd.org/base/head/sys/sys/elf_common.h?revision=303677&view=markup#l33 -.\" NetBSD: https://www.netbsd.org/docs/kernel/elf-notes.html -.\" OpenBSD: https://github.com/openbsd/src/blob/master/sys/sys/exec_elf.h#L533 -.\" -.SS Notes (Nhdr) -ELF notes allow for appending arbitrary information for the system to use. -They are largely used by core files -.RI ( e_type -of -.BR ET_CORE ), -but many projects define their own set of extensions. -For example, -the GNU tool chain uses ELF notes to pass information from -the linker to the C library. -.P -Note sections contain a series of notes (see the -.I struct -definitions below). -Each note is followed by the name field (whose length is defined in -\fIn_namesz\fR) and then by the descriptor field (whose length is defined in -\fIn_descsz\fR) and whose starting address has a 4 byte alignment. -Neither field is defined in the note struct due to their arbitrary lengths. -.P -An example for parsing out two consecutive notes should clarify their layout -in memory: -.P -.in +4n -.EX -void *memory, *name, *desc; -Elf64_Nhdr *note, *next_note; -\& -/* The buffer is pointing to the start of the section/segment. */ -note = memory; -\& -/* If the name is defined, it follows the note. */ -name = note\->n_namesz == 0 ? NULL : memory + sizeof(*note); -\& -/* If the descriptor is defined, it follows the name - (with alignment). */ -\& -desc = note\->n_descsz == 0 ? NULL : - memory + sizeof(*note) + ALIGN_UP(note\->n_namesz, 4); -\& -/* The next note follows both (with alignment). */ -next_note = memory + sizeof(*note) + - ALIGN_UP(note\->n_namesz, 4) + - ALIGN_UP(note\->n_descsz, 4); -.EE -.in -.P -Keep in mind that the interpretation of -.I n_type -depends on the namespace defined by the -.I n_namesz -field. -If the -.I n_namesz -field is not set (e.g., is 0), then there are two sets of notes: -one for core files and one for all other ELF types. -If the namespace is unknown, then tools will usually fallback to these sets -of notes as well. -.P -.in +4n -.EX -typedef struct { - Elf32_Word n_namesz; - Elf32_Word n_descsz; - Elf32_Word n_type; -} Elf32_Nhdr; -.EE -.in -.P -.in +4n -.EX -typedef struct { - Elf64_Word n_namesz; - Elf64_Word n_descsz; - Elf64_Word n_type; -} Elf64_Nhdr; -.EE -.in -.TP -.I n_namesz -The length of the name field in bytes. -The contents will immediately follow this note in memory. -The name is null terminated. -For example, if the name is "GNU", then -.I n_namesz -will be set to 4. -.TP -.I n_descsz -The length of the descriptor field in bytes. -The contents will immediately follow the name field in memory. -.TP -.I n_type -Depending on the value of the name field, this member may have any of the -following values: -.RS -.TP 5 -.B Core files (e_type = ET_CORE) -Notes used by all core files. -These are highly operating system or architecture specific and often require -close coordination with kernels, C libraries, and debuggers. -These are used when the namespace is the default (i.e., -.I n_namesz -will be set to 0), or a fallback when the namespace is unknown. -.RS -.TP 21 -.PD 0 -.B NT_PRSTATUS -prstatus struct -.TP -.B NT_FPREGSET -fpregset struct -.TP -.B NT_PRPSINFO -prpsinfo struct -.TP -.B NT_PRXREG -prxregset struct -.TP -.B NT_TASKSTRUCT -task structure -.TP -.B NT_PLATFORM -String from sysinfo(SI_PLATFORM) -.TP -.B NT_AUXV -auxv array -.TP -.B NT_GWINDOWS -gwindows struct -.TP -.B NT_ASRS -asrset struct -.TP -.B NT_PSTATUS -pstatus struct -.TP -.B NT_PSINFO -psinfo struct -.TP -.B NT_PRCRED -prcred struct -.TP -.B NT_UTSNAME -utsname struct -.TP -.B NT_LWPSTATUS -lwpstatus struct -.TP -.B NT_LWPSINFO -lwpinfo struct -.TP -.B NT_PRFPXREG -fprxregset struct -.TP -.B NT_SIGINFO -siginfo_t (size might increase over time) -.TP -.B NT_FILE -Contains information about mapped files -.TP -.B NT_PRXFPREG -user_fxsr_struct -.TP -.B NT_PPC_VMX -PowerPC Altivec/VMX registers -.TP -.B NT_PPC_SPE -PowerPC SPE/EVR registers -.TP -.B NT_PPC_VSX -PowerPC VSX registers -.TP -.B NT_386_TLS -i386 TLS slots (struct user_desc) -.TP -.B NT_386_IOPERM -x86 io permission bitmap (1=deny) -.TP -.B NT_X86_XSTATE -x86 extended state using xsave -.TP -.B NT_S390_HIGH_GPRS -s390 upper register halves -.TP -.B NT_S390_TIMER -s390 timer register -.TP -.B NT_S390_TODCMP -s390 time-of-day (TOD) clock comparator register -.TP -.B NT_S390_TODPREG -s390 time-of-day (TOD) programmable register -.TP -.B NT_S390_CTRS -s390 control registers -.TP -.B NT_S390_PREFIX -s390 prefix register -.TP -.B NT_S390_LAST_BREAK -s390 breaking event address -.TP -.B NT_S390_SYSTEM_CALL -s390 system call restart data -.TP -.B NT_S390_TDB -s390 transaction diagnostic block -.TP -.B NT_ARM_VFP -ARM VFP/NEON registers -.TP -.B NT_ARM_TLS -ARM TLS register -.TP -.B NT_ARM_HW_BREAK -ARM hardware breakpoint registers -.TP -.B NT_ARM_HW_WATCH -ARM hardware watchpoint registers -.TP -.B NT_ARM_SYSTEM_CALL -ARM system call number -.PD -.RE -.TP -.B n_name = GNU -Extensions used by the GNU tool chain. -.RS -.TP -.B NT_GNU_ABI_TAG -Operating system (OS) ABI information. -The desc field will be 4 words: -.IP -.PD 0 -.RS -.IP [0] 5 -OS descriptor -(\fBELF_NOTE_OS_LINUX\fR, \fBELF_NOTE_OS_GNU\fR, and so on)` -.IP [1] -major version of the ABI -.IP [2] -minor version of the ABI -.IP [3] -subminor version of the ABI -.RE -.PD -.TP -.B NT_GNU_HWCAP -Synthetic hwcap information. -The desc field begins with two words: -.IP -.PD 0 -.RS -.IP [0] 5 -number of entries -.IP [1] -bit mask of enabled entries -.RE -.PD -.IP -Then follow variable-length entries, one byte followed by a null-terminated -hwcap name string. -The byte gives the bit number to test if enabled, (1U << bit) & bit mask. -.TP -.B NT_GNU_BUILD_ID -Unique build ID as generated by the GNU -.BR ld (1) -.B \-\-build\-id -option. -The desc consists of any nonzero number of bytes. -.TP -.B NT_GNU_GOLD_VERSION -The desc contains the GNU Gold linker version used. -.RE -.TP -.B Default/unknown namespace (e_type != ET_CORE) -These are used when the namespace is the default (i.e., -.I n_namesz -will be set to 0), or a fallback when the namespace is unknown. -.RS -.TP 12 -.PD 0 -.B NT_VERSION -A version string of some sort. -.TP -.B NT_ARCH -Architecture information. -.PD -.RE -.RE -.SH NOTES -.\" OpenBSD -.\" ELF support first appeared in -.\" OpenBSD 1.2, -.\" although not all supported platforms use it as the native -.\" binary file format. -ELF first appeared in -System V. -The ELF format is an adopted standard. -.P -The extensions for -.IR e_phnum , -.IR e_shnum , -and -.I e_shstrndx -respectively are -Linux extensions. -Sun, BSD, and AMD64 also support them; for further information, -look under SEE ALSO. -.\" .SH AUTHORS -.\" The original version of this manual page was written by -.\" .An Jeroen Ruigrok van der Werven -.\" .Aq asmodai@FreeBSD.org -.\" with inspiration from BSDi's -.\" .Bsx -.\" .Nm elf -.\" man page. -.SH SEE ALSO -.BR as (1), -.BR elfedit (1), -.BR gdb (1), -.BR ld (1), -.BR nm (1), -.BR objcopy (1), -.BR objdump (1), -.BR patchelf (1), -.BR readelf (1), -.BR size (1), -.BR strings (1), -.BR strip (1), -.BR execve (2), -.BR dl_iterate_phdr (3), -.BR core (5), -.BR ld.so (8) -.P -Hewlett-Packard, -.IR "Elf-64 Object File Format" . -.P -Santa Cruz Operation, -.IR "System V Application Binary Interface" . -.P -UNIX System Laboratories, -"Object Files", -.IR "Executable and Linking Format (ELF)" . -.P -Sun Microsystems, -.IR "Linker and Libraries Guide" . -.P -AMD64 ABI Draft, -.IR "System V Application Binary Interface AMD64 Architecture Processor Supplement" . |