{ "content": [ { "type": "text", "text": "# ELF(5) (man)\n\n**Summary:** elf - format of Executable and Linking Format (ELF) files\n\n## See Also\n\n- as(1)\n- elfedit(1)\n- gdb(1)\n- ld(1)\n- nm(1)\n- objcopy(1)\n- objdump(1)\n- patchelf(1)\n- readelf(1)\n- size(1)\n- strings(1)\n- strip(1)\n- execve(2)\n- dliteratephdr(3)\n- core(5)\n- ld.so(8)\n\n## Section Outline\n\n- **NAME** (2 lines)\n- **SYNOPSIS** (1 lines) — 1 subsections\n - #include (1 lines)\n- **DESCRIPTION** (12 lines) — 9 subsections\n - Basic types (23 lines)\n - ELF header (Ehdr) (197 lines)\n - Program header (Phdr) (118 lines)\n - Section header (Shdr) (340 lines)\n - String and symbol tables (115 lines)\n - ELF32___ST___VISIBILITY(other) (4 lines)\n - Relocation entries (Rel & Rela) (47 lines)\n - Dynamic tags (Dyn) (92 lines)\n - Notes (Nhdr) (142 lines)\n- **NOTES** (5 lines)\n- **SEE ALSO** (14 lines)\n- **COLOPHON** (7 lines)\n\n## Full Content\n\n### NAME\n\nelf - format of Executable and Linking Format (ELF) files\n\n### SYNOPSIS\n\n#### #include \n\n### DESCRIPTION\n\nThe header file defines the format of ELF executable binary files. Amongst these\nfiles are normal executable files, relocatable object files, core files, and shared objects.\n\nAn executable file using the ELF file format consists of an ELF header, followed by a program\nheader table or a section header table, or both. The ELF header is always at offset zero of\nthe file. The program header table and the section header table's offset in the file are de‐\nfined in the ELF header. The two tables describe the rest of the particularities of the\nfile.\n\nThis header file describes the above mentioned headers as C structures and also includes\nstructures for dynamic sections, relocation sections and symbol tables.\n\n#### Basic types\n\nThe following types are used for N-bit architectures (N=32,64, ElfN stands for Elf32 or\nElf64, uintNt stands for uint32t or uint64t):\n\nElfNAddr Unsigned program address, uintNt\nElfNOff Unsigned file offset, uintNt\nElfNSection Unsigned section index, uint16t\nElfNVersym Unsigned version symbol information, uint16t\nElfByte unsigned char\nElfNHalf uint16t\nElfNSword int32t\nElfNWord uint32t\nElfNSxword int64t\nElfNXword uint64t\n\n(Note: the *BSD terminology is a bit different. There, Elf64Half is twice as large as\nElf32Half, and Elf64Quarter is used for uint16t. In order to avoid confusion these types\nare replaced by explicit ones in the below.)\n\nAll data structures that the file format defines follow the \"natural\" size and alignment\nguidelines for the relevant class. If necessary, data structures contain explicit padding to\nensure 4-byte alignment for 4-byte objects, to force structure sizes to a multiple of 4, and\nso on.\n\n#### ELF header (Ehdr)\n\nThe ELF header is described by the type Elf32Ehdr or Elf64Ehdr:\n\n#define EINIDENT 16\n\ntypedef struct {\nunsigned char eident[EINIDENT];\nuint16t etype;\nuint16t emachine;\nuint32t eversion;\nElfNAddr eentry;\nElfNOff ephoff;\nElfNOff eshoff;\nuint32t eflags;\nuint16t eehsize;\nuint16t ephentsize;\nuint16t ephnum;\nuint16t eshentsize;\nuint16t eshnum;\nuint16t eshstrndx;\n} ElfNEhdr;\n\nThe fields have the following meanings:\n\neident\nThis array of bytes specifies how to interpret the file, independent of the processor\nor the file's remaining contents. Within this array everything is named by macros,\nwhich start with the prefix EI and may contain values which start with the prefix\nELF. The following macros are defined:\n\nEIMAG0\nThe first byte of the magic number. It must be filled with ELFMAG0. (0: 0x7f)\n\nEIMAG1\nThe second byte of the magic number. It must be filled with ELFMAG1. (1: 'E')\n\nEIMAG2\nThe third byte of the magic number. It must be filled with ELFMAG2. (2: 'L')\n\nEIMAG3\nThe fourth byte of the magic number. It must be filled with ELFMAG3. (3: 'F')\n\nEICLASS\nThe fifth byte identifies the architecture for this binary:\n\nELFCLASSNONE This class is invalid.\nELFCLASS32 This defines the 32-bit architecture. It supports machines with\nfiles and virtual address spaces up to 4 Gigabytes.\nELFCLASS64 This defines the 64-bit architecture.\n\nEIDATA\nThe sixth byte specifies the data encoding of the processor-specific data in\nthe file. Currently, these encodings are supported:\n\nELFDATANONE Unknown data format.\nELFDATA2LSB Two's complement, little-endian.\nELFDATA2MSB Two's complement, big-endian.\n\nEIVERSION\nThe seventh byte is the version number of the ELF specification:\n\nEVNONE Invalid version.\nEVCURRENT Current version.\n\nEIOSABI\nThe eighth byte identifies the operating system and ABI to which the object is\ntargeted. Some fields in other ELF structures have flags and values that have\nplatform-specific meanings; the interpretation of those fields is determined by\nthe value of this byte. For example:\n\nELFOSABINONE Same as ELFOSABISYSV\nELFOSABISYSV UNIX System V ABI\nELFOSABIHPUX HP-UX ABI\nELFOSABINETBSD NetBSD ABI\nELFOSABILINUX Linux ABI\nELFOSABISOLARIS Solaris ABI\nELFOSABIIRIX IRIX ABI\nELFOSABIFREEBSD FreeBSD ABI\nELFOSABITRU64 TRU64 UNIX ABI\nELFOSABIARM ARM architecture ABI\nELFOSABISTANDALONE Stand-alone (embedded) ABI\n\nEIABIVERSION\nThe ninth byte identifies the version of the ABI to which the object is tar‐\ngeted. This field is used to distinguish among incompatible versions of an\nABI. The interpretation of this version number is dependent on the ABI identi‐\nfied by the EIOSABI field. Applications conforming to this specification use\nthe value 0.\n\nEIPAD Start of padding. These bytes are reserved and set to zero. Programs which\nread them should ignore them. The value for EIPAD will change in the future\nif currently unused bytes are given meanings.\n\nEINIDENT\nThe size of the eident array.\n\netype This member of the structure identifies the object file type:\n\nETNONE An unknown type.\nETREL A relocatable file.\nETEXEC An executable file.\nETDYN A shared object.\nETCORE A core file.\n\nemachine\nThis member specifies the required architecture for an individual file. For example:\n\nEMNONE An unknown machine\nEMM32 AT&T WE 32100\nEMSPARC Sun Microsystems SPARC\nEM386 Intel 80386\nEM68K Motorola 68000\nEM88K Motorola 88000\nEM860 Intel 80860\nEMMIPS MIPS RS3000 (big-endian only)\nEMPARISC HP/PA\nEMSPARC32PLUS SPARC with enhanced instruction set\nEMPPC PowerPC\nEMPPC64 PowerPC 64-bit\nEMS390 IBM S/390\nEMARM Advanced RISC Machines\nEMSH Renesas SuperH\nEMSPARCV9 SPARC v9 64-bit\nEMIA64 Intel Itanium\nEMX8664 AMD x86-64\nEMVAX DEC Vax\n\neversion\nThis member identifies the file version:\n\nEVNONE Invalid version\nEVCURRENT Current version\n\neentry\nThis member gives the virtual address to which the system first transfers control,\nthus starting the process. If the file has no associated entry point, this member\nholds zero.\n\nephoff\nThis member holds the program header table's file offset in bytes. If the file has no\nprogram header table, this member holds zero.\n\neshoff\nThis member holds the section header table's file offset in bytes. If the file has no\nsection header table, this member holds zero.\n\neflags\nThis member holds processor-specific flags associated with the file. Flag names take\nthe form EF`machineflag'. Currently, no flags have been defined.\n\neehsize\nThis member holds the ELF header's size in bytes.\n\nephentsize\nThis member holds the size in bytes of one entry in the file's program header table;\nall entries are the same size.\n\nephnum\nThis member holds the number of entries in the program header table. Thus the product\nof ephentsize and ephnum gives the table's size in bytes. If a file has no program\nheader, ephnum holds the value zero.\n\nIf the number of entries in the program header table is larger than or equal to\nPNXNUM (0xffff), this member holds PNXNUM (0xffff) and the real number of entries in\nthe program header table is held in the shinfo member of the initial entry in section\nheader table. Otherwise, the shinfo member of the initial entry contains the value\nzero.\n\nPNXNUM\nThis is defined as 0xffff, the largest number ephnum can have, specifying\nwhere the actual number of program headers is assigned.\n\neshentsize\nThis member holds a sections header's size in bytes. A section header is one entry in\nthe section header table; all entries are the same size.\n\neshnum\nThis member holds the number of entries in the section header table. Thus the product\nof eshentsize and eshnum gives the section header table's size in bytes. If a file\nhas no section header table, eshnum holds the value of zero.\n\nIf the number of entries in the section header table is larger than or equal to\nSHNLORESERVE (0xff00), eshnum holds the value zero and the real number of entries in\nthe section header table is held in the shsize member of the initial entry in section\nheader table. Otherwise, the shsize member of the initial entry in the section\nheader table holds the value zero.\n\neshstrndx\nThis member holds the section header table index of the entry associated with the sec‐\ntion name string table. If the file has no section name string table, this member\nholds the value SHNUNDEF.\n\nIf the index of section name string table section is larger than or equal to SHNLORE‐‐\nSERVE (0xff00), this member holds SHNXINDEX (0xffff) and the real index of the sec‐\ntion name string table section is held in the shlink member of the initial entry in\nsection header table. Otherwise, the shlink member of the initial entry in section\nheader table contains the value zero.\n\n#### Program header (Phdr)\n\nAn executable or shared object file's program header table is an array of structures, each\ndescribing a segment or other information the system needs to prepare the program for execu‐\ntion. An object file segment contains one or more sections. Program headers are meaningful\nonly for executable and shared object files. A file specifies its own program header size\nwith the ELF header's ephentsize and ephnum members. The ELF program header is described\nby the type Elf32Phdr or Elf64Phdr depending on the architecture:\n\ntypedef struct {\nuint32t ptype;\nElf32Off poffset;\nElf32Addr pvaddr;\nElf32Addr ppaddr;\nuint32t pfilesz;\nuint32t pmemsz;\nuint32t pflags;\nuint32t palign;\n} Elf32Phdr;\n\ntypedef struct {\nuint32t ptype;\nuint32t pflags;\nElf64Off poffset;\nElf64Addr pvaddr;\nElf64Addr ppaddr;\nuint64t pfilesz;\nuint64t pmemsz;\nuint64t palign;\n} Elf64Phdr;\n\nThe main difference between the 32-bit and the 64-bit program header lies in the location of\nthe pflags member in the total struct.\n\nptype This member of the structure indicates what kind of segment this array element de‐\nscribes or how to interpret the array element's information.\n\nPTNULL\nThe array element is unused and the other members' values are undefined.\nThis lets the program header have ignored entries.\n\nPTLOAD\nThe array element specifies a loadable segment, described by pfilesz and\npmemsz. The bytes from the file are mapped to the beginning of the memory\nsegment. If the segment's memory size pmemsz is larger than the file size\npfilesz, the \"extra\" bytes are defined to hold the value 0 and to follow\nthe segment's initialized area. The file size may not be larger than the\nmemory size. Loadable segment entries in the program header table appear in\nascending order, sorted on the pvaddr member.\n\nPTDYNAMIC\nThe array element specifies dynamic linking information.\n\nPTINTERP\nThe array element specifies the location and size of a null-terminated path‐\nname to invoke as an interpreter. This segment type is meaningful only for\nexecutable files (though it may occur for shared objects). However it may\nnot occur more than once in a file. If it is present, it must precede any\nloadable segment entry.\n\nPTNOTE\nThe array element specifies the location of notes (ElfNNhdr).\n\nPTSHLIB\nThis segment type is reserved but has unspecified semantics. Programs that\ncontain an array element of this type do not conform to the ABI.\n\nPTPHDR\nThe array element, if present, specifies the location and size of the pro‐\ngram header table itself, both in the file and in the memory image of the\nprogram. This segment type may not occur more than once in a file. More‐\nover, it may occur only if the program header table is part of the memory\nimage of the program. If it is present, it must precede any loadable seg‐\nment entry.\n\nPTLOPROC, PTHIPROC\nValues in the inclusive range [PTLOPROC, PTHIPROC] are reserved for pro‐\ncessor-specific semantics.\n\nPTGNUSTACK\nGNU extension which is used by the Linux kernel to control the state of the\nstack via the flags set in the pflags member.\n\npoffset\nThis member holds the offset from the beginning of the file at which the first byte of\nthe segment resides.\n\npvaddr\nThis member holds the virtual address at which the first byte of the segment resides\nin memory.\n\nppaddr\nOn systems for which physical addressing is relevant, this member is reserved for the\nsegment's physical address. Under BSD this member is not used and must be zero.\n\npfilesz\nThis member holds the number of bytes in the file image of the segment. It may be\nzero.\n\npmemsz\nThis member holds the number of bytes in the memory image of the segment. It may be\nzero.\n\npflags\nThis member holds a bit mask of flags relevant to the segment:\n\nPFX An executable segment.\nPFW A writable segment.\nPFR A readable segment.\n\nA text segment commonly has the flags PFX and PFR. A data segment commonly has PFW\nand PFR.\n\npalign\nThis member holds the value to which the segments are aligned in memory and in the\nfile. Loadable process segments must have congruent values for pvaddr and poffset,\nmodulo the page size. Values of zero and one mean no alignment is required. Other‐\nwise, palign should be a positive, integral power of two, and pvaddr should equal\npoffset, modulo palign.\n\n#### Section header (Shdr)\n\nA file's section header table lets one locate all the file's sections. The section header\ntable is an array of Elf32Shdr or Elf64Shdr structures. The ELF header's eshoff member\ngives the byte offset from the beginning of the file to the section header table. eshnum\nholds the number of entries the section header table contains. eshentsize holds the size in\nbytes of each entry.\n\nA section header table index is a subscript into this array. Some section header table in‐\ndices are reserved: the initial entry and the indices between SHNLORESERVE and SHNHIRE‐‐\nSERVE. The initial entry is used in ELF extensions for ephnum, eshnum, and eshstrndx; in\nother cases, each field in the initial entry is set to zero. An object file does not have\nsections for these special indices:\n\nSHNUNDEF\nThis value marks an undefined, missing, irrelevant, or otherwise meaningless section\nreference.\n\nSHNLORESERVE\nThis value specifies the lower bound of the range of reserved indices.\n\nSHNLOPROC, SHNHIPROC\nValues greater in the inclusive range [SHNLOPROC, SHNHIPROC] are reserved for pro‐\ncessor-specific semantics.\n\nSHNABS\nThis value specifies the absolute value for the corresponding reference. For example,\na symbol defined relative to section number SHNABS has an absolute value and is not\naffected by relocation.\n\nSHNCOMMON\nSymbols defined relative to this section are common symbols, such as FORTRAN COMMON or\nunallocated C external variables.\n\nSHNHIRESERVE\nThis value specifies the upper bound of the range of reserved indices. The system re‐\nserves indices between SHNLORESERVE and SHNHIRESERVE, inclusive. The section header\ntable does not contain entries for the reserved indices.\n\nThe section header has the following structure:\n\ntypedef struct {\nuint32t shname;\nuint32t shtype;\nuint32t shflags;\nElf32Addr shaddr;\nElf32Off shoffset;\nuint32t shsize;\nuint32t shlink;\nuint32t shinfo;\nuint32t shaddralign;\nuint32t shentsize;\n} Elf32Shdr;\n\ntypedef struct {\nuint32t shname;\nuint32t shtype;\nuint64t shflags;\nElf64Addr shaddr;\nElf64Off shoffset;\nuint64t shsize;\nuint32t shlink;\nuint32t shinfo;\nuint64t shaddralign;\nuint64t shentsize;\n} Elf64Shdr;\n\nNo real differences exist between the 32-bit and 64-bit section headers.\n\nshname\nThis member specifies the name of the section. Its value is an index into the section\nheader string table section, giving the location of a null-terminated string.\n\nshtype\nThis member categorizes the section's contents and semantics.\n\nSHTNULL\nThis value marks the section header as inactive. It does not have an associ‐\nated section. Other members of the section header have undefined values.\n\nSHTPROGBITS\nThis section holds information defined by the program, whose format and meaning\nare determined solely by the program.\n\nSHTSYMTAB\nThis section holds a symbol table. Typically, SHTSYMTAB provides symbols for\nlink editing, though it may also be used for dynamic linking. As a complete\nsymbol table, it may contain many symbols unnecessary for dynamic linking. An\nobject file can also contain a SHTDYNSYM section.\n\nSHTSTRTAB\nThis section holds a string table. An object file may have multiple string ta‐\nble sections.\n\nSHTRELA\nThis section holds relocation entries with explicit addends, such as type\nElf32Rela for the 32-bit class of object files. An object may have multiple\nrelocation sections.\n\nSHTHASH\nThis section holds a symbol hash table. An object participating in dynamic\nlinking must contain a symbol hash table. An object file may have only one\nhash table.\n\nSHTDYNAMIC\nThis section holds information for dynamic linking. An object file may have\nonly one dynamic section.\n\nSHTNOTE\nThis section holds notes (ElfNNhdr).\n\nSHTNOBITS\nA section of this type occupies no space in the file but otherwise resembles\nSHTPROGBITS. Although this section contains no bytes, the shoffset member\ncontains the conceptual file offset.\n\nSHTREL\nThis section holds relocation offsets without explicit addends, such as type\nElf32Rel for the 32-bit class of object files. An object file may have multi‐\nple relocation sections.\n\nSHTSHLIB\nThis section is reserved but has unspecified semantics.\n\nSHTDYNSYM\nThis section holds a minimal set of dynamic linking symbols. An object file\ncan also contain a SHTSYMTAB section.\n\nSHTLOPROC, SHTHIPROC\nValues in the inclusive range [SHTLOPROC, SHTHIPROC] are reserved for proces‐\nsor-specific semantics.\n\nSHTLOUSER\nThis value specifies the lower bound of the range of indices reserved for ap‐\nplication programs.\n\nSHTHIUSER\nThis value specifies the upper bound of the range of indices reserved for ap‐\nplication programs. Section types between SHTLOUSER and SHTHIUSER may be\nused by the application, without conflicting with current or future system-de‐\nfined section types.\n\nshflags\nSections support one-bit flags that describe miscellaneous attributes. If a flag bit\nis set in shflags, the attribute is \"on\" for the section. Otherwise, the attribute\nis \"off\" or does not apply. Undefined attributes are set to zero.\n\nSHFWRITE\nThis section contains data that should be writable during process execution.\n\nSHFALLOC\nThis section occupies memory during process execution. Some control sections\ndo not reside in the memory image of an object file. This attribute is off for\nthose sections.\n\nSHFEXECINSTR\nThis section contains executable machine instructions.\n\nSHFMASKPROC\nAll bits included in this mask are reserved for processor-specific semantics.\n\nshaddr\nIf this section appears in the memory image of a process, this member holds the ad‐\ndress at which the section's first byte should reside. Otherwise, the member contains\nzero.\n\nshoffset\nThis member's value holds the byte offset from the beginning of the file to the first\nbyte in the section. One section type, SHTNOBITS, occupies no space in the file, and\nits shoffset member locates the conceptual placement in the file.\n\nshsize\nThis member holds the section's size in bytes. Unless the section type is SHTNOBITS,\nthe section occupies shsize bytes in the file. A section of type SHTNOBITS may have\na nonzero size, but it occupies no space in the file.\n\nshlink\nThis member holds a section header table index link, whose interpretation depends on\nthe section type.\n\nshinfo\nThis member holds extra information, whose interpretation depends on the section type.\n\nshaddralign\nSome sections have address alignment constraints. If a section holds a doubleword,\nthe system must ensure doubleword alignment for the entire section. That is, the\nvalue of shaddr must be congruent to zero, modulo the value of shaddralign. Only\nzero and positive integral powers of two are allowed. The value 0 or 1 means that the\nsection has no alignment constraints.\n\nshentsize\nSome sections hold a table of fixed-sized entries, such as a symbol table. For such a\nsection, this member gives the size in bytes for each entry. This member contains\nzero if the section does not hold a table of fixed-size entries.\n\nVarious sections hold program and control information:\n\n.bss This section holds uninitialized data that contributes to the program's memory image.\nBy definition, the system initializes the data with zeros when the program begins to\nrun. This section is of type SHTNOBITS. The attribute types are SHFALLOC and\nSHFWRITE.\n\n.comment\nThis section holds version control information. This section is of type SHTPROGBITS.\nNo attribute types are used.\n\n.ctors This section holds initialized pointers to the C++ constructor functions. This sec‐\ntion is of type SHTPROGBITS. The attribute types are SHFALLOC and SHFWRITE.\n\n.data This section holds initialized data that contribute to the program's memory image.\nThis section is of type SHTPROGBITS. The attribute types are SHFALLOC and\nSHFWRITE.\n\n.data1 This section holds initialized data that contribute to the program's memory image.\nThis section is of type SHTPROGBITS. The attribute types are SHFALLOC and\nSHFWRITE.\n\n.debug This section holds information for symbolic debugging. The contents are unspecified.\nThis section is of type SHTPROGBITS. No attribute types are used.\n\n.dtors This section holds initialized pointers to the C++ destructor functions. This section\nis of type SHTPROGBITS. The attribute types are SHFALLOC and SHFWRITE.\n\n.dynamic\nThis section holds dynamic linking information. The section's attributes will include\nthe SHFALLOC bit. Whether the SHFWRITE bit is set is processor-specific. This sec‐\ntion is of type SHTDYNAMIC. See the attributes above.\n\n.dynstr\nThis section holds strings needed for dynamic linking, most commonly the strings that\nrepresent the names associated with symbol table entries. This section is of type\nSHTSTRTAB. The attribute type used is SHFALLOC.\n\n.dynsym\nThis section holds the dynamic linking symbol table. This section is of type SHTDYN‐‐\nSYM. The attribute used is SHFALLOC.\n\n.fini This section holds executable instructions that contribute to the process termination\ncode. When a program exits normally the system arranges to execute the code in this\nsection. This section is of type SHTPROGBITS. The attributes used are SHFALLOC and\nSHFEXECINSTR.\n\n.gnu.version\nThis section holds the version symbol table, an array of ElfNHalf elements. This\nsection is of type SHTGNUversym. The attribute type used is SHFALLOC.\n\n.gnu.versiond\nThis section holds the version symbol definitions, a table of ElfNVerdef structures.\nThis section is of type SHTGNUverdef. The attribute type used is SHFALLOC.\n\n.gnu.versionr\nThis section holds the version symbol needed elements, a table of ElfNVerneed struc‐\ntures. This section is of type SHTGNUversym. The attribute type used is SHFALLOC.\n\n.got This section holds the global offset table. This section is of type SHTPROGBITS.\nThe attributes are processor-specific.\n\n.hash This section holds a symbol hash table. This section is of type SHTHASH. The attri‐\nbute used is SHFALLOC.\n\n.init This section holds executable instructions that contribute to the process initializa‐\ntion code. When a program starts to run the system arranges to execute the code in\nthis section before calling the main program entry point. This section is of type\nSHTPROGBITS. The attributes used are SHFALLOC and SHFEXECINSTR.\n\n.interp\nThis section holds the pathname of a program interpreter. If the file has a loadable\nsegment that includes the section, the section's attributes will include the SHFALLOC\nbit. Otherwise, that bit will be off. This section is of type SHTPROGBITS.\n\n.line This section holds line number information for symbolic debugging, which describes the\ncorrespondence between the program source and the machine code. The contents are un‐\nspecified. This section is of type SHTPROGBITS. No attribute types are used.\n\n.note This section holds various notes. This section is of type SHTNOTE. No attribute\ntypes are used.\n\n.note.ABI-tag\nThis section is used to declare the expected run-time ABI of the ELF image. It may\ninclude the operating system name and its run-time versions. This section is of type\nSHTNOTE. The only attribute used is SHFALLOC.\n\n.note.gnu.build-id\nThis section is used to hold an ID that uniquely identifies the contents of the ELF\nimage. Different files with the same build ID should contain the same executable con‐\ntent. See the --build-id option to the GNU linker (ld (1)) for more details. This\nsection is of type SHTNOTE. The only attribute used is SHFALLOC.\n\n.note.GNU-stack\nThis section is used in Linux object files for declaring stack attributes. This sec‐\ntion is of type SHTPROGBITS. The only attribute used is SHFEXECINSTR. This indi‐\ncates to the GNU linker that the object file requires an executable stack.\n\n.note.openbsd.ident\nOpenBSD native executables usually contain this section to identify themselves so the\nkernel can bypass any compatibility ELF binary emulation tests when loading the file.\n\n.plt This section holds the procedure linkage table. This section is of type SHTPROGBITS.\nThe attributes are processor-specific.\n\n.relNAME\nThis section holds relocation information as described below. If the file has a load‐\nable segment that includes relocation, the section's attributes will include the\nSHFALLOC bit. Otherwise, the bit will be off. By convention, \"NAME\" is supplied by\nthe section to which the relocations apply. Thus a relocation section for .text nor‐\nmally would have the name .rel.text. This section is of type SHTREL.\n\n.relaNAME\nThis section holds relocation information as described below. If the file has a load‐\nable segment that includes relocation, the section's attributes will include the\nSHFALLOC bit. Otherwise, the bit will be off. By convention, \"NAME\" is supplied by\nthe section to which the relocations apply. Thus a relocation section for .text nor‐\nmally would have the name .rela.text. This section is of type SHTRELA.\n\n.rodata\nThis section holds read-only data that typically contributes to a nonwritable segment\nin the process image. This section is of type SHTPROGBITS. The attribute used is\nSHFALLOC.\n\n.rodata1\nThis section holds read-only data that typically contributes to a nonwritable segment\nin the process image. This section is of type SHTPROGBITS. The attribute used is\nSHFALLOC.\n\n.shstrtab\nThis section holds section names. This section is of type SHTSTRTAB. No attribute\ntypes are used.\n\n.strtab\nThis section holds strings, most commonly the strings that represent the names associ‐\nated with symbol table entries. If the file has a loadable segment that includes the\nsymbol string table, the section's attributes will include the SHFALLOC bit. Other‐\nwise, the bit will be off. This section is of type SHTSTRTAB.\n\n.symtab\nThis section holds a symbol table. If the file has a loadable segment that includes\nthe symbol table, the section's attributes will include the SHFALLOC bit. Otherwise,\nthe bit will be off. This section is of type SHTSYMTAB.\n\n.text This section holds the \"text\", or executable instructions, of a program. This section\nis of type SHTPROGBITS. The attributes used are SHFALLOC and SHFEXECINSTR.\n\n#### String and symbol tables\n\nString table sections hold null-terminated character sequences, commonly called strings. The\nobject file uses these strings to represent symbol and section names. One references a\nstring as an index into the string table section. The first byte, which is index zero, is\ndefined to hold a null byte ('\\0'). Similarly, a string table's last byte is defined to hold\na null byte, ensuring null termination for all strings.\n\nAn object file's symbol table holds information needed to locate and relocate a program's\nsymbolic definitions and references. A symbol table index is a subscript into this array.\n\ntypedef struct {\nuint32t stname;\nElf32Addr stvalue;\nuint32t stsize;\nunsigned char stinfo;\nunsigned char stother;\nuint16t stshndx;\n} Elf32Sym;\n\ntypedef struct {\nuint32t stname;\nunsigned char stinfo;\nunsigned char stother;\nuint16t stshndx;\nElf64Addr stvalue;\nuint64t stsize;\n} Elf64Sym;\n\nThe 32-bit and 64-bit versions have the same members, just in a different order.\n\nstname\nThis member holds an index into the object file's symbol string table, which holds\ncharacter representations of the symbol names. If the value is nonzero, it represents\na string table index that gives the symbol name. Otherwise, the symbol has no name.\n\nstvalue\nThis member gives the value of the associated symbol.\n\nstsize\nMany symbols have associated sizes. This member holds zero if the symbol has no size\nor an unknown size.\n\nstinfo\nThis member specifies the symbol's type and binding attributes:\n\nSTTNOTYPE\nThe symbol's type is not defined.\n\nSTTOBJECT\nThe symbol is associated with a data object.\n\nSTTFUNC\nThe symbol is associated with a function or other executable code.\n\nSTTSECTION\nThe symbol is associated with a section. Symbol table entries of this type ex‐\nist primarily for relocation and normally have STBLOCAL bindings.\n\nSTTFILE\nBy convention, the symbol's name gives the name of the source file associated\nwith the object file. A file symbol has STBLOCAL bindings, its section index\nis SHNABS, and it precedes the other STBLOCAL symbols of the file, if it is\npresent.\n\nSTTLOPROC, STTHIPROC\nValues in the inclusive range [STTLOPROC, STTHIPROC] are reserved for proces‐\nsor-specific semantics.\n\nSTBLOCAL\nLocal symbols are not visible outside the object file containing their defini‐\ntion. Local symbols of the same name may exist in multiple files without in‐\nterfering with each other.\n\nSTBGLOBAL\nGlobal symbols are visible to all object files being combined. One file's def‐\ninition of a global symbol will satisfy another file's undefined reference to\nthe same symbol.\n\nSTBWEAK\nWeak symbols resemble global symbols, but their definitions have lower prece‐\ndence.\n\nSTBLOPROC, STBHIPROC\nValues in the inclusive range [STBLOPROC, STBHIPROC] are reserved for proces‐\nsor-specific semantics.\n\nThere are macros for packing and unpacking the binding and type fields:\n\nELF32STBIND(info), ELF64STBIND(info)\nExtract a binding from an stinfo value.\n\nELF32STTYPE(info), ELF64STTYPE(info)\nExtract a type from an stinfo value.\n\nELF32STINFO(bind, type), ELF64STINFO(bind, type)\nConvert a binding and a type into an stinfo value.\n\nstother\nThis member defines the symbol visibility.\n\nSTVDEFAULT\nDefault symbol visibility rules. Global and weak symbols are available to\nother modules; references in the local module can be interposed by definitions\nin other modules.\nSTVINTERNAL\nProcessor-specific hidden class.\nSTVHIDDEN\nSymbol is unavailable to other modules; references in the local module always\nresolve to the local symbol (i.e., the symbol can't be interposed by defini‐\ntions in other modules).\nSTVPROTECTED\nSymbol is available to other modules, but references in the local module always\nresolve to the local symbol.\n\nThere are macros for extracting the visibility type:\n\n#### ELF32___ST___VISIBILITY(other)\n\nstshndx\nEvery symbol table entry is \"defined\" in relation to some section. This member holds\nthe relevant section header table index.\n\n#### Relocation entries (Rel & Rela)\n\nRelocation is the process of connecting symbolic references with symbolic definitions. Relo‐\ncatable files must have information that describes how to modify their section contents, thus\nallowing executable and shared object files to hold the right information for a process's\nprogram image. Relocation entries are these data.\n\nRelocation structures that do not need an addend:\n\ntypedef struct {\nElf32Addr roffset;\nuint32t rinfo;\n} Elf32Rel;\n\ntypedef struct {\nElf64Addr roffset;\nuint64t rinfo;\n} Elf64Rel;\n\nRelocation structures that need an addend:\n\ntypedef struct {\nElf32Addr roffset;\nuint32t rinfo;\nint32t raddend;\n} Elf32Rela;\n\ntypedef struct {\nElf64Addr roffset;\nuint64t rinfo;\nint64t raddend;\n} Elf64Rela;\n\nroffset\nThis member gives the location at which to apply the relocation action. For a relo‐\ncatable file, the value is the byte offset from the beginning of the section to the\nstorage unit affected by the relocation. For an executable file or shared object, the\nvalue is the virtual address of the storage unit affected by the relocation.\n\nrinfo This member gives both the symbol table index with respect to which the relocation\nmust be made and the type of relocation to apply. Relocation types are processor-spe‐\ncific. When the text refers to a relocation entry's relocation type or symbol table\nindex, it means the result of applying ELF[32|64]RTYPE or ELF[32|64]RSYM, respec‐\ntively, to the entry's rinfo member.\n\nraddend\nThis member specifies a constant addend used to compute the value to be stored into\nthe relocatable field.\n\n#### Dynamic tags (Dyn)\n\nThe .dynamic section contains a series of structures that hold relevant dynamic linking in‐\nformation. The dtag member controls the interpretation of dun.\n\ntypedef struct {\nElf32Sword dtag;\nunion {\nElf32Word dval;\nElf32Addr dptr;\n} dun;\n} Elf32Dyn;\nextern Elf32Dyn DYNAMIC[];\n\ntypedef struct {\nElf64Sxword dtag;\nunion {\nElf64Xword dval;\nElf64Addr dptr;\n} dun;\n} Elf64Dyn;\nextern Elf64Dyn DYNAMIC[];\n\ndtag This member may have any of the following values:\n\nDTNULL Marks end of dynamic section\n\nDTNEEDED String table offset to name of a needed library\n\nDTPLTRELSZ Size in bytes of PLT relocation entries\n\nDTPLTGOT Address of PLT and/or GOT\n\nDTHASH Address of symbol hash table\n\nDTSTRTAB Address of string table\n\nDTSYMTAB Address of symbol table\n\nDTRELA Address of Rela relocation table\n\nDTRELASZ Size in bytes of the Rela relocation table\n\nDTRELAENT Size in bytes of a Rela relocation table entry\n\nDTSTRSZ Size in bytes of string table\n\nDTSYMENT Size in bytes of a symbol table entry\n\nDTINIT Address of the initialization function\n\nDTFINI Address of the termination function\n\nDTSONAME String table offset to name of shared object\n\nDTRPATH String table offset to library search path (deprecated)\n\nDTSYMBOLIC Alert linker to search this shared object before the executable for sym‐\nbols\n\nDTREL Address of Rel relocation table\n\nDTRELSZ Size in bytes of Rel relocation table\n\nDTRELENT Size in bytes of a Rel table entry\n\nDTPLTREL Type of relocation entry to which the PLT refers (Rela or Rel)\n\nDTDEBUG Undefined use for debugging\n\nDTTEXTREL Absence of this entry indicates that no relocation entries should apply to\na nonwritable segment\n\nDTJMPREL Address of relocation entries associated solely with the PLT\n\nDTBINDNOW Instruct dynamic linker to process all relocations before transferring\ncontrol to the executable\n\nDTRUNPATH String table offset to library search path\n\nDTLOPROC, DTHIPROC\nValues in the inclusive range [DTLOPROC, DTHIPROC] are reserved for pro‐\ncessor-specific semantics\n\ndval This member represents integer values with various interpretations.\n\ndptr This member represents program virtual addresses. When interpreting these addresses,\nthe actual address should be computed based on the original file value and memory base\naddress. Files do not contain relocation entries to fixup these addresses.\n\nDYNAMIC\nArray containing all the dynamic structures in the .dynamic section. This is automat‐\nically populated by the linker.\n\n#### Notes (Nhdr)\n\nELF notes allow for appending arbitrary information for the system to use. They are largely\nused by core files (etype of ETCORE), but many projects define their own set of extensions.\nFor example, the GNU tool chain uses ELF notes to pass information from the linker to the C\nlibrary.\n\nNote sections contain a series of notes (see the struct definitions below). Each note is\nfollowed by the name field (whose length is defined in nnamesz) and then by the descriptor\nfield (whose length is defined in ndescsz) and whose starting address has a 4 byte align‐\nment. Neither field is defined in the note struct due to their arbitrary lengths.\n\nAn example for parsing out two consecutive notes should clarify their layout in memory:\n\nvoid *memory, *name, *desc;\nElf64Nhdr *note, *nextnote;\n\n/* The buffer is pointing to the start of the section/segment */\nnote = memory;\n\n/* If the name is defined, it follows the note */\nname = note->nnamesz == 0 ? NULL : memory + sizeof(*note);\n\n/* If the descriptor is defined, it follows the name\n(with alignment) */\n\ndesc = note->ndescsz == 0 ? NULL :\nmemory + sizeof(*note) + ALIGNUP(note->nnamesz, 4);\n\n/* The next note follows both (with alignment) */\nnextnote = memory + sizeof(*note) +\nALIGNUP(note->nnamesz, 4) +\nALIGNUP(note->ndescsz, 4);\n\nKeep in mind that the interpretation of ntype depends on the namespace defined by the\nnnamesz field. If the nnamesz field is not set (e.g., is 0), then there are two sets of\nnotes: one for core files and one for all other ELF types. If the namespace is unknown, then\ntools will usually fallback to these sets of notes as well.\n\ntypedef struct {\nElf32Word nnamesz;\nElf32Word ndescsz;\nElf32Word ntype;\n} Elf32Nhdr;\n\ntypedef struct {\nElf64Word nnamesz;\nElf64Word ndescsz;\nElf64Word ntype;\n} Elf64Nhdr;\n\nnnamesz\nThe length of the name field in bytes. The contents will immediately follow this note\nin memory. The name is null terminated. For example, if the name is \"GNU\", then\nnnamesz will be set to 4.\n\nndescsz\nThe length of the descriptor field in bytes. The contents will immediately follow the\nname field in memory.\n\nntype Depending on the value of the name field, this member may have any of the following\nvalues:\n\nCore files (etype = ETCORE)\nNotes used by all core files. These are highly operating system or architecture\nspecific and often require close coordination with kernels, C libraries, and de‐\nbuggers. These are used when the namespace is the default (i.e., nnamesz will\nbe set to 0), or a fallback when the namespace is unknown.\n\nNTPRSTATUS prstatus struct\nNTFPREGSET fpregset struct\nNTPRPSINFO prpsinfo struct\nNTPRXREG prxregset struct\nNTTASKSTRUCT task structure\nNTPLATFORM String from sysinfo(SIPLATFORM)\nNTAUXV auxv array\nNTGWINDOWS gwindows struct\nNTASRS asrset struct\nNTPSTATUS pstatus struct\nNTPSINFO psinfo struct\nNTPRCRED prcred struct\nNTUTSNAME utsname struct\nNTLWPSTATUS lwpstatus struct\nNTLWPSINFO lwpinfo struct\nNTPRFPXREG fprxregset struct\nNTSIGINFO siginfot (size might increase over time)\nNTFILE Contains information about mapped files\nNTPRXFPREG userfxsrstruct\nNTPPCVMX PowerPC Altivec/VMX registers\nNTPPCSPE PowerPC SPE/EVR registers\nNTPPCVSX PowerPC VSX registers\nNT386TLS i386 TLS slots (struct userdesc)\nNT386IOPERM x86 io permission bitmap (1=deny)\nNTX86XSTATE x86 extended state using xsave\nNTS390HIGHGPRS s390 upper register halves\nNTS390TIMER s390 timer register\nNTS390TODCMP s390 time-of-day (TOD) clock comparator register\nNTS390TODPREG s390 time-of-day (TOD) programmable register\nNTS390CTRS s390 control registers\nNTS390PREFIX s390 prefix register\nNTS390LASTBREAK s390 breaking event address\nNTS390SYSTEMCALL s390 system call restart data\nNTS390TDB s390 transaction diagnostic block\nNTARMVFP ARM VFP/NEON registers\nNTARMTLS ARM TLS register\nNTARMHWBREAK ARM hardware breakpoint registers\nNTARMHWWATCH ARM hardware watchpoint registers\nNTARMSYSTEMCALL ARM system call number\n\nnname = GNU\nExtensions used by the GNU tool chain.\n\nNTGNUABITAG\nOperating system (OS) ABI information. The desc field will be 4 words:\n\n• word 0: OS descriptor (ELFNOTEOSLINUX, ELFNOTEOSGNU, and so on)`\n• word 1: major version of the ABI\n• word 2: minor version of the ABI\n• word 3: subminor version of the ABI\n\nNTGNUHWCAP\nSynthetic hwcap information. The desc field begins with two words:\n\n• word 0: number of entries\n• word 1: bit mask of enabled entries\n\nThen follow variable-length entries, one byte followed by a null-termi‐\nnated hwcap name string. The byte gives the bit number to test if en‐\nabled, (1U << bit) & bit mask.\n\nNTGNUBUILDID\nUnique build ID as generated by the GNU ld(1) --build-id option. The desc\nconsists of any nonzero number of bytes.\n\nNTGNUGOLDVERSION\nThe desc contains the GNU Gold linker version used.\n\nDefault/unknown namespace (etype != ETCORE)\nThese are used when the namespace is the default (i.e., nnamesz will be set to\n0), or a fallback when the namespace is unknown.\n\nNTVERSION A version string of some sort.\nNTARCH Architecture information.\n\n### NOTES\n\nELF first appeared in System V. The ELF format is an adopted standard.\n\nThe extensions for ephnum, eshnum, and eshstrndx respectively are Linux extensions. Sun,\nBSD and AMD64 also support them; for further information, look under SEE ALSO.\n\n### SEE ALSO\n\nas(1), elfedit(1), gdb(1), ld(1), nm(1), objcopy(1), objdump(1), patchelf(1), readelf(1),\nsize(1), strings(1), strip(1), execve(2), dliteratephdr(3), core(5), ld.so(8)\n\nHewlett-Packard, Elf-64 Object File Format.\n\nSanta Cruz Operation, System V Application Binary Interface.\n\nUNIX System Laboratories, \"Object Files\", Executable and Linking Format (ELF).\n\nSun Microsystems, Linker and Libraries Guide.\n\nAMD64 ABI Draft, System V Application Binary Interface AMD64 Architecture Processor Supple‐\nment.\n\n### COLOPHON\n\nThis page is part of release 5.10 of the Linux man-pages project. A description of the\nproject, information about reporting bugs, and the latest version of this page, can be found\nat https://www.kernel.org/doc/man-pages/.\n\n\n\nLinux 2020-12-21 ELF(5)\n\n" } ], "structuredContent": { "command": "ELF", "section": "5", "mode": "man", "summary": "elf - format of Executable and Linking Format (ELF) files", "synopsis": "", "tldr_summary": null, "tldr_examples": [], "tldr_source": null, "flags": [], "examples": [], "see_also": [ { "name": "as", "section": "1", "url": "https://www.chedong.com/phpMan.php/man/as/1/json" }, { "name": "elfedit", "section": "1", "url": "https://www.chedong.com/phpMan.php/man/elfedit/1/json" }, { "name": "gdb", "section": "1", "url": "https://www.chedong.com/phpMan.php/man/gdb/1/json" }, { "name": "ld", "section": "1", "url": "https://www.chedong.com/phpMan.php/man/ld/1/json" }, { "name": "nm", "section": "1", "url": "https://www.chedong.com/phpMan.php/man/nm/1/json" }, { "name": "objcopy", "section": "1", "url": "https://www.chedong.com/phpMan.php/man/objcopy/1/json" }, { "name": "objdump", "section": "1", "url": "https://www.chedong.com/phpMan.php/man/objdump/1/json" }, { "name": "patchelf", "section": "1", "url": "https://www.chedong.com/phpMan.php/man/patchelf/1/json" }, { "name": "readelf", "section": "1", "url": "https://www.chedong.com/phpMan.php/man/readelf/1/json" }, { "name": "size", "section": "1", "url": "https://www.chedong.com/phpMan.php/man/size/1/json" }, { "name": "strings", "section": "1", "url": "https://www.chedong.com/phpMan.php/man/strings/1/json" }, { "name": "strip", "section": "1", "url": "https://www.chedong.com/phpMan.php/man/strip/1/json" }, { "name": "execve", "section": "2", "url": "https://www.chedong.com/phpMan.php/man/execve/2/json" }, { "name": "dliteratephdr", "section": "3", "url": "https://www.chedong.com/phpMan.php/man/dliteratephdr/3/json" }, { "name": "core", "section": "5", "url": "https://www.chedong.com/phpMan.php/man/core/5/json" }, { "name": "ld.so", "section": "8", "url": "https://www.chedong.com/phpMan.php/man/ld.so/8/json" } ], "section_outline": [ { "name": "NAME", "lines": 2, "subsections": [] }, { "name": "SYNOPSIS", "lines": 1, "subsections": [ { "name": "#include ", "lines": 1 } ] }, { "name": "DESCRIPTION", "lines": 12, "subsections": [ { "name": "Basic types", "lines": 23 }, { "name": "ELF header (Ehdr)", "lines": 197 }, { "name": "Program header (Phdr)", "lines": 118 }, { "name": "Section header (Shdr)", "lines": 340 }, { "name": "String and symbol tables", "lines": 115 }, { "name": "ELF32___ST___VISIBILITY(other)", "lines": 4 }, { "name": "Relocation entries (Rel & Rela)", "lines": 47 }, { "name": "Dynamic tags (Dyn)", "lines": 92 }, { "name": "Notes (Nhdr)", "lines": 142 } ] }, { "name": "NOTES", "lines": 5, "subsections": [] }, { "name": "SEE ALSO", "lines": 14, "subsections": [] }, { "name": "COLOPHON", "lines": 7, "subsections": [] } ] } }