5 Other Contents of the File


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.



The Common Language Infrastructure Annotated Standard (Microsoft. NET Development Series)
The Common Language Infrastructure Annotated Standard (Microsoft. NET Development Series)
ISBN: N/A
EAN: N/A
Year: 2002
Pages: 121

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net