X-Git-Url: https://pintos-os.org/cgi-bin/gitweb.cgi?p=pintos-anon;a=blobdiff_plain;f=specs%2Fsysv-abi-update.html%2Fch4.eheader.html;fp=specs%2Fsysv-abi-update.html%2Fch4.eheader.html;h=5ddd45b419f50e6ae5ae73430e84c7e54c100d76;hp=0000000000000000000000000000000000000000;hb=8af06d1fd50343e17229618ef4d2693193b2b3d9;hpb=d0d14ca50fbac167253e1e1d8d806bfd749a5e8a
diff --git a/specs/sysv-abi-update.html/ch4.eheader.html b/specs/sysv-abi-update.html/ch4.eheader.html
new file mode 100644
index 0000000..5ddd45b
--- /dev/null
+++ b/specs/sysv-abi-update.html/ch4.eheader.html
@@ -0,0 +1,1184 @@
+
+ELF Header
+ELF Header
+
+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.
+
+Figure 4-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;
+
+typedef struct {
+ unsigned char e_ident[EI_NIDENT];
+ Elf64_Half e_type;
+ Elf64_Half e_machine;
+ Elf64_Word e_version;
+ Elf64_Addr e_entry;
+ Elf64_Off e_phoff;
+ Elf64_Off e_shoff;
+ Elf64_Word e_flags;
+ Elf64_Half e_ehsize;
+ Elf64_Half e_phentsize;
+ Elf64_Half e_phnum;
+ Elf64_Half e_shentsize;
+ Elf64_Half e_shnum;
+ Elf64_Half e_shstrndx;
+} 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''.
+e_type- This member identifies the object file type.
+
+
+
+| 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_LOOS |
+0xfe00 |
+Operating system-specific |
+
+
+ET_HIOS |
+0xfeff |
+Operating system-specific |
+
+
+ET_LOPROC |
+0xff00 |
+Processor-specific |
+
+
+ET_HIPROC |
+0xffff |
+Processor-specific |
+
+
+
+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.
+
+
e_machine- This member's value specifies the required architecture for
+an individual file.
+
+
+
+| 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 |
+
+
+
+| reserved |
+6 |
+Reserved for future use (was EM_486) |
+
+
+
+EM_860 |
+7 |
+Intel 80860 |
+
+
+
+EM_MIPS |
+8 |
+MIPS I Architecture |
+
+
+
+EM_S370 |
+9 |
+IBM System/370 Processor |
+
+
+
+EM_MIPS_RS3_LE |
+10 |
+MIPS RS3000 Little-endian |
+
+
+
+| reserved |
+11-14 |
+Reserved for future use |
+
+
+
+EM_PARISC |
+15 |
+Hewlett-Packard PA-RISC |
+
+
+
+| reserved |
+16 |
+Reserved for future use |
+
+
+
+EM_VPP500 |
+17 |
+Fujitsu VPP500 |
+
+
+
+EM_SPARC32PLUS |
+18 |
+Enhanced instruction set SPARC |
+
+
+
+EM_960 |
+19 |
+Intel 80960 |
+
+
+
+EM_PPC |
+20 |
+PowerPC |
+
+
+
+EM_PPC64 |
+21 |
+64-bit PowerPC |
+
+
+
+EM_S390 |
+22 |
+IBM System/390 Processor |
+
+
+
+| reserved |
+23-35 |
+Reserved for future use |
+
+
+
+EM_V800 |
+36 |
+NEC V800 |
+
+
+
+EM_FR20 |
+37 |
+Fujitsu FR20 |
+
+
+ EM_RH32 |
+38 |
+TRW RH-32 |
+
+
+
+EM_RCE |
+39 |
+Motorola RCE |
+
+
+
+EM_ARM |
+40 |
+Advanced RISC Machines ARM |
+
+
+
+EM_ALPHA |
+41 |
+Digital Alpha |
+
+
+
+EM_SH |
+42 |
+Hitachi SH |
+
+
+
+EM_SPARCV9 |
+43 |
+SPARC Version 9 |
+
+
+
+EM_TRICORE |
+44 |
+Siemens TriCore embedded processor |
+
+
+
+EM_ARC |
+45 |
+Argonaut RISC Core, Argonaut Technologies Inc. |
+
+
+
+EM_H8_300 |
+46 |
+Hitachi H8/300 |
+
+
+
+EM_H8_300H |
+47 |
+Hitachi H8/300H |
+
+
+
+EM_H8S |
+48 |
+Hitachi H8S |
+
+
+
+EM_H8_500 |
+49 |
+Hitachi H8/500 |
+
+
+
+EM_IA_64 |
+50 |
+Intel IA-64 processor architecture |
+
+
+
+EM_MIPS_X |
+51 |
+Stanford MIPS-X |
+
+
+
+EM_COLDFIRE |
+52 |
+Motorola ColdFire |
+
+
+
+EM_68HC12 |
+53 |
+Motorola M68HC12 |
+
+
+
+EM_MMA |
+54 |
+Fujitsu MMA Multimedia Accelerator |
+
+
+
+EM_PCP |
+55 |
+Siemens PCP |
+
+
+
+EM_NCPU |
+56 |
+Sony nCPU embedded RISC processor |
+
+
+
+EM_NDR1 |
+57 |
+Denso NDR1 microprocessor |
+
+
+
+EM_STARCORE |
+58 |
+Motorola Star*Core processor |
+
+
+
+EM_ME16 |
+59 |
+Toyota ME16 processor |
+
+
+
+EM_ST100 |
+60 |
+STMicroelectronics ST100 processor |
+
+
+
+EM_TINYJ |
+61 |
+Advanced Logic Corp. TinyJ embedded processor family |
+
+
+
+EM_X86_64 |
+62 |
+AMD x86-64 architecture |
+
+
+
+EM_PDSP |
+63 |
+Sony DSP Processor |
+
+
+
+EM_PDP10 |
+64 |
+Digital Equipment Corp. PDP-10 |
+
+
+
+EM_PDP11 |
+65 |
+Digital Equipment Corp. PDP-11 |
+
+
+
+EM_FX66 |
+66 |
+Siemens FX66 microcontroller |
+
+
+
+EM_ST9PLUS |
+67 |
+STMicroelectronics ST9+ 8/16 bit microcontroller |
+
+
+
+EM_ST7 |
+68 |
+STMicroelectronics ST7 8-bit microcontroller |
+
+
+
+EM_68HC16 |
+69 |
+Motorola MC68HC16 Microcontroller |
+
+
+
+EM_68HC11 |
+70 |
+Motorola MC68HC11 Microcontroller |
+
+
+
+EM_68HC08 |
+71 |
+Motorola MC68HC08 Microcontroller |
+
+
+
+EM_68HC05 |
+72 |
+Motorola MC68HC05 Microcontroller |
+
+
+
+EM_SVX |
+73 |
+Silicon Graphics SVx |
+
+
+
+EM_ST19 |
+74 |
+STMicroelectronics ST19 8-bit microcontroller |
+
+
+
+EM_VAX |
+75 |
+Digital VAX |
+
+
+EM_CRIS |
+76 |
+Axis Communications 32-bit embedded processor |
+
+
+
+EM_JAVELIN |
+77 |
+Infineon Technologies 32-bit embedded processor |
+
+
+
+EM_FIREPATH |
+78 |
+Element 14 64-bit DSP Processor |
+
+
+
+EM_ZSP |
+79 |
+LSI Logic 16-bit DSP Processor |
+
+
+
+EM_MMIX |
+80 |
+Donald Knuth's educational 64-bit processor |
+
+
+
+EM_HUANY |
+81 |
+Harvard University machine-independent object files |
+
+
+
+
+EM_PRISM |
+82 |
+SiTera Prism |
+
+
+
+EM_AVR |
+83 |
+Atmel AVR 8-bit microcontroller |
+
+
+EM_FR30 |
+84 |
+Fujitsu FR30 |
+
+
+EM_D10V |
+85 |
+Mitsubishi D10V |
+
+
+EM_D30V |
+86 |
+Mitsubishi D30V |
+
+
+EM_V850 |
+87 |
+NEC v850 |
+
+
+EM_M32R |
+88 |
+Mitsubishi M32R |
+
+
+EM_MN10300 |
+89 |
+Matsushita MN10300 |
+
+
+EM_MN10200 |
+90 |
+Matsushita MN10200 |
+
+
+EM_PJ |
+91 |
+picoJava |
+
+
+EM_OPENRISC |
+92 |
+OpenRISC 32-bit embedded processor |
+
+
+
+EM_ARC_A5 |
+93 |
+ARC Cores Tangent-A5 |
+
+
+
+
+EM_XTENSA |
+94 |
+Tensilica Xtensa Architecture |
+
+
+
+EM_VIDEOCORE |
+95 |
+Alphamosaic VideoCore processor |
+
+
+
+EM_TMM_GPP |
+96 |
+Thompson Multimedia General Purpose Processor |
+
+
+
+EM_NS32K |
+97 |
+National Semiconductor 32000 series |
+
+
+
+EM_TPC |
+98 |
+Tenor Network TPC processor |
+
+
+
+EM_SNP1K |
+99 |
+Trebia SNP 1000 processor |
+
+
+
+EM_ST200 |
+100 |
+STMicroelectronics (www.st.com) ST200 microcontroller |
+
+
+
+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.
+
e_version- This member identifies the object file version.
+
+
+
+| Name |
+Value |
+Meaning |
+
+
+EV_NONE |
+0 |
+Invalid version |
+
+
+EV_CURRENT |
+1 |
+Current version |
+
+
+
+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.
+
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.
+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_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_flags- This member holds processor-specific flags associated with the file.
+Flag names take the form
+
EF_machine_flag.
+e_ehsize- This member holds the ELF header's size in bytes.
+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_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_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_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.
+
+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.)
+
+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
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.)
+
+
+
+
ELF Identification
+
+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 initial bytes of an ELF header (and an object file) correspond to
+the e_ident member.
+
+Figure 4-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_OSABI |
+7 |
+Operating system/ABI identification |
+
+
+EI_ABIVERSION |
+8 |
+ABI version |
+
+
+EI_PAD |
+9 |
+Start of padding bytes |
+
+
+EI_NIDENT |
+16 |
+Size of e_ident[] |
+
+
+
+
+These indexes access bytes that hold the following values.
+
+EI_MAG0 to EI_MAG3- A file's first 4 bytes hold a ``magic number,'' identifying the file
+as an ELF object file.
+
+
+
+| Name |
+Value |
+Position |
+
+
+ELFMAG0 |
+0x7f |
+e_ident[EI_MAG0] |
+
+
+ELFMAG1 |
+'E' |
+e_ident[EI_MAG1] |
+
+
+ELFMAG2 |
+'L' |
+e_ident[EI_MAG2] |
+
+
+ELFMAG3 |
+'F' |
+e_ident[EI_MAG3] |
+
+
+
+
EI_CLASS- The next byte,
e_ident[EI_CLASS], identifies the
+file's class, or capacity.
+
+
+
+| Name |
+Value |
+Meaning |
+
+
+ELFCLASSNONE |
+0 |
+Invalid class |
+
+
+ELFCLASS32 |
+1 |
+32-bit objects |
+
+
+ELFCLASS64 |
+2 |
+64-bit objects |
+
+
+
+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.''
+
+Class ELFCLASS64 supports machines with 64-bit
+architectures. It uses the basic types defined in the table
+labeled ``64-Bit Data Types.''
+
+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.
+
+
+
+
+| Name |
+Value |
+Meaning |
+
+
+ELFDATANONE |
+0 |
+Invalid data encoding |
+
+
+ELFDATA2LSB |
+1 |
+See below |
+
+
+ELFDATA2MSB |
+2 |
+See below |
+
+
+
+Other values are reserved and will be assigned to new
+encodings as necessary.
+
+
+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.
+
+EI_VERSION- Byte
e_ident[EI_VERSION] specifies the
+ELF header version
+number. Currently, this value must be EV_CURRENT,
+as explained above for e_version.
+
+
EI_OSABI- 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.
+
+
+
+
+| Name |
+Value |
+Meaning |
+
+
+ELFOSABI_NONE |
+0 |
+No extensions or unspecified |
+
+
+ELFOSABI_HPUX |
+1 |
+Hewlett-Packard HP-UX |
+
+
+ELFOSABI_NETBSD |
+2 |
+NetBSD |
+
+
+ELFOSABI_LINUX |
+3 |
+Linux |
+
+
+
+
+ELFOSABI_SOLARIS |
+6 |
+Sun Solaris |
+
+
+ELFOSABI_AIX |
+7 |
+AIX |
+
+
+ELFOSABI_IRIX |
+8 |
+IRIX |
+
+
+ELFOSABI_FREEBSD |
+9 |
+FreeBSD |
+
+
+ELFOSABI_TRU64 |
+10 |
+Compaq TRU64 UNIX |
+
+
+ELFOSABI_MODESTO |
+11 |
+Novell Modesto |
+
+
+ELFOSABI_OPENBSD |
+12 |
+Open BSD |
+
+
+
+ELFOSABI_OPENVMS |
+13 |
+Open VMS |
+
+
+
+ELFOSABI_NSK |
+14 |
+Hewlett-Packard Non-Stop Kernel |
+
+
+| |
+64-255 |
+Architecture-specific value range |
+
+
+
+
+
EI_ABIVERSION- 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.
+
+
EI_PAD- 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.
+
+Encoding ELFDATA2LSB specifies 2's complement values,
+with the least significant byte occupying the lowest address.
+
+Figure 4-5: Data Encoding ELFDATA2LSB, byte address zero on the left
+
+
+
+
+
+
+
+| 04 |
+03 |
+02 |
+01 |
+
+0x01020304
+
+
+
+
+| 08 |
+07 |
+06 |
+05 |
+04 |
+03 |
+02 |
+01 |
+
+0x0102030405060708
+
+
+
+Encoding ELFDATA2MSB specifies 2's complement values,
+with the most significant byte occupying the lowest address.
+
+Figure 4-6: Data Encoding ELFDATA2MSB, byte address zero on the left
+
+
+
+
+
+
+
+| 01 |
+02 |
+03 |
+04 |
+
+0x01020304
+
+
+
+
+| 01 |
+02 |
+03 |
+04 |
+05 |
+06 |
+07 |
+08 |
+
+0x0102030405060708
+
+
+
+
+Machine Information (Processor-Specific)
+
+
+This section requires processor-specific information.
+The ABI supplement for the desired processor describes the details.
+
+
+
+
+
+
+
+© 1997, 1998, 1999, 2000, 2001 The Santa Cruz Operation, Inc. All rights reserved.
+© 2002 Caldera International. All rights reserved.
+
+
+