The data structures described so far, up to and including the optional header, are all located at a fixed offset from the beginning of the file (or from the PE header if the file is an image containing an MS-DOS stub). The remainder of a COFF object or image file contains blocks of data that are not necessarily at any specific file offset. Instead, the locations are defined by pointers in the Optional Header or a section header. An exception is for images with a Section Alignment value (see the Optional Header description [Section 3.4]) of less than the page size of the architecture (4K for Intel x86 and for MIPS; 8K for IA64). In this case there are constraints on the file offset of the section data, as described in the next section. Another exception is that attribute certificate and debug information must be placed at the very end of an image file (with the attribute certificate table immediately preceding the debug section), because the loader does not map these into memory. The rule on attribute certificate and debug information does not apply to object files, however. 5.1 Section Data Initialized data for a section consists of simple blocks of bytes. However, for sections containing all zeros, the section data need not be included. The data for each section is located at the file offset given by the PointerToRawData field in the section header, and the size of this data in the file is indicated by the SizeOfRawData field. If the SizeOfRawData is less than the VirtualSize, the remainder is padded with zeros. In an image file, the section data must be aligned on a boundary as specified by the FileAlignment field in the optional header. Section data must appear in order of the RVA values for the corresponding sections (as do the individual section headers in the Section Table). There are additional restrictions on image files where the Section Align value in the Optional Header is less than the page size of the architecture. For such files, the location of section data in the file must match its location in memory when the image is loaded, so that the physical offset for section data is the same as the RVA. 5.2 COFF Relocations (Object Only) Object files contain COFF relocations, which specify how the section data should be modified when placed in the image file and subsequently loaded into memory. Image files do not contain COFF relocations, because all symbols referenced have already been assigned addresses in a flat address space. An image contains relocation information in the form of base relocations in the .reloc section (unless the image has the IMAGE_FILE_RELOCS_STRIPPED attribute). See Section 6.6 for more information. For each section in an object file, there is an array of fixed-length records that are the section's COFF relocations. The position and length of the array are specified in the section header. Each element of the array has the following format: Offset | Size | Field | Description |
---|
0 | 4 | VirtualAddress | Address of the item to which relocation is applied; this is the offset from the beginning of the section, plus the value of the section's RVA/Offset field (see Section 4, "Section Table."). For example, if the first byte of the section has an address of 0x10, the third byte has an address of 0x12. | 4 | 4 | SymbolTableIndex | A zero-based index into the symbol table. This symbol gives the address to be used for the relocation. If the specified symbol has section storage class, then the symbol's address is the address with the first section of the same name. | 8 | 2 | Type | A value indicating what kind of relocation should be performed. Valid relocation types depend on machine type. See Section 5.2.1, "Type Indicators." | If the symbol referred to (by the SymbolTableIndex field) has storage class IMAGE_SYM_ CLASS_SECTION, the symbol's address is the beginning of the section. The section is usually in the same file, except when the object file is part of an archive (library). In that case, the section may be found in any other object file in the archive that has the same archive-member name as the current object file. (The relationship with the archive-member name is used in the linking of import tables, i.e., the .idata section.) 5.2.1 Type Indicators The Type field of the relocation record indicates what kind of relocation should be performed. Different relocation types are defined for each type of machine. AMD AMD64 The following relocation type indicators are defined for AMD AMD64 and compatible processors: Constant | Value | Description |
---|
IMAGE_REL_AMD64_ABSOLUTE | 0x0000 | This relocation is ignored. | IMAGE_REL_AMD64_ADDR64 | 0x0001 | 64-bit VA. | IMAGE_REL_AMD64_ADDR32 | 0x0002 | 32-bit VA. | IMAGE_REL_AMD64_ADDR32NB | 0x0003 | 32-bit address w/o image base (RVA). | IMAGE_REL_AMD64_REL32 | 0x0004 | 32-bit relative address from byte following relocation. | IMAGE_REL_AMD64_REL32_1 | 0x0005 | 32-bit relative address from byte distance 1 from relocation. | IMAGE_REL_AMD64_REL32_2 | 0x0006 | 32-bit relative address from byte distance 2 from relocation. | IMAGE_REL_AMD64_REL32_3 | 0x0007 | 32-bit relative address from byte distance 3 from relocation. | IMAGE_REL_AMD64_REL32_4 | 0x0008 | 32-bit relative address from byte distance 4 from relocation. | IMAGE_REL_AMD64_REL32_5 | 0x0009 | 32-bit relative address from byte distance 5 from relocation. | IMAGE_REL_AMD64_SECTION | 0x000A | The 16-bit section index of the section containing the target. This is used to support debugging information. | IMAGE_REL_AMD64_SECREL | 0x000B | The 32-bit offset of the target from the beginning of its section. This is used to support debugging information as well as static thread local storage. | IMAGE_REL_AMD64_SECREL7 | 0x000C | 7 bit unsigned offset from base of section containing target. | IMAGE_REL_AMD64_TOKEN | 0x000D | clr token. | IMAGE_REL_AMD64_SREL32 | 0x000E | 32 bit signed span-dependent value emitted into object. | IMAGE_REL_AMD64_PAIR | 0x000F | | IMAGE_REL_AMD64_SSPAN32 | 0x0010 | 32 bit signed span-dependent value applied at link time. | ARM Processors The following relocation Type indicators are defined for ARM processors: Constant | Value | Description |
---|
IMAGE_REL_ARM_ABSOLUTE | 0x0000 | This relocation is ignored. | IMAGE_REL_ARM_ADDR32 | 0x0001 | The target's 32-bit virtual address. | IMAGE_REL_ARM_ADDR32NB | 0x0002 | The target's 32-bit relative virtual address. | IMAGE_REL_ARM_BRANCH24 | 0x0003 | The 24-bit relative displacement to the target. | IMAGE_REL_ARM_BRANCH11 | 0x0004 | Reference to a subroutine call, consisting of two 16-bit instructions with 11-bit offsets. | IMAGE_REL_ARM_SECTION | 0x000E | The 16-bit section index of the section containing the target. This is used to support debugging information. | IMAGE_REL_ARM_SECREL | 0x000F | The 32-bit offset of the target from the beginning of its section. This is used to support debugging information as well as static thread local storage. | CEE The following relocation type indicators are defined for CEE (clr pure object files): Constant | Value | Description |
---|
IMAGE_REL_CEE_ABSOLUTE | 0x0000 | The relocation is ignored. | IMAGE_REL_CEE_ADDR32 | 0x0001 | 32-bit address (VA). | IMAGE_REL_CEE_ADDR64 | 0x0002 | 64-bit address (VA). | IMAGE_REL_CEE_ADDR32NB | 0x0003 | 32-bit address w/o image base (RVA). | IMAGE_REL_CEE_SECTION | 0x0004 | The 16-bit section index of the section containing the target. This is used to support debugging information. | IMAGE_REL_CEE_SECREL | 0x0005 | The 32-bit offset of the target from the beginning of its section. This is used to support debugging information as well as static thread local storage. | IMAGE_REL_CEE_TOKEN | 0x0006 | clr token. | Hitachi SuperH Processors The following relocation type indicators are defined for SH3 and SH4 processors. SH5 specific relocations are noted as SHM (SH Media): Constant | Value | Description |
---|
IMAGE_REL_SH3_ABSOLUTE | 0x0000 | This relocation is ignored. | IMAGE_REL_SH3_DIRECT16 | 0x0001 | Reference to the 16-bit location that contains the virtual address of the target symbol. | IMAGE_REL_SH3_DIRECT32 | 0x0002 | The target's 32-bit virtual address. | IMAGE_REL_SH3_DIRECT8 | 0x0003 | Reference to the 8-bit location that contains the virtual address of the target symbol. | IMAGE_REL_SH3_DIRECT8_WORD | 0x0004 | Reference to the 8-bit instruction that contains the effective 16 bit virtual address of the target symbol. | IMAGE_REL_SH3_DIRECT8_LONG | 0x0005 | Reference to the 8-bit instruction that contains the effective 32 bit virtual address of the target symbol. | IMAGE_REL_SH3_DIRECT4 | 0x0006 | Reference to the 8-bit location whose low 4 bits contain the virtual address of the target symbol. | IMAGE_REL_SH3_DIRECT4_WORD | 0x0007 | Reference to the 8-bit instruction whose low 4 bits contain the effective 16 bit virtual address of the target symbol. | IMAGE_REL_SH3_DIRECT4_LONG | 0x0008 | Reference to the 8-bit instruction whose low 4 bits contain the effective 32 bit virtual address of the target symbol. | IMAGE_REL_SH3_PCREL8_WORD | 0x0009 | Reference to the 8-bit instruction which contains the effective 16-bit relative offset of the target symbol. | IMAGE_REL_SH3_PCREL8_LONG | 0x000A | Reference to the 8-bit instruction which contains the effective 32-bit relative offset of the target symbol. | IMAGE_REL_SH3_PCREL12_WORD | 0x000B | Reference to the 16-bit instruction whose low 12 bits contain the effective 16 bit relative offset of the target symbol. | IMAGE_REL_SH3_STARTOF_SECTION | 0x000C | Reference to a 32-bit location that is the virtual address of the symbol's section. | IMAGE_REL_SH3_SIZEOF_SECTION | 0x000D | Reference to the 32-bit location that is the size of the symbol's section. | IMAGE_REL_SH3_SECTION | 0x000E | The 16-bit section index of the section containing the target. This is used to support debugging information. | IMAGE_REL_SH3_SECREL | 0x000F | The 32-bit offset of the target from the beginning of its section. This is used to support debugging information as well as static thread local storage. | IMAGE_REL_SH3_DIRECT32_NB | 0x0010 | The target's 32-bit relative virtual address. | IMAGE_REL_SH3_GPREL4_LONG | 0x0011 | GP relative. | IMAGE_REL_SH3_TOKEN | 0x0012 | clr token. | IMAGE_REL_SHM_PCRELPT | 0x0013 | Offset from current instruction in longwords; if not NOMODE, insert the inverse of the low bit at bit 32 to select PTA/PTB. | IMAGE_REL_SHM_REFLO | 0x0014 | Low 16 bits of 32-bit address. | IMAGE_REL_SHM_REFHALF | 0x0015 | High 16 bits of 32-bit address. | IMAGE_REL_SHM_RELLO | 0x0016 | Low 16 bits of relative address. | IMAGE_REL_SHM_RELHALF | 0x0017 | High 16 bits of relative address. | IMAGE_REL_SHM_PAIR | 0x0018 | This relocation is only valid when it immediately follows a REFHALF, RELHALF, or RELLO relocation. Its SymbolTableIndex contains a displacement and not an index into the symbol table. | IMAGE_REL_SHM_NOMODE | 0x8000 | Relocation ignores section mode. | IBM PowerPC Processors The following relocation Type indicators are defined for PowerPC processors: Constant | Value | Description |
---|
IMAGE_REL_PPC_ABSOLUTE | 0x0000 | This relocation is ignored. | IMAGE_REL_PPC_ADDR64 | 0x0001 | The target's 64-bit virtual address. | IMAGE_REL_PPC_ADDR32 | 0x0002 | The target's 32-bit virtual address. | IMAGE_REL_PPC_ADDR24 | 0x0003 | The low 24 bits of the target's virtual address. This is only valid when the target symbol is absolute and can be sign extended to its original value. | IMAGE_REL_PPC_ADDR16 | 0x0004 | The low 16 bits of the target's virtual address. | IMAGE_REL_PPC_ADDR14 | 0x0005 | The low 14 bits of the target's virtual address. This is only valid when the target symbol is absolute and can be sign extended to its original value. | IMAGE_REL_PPC_REL24 | 0x0006 | A 24-bit PC-relative offset to the symbol's location. | IMAGE_REL_PPC_REL14 | 0x0007 | A 14-bit PC-relative offset to the symbol's location. | IMAGE_REL_PPC_ADDR32NB | 0x000A | The target's 32-bit relative virtual address. | IMAGE_REL_PPC_SECREL | 0x000B | The 32-bit offset of the target from the beginning of its section. This is used to support debugging information as well as static thread local storage. | IMAGE_REL_PPC_SECTION | 0x000C | The 16-bit section index of the section containing the target. This is used to support debugging information. | IMAGE_REL_PPC_SECREL16 | 0x000F | The 16-bit offset of the target from the beginning of its section. This is used to support debugging information as well as static thread local storage. | IMAGE_REL_PPC_REFHI | 0x0010 | The high 16 bits of the target's 32-bit virtual address. Used for the first instruction in a two-instruction sequence that loads a full address. This relocation must be immediately followed by a PAIR relocation whose SymbolTableIndex contains a signed 16 bit displacement which is added to the upper 16 bits taken from the location being relocated. | IMAGE_REL_PPC_REFLO | 0x0011 | The low 16 bits of the target's virtual address. | IMAGE_REL_PPC_PAIR | 0x0012 | This relocation is only valid when it immediately follows a REFHI or SECRELHI relocation. Its SymbolTableIndex contains a displacement and not an index into the symbol table. | IMAGE_REL_PPC_SECRELLO | 0x0013 | The low 16 bits of the 32-bit offset of the target from the beginning of its section. | IMAGE_REL_PPC_SECRELHI | 0x0014 | The high 16 bits of the 32-bit offset of the target from the beginning of its section. A PAIR relocation must immediately follow this one. The SymbolTableIndex of the PAIR relocation contains a signed 16 bit displacement which is added to the upper 16 bits taken from the location being relocated. | IMAGE_REL_PPC_GPREL | 0x0015 | 16-bit signed displacement of the target relative to the Global Pointer (GP) register. | IMAGE_REL_PPC_TOKEN | 0x0016 | clr token. | Intel 386 The following relocation type indicators are defined for Intel386 and compatible processors: Constant | Value | Description |
---|
IMAGE_REL_I386_ABSOLUTE | 0x0000 | This relocation is ignored. | IMAGE_REL_I386_DIR16 | 0x0001 | Not supported. | IMAGE_REL_I386_REL16 | 0x0002 | Not supported. | IMAGE_REL_I386_DIR32 | 0x0006 | The target's 32-bit virtual address. | IMAGE_REL_I386_DIR32NB | 0x0007 | The target's 32-bit relative virtual address. | IMAGE_REL_I386_SEG12 | 0x0009 | Not supported. | IMAGE_REL_I386_SECTION | 0x000A | The 16-bit section index of the section containing the target. This is used to support debugging information. | IMAGE_REL_I386_SECREL | 0x000B | The 32-bit offset of the target from the beginning of its section. This is used to support debugging information as well as static thread local storage. | IMAGE_REL_I386_TOKEN | 0x000C | clr token. | IMAGE_REL_I386_SECREL7 | 0x000D | 7 bit offset from base of section containing target. | IMAGE_REL_I386_REL32 | 0x0014 | The 32-bit relative displacement to the target. This supports the x86 relative branch and call instructions. | Intel Itanium Processor Family (IPF) The following relocation type indicators are defined for the Intel Itanium Processor Family and compatible processors. Note that relocations on instructions use the bundle's offset and slot number for the relocation offset: Constant | Value | Description |
---|
IMAGE_REL_IA64_ABSOLUTE | 0x0000 | This relocation is ignored. | IMAGE_REL_IA64_IMM14 | 0x0001 | This instruction relocation may be followed by an ADDEND relocation whose Value is added to the target address before it is inserted into the specified slot in the IMM14 bundle. The relocation target must be absolute or the image must be fixed. | IMAGE_REL_IA64_IMM22 | 0x0002 | This instruction relocation may be followed by an ADDEND relocation whose Value is added to the target address before it is inserted into the specified slot in the IMM22 bundle. The relocation target must be absolute or the image must be fixed. | IMAGE_REL_IA64_IMM64 | 0x0003 | The slot number for this relocation must be one (1). The relocation may be followed by an ADDEND relocation whose Value is added to the target address before it is stored in all three slots of the IMM64 bundle. | IMAGE_REL_IA64_DIR32 | 0x0004 | The target's 32-bit virtual address. Supported only for /LARGEADDRESSAWARE:NO images. | IMAGE_REL_IA64_DIR64 | 0x0005 | The target's 64-bit virtual address. | IMAGE_REL_IA64_PCREL21B | 0x0006 | The instruction is fixed up with the 25-bit relative displacement to the 16-bit aligned target. The low four bits of the displacement, which are zero, are not stored. | IMAGE_REL_IA64_PCREL21M | 0x0007 | The instruction is fixed up with the 25-bit relative displacement to the 16-bit aligned target. The low four bits of the displacement, which are zero, are not stored. | IMAGE_REL_IA64_PCREL21F | 0x0008 | The least significant bits of this relocation's offset must contain the slot number, and the rest is the bundle address. The bundle is fixed up with the 25-bit relative displacement to the 16-bit aligned target. The low four bits of the displacement, which are zero, are not stored. | IMAGE_REL_IA64_GPREL22 | 0x0009 | This instruction relocation may be followed by an ADDEND relocation whose Value is added to the target address, and then a 22-bit GP-relative offset is calculated and applied to the GPREL22 bundle. | IMAGE_REL_IA64_LTOFF22 | 0x000A | The instruction is fixed up with the 22-bit GP-relative offset to the target symbol's literal table entry. The linker creates this literal table entry based on this relocation and the ADDEND relocation that may follow. | IMAGE_REL_IA64_SECTION | 0x000B | The 16-bit section index of the section containing the target. This is used to support debugging information. | IMAGE_REL_IA64_SECREL22 | 0x000C | The instruction is fixed up with the 22-bit offset of the target from the beginning of its section. This relocation may be followed immediately by an ADDEND relocation, whose Value field contains the 32-bit unsigned offset of the target from the beginning of the section. | IMAGE_REL_IA64_SECREL64I | 0x000D | The slot number for this relocation must be one (1). The instruction is fixed up with the 64-bit offset of the target from the beginning of its section. This relocation may be followed immediately by an ADDEND relocation, whose Value field contains the 32-bit unsigned offset of the target from the beginning of the section. | IMAGE_REL_IA64_SECREL32 | 0x000E | The address of data to be fixed up with the 32-bit offset of the target from the beginning of its section. | IMAGE_REL_IA64_DIR32NB | 0x0010 | The target's 32-bit relative virtual address. | IMAGE_REL_IA64_SREL14 | 0x0011 | 14-bit signed relative for an immediate 14 bit storage, used for the difference between two relocatable targets, information only. The linker does not apply these. | IMAGE_REL_IA64_SREL22 | 0x0012 | 22-bit signed relative for an immediate 22 bit storage, used for the difference between two relocatable targets, information only. The linker does not apply these. | IMAGE_REL_IA64_SREL32 | 0x0013 | 32-bit signed relative for an immediate 32 bit storage, used for the difference between two relocatable targets, information only. The linker does not apply these. | IMAGE_REL_IA64_UREL32 | 0x0014 | 32-bit unsigned relative for an immediate 32 bit storage, used for the difference between two relocatable targets, information only. The linker does not apply these. | IMAGE_REL_IA64_PCREL60X | 0x0015 | 60-bit PC relative fixup that always stays as a BRL instruction in slots 1/2 of an MLX bundle. | IMAGE_REL_IA64_PCREL60B | 0x0016 | 60-bit PC relative fixup; if target displacement fits in a signed 25-bit field, convert to MBB bundle with NOP.B in slot 1 and a 25-bit (4 lowest bits all zero and dropped) BR instruction in slot 2. | IMAGE_REL_IA64_PCREL60F | 0x0017 | 60-bit PC relative fixup; if target displacement fits in a signed 25-bit field, convert to MFB bundle with NOP.F in slot 1 and a 25-bit (4 lowest bits all zero and dropped) BR instruction in slot 2. | IMAGE_REL_IA64_PCREL60I | 0x0018 | 60-bit PC relative fixup; if target displacement fits in a signed 25-bit field, convert to MIB bundle with NOP.I in slot 1 and a 25-bit (4 lowest bits all zero and dropped) BR instruction in slot 2. | IMAGE_REL_IA64_PCREL60M | 0x0019 | 60-bit PC relative fixup; if target displacement fits in a signed 25-bit field, convert to MMB bundle with NOP.M in slot 1 and a 25-bit (4 lowest bits all zero and dropped) BR instruction in slot 2. | IMAGE_REL_IA64_IMMGPREL64 | 0x001a | 64-bit GP relative fixup. | IMAGE_REL_IA64_TOKEN | 0x001b | clr token. | IMAGE_REL_IA64_GPREL32 | 0x001c | 32-bit GP relative fixup. | IMAGE_REL_IA64_ADDEND | 0x001F | This relocation is only valid when it immediately follows an IMM14, IMM22, IMM64, GPREL22, LTOFF22, LTOFF64, SECREL22, SECREL64I, or SECREL32 relocation. Its Value contains the addend to apply to instructions within a bundle, not for data. | MIPS Processors The following relocation type indicators are defined for MIPS processors: Constant | Value | Description |
---|
IMAGE_REL_MIPS_ABSOLUTE | 0x0000 | This relocation is ignored. | IMAGE_REL_MIPS_REFHALF | 0x0001 | The high 16 bits of the target's 32-bit virtual address. | IMAGE_REL_MIPS_REFWORD | 0x0002 | The target's 32-bit virtual address. | IMAGE_REL_MIPS_JMPADDR | 0x0003 | The low 26 bits of the target's virtual address. This supports the MIPS J and JAL instructions. | IMAGE_REL_MIPS_REFHI | 0x0004 | The high 16 bits of the target's 32-bit virtual address. Used for the first instruction in a two-instruction sequence that loads a full address. This relocation must be immediately followed by a PAIR relocation whose SymbolTableIndex contains a signed 16 bit displacement which is added to the upper 16 bits taken from the location being relocated. | IMAGE_REL_MIPS_REFLO | 0x0005 | The low 16 bits of the target's virtual address. | IMAGE_REL_MIPS_GPREL | 0x0006 | 16-bit signed displacement of the target relative to the Global Pointer (GP) register. | IMAGE_REL_MIPS_LITERAL | 0x0007 | Same as IMAGE_REL_MIPS_GPREL. | IMAGE_REL_MIPS_SECTION | 0x000A | The 16 bit section index of the section containing the target. This is used to support debugging information. | IMAGE_REL_MIPS_SECREL | 0x000B | The 32-bit offset of the target from the beginning of its section. This is used to support debugging information as well as static thread local storage. | IMAGE_REL_MIPS_SECRELLO | 0x000C | The low 16 bits of the 32-bit offset of the target from the beginning of its section. | IMAGE_REL_MIPS_SECRELHI | 0x000D | The high 16 bits of the 32-bit offset of the target from the beginning of its section. An IMAGE_REL_MIPS_PAIR relocation must immediately follow this one. The SymbolTableIndex of the PAIR relocation contains a signed 16 bit displacement which is added to the upper 16 bits taken from the location being relocated. | IMAGE_REL_MIPS_JMPADDR16 | 0x0010 | The low 26 bits of the target's virtual address. This supports the MIPS16 JAL instruction. | IMAGE_REL_MIPS_REFWORDNB | 0x0022 | The target's 32-bit relative virtual address. | IMAGE_REL_MIPS_PAIR | 0x0025 | This relocation is only valid when it immediately follows a REFHI or SECRELHI relocation. Its SymbolTableIndex contains a displacement and not an index into the symbol table. | Mitsubishi M32R The following relocation type indicators are defined for the Mitsubishi M32R processors: Constant | Value | Description |
---|
IMAGE_REL_M32R_ABSOLUTE | 0x0000 | This relocation is ignored. | IMAGE_REL_M32R_ADDR32 | 0x0001 | The target's 32-bit virtual address. | IMAGE_REL_M32R_ADDR32NB | 0x0002 | The target's 32-bit relative virtual address. | IMAGE_REL_M32R_ADDR24 | 0x0003 | The target's 24-bit virtual address. | IMAGE_REL_M32R_GPREL16 | 0x0004 | The target's 16-bit offset from GP (global pointer). | IMAGE_REL_M32R_PCREL24 | 0x0005 | The target's 24-bit offset << 2 & sign extended from PC (program counter). | IMAGE_REL_M32R_PCREL16 | 0x0006 | The target's 16-bit offset << 2 & sign extended from PC. | IMAGE_REL_M32R_PCREL8 | 0x0007 | The target's 8-bit offset << 2 & sign extended from PC. | IMAGE_REL_M32R_REFHALF | 0x0008 | The target's 16 MSB (most significant bits) (VA). | IMAGE_REL_M32R_REFHI | 0x0009 | The target's 16 MSB adjusted for LSB sign extension. Used for the first instruction in a two-instruction sequence that loads a full 32-bit address. This relocation must be immediately followed by a PAIR relocation whose SymbolTableIndex contains a signed 16 bit displacement which is added to the upper 16 bits taken from the location being relocated. | IMAGE_REL_M32R_REFLO | 0x000A | The target's 16 LSB (least significant bits). | IMAGE_REL_M32R_PAIR | 0x000B | Must follow the REFHI relocation. Its SymbolTableIndex contains a displacement and not an index into the symbol table. | IMAGE_REL_M32R_SECTION | 0x000C | The 16-bit section index of the section containing the target. This is used to support debugging information. | IMAGE_REL_M32R_SECREL | 0x000D | The 32-bit offset of the target from the beginning of its section. This is used to support debugging information as well as static thread local storage. | IMAGE_REL_M32R_TOKEN | 0x000E | clr token. | 5.3 COFF Line Numbers Current and future versions of Visual C++ may not create COFF line numbers due to the restrictions of the COFF system using ANSI file names in .file symbols and limitations of 16-bit line numbers without any column information. The preferred format is the new Visual C++ 8.0 files and lines. Please see the latest version of the Visual C++ Debugging Information specification in MSDN's specifications section for information on this new format of the file and line number data in object files. COFF line numbers indicate the relationship between code and line-numbers in source files. The Microsoft format for COFF line numbers is similar to standard COFF, but it has been extended to allow a single section to relate to line numbers in multiple source files. COFF line numbers consist of an array of fixed-length records. The location (file offset) and size of the array are specified in the section header. Each line-number record is of the following format: Offset | Size | Field | Description |
---|
0 | 4 | Type (*) | Union of two fields: Symbol Table Index and RVA. Whether Symbol Table Index or RVA is used depends on the value of Linenumber. | 4 | 2 | Linenumber | When nonzero, this field specifies a one-based line number. When zero, the Type field is interpreted as a Symbol Table Index for a function. | The Type field is a union of two four-byte fields: Symbol Table Index and RVA: Offset | Size | Field | Description |
---|
0 | 4 | SymbolTableIndex | Used when Linenumber is 0: index to symbol table entry for a function. This format is used to indicate the function that a group of line-number records refer to. | 0 | 4 | VirtualAddress | Used when Linenumber is non-zero: relative virtual address of the executable code that corresponds to the source line indicated. In an object file, this contains the virtual address within the section. | A line-number record, then, can either set the Linenumber field to 0 and point to a function definition in the Symbol Table, or else it can work as a standard line-number entry by giving a positive integer (line number) and the corresponding address in the object code. A group of line-number entries always begins with the first format: the index of a function symbol. If this is the first line-number record in the section, then it is also the COMDAT symbol name for the function if the section's COMDAT flag is set. (See Section 5.5.6, "COMDAT Sections.") The function's auxiliary record in the Symbol Table has a Pointer to [the] Linenumbers field that points to this same line-number record. A record identifying a function is followed by any number of line-number entries that give actual line-number information (Linenumber greater than zero). These entries are one-based, relative to the beginning of the function, and represent every source line in the function except for the first one. For example, the first line-number record for the following example would specify the ReverseSign function (Symbol Table Index of ReverseSign, Linenumber set to 0). Then records with Linenumber values of 1, 2, and 3 would follow, corresponding to source lines as shown: // some code precedes ReverseSign function int ReverseSign(int i) 1:{ 2: return -1 * i; 3:} 5.4 COFF Symbol Table The Symbol Table described in this section is inherited from the traditional COFF format. It is distinct from Visual C++ Debug information. A file may contain both a COFF Symbol Table and Visual C++ debug information, and the two are kept separate. Some Microsoft tools use the Symbol Table for limited but important purposes, such as communicating COMDAT information to the linker. Section names and file names, as well as code and data symbols, are listed in the Symbol Table. The location of the Symbol Table is indicated in the COFF Header. The Symbol Table is an array of records, each 18 bytes long. Each record is either a standard or auxiliary symbol-table record. A standard record defines a symbol or name, and has the following format: Offset | Size | Field | Description |
---|
0 | 8 | Name (*) | Name of the symbol, represented by union of three structures. An array of eight bytes is used if the name is not more than eight bytes long. See Section 5.4.1, "Symbol Name Representation," for more information. | 8 | 4 | Value | Value associated with the symbol. The interpretation of this field depends on Section Number and Storage Class. A typical meaning is the relocatable address. | 12 | 2 | SectionNumber | Signed integer identifying the section, using a one-based index into the Section Table. Some values have special meaning defined in [Section 5.4.2,] "Section Number Values." | 14 | 2 | Type | A number representing type. Microsoft tools set this field to 0x20 (function) or 0x0 (not a function). See Section 5.4.3, "Type Representation," for more information. | 16 | 1 | StorageClass | Enumerated value representing storage class. See Section 5.4.4, "Storage Class," for more information. | 17 | 1 | NumberOfAuxSymbols | Number of auxiliary symbol table entries that follow this record. | Zero or more auxiliary symbol-table records immediately follow each standard symbol-table record. However, typically not more than one auxiliary symbol-table record follows a standard symbol-table record (except for .file records with long file names). Each auxiliary record is the same size as a standard symbol-table record (18 bytes), but rather than define a new symbol, the auxiliary record gives additional information on the last symbol defined. The choice of which of several formats to use depends on the Storage Class field. Currently defined formats for auxiliary symbol table records are shown in "Auxiliary Symbol Records." Tools that read COFF symbol tables must ignore auxiliary symbol records whose interpretation is unknown. This allows the symbol table format to be extended to add new auxiliary records, without breaking existing tools. 5.4.1 Symbol Name Representation The Name field in a symbol table consists of eight bytes that contain the name itself, if it is not more than eight bytes long, or else give an offset into the String Table. To determine whether the name itself or an offset is given, test the first four bytes for equality to zero. By convention, the names are treated as zero-terminated UTF-8 encoded strings. Offset | Size | Field | Description |
---|
0 | 8 | Short Name | An array of eight bytes. This array is padded with nulls on the right if the name is less than eight bytes long. | 0 | 4 | Zeroes | Set to all zeros if the name is longer than eight bytes. | 4 | 4 | Offset | Offset into the String Table. | 5.4.2 Section Number Values Normally, the Section Value field in a symbol table entry is a one-based index into the Section Table. However, this field is a signed integer and may take negative values. The following values, less than one, have special meanings: Constant | Value | Description |
---|
IMAGE_SYM_UNDEFINED | 0 | Symbol record is not yet assigned a section. If the value is 0, this indicates a references to an external symbol defined elsewhere. If the value is non-zero, this is a common symbol with a size specified by the value. | IMAGE_SYM_ABSOLUTE | -1 | The symbol has an absolute (non-relocatable) value and is not an address. | IMAGE_SYM_DEBUG | -2 | The symbol provides general type or debugging information but does not correspond to a section. Microsoft tools use this setting along with .file records (storage class FILE). | 5.4.3 Type Representation The Type field of a symbol table entry contains two bytes, where each byte represents type information. The least-significant byte represents simple (base) data type, and the most-significant byte represents complex type, if any: MSB | LSB |
---|
Complex type: none, pointer, function, array. | Base type: integer, floating-point, etc. | The following values are defined for base type, although Microsoft tools generally do not use this field, setting the least-significant byte to 0. Instead, Visual C++ Debug information is used to indicate types. However, the possible COFF values are listed here for completeness. Constant | Value | Description |
---|
IMAGE_SYM_TYPE_NULL | 0 | No type information or unknown base type. Microsoft tools use this setting. | IMAGE_SYM_TYPE_VOID | 1 | No valid type; used with void pointers and functions. | IMAGE_SYM_TYPE_CHAR | 2 | Character (signed byte). | IMAGE_SYM_TYPE_SHORT | 3 | Two-byte signed integer. | IMAGE_SYM_TYPE_INT | 4 | Natural integer type (normally four bytes in Windows). | IMAGE_SYM_TYPE_LONG | 5 | Four-byte signed integer. | IMAGE_SYM_TYPE_FLOAT | 6 | Four-byte floating point number. | IMAGE_SYM_TYPE_DOUBLE | 7 | Eight-byte floating point number. | IMAGE_SYM_TYPE_STRUCT | 8 | Structure. | IMAGE_SYM_TYPE_UNION | 9 | Union. | IMAGE_SYM_TYPE_ENUM | 10 | Enumerated type. | IMAGE_SYM_TYPE_MOE | 11 | Member of enumeration (a specific value). | IMAGE_SYM_TYPE_BYTE | 12 | Byte; unsigned one-byte integer. | IMAGE_SYM_TYPE_WORD | 13 | Word; unsigned two-byte integer. | IMAGE_SYM_TYPE_UINT | 14 | Unsigned integer of natural size (normally, four bytes). | IMAGE_SYM_TYPE_DWORD | 15 | Unsigned four-byte integer. | The most significant byte specifies whether the symbol is a pointer to, function returning, or array of the base type specified in the least significant byte. Microsoft tools use this field only to indicate whether or not the symbol is a function, so that the only two resulting values are 0x0 and 0x20 for the Type field. However, other tools can use this field to communicate more information. It is very important to specify the function attribute correctly. This information is required for incremental linking to work correctly. For some architectures, the information may be required for other purposes. Constant | Value | Description |
---|
IMAGE_SYM_DTYPE_NULL | 0 | No derived type; the symbol is a simple scalar variable. | IMAGE_SYM_DTYPE_POINTER | 1 | Pointer to base type. | IMAGE_SYM_DTYPE_FUNCTION | 2 | Function returning base type. | IMAGE_SYM_DTYPE_ARRAY | 3 | Array of base type. | 5.4.4 Storage Class The Storage Class field of the Symbol Table indicates what kind of definition a symbol represents. The following table shows possible values. Note that the Storage Class field is an unsigned one-byte integer. The special value 1 should therefore be taken to mean its unsigned equivalent, 0xFF. Although traditional COFF format makes use of many storage-class values, Microsoft tools rely on Visual C++ Debug format for most symbolic information and generally use only four storage-class values: EXTERNAL (2), STATIC (3), FUNCTION (101), and STATIC (103). Except in the second column heading below, "Value" should be taken to mean the Value field of the symbol record (whose interpretation depends on the number found as the storage class). Constant | Value | Description / Interpretation of Value Field |
---|
IMAGE_SYM_CLASS_END_OF_FUNCTION | 1 (0xFF) | Special symbol representing end of function, for debugging purposes. | IMAGE_SYM_CLASS_NULL | 0 | No storage class assigned. | IMAGE_SYM_CLASS_AUTOMATIC | 1 | Automatic (stack) variable. The Value field specifies stack frame offset. | IMAGE_SYM_CLASS_EXTERNAL | 2 | Used by Microsoft tools for external symbols. The Value field indicates the size if the section number is IMAGE_SYM_UNDEFINED (0). If the section number is not 0, then the Value field specifies the offset within the section. | IMAGE_SYM_CLASS_STATIC | 3 | The Value field specifies the offset of the symbol within the section. If the Value is 0, then the symbol represents a section name. | IMAGE_SYM_CLASS_REGISTER | 4 | Register variable. The Value field specifies register number. | IMAGE_SYM_CLASS_EXTERNAL_DEF | 5 | Symbol is defined externally. | IMAGE_SYM_CLASS_LABEL | 6 | Code label defined within the module. The Value field specifies the offset of the symbol within the section. | IMAGE_SYM_CLASS_UNDEFINED_LABEL | 7 | Reference to a code label not defined. | IMAGE_SYM_CLASS_MEMBER_OF_STRUCT | 8 | Structure member. The Value field specifies nth member. | IMAGE_SYM_CLASS_ARGUMENT | 9 | Formal argument (parameter) of a function. The Value field specifies nth argument. | IMAGE_SYM_CLASS_STRUCT_TAG | 10 | Structure tag-name entry. | IMAGE_SYM_CLASS_MEMBER_OF_UNION | 11 | Union member. The Value field specifies nth member. | IMAGE_SYM_CLASS_UNION_TAG | 12 | Union tag-name entry. | IMAGE_SYM_CLASS_TYPE_DEFINITION | 13 | Typedef entry. | IMAGE_SYM_CLASS_UNDEFINED_STATIC | 14 | Static data declaration. | IMAGE_SYM_CLASS_ENUM_TAG | 15 | Enumerated type tagname entry. | IMAGE_SYM_CLASS_MEMBER_OF_ENUM | 16 | Member of enumeration. Value specifies nth member. | IMAGE_SYM_CLASS_REGISTER_PARAM | 17 | Register parameter. | IMAGE_SYM_CLASS_BIT_FIELD | 18 | Bit-field reference. Value specifies nth bit in the bit field. | IMAGE_SYM_CLASS_BLOCK | 100 | A .bb (beginning of block) or .eb (end of block) record. Value is the relocatable address of the code location. | IMAGE_SYM_CLASS_FUNCTION | 101 | Used by Microsoft tools for symbol records that define the extent of a function: begin function (named .bf), end function (.ef), and lines in function (.lf). For .lf records, Value gives the number of source lines in the function. For .ef records, Value gives the size of function code. | IMAGE_SYM_CLASS_END_OF_STRUCT | 102 | End of structure entry. | IMAGE_SYM_CLASS_FILE | 103 | Used by Microsoft tools, as well as traditional COFF format, for the source-file symbol record. The symbol is followed by auxiliary records that name the file. | IMAGE_SYM_CLASS_SECTION | 104 | Definition of a section (Microsoft tools use STATIC storage class instead). | IMAGE_SYM_CLASS_WEAK_EXTERNAL | 105 | Weak external. See Section 5.5.3, "Auxiliary Format 3: Weak Externals," for more information. | IMAGE_SYM_CLASS_CLR_TOKEN | 107 | clr token symbol; name is ASCII string consisting of the hexadecimal value of the token. See Section 5.5.7, "clr Token Definition," for more information. | 5.5 Auxiliary Symbol Records Auxiliary Symbol Table records always follow, and apply to, some standard Symbol Table record. An auxiliary record can have any format that the tools are designed to recognize, but 18 bytes must be allocated for them so that Symbol Table is maintained as an array of regular size. Currently, Microsoft tools recognize auxiliary formats for the following kinds of records: function definitions, function begin and end symbols (.bf and .ef), weak externals, filenames, and section definitions. The traditional COFF design also includes auxiliary-record formats for arrays and structures. Microsoft tools do not use these, instead placing that symbolic information in Visual C++ Debug format in the debug sections. 5.5.1 Auxiliary Format 1: Function Definitions A symbol table record marks the beginning of a function definition if all of the following are true: it has storage class EXTERNAL (2), a Type value indicating it is a function (0x20), and a section number greater than zero. Note that a symbol table record that has a section number of UNDEFINED (0) does not define the function and does not have an auxiliary record. Function-definition symbol records are followed by an auxiliary record with the format described below. Offset | Size | Field | Description |
---|
0 | 4 | TagIndex | Symbol-table index of the corresponding .bf (begin function) symbol record. | 4 | 4 | TotalSize | Size of the executable code for the function itself. If the function is in its own section, the Size of Raw Data in the section header will be greater or equal to this field, depending on alignment considerations. | 8 | 4 | PointerToLinenumber | File offset of the first COFF line-number entry for the function, or zero if none exists. See Section 5.3, "COFF Line Numbers," for more information. | 12 | 4 | PointerToNextFunction | Symbol-table index of the record for the next function. If the function is the last in the symbol table, this field is set to zero. | 16 | 2 | Unused. | 5.5.2 Auxiliary Format 2: .bf and .ef Symbols For each function definition in the Symbol Table, there are three items that describe the beginning, ending, and number of lines. Each of these symbols has storage class FUNCTION (101): A symbol record named .bf (begin function). The Value field is unused. A symbol record named .lf (lines in function). The Value field gives the number of lines in the function. A symbol record named .ef (end of function). The Value field has the same number as the Total Size field in the function-definition symbol record. The .bf and .ef symbol records (but not .lf records) are followed by an auxiliary record with the following format: Offset | Size | Field | Description |
---|
0 | 4 | Unused. | 4 | 2 | Linenumber | Actual ordinal line number (1, 2, 3, etc.) within source file, corresponding to the .bf or .ef record. | 6 | 6 | Unused. | 12 | 4 | PointerToNextFunction (.bf only) | Symbol-table index of the next .bf symbol record. If the function is the last in the symbol table, this field is set to zero. Not used for .ef records. | 16 | 2 | Unused. | 5.5.3 Auxiliary Format 3: Weak Externals "Weak externals" are a mechanism for object files allowing flexibility at link time. A module can contain an unresolved external symbol (sym1), but it can also include an auxiliary record indicating that if sym1 is not present at link time, another external symbol (sym2) is used to resolve references instead. If a definition of sym1 is linked, then an external reference to the symbol is resolved normally. If a definition of sym1 is not linked, then all references to the weak external for sym1 refer to sym2 instead. The external symbol, sym2, must always be linked; typically it is defined in the module containing the weak reference to sym1. Weak externals are represented by a Symbol Table record with EXTERNAL storage class, UNDEF section number, and a value of 0. The weak-external symbol record is followed by an auxiliary record with the following format: Offset | Size | Field | Description |
---|
0 | 4 | TagIndex | Symbol-table index of sym2, the symbol to be linked if sym1 is not found. | 4 | 4 | Characteristics | A value of IMAGE_WEAK_EXTERN_SEARCH_NOLIBRARY indicates that no library search for sym1 should be performed. A value of IMAGE_WEAK_EXTERN_SEARCH_LIBRARY indicates that a library search for sym1 should be performed. A value of IMAGE_WEAK_EXTERN_SEARCH_ALIAS indicates that sym1 is an alias for sym2. | 8 | 10 | Unused. | Note that the Characteristics field is not defined in WINNT.H; instead, the Total Size field is used. 5.5.4 Auxiliary Format 4: Files This format follows a symbol-table record with storage class FILE (103). The symbol name itself should be .file, and the auxiliary record that follows it gives the name of a source-code file. Offset | Size | Field | Description |
---|
0 | 18 | File Name | ANSI string giving the name of the source file; padded with nulls if less than maximum length. | 5.5.5 Auxiliary Format 5: Section Definitions This format follows a symbol-table record that defines a section: such a record has a symbol name that is the name of a section (such as .text or .drectve) and has storage class STATIC (3). The auxiliary record provides information on the section referred to. Thus it duplicates some of the information in the section header. Offset | Size | Field | Description |
---|
0 | 4 | Length | Size of section data; same as Size of Raw Data in the section header. | 4 | 2 | NumberOfRelocations | Number of relocation entries for the section. | 6 | 2 | NumberOfLinenumbers | Number of line-number entries for the section. | 8 | 4 | Check Sum | Checksum for communal data. Applicable if the IMAGE_SCN_LNK_COMDAT flag is set in the section header. See "COMDAT Sections" below, for more information. | 12 | 2 | Number | One-based index into the Section Table for the associated section; used when the COMDAT Selection setting is 5. | 14 | 1 | Selection | COMDAT selection number. Applicable if the section is a COMDAT section. | 15 | 3 | Unused. | 5.5.6 COMDAT Sections (Object Only) The Selection field of the Section Definition auxiliary format is applicable if the section is a COMDAT section: a section that can be defined by more than one object file. (The flag IMAGE_SCN_LNK_COMDAT is set in the Section Flags field of the section header.) The Selection field determines the way that the linker resolves the multiple definitions of COMDAT sections. The first symbol having the section value of the COMDAT section must be the section symbol. This symbol has the name of the section, Value field equal to 0, the section number of the COMDAT section in question, Type field equal to IMAGE_SYM_TYPE_NULL, Class field equal to IMAGE_SYM_CLASS_STATIC, and one auxiliary record. The second symbol is called "the COMDAT symbol" and is used by the linker in conjunction with the Selection field. Values for the Selection field are shown below. Constant | Value | Description |
---|
IMAGE_COMDAT_SELECT_NODUPLICATES | 1 | The linker issues a multiply defined symbol error if this symbol is already defined. | IMAGE_COMDAT_SELECT_ANY | 2 | Any section defining the same COMDAT symbol may be linked; the rest are removed. | IMAGE_COMDAT_SELECT_SAME_SIZE | 3 | The linker chooses an arbitrary section among the definitions for this symbol. A multiply defined symbol error is issued if all definitions don't have the same size. | IMAGE_COMDAT_SELECT_EXACT_MATCH | 4 | The linker chooses an arbitrary section among the definitions for this symbol. A multiply defined symbol error is issued if all definitions don't match exactly. | IMAGE_COMDAT_SELECT_ASSOCIATIVE | 5 | The section is linked if a certain other COMDAT section is linked. This other section is indicated by the Number field of the auxiliary symbol record for the section definition. Use of this setting is useful for definitions that have components in multiple sections (for example, code in one and data in another), but where all must be linked or discarded as a set. The other section that this one is associated with must be a COMDAT and not another associative COMDAT. | IMAGE_COMDAT_SELECT_LARGEST | 6 | The linker chooses the largest from the definitions for this symbol. If multiple definitions have this size, the choice between them is arbitrary. | 5.5.7 clr Token Definition (Object Only) This auxiliary symbol generally follows the IMAGE_SYM_CLASS_CLR_TOKEN and is used to tie together a token to the COFF symbol table's namespace. Offset | Size | Field | Description |
---|
0 | 1 | bAuxType | Must be IMAGE_AUX_SYMBOL_TYPE_TOKEN_DEF (1). | 1 | 1 | bReserved | Reserved, must be zero. | 2 | 4 | SymbolTableIndex | Symbol index of the COFF symbol that this clr Token Definition refers to. | 6 | 12 | | Reserved, must be zero. | 5.6 COFF String Table Immediately following the COFF symbol table is the COFF string table. The position of this table is found by taking the symbol table address in the COFF header, and adding the number of symbols multiplied by the size of a symbol. At the beginning of the COFF string table are 4 bytes containing the total size (in bytes) of the rest of the string table. This size includes the size field itself, so that the value in this location would be 4 if no strings were present. Following the size are null-terminated strings pointed to by symbols in the COFF symbol table. 5.7 The Attribute Certificate Table (Image Only) Attribute Certificates may be associated with an image by adding an Attribute Certificate Table. There are a number of different types of Attribute Certificates. The meaning and use of each certificate type is not covered in this document. For this information see the Microsoft Distributed System Architecture, Attribute Certificate Architecture Specification. An Attribute Certificate Table is added at the end of the image, with only a .debug section following (if a .debug section is present). The Attribute Certificate Table contains one or more fixed length table entries that can be found via the Certificate Table field of the Optional Header Data Directories list (offset 128). Each entry of this table identifies the beginning location and length of a corresponding certificate. There is one Certificate Table entry for each certificate stored in this section. The number of entries in the certificate table can be calculated by dividing the size of the certificate table (found in offset 132) by the size of an entry in the certificate table (8). Note that the size of the certificate table includes only the table entries, not the actual certificates which the table entries, in turn, point to. The format of each table entry is: Offset | Size | Field | Description |
---|
0 | 4 | Certificate Data | File pointer to the certificate data. This will always point to an address that is octaword aligned (i.e., is a multiple of 8 bytes and so the low-order 3 bits are zero). | 0 | 4 | Size of Certificate | Unsigned integer identifying the size (in bytes) of the certificate. | Notice that certificates always start on an octaword boundary. If a certificate is not an even number of octawords long, it is zero padded to the next octaword boundary. However, the length of the certificate does not include this padding and so any certificate navigation software must be sure to round up to the next octaword to locate another certificate. 5.7.1 Certificate Data This is the binary data representing an Attribute Certificate. The format and meaning of each certificate is defined in Attribute Certificate Architecture Specification. The certificate starting location and length is specified by an entry in the Certificate Table. Each certificate is represented by a single Certificate Table entry. 5.8 Delay-Load Import Tables (Image Only) These tables were added to the image in order to support a uniform mechanism for applications to delay the loading of a dll until the first call into that dll. The layout of the tables matches that of the traditional import tables (see Section 6.4, "The .idata Section," for details), so only a few details will be discussed here. 5.8.1 The Delay-Load Directory Table The Delay-Load Directory Table is the counterpart to the Import Directory Table, and can be retrieved via the Delay Import Descriptor entry in the Optional Header Data Directories list (offset 200). The Table is arranged as follows: Offset | Size | Field | Description |
---|
0 | 4 | Attributes | Must be zero. | 4 | 4 | Name | Relative virtual address of the name of the dll to be loaded. The name resides in the read-only data section of the image. | 8 | 4 | Module Handle | Relative virtual address of the module handle (in the data section of the image) of the dll to be delay-loaded. Used for storage by the routine supplied to manage delay-loading. | 12 | 4 | Delay Import Address Table | Relative virtual address of the delay-load import address table. See below for further details. | 16 | 4 | Delay Import Name Table | Relative virtual address of the delay-load name table, which contains the names of the imports that may need to be loaded. Matches the layout of the Import Name Table (Section 6.4.3, "Hint/Name Table"). | 20 | 4 | Bound Delay Import Table | Relative virtual address of the bound delay-load address table, if it exists. | 24 | 4 | Unload Delay Import Table | Relative virtual address of the unload delay-load address table, if it exists. This is an exact copy of the Delay Import Address Table. In the event that the caller unloads the dll, this table should be copied back over the Delay IAT such that subsequent calls to the dll continue to use the thunking mechanism correctly. | 28 | 4 | Time Stamp | Time stamp of dll to which this image has been bound. | The tables referenced in this data structure are organized and sorted just as their counterparts are for traditional imports. See Section 6.4, "The .idata Section," for details. 5.8.2 Attributes As yet, there are no attribute flags defined. This field is currently set to zero by the linker in the image. This field can be used to extend the record by indicating the presence of new fields or for indicating behaviors to the delay and/or unload helper functions. 5.8.3 Name The name of the DLL to be delay loaded resides in the read-only data section of the image and is referenced via the szName field. 5.8.4 Module Handle The handle of the DLL to be delay loaded is located in the data section of the image and pointed to via the phmod field. The supplied delay load helper uses this location to store the handle to the loaded DLL. 5.8.5 Delay Import Address Table (IAT) The delay IAT is referenced by the delay import descriptor via the pIAT field. This is the working copy of the entry point, function pointers that reside in the data section of the image and initially refer to the delay load thunks. The delay load helper is responsible for updating these pointers with the real entry points so that the thunks are no longer in the calling loop. The function pointers are accessed via the expression pINT->u1.Function. 5.8.6 Delay Import Name Table (INT) The delay INT has the names of the imports that may need to be loaded. They are ordered in the same fashion as the function pointers in the IAT. They consist of the same structures as the standard INT and are accessed via the expression pINT->u1.AddressOfData->Name[0]. 5.8.7 Delay Bound Import Address Table (BIAT) and Time Stamp The delay BIAT is an optional table of IMAGE_THUNK_DATA items that is used along with the timestamp field by a post process binding phase. 5.8.8 Delay Unload Import Address Table (UIAT) The delay UIAT is an optional table of IMAGE_THUNK_DATA items that is used by the unload code to handle an explicit unload request. It is initialized data in the read-only section that is an exact copy of the original IAT that referred the code to the delay load thunks. On the unload request, the library can be freed, the *phmod cleared, and the UIAT written over the IAT to restore everything to its pre-load state. |