ELF file format - another text method ELF document
Translator Note: Due to limited levels of translator (including technical level and translation level: (), some places may be more difficult, there may be a wrong place, if there is any problem, welcome email: alert7@21cn.com We will accept it vain, and will be more in the future revision. (I can't miss the later readers, so if you are better, you still look at the original version :), don't lose eggs ^ _ ^) this document And the original document in the original ELF file format is different: 1. Ignore the paging count. 2. For the above reasons, the page number is removed in this content directory, and the index is completely ignored. (Not like PostScript documents, txt text can be used to search) 3. The content of the page title and the foot of the article have been changed at the beginning. 4. The layout of the article has also been corrected. 5. If necessary, different fonts have been ignored. Most places, this document can make you fully understand. However, small places, the original document uses a slope to indicate the character variable in the article. In that case, this article uses
Such an error, please mailto:. Breadbox@muppetlabs.com Brian Raiter [Last edited Fri Jul 23 1999] ________________________________________________________________ EXECUTABLE AND LINKABLE FORMAT (ELF) Portable Formats Specification, Version 1.1 Tool Interface Standards (TIS) ________________________________________________________________ ======= ================================================== preface 1. Object file introduction ELF header sections string table (Symbol Table) Relocation 2. Program loading and dynamic connection introduction Program header PROGRAM Loading Dynamic connection (Dynamic Linking) 3. C LIBRARY C Library ________________________________________________________________ Introduction ________________________________________________________________ ELF: executable and Linking format executable format is connected to UNIX system laboratories (USL) as an application binary interface (application binary Interface (ABI) developed and released. Tool Interface Standards Committee (TIS) Chooses the development of ELF standards as a portable binary file format that works between 32-bit Intel systems. Assume that developers have defined a binary interface Collection, ELF standards use it to support streamlined software development. The number of different execution interfaces should be reduced. Therefore, you can reduce the reconstruction of the reconstruction. About this document This document is preparing for those who want to create a target file or perform files on a different operating system. It is divided into the following three parts: * Part 1, "Target Document Object Files" describes three main types of ELF target file formats. * Part 2, "Program Reprint and Dynamic Connections" describe the information of the target file and the behavior of the system in creating a runtime program. * Part III, "C Library" lists all runners that contain symbols, standard ANSI C and LIBCs included in libsys, as well as global data symbols required by the libc run program. Note: Reference X86 system has been changed to an Intel system.
________________________________________________________________ 1. The target file (Object file) ________________________________________________________________ ========================= preamble ============== =========== The first section describes the format of the IABI Object file, called Elfutable and Linking Format. There are three main types in the Object file. * A Relocatable file holds code and appropriate data, uses other Object files to create an executable or a shared file. * An executable file holds a program for execution; this file indicates how Exec (ba_OS) is how to create a program process image. * A shared Object file saves code and appropriate data for links to the following two linkers. The first is to connect the editor [see LD (SD_CMD)], you can create other objects and share Object files with other heavy positionable and shared object files. The second is a dynamic linker, combined with an executable file and other shared object files to create a process image. An Object file is created by the assembler and coupling, and the Object file you want to run directly on the process is stored in binary. Those programs that require abstract mechanisms are like the shell script, which is not accepted. After the introductory material, the first part mainly surrounds the format of the file and how to establish a program. The second part also describes several components of the Object file, focusing on the information necessary to execute the program. File format Object file Participate in the connection of the program (create a program) and the execution of the program (running a program). The Object file format provides a convenient and effective way to view the content of the file in parallelism, in their activities, reflecting different needs. Example 1-1 shows an organization diagram of an Object file.
Figure 1-1: Object file format LINKING view EXECUTION perspective ============ =================================== Header Table Segment 1 Segment 1 ... segment 2 section n ... section Header Table Section Header Table (optional) An ELF header in the beginning of the file, saves the road map (Road Map), describes the organization of the file. Sections saves the information of the Object file, from the perspective: including instructions, data, symbolic tables, relocation information, and more. Special Sections describes the first part of the future. The second part discusses the segment and the execution angle of the program. If a program header (Program Header Table) exists, then it tells how to create a memory image of a process. Files used to establish a process image (executing a program) must have a program header; the relocationable file does not require this header. A section header contains information about describing the file sections. Each section has an entry in this table; each entry gives the name, size, and so on of the section. The file in the coupling process must have a section header; other Object files can not be this step header. Note: Although the figure shows that the program header appears immediately after an ELF header, the section header appears to appear in the other section section, the fact is that the file is different. In addition, the segments and segments have no special order. Only the ELF header is a fixed location in the file. Data indicates that the Object file format supports 8 bits, 32-bit different processors. However, it tries to work hard to run on a larger or smaller system. Therefore, Object files depict some control data need to be used with the machine-independent format, so that it uses the general method as much as possible to identify the Object file and describe their content. The remaining data in the Object file uses the coding method of the target processor, regardless of which the file is created on.
Figure 1-2: 32-bit data type ========= ========= ======= Elf32_addr 4 4 Unsigned Program Address ELF32_HALF 2 2 unsigned Medium integer Elf32_Off 4 4 unsigned file offset Elf32_Sword 4 4 Signed large integer Elf32_Word 4 4 unsigned large integer unsigned char 1 1 unsigned small integer all object file format definition data structure is the natural size (natural size), adjusted pointer type associated. If desired, the data structure is clearly included in the filling field that ensures 4 bytes aligned. To make the structure size of 4 times. Data is also appropriately aligned from the beginning of the file. For example, a structure containing an ELF32_ADDR will be aligned to the 4-byte boundary within the file. Because of the transplantability, the ELF does not use the bit field. ========================== e h ==================================================================================================================================================================================== ==== Some Object files can grow, so the ELF header contains their current size. If the Object file format changes, the program may encounter or small or small to control the control structure. The program is also possible to ignore additional (extra) information. The information that is not unknown (MISSING) is explained by context, if the extension is defined, they will be specified.
FIG. 1-3: ELF Header #define EI_NIDENT 16 typedef struct {unsigned char e_ident [EI_NIDENT]; Elf32_Half e_type; Elf32_Half e_machine; Elf32_Word e_version; Elf32_Addr e_entry; Elf32_Off e_phoff; Elf32_Off e_shoff; Elf32_Word e_flags; Elf32_Half e_ehsize; Elf32_Half e_phentsize; Elf32_Half E_phnum; ELF32_HALF E_SHENTSIZE; ELF32_HALF E_SHNUM; ELF32_HALF E_SHSTRNDX;} Elf32_ehdr; * E_IDENT This initial field indicates that the file is an Object file, providing a machine-independent data, explaining the content of the file. There is more detailed information in the ELF Identification part of the ELF below. * E_TYPE This member determines the type of the Object. Name Value Meaning ==== ===== ======= ET_NONE 0 No file type ET_REL 1 Relocatable file ET_EXEC 2 Executable file ET_DYN 3 Shared object file ET_CORE 4 Core file ET_LOPROC 0xff00 Processor-specific ET_HIPROC 0xffff Processor- Specific Although the content of Core is not indicated, the type et_core is reserved. The value is reserved for a special processor from ET_LOPROC to ET_HIPROC (including et_hiproc). If necessary, the other reserved variables will be used on the new Object file type. * E_MACHINE This member variable indicates the architecture that runs the program.
Name Value Meaning ==== ===== ======= EM_NONE 0 No machine EM_M32 1 AT & T WE 32100 EM_SPARC 2 SPARC EM_386 3 Intel 80386 EM_68K 4 Motorola 68000 EM_88K 5 Motorola 88000 EM_860 7 Intel 80860 EM_MIPS 8 MIPS If RS3000 is required, the other reserved values will be used on new machine types. Special processor names use the machine name to distinguish them. For example, the member Flags that will be mentioned will use prefix EF_; on an EM_XYZ machine, Flag is called a widget, which is called EF_XYZ_WIDGET. * E_VERSION This member determines the version of the Object file. Name value meaning ==== ===== ======= Ev_none 0 Invalid Version EV_CURRENT 1 CURRENT VERSION value 1 Represents the original file format; create a new version to use> 1. EV_CURRENT value (1 above) If you need to point to the current version number. * E_ENTRY This member is the virtual address of the first transmission control of the system, where the startup process is started. If the file has not been associated with the entry point, the member remains 0. * E_PHOFF This member maintains the offset of the program header (in byte count) in the file table. If the file has no programmed head table, the member remains 0. * E_SHOFF This member maintains the offset (in byte count) in the section headheet (Section header Table). If the file does not have a section header, the member remains 0. * E_FLAGS This member saves the specific processor flag of the relevant file. The name of the FLAG comes from EF_
* E_SHENTSIZE This member saves the size of the section header (in byte count). A section header is an entry at the section header (Section header Table); all portions are the same size. * E_SHNUM This member saves the number of portions in the section header Table. Therefore, the product of E_SHENTSIZE and E_SHNUM is the size of the section header (in byte count). If the file does not have a section headset, the E_SHNUM value is 0. * E_SHSTRNDX This member saves the section headheet index of the Section Name Chart Related Entrance. If there is no section name character table in the file, the variable value is shn_undef. More detailed information Look at the "Sections" and string tables ("String Table"). Identification (Identification) mentioned above, ELF provides a frame structure of an Object file to support a variety of processors, a variety of data encoding methods, a variety of machine types. In order to support this Object file family, the original byte specifies to explain how to explain the file, independent of the processor, independent of the content of the file. The ELF header (that is, the Object file) is identical to the member E_IDENT. FIG. 1-4: e_ident [] Identification Indexes Name Value Purpose ==== ===== ======= EI_MAG0 0 File identification EI_MAG1 1 File identification EI_MAG2 2 File identification EI_MAG3 3 File identification EI_CLASS 4 File class EI_DATA 5 DATA ENCODING EI_VERSION 6 FILE VERSION EI_PAD 7 START OF PADDING BYTES EI_NIDENT 16 SIZE OF E_IDENT [] The following variables are defined by index access bytes. * The first 4 characters of the EI_MAG0 TO EI_MAG3 file saves a magic number to determine if the file is the target file of ELF. Name value position ================================================================================================================ * EI_CLASS The next byte is e_ident [ei_class], used to determine the type or ability of the file.
Name value meaning ================ Elfclassnone 0 Invalid Class Elfclass32 1 32-bit Objects Elfclass64 2 64-bit objects file format is designed to be portable in different size machines, The size of the mainframe is not needed on the small machine. Type ELFCLASS32 supports virtual address space up to 4GB machine; use the basic type defined above. Type ELFCLASS64 is a machine reserved for a 64-bit system. Its appearance indicates that the Object file may change, but the 64-bit format has not been defined. If necessary, other types will be defined, there will be different types and different sizes of data size. * EI_DATA Byte E_IDENT [EI_DATA] Specifies the encoding method of specific processor data in the Object file. The following encoding method is currently defined. Name value meaning ==== ===== ======= Elfdatanone 0 Invalid Data Encoding Elfdata2lsb 1 See Below Elfdata2msb 2 See Below More information about encoding appears below. Other values remain, will be assigned a new encoding method, of course, if necessary. * EI_VERSION Byte E_IDENT [EI_VERSION] indicates the version number of the ELF header. Now this variable must be set to EV_CURRENT as an explanation of the E_VERSION above. * EI_PAD This variable identifies unused bytes starting in E_IDENT. Those bytes are reserved and set to 0; the program reads them from the Object file but should be ignored. If the bytes that are not currently used have new definitions, the EI_PAD variable will be changed. A file's data coding indicates how to explain a basic Object file. In the above description, the type ELFCLAS32 file uses a target file that occupies 1, 2 and 4 bytes. The encoding method defined below is depicted with the following graph. The data appears in the upper left corner. ElfData2lsb coding specifies 2 complement values. The minimum meaningful byte has the lowest address.
Figure 1-5: Data encoding Elfdata2lsb 0 ------ 0x0102 | 01 | ------ 0 ---- 1 ------ 0x010204 | 02 | 01 | ---- ------ 0 ------ 1 ------ 2 ------ 3 ------ 0x01020304 | 04 | 03 | 02 | 01 | ------ ------ ---- ------ Elfdata2LSB Code Specifies 2 rations. The biggest means occupy the lowest address. Figure 1-6: Data encoding Elfdata2msb 0 ------ 0x0102 | 01 | ------ 0 ---- 1 ------ 0x010204 | 01 | 02 | ---- ------ 0 ------ 1 ------ 2 ------ 3 ------ 0 × 01020304 | 01 | 02 | 03 | 04 | ------ ---------- ------ Machine information In order to determine the file, the 32-bit Intel architecture requires the following variables. Figure 1-7: 32-bit intel architecture identification, e_ident position value ========= ===== E_IDENT [EI_CLASS] Elfclass32 E_IDENT [EI_DATA] ElfData2lsb processor confirms the E_MACHINE member in the ELF header, the Members must be EM_386. E_FLAGS members in the ELF header saves the bit tags related to the file. This tag is not defined on the 32-bit Intel system; so this member should be 0; =========================== ======== ====================== Section header table for an Object file allows us to locate all Sections. Section header table is an array of ELF32_SHDR structures (described below). A section header table index is the subscript of this array. E_SHOFF members of ELF Header Table give the offset of the section header (count from the beginning of the file).
E_SHNUM tells us how many entrances contain in the section header table; E_SHENTSIZE gives the size of each entrance. Some section header table indexes are retained; those special indexes will have no corresponding sections in an Object file. FIG. 1-8: Special Section Indexes Name Value ==== ===== SHN_UNDEF 0 SHN_LORESERVE 0xff00 SHN_LOPROC 0xff00 SHN_HIPROC 0xff1f SHN_ABS 0xfff1 SHN_COMMON 0xfff2 SHN_HIRESERVE 0xffff * SHN_UNDEF not defined the value indicates, missing, or other unrelated relates The meaningless section. For example, the label "defined" relative to the section index number shn_undef is a label that is not defined. Note: Although index 0 reserves the undefined value, the section header table contains an entry of index 0. Therefore, if the ELF header says 6 section portfolios in the section header table of a file, the value of E_SHNUM should be from 0 to 5. The content of the initial entrance will be specified in this section. * SHN_LORESERVE This value specifies the minimum value of the reserved index range. * SHN_LOPROC THROUGH SHN_HIPROC This value contains a reservation range of a specific processor language. * SHN_ABS This variable is an absolute address relative to the corresponding reference. For example, the reference number of the Section number is an absolute address and is not affected by the relocation. * SHN_COMMON This section is a public (COMMON) label, just like Fortran Common or the Unmissible C extend variable. * SHN_HIRESERVE This value specifies the upper limit of the reserved index range. The index value of the system reserved is from Shn_LoreServe to Shn_HireServe; this variable does not involve the section header table. Therefore, the section header table contains the entry for the reserved index value. Sections contains all information in an Object file, in addition to the ELF header, Program Header Table, and section header table. In addition, the section of the Object file meets several days: * Every section in the Object file has its own section header to describe it. The section headers may exist but section can not exist. * Each section occupies a continuous order in the file (but may be empty). * The sections in the file cannot be repeated. There is no byte in the file in this section and in another section. * Object files can have "non-active" space. Different headers and Sections may not override each byte in the Object file. The "non-active" data is not specified. A section head has the following structure.
FIG. 1-9: Section Header typedef struct {Elf32_Word sh_name; Elf32_Word sh_type; Elf32_Word sh_flags; Elf32_Addr sh_addr; Elf32_Off sh_offset; Elf32_Word sh_size; Elf32_Word sh_link; Elf32_Word sh_info; Elf32_Word sh_addralign; Elf32_Word sh_entsize;} Elf32_Shdr; * sh_name the members designated The name of this section. Its value is the index of the section header character table section. [Look at the following "String Table"], end with NULL empty characters. * SH_TYPE This member classifies sections by content and meaning. Section's type and their description below. * SH_FLAGS Sections support bit tags to describe multiple properties. FLAG definitions appear below. * SH_ADDR If this section will appear in the memory image space of the process, the member gives a position in the memory. Otherwise, this variable is 0. * SH_OFFSET This member variable gives the section byte offset (counting from the file). SHT_NOBITS Type Section (discussed below) does not occupy space in the file, and its SH_OFFSET member is positioned in the concept of the file. * SH_SIZE This member gives you the byte size of the section. Unless the type of this section is SHT_NOBITS, the section will occupy the SH_SIZE byte in the file. The SHT_NOBITS type section may be non-0 size, but does not account for file space. * SH_LINK This member saves an index connection of a section header, which relies on the type of this section. One of the following describes these values. * SH_INFO This member saves additional information, which interprets the type of section relies on this section. One of the following plans these values. * SH_ADDralign Some Sections has address alignment constraints. For example, if a section saves a double word, the system must determine if the entire section is aligned. Therefore, the value of SH_ADDR is used as the value of sh_addralign, so it is 0. Of course, only 0 and positive 2 is allowed. Values 0 and 1 mean that this section is not aligned. * SH_ENTSIZE Some Sections saves a table with a fixed size entry, like a symbol table. For such a section, the member gives the byte size of each entrance. If the section does not save a table with a fixed size entry, the member is 0. The section head member sh_type indicates the language of the section.
FIG. 1-10: Section Types, sh_type Name Value ==== ===== SHT_NULL 0 SHT_PROGBITS 1 SHT_SYMTAB 2 SHT_STRTAB 3 SHT_RELA 4 SHT_HASH 5 SHT_DYNAMIC 6 SHT_NOTE 7 SHT_NOBITS 8 SHT_REL 9 SHT_SHLIB 10 SHT_DYNSYM 11 SHT_LOPROC 0x70000000 SHT_HIPROC 0x7fffffff SHT_LOUSER 0x80000000 SHT_HIUSER 0xfffffffff * SHT_NULL This value indicates that the section header is invalid; it has no related section. The values of other members of this section are undefined. * SHT_PROGBITS This section saves some information defined by the program, and its format and significance depends on the program itself. * SHT_SYMTAB and SHT_DYNSYM Those Sembol tables are saved. Under normal circumstances, an Object file has only one section, but in the future, this constraint may be relaxed. Typically, SHT_SYMTAB provides labels for connectors, of course, it may also be used dynamically. As a complete symbol table, it may contain some labels that are not required when dynamically connected. Therefore, an Object file may also contain a SHT_DYNSYM section, which saves the minimum label collection when a dynamic connection is saved. See the details of the Symbol Table in the following symbol table. * SHT_STRTAB This section saves a string table. An Object file can contain section of multiple string tables. Look at the details of the string "String Table". * SHT_RELA This section saves a repositioning entry with explicit plus. Just like the Object file 32-bit ELF32_RELA type. An Object file may have multiple repositioned sections. The specific details are locked in `` Relocation ''. * SHT_HASH This label holds a latcher's hash table. All Participate Dynamic Connected Object must have a label hash table (Hash Table). Currently, an Object file may have only one hash table. Detailed detail looks at the second part of the hash table "hash table". * SHT_DYNAMIC This section saves the information of dynamic connection. Currently, an Object may have only one dynamic section, but this limit may be canceled in the future. Detailed detail see the dynamic section ("Dynamic Section") of the second part. * SHT_Note This section saves other information of some of the flag files. Detailed details Look at the "Note Section" of the second part. * SHT_NOBITS This type of section does not occupy space in the file, but similar to SHT_Progbits. Although the section does not contain bytes, the SH_OFFSET member contains the conceptual file offset.
* SHT_REL This section saves the entry with the repositioning of the exponential. Just like the Object file 32-bit type ELF32_REL type. An Object file may have multiple repositioned sections. The specific details are locked in `` Relocation ''. * SHT_SHLIB This section is reserved but does not specify. The program containing this type of section does not match ABI. * SHT_LOPROC THROUGH SHT_HIPROC The value between this range is reserved for a particular processor. * SHT_LOUSER This variable is the smallest boundary of the index range reserved by the application. * SHT_HIUSER This variable is the maximum boundary of the index range reserved. The section type of SHT_LOUSER and HIUSER may be used by the application, which is not contradictory in the schedule of the system or future system. The variables of the other section type are reserved. As mentioned earlier, index 0 (shn_undef) The section header exists, even index tags is undefined section references. This entry saves the following information. FIG. 1-11: Section Header Table Entry: Index 0 Name Value Note ==== ===== ==== sh_name 0 No name sh_type SHT_NULL Inactive sh_flags 0 No flags sh_addr 0 No address sh_offset 0 No file offset sh_size 0 No size sh_link SHN_UNDEF No link information sh_info 0 No auxiliary information sh_addralign 0 No alignment sh_entsize 0 No entries a section header (section header table) sh_flags member holds the 1-bit flag, attributes used to describe the section. The following is the defined value; other values are retained. Figure 1-12: Section Attribute Flags, SH_FLAGS NAME ==== ===== SHF_WRITE 0X1 SHF_ALLOC 0X2 SHF_EXECINSTR 0X4 SHF_MASKPROC 0XF0000000 If a marker bit in SH_FLAGS is set, the section corresponding to the corresponding attribute is also opened. Otherwise, this property is not applied. The unknown attribute is set to 0. * SHF_WRITE This section contains data that can be written during the process execution. * SHF_ALLOC This section occupies memory during the process execution. Some control sections does not exist in memory images of an Object file; for these sections, this property should be turned off. * SHF_EXECINSTR This section contains executable machine instructions. * SHF_MASKPROC All of the bits included in this mask are gearly reserved for specific processing.
In the section header, the interpretation of two members SH_LINK and SH_INFO relies on the type of section. Figure 1-13: sh_link and sh_link sh_info ======= ======= ====== == ====== sht_dynamic the section header index of 0 the string Table Used by Entries in the section . SHT_HASH The section header index of 0 the symbol table to which the hash table applies. SHT_REL, The section header index of The section header index of SHT_RELA the associated symbol table. the section to which the relocation applies. SHT_SYMTAB, The section header index OF One Greater THE SYMBOL SHT_DYNSYM The Associated String Table. Table Index of The Last Local Symbol (Binding Stb_local). Other SHN_UNDEF 0 Special Sections Special Sections Different Sections Save Programs and Control Information. The section in the list below is used by the system, indicating type and properties.
FIG. 1-14: Special Sections Name Type Attributes ==== ==== ========== .bss SHT_NOBITS SHF_ALLOC SHF_WRITE .comment SHT_PROGBITS none .data SHT_PROGBITS SHF_ALLOC SHF_WRITE .data1 SHT_PROGBITS SHF_ALLOC SHF_WRITE .debug SHT_PROGBITS none .dynamic SHT_DYNAMIC see below .dynstr SHT_STRTAB SHF_ALLOC .dynsym SHT_DYNSYM SHF_ALLOC .fini SHT_PROGBITS SHF_ALLOC SHF_EXECINSTR .got SHT_PROGBITS see below .hash SHT_HASH SHF_ALLOC .init SHT_PROGBITS SHF_ALLOC SHF_EXECINSTR .interp SHT_PROGBITS see below .line SHT_PROGBITS none .note SHT_NOTE none .plt SHT_PROGBITS see below .rel
* .dynsym This section saves a dynamic symbol table, such as a description of Symbol Table. The second part has more detailed information. * .Fini This section saves the executable instruction that constitutes the termination code of the process. Therefore, when a program is exit, the system schedules the code in this section. * .got This section saves the global offset table. See "Special Offset Table" for the first part to get more information. * .hash This section saves a label has a hash table. Look at the second part of "Hash Table" to get more information. * .INIT This section saves the executable instructions that form the initialization code of the process. Therefore, when a program starts running, the system schedules the code in this section before the main function is called before the MAIN function is called. * .INTERP This section saves the path of the program's interpretator. If there is a loaded segment in this section, the SHF_alloc bit of the properties of this section will be set; otherwise, the bit will not be set. See the second part to get more information. * .LINE This section contains the number of row information of the character, which describes the relationship between the source program and the machine code. The section content is not clear. * .note This section saves some information, using the format mentioned in the "Note Section". * .plt This section saves the Procedure Linkage Table. Look at the first part of `` Special Sections '' and the second part of "Procedure Linkage Table". * .rel
