Some object file control structures can grow, because the ELF header contains their actual sizes. If the object file format changes, a program may encounter control structures that are larger or smaller than expected. Programs might therefore ignore ``extra'' information. The treatment of ``missing'' information depends on context and will be specified when and if extensions are defined.
/* The ELF file header. This appears at the start of every ELF file. */
#define EI_NIDENT (16)
typedef struct
{
unsigned char e_ident[EI_NIDENT]; /* Magic number and other info */
Elf32_Half e_type; /* Object file type */
Elf32_Half e_machine; /* Architecture */
Elf32_Word e_version; /* Object file version */
Elf32_Addr e_entry; /* Entry point virtual address */
Elf32_Off e_phoff; /* Program header table file offset */
Elf32_Off e_shoff; /* Section header table file offset */
Elf32_Word e_flags; /* Processor-specific flags */
Elf32_Half e_ehsize; /* ELF header size in bytes */
Elf32_Half e_phentsize; /* Program header table entry size */
Elf32_Half e_phnum; /* Program header table entry count */
Elf32_Half e_shentsize; /* Section header table entry size */
Elf32_Half e_shnum; /* Section header table entry count */
Elf32_Half e_shstrndx; /* Section header string table index */
} Elf32_Ehdr;
typedef struct
{
unsigned char e_ident[EI_NIDENT]; /* Magic number and other info */
Elf64_Half e_type; /* Object file type */
Elf64_Half e_machine; /* Architecture */
Elf64_Word e_version; /* Object file version */
Elf64_Addr e_entry; /* Entry point virtual address */
Elf64_Off e_phoff; /* Program header table file offset */
Elf64_Off e_shoff; /* Section header table file offset */
Elf64_Word e_flags; /* Processor-specific flags */
Elf64_Half e_ehsize; /* ELF header size in bytes */
Elf64_Half e_phentsize; /* Program header table entry size */
Elf64_Half e_phnum; /* Program header table entry count */
Elf64_Half e_shentsize; /* Section header table entry size */
Elf64_Half e_shnum; /* Section header table entry count */
Elf64_Half e_shstrndx; /* Section header string table index */
} Elf64_Ehdr;
e_ident
The initial bytes mark the file as an object file and provide machine-independent data with which to decode and interpret the file's contents. Complete descriptions appear below in ``ELF Identification''.
Although the core file contents are unspecified, type ET_CORE is reserved to mark the file. Values from ET_LOOS through ET_HIOS (inclusive) are reserved for operating system-specific semantics. Values from ET_LOPROC through ET_HIPROC (inclusive) are reserved for processor-specific semantics. If meanings are specified, the processor supplement explains them. Other values are reserved and will be assigned to new object file types as necessary.
Other values are reserved and will be assigned to new machines as necessary. Processor-specific ELF names use the machine name to distinguish them. For example, the flags mentioned below use the prefix EF_; a flag named WIDGET for the EM_XYZ machine would be called EF_XYZ_WIDGET.
The value 1 signifies the original file format; extensions will create new versions with higher numbers. Although the value of EV_CURRENT is shown as 1 in the previous table, it will change as necessary to reflect the current version number.
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.
成員e_entry的值給出的是系統将控制權交給程式時的虛拟位址，程序才得以啟動。
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.
e_phoff的數值代表的意思是程式頭表在檔案中的偏移。
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.
e_shoff的數值代表的意思是節頭表在檔案中的偏移。
e_flags
This member holds processor-specific flags associated with the file. Flag names take the form EF_machine_flag.
e_flags指出處理器獨有的特性。它的格式為EF_<machine>_<flag>。
e_ehsize
This member holds the ELF header's size in bytes.
e_ehsize代表的就是ELF檔案頭的大小。
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.
e_phentsize代表的意思是程式頭表表項的大小。
e_phnum
This member holds the number of entries in the program header table. Thus the product of e_phentsize and e_phnum gives the table's size in bytes. If a file has no program header table, e_phnum holds the value zero.
e_phnum代表的意思是程式頭表表項總個數。
If the number of entries in the program header table is larger than or equal to PN_XNUM(0xffff), this member holds PN_XNUM(0xffff) and the real number of entries in the program header table is held in the sh_info member of the initial entry in section header table. Otherwise, the sh_info member of the initial entry contains the value zero.
PN_XNUM This is defined as 0xffff, the largest number e_phnum can have, specifying where the actual number of program headers is assigned.
PN_XNUM是e_phnum最大的值，代表的意思是真實的程式頭表表項個數已經記錄在别處。
e_shentsize
This member holds a section header's size in bytes. A section header is one entry in the section header table; all entries are the same size.
e_shentsize代表的意思是節頭表表項的大小。
e_shnum
This member holds the number of entries in the section header table. Thus the product of e_shentsize and e_shnum gives the section header table's size in bytes. If a file has no section header table, e_shnum holds the value zero.
e_shnum代表的意思是節頭表表項總個數。
If the number of sections is greater than or equal to SHN_LORESERVE (0xff00), this member has the value zero and the actual number of section header table entries is contained in the sh_size field of the section header at index 0. (Otherwise, the sh_size member of the initial entry contains 0.)
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 SHN_UNDEF. See ``Sections'' and ``String Table'' below for more information.
If the section name string table section index is greater than or equal to SHN_LORESERVE (0xff00), this member has the value SHN_XINDEX (0xffff) and the actual index of the section name string table section is contained in the sh_link field of the section header at index 0. (Otherwise, the sh_link member of the initial entry contains 0.)
As mentioned above, ELF provides an object file framework to support multiple processors, multiple data encodings, and multiple classes of machines. To support this object file family, the initial bytes of the file specify how to interpret the file, independent of the processor on which the inquiry is made and independent of the file's remaining contents.
The file format is designed to be portable among machines of various sizes, without imposing the sizes of the largest machine on the smallest. The class of the file defines the basic types used by the data structures of the object file container itself. The data contained in object file sections may follow a different programming model. If so, the processor supplement describes the model used.
Class ELFCLASS32 supports machines with 32-bit architectures. It uses the basic types defined in the table labeled ``32-Bit Data Types.''
ELFCLASS32表明是32-bit平台。
Class ELFCLASS64 supports machines with 64-bit architectures. It uses the basic types defined in the table labeled ``64-Bit Data Types.''
ELFCLASS64表明是64-bit平台。
Other classes will be defined as necessary, with different basic types and sizes for object file data.
将來出現其它位數的平台也是有可能的，到時就要根據新平台的特性來定義資料類型的大小。
EI_DATA
Byte e_ident[EI_DATA] specifies the encoding of both the data structures used by object file container and data contained in object file sections. The following encodings are currently defined.
Other values are reserved and will be assigned to new encodings as necessary.
其它值用作保留值。
NOTE：Primarily for the convenience of code that looks at the ELF file at runtime, the ELF data structures are intended to have the same byte order as that of the running program.
Byte e_ident[EI_OSABI] identifies the OS- or ABI-specific ELF extensions used by this file. Some fields in other ELF structures have flags and values that have operating system and/or ABI specific meanings; the interpretation of those fields is determined by the value of this byte. If the object file does not use any extensions, it is recommended that this byte be set to 0. If the value for this byte is 64 through 255, its meaning depends on the value of the e_machine header member. The ABI processor supplement for an architecture can define its own associated set of values for this byte in this range. If the processor supplement does not specify a set of values, one of the following values shall be used, where 0 can also be taken to mean unspecified.
Byte e_ident[EI_ABIVERSION] 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 EI_OSABI field. If no values are specified for the EI_OSABI field by the processor supplement or no version values are specified for the ABI determined by a particular value of the EI_OSABI byte, the value 0 shall be used for the EI_ABIVERSION byte; it indicates unspecified.
This value marks the beginning of the unused bytes in e_ident. These bytes are reserved and set to zero; programs that read object files should ignore them. The value of EI_PAD will change in the future if currently unused bytes are given meanings.
A file's data encoding specifies how to interpret the basic objects in a file. Class ELFCLASS32 files use objects that occupy 1, 2, and 4 bytes. Class ELFCLASS64 files use objects that occupy 1, 2, 4, and 8 bytes. Under the defined encodings, objects are represented as shown below.
