Symbolic Debug Information Page 1 of 89

Visual C++ 5.0 Symbolic Debug Information

Specification
Visual C++ Product Unit
VC5.0 Symbolic Debug Information Specification

Authors: Steve Smith, Dan Spalding, et al.

Revision 5, 32-Bit only September 30, 1996

This document describes the format and meaning of the information of the Microsoft CodeView
debugging information. The information is contained within two tables emitted by the language
processor into the object file. Each table is treated as a stream of variable length records. The first
table is called $$SYMBOLS and describes the symbols in the object file. The record for each symbol
contains the symbol name, the symbol address and other information needed to describe the symbol.
The second table is called $$TYPES and contains information about symbol typing. There are fields
in the records contained in $$SYMBOLS that index into the records contained in $$TYPES. Records
in $$TYPES can also index into the records contained in the $$TYPES table.

The records for $$SYMBOLS and $$TYPES are accumulated by the linker and are written into the
executable file. There is a third table of symbol information for each object file that is generated by
the linker and written into the executable file called the PUBLICS table. This table contains symbol
records for each public symbol definition encountered in the object file.

Field sizes and arrangement in $$SYMBOLS and $$TYPES are arranged to maintain "natural
alignment" to improve performance. Natural alignment indicates that a field begins on an address
that is divisible by the size of the field. For example, a four byte (long) value begins on an address
that is evenly divisible by four. Most architectures, such as the MIPS R4K, Motorola PowerPC, and
Digital Alpha family of processors, impose a severe penalty for loading data that is not in natural
alignment. Even for the Intel x86 architecture there is a significant improvement processing data that
is in natural alignment.

Compilers that emit Symbol and Type OMF according to this specification indicate so by placing a
signature of 0x00000002 at the beginning of the $$SYMBOLS and $$TYPES tables. The signature
0x00000001 is still valid for 16-bit type and symbol records but those are not covered in this
specification. Please refer to the CV4 Symbolic Debug Information Specification in the specification
section of MSDN. The 16-bit versions of symbols and types are converted automatically to their 32-
bit equivalents by LINK and/or CVPACK in Visual C++ v5.0 before storing the debug information.
There is to be no 16- and 32-bit records mixed together in either one object file, one type server, or
one executable's debug information.

In all structure descriptions and value enumerations, all values not specified in this document are
reserved for future use. All values should be referenced by the symbolic descriptions.

CVPACK must be run on a linked executable file before the Visual C++ debugger can process the
file. CVPACK removes duplicate symbol and type information and rewrites the remaining
information in a format optimized for CodeView processing. CVPACK will recognize old Symbol
and Type OMF and rewrite it to this format during packing.

Information in this document is subject to change without notice and does not represent a
commitment on the part of Microsoft Corporation. No part of the document may be reproduced or
transmitted in any form or by any means, electronic or mechanical, including photocopying and
Symbolic Debug Information Page 2 of 89

recording, for any purpose without the express written permission of Microsoft.

Introduction
This section describes the format used to embed debugging information into the executable file.

Debug Information Format

The debug information format encompasses a block of data which goes into the .exe file at a location
dependent upon the executable file format. The version of the debug information is specified by a
signature that is contained within the debug information. The signature has the format NBxx, where
xx is the version number and have the following meanings.

NB00 Not supported

NB01 Not supported

NB02 Linked by a Microsoft LINK, version 5.10, or equivalent OEM linker

NB03 Not supported

NB04 Not supported

NB05 The signature emitted by LINK 5.20 and later linkers for a file before it has been packed.

NB06 Not supported.

NB07 This signature is used for Quick C for Windows 1.0 only.

NB08 The signature CodeView 4.00 through CodeView 4.05 uses for a file after it has been packed.
CodeView 4.00 - 4.05 will not process a file that does not have this signature.

NB09 The signature for CodeView 4.10 for a file after it has been packed. CodeView 4.10 will not
process a file that does not have this signature.

NB10 The signature for an executable with the debug information stored in a separate PDB file.
Corresponds with the formats set forth in NB09 or NB11.

NB11 The signature for Visual C++ 5.0 debug information that has been packed and bonded to the
executable. This includes all 32-bit type indices.

The method for finding the debug information depends upon the executable format.

PE Format:

For PE format executables, the base address lfaBase is found by examining the executable header.

executable header Contains pointer to debug

information

executable code
Symbolic Debug Information Page 3 of 89

+ ...

NBxx Signature at lfaBase

lfoDirectory Offset of directory from base

address (lfoDir)

Subsection tables sstModule, sstType, sstLibraries,

...

Subsection At file offset lfaBase + lfoDir

Directory

other information

All other file offsets in the Symbol and Type OMF are relative to lfaBase. At the base address the
signature is repeated, followed by the long displacement to the subsection directory (lfoDir). All
subsections start on a long word boundary and are designed to maintain natural alignment internally
in each subsection and within the subsection directory.

Subsection Directory
The subsection directory has the format

Directory header

Directory entry 0

Directory entry 1

Directory entry n

The subsection directory is prefixed with a directory header structure indicating size and number of
subsection directory entries that follow.

2 2 4 4 4

cbDirHeader cbDirEntry cDir lfoNextDir flags

Symbolic Debug Information Page 4 of 89

cbDirHeader Length of the directory header

cbDirEntry Length of each directory entry

cDir Number of directory entries

lfoNextDir Offset from lfaBase of next directory. This field is currently unused. It is intended for use
by the incremental linker to point to the next directory containing Symbol and Type OMF
information from an incremental link.

flags Flags describing directory and subsection tables. No values have been defined for this field.

The directory header structure is followed by the directory entries which specify the subsection type,
module index if applicable, the subsection offset, and subsection size.

2 2 4 4

subsection iMod lfo cb

subsection Subdirectory index. See the table below for a listing of the valid subsection indices.

iMod Module index. This number is 1 based and zero is never a valid index. The index 0xffff is
reserved for tables that are not associated with a specific module. These tables include sstLibraries,
sstGlobalSym, sstGlobalPub and sstGlobalTypes.

lfo Offset from the base address lfaBase

cb Number of bytes in subsection

There is no requirement for a particular subsection to exist for a particular module. There is a
preferred order for subsections within the Symbol and Type OMF portion and the subsection
directory of the file as emitted by the linker (NB05 signature). The preferred order is:

sstModule1 Module 1

. .

sstModulen Module n

sstTypes1 Module 1

sstPublics1 Module 1

sstSymbols1 Module 1

sstSrcModule1 Module 1

sstTypesn Module n
Symbolic Debug Information Page 5 of 89

sstPublicsn Module n

sstSymbolsn Module n

sstSrcModulen Module n

sstLibraries

directory

However, if the tables are not written in this order by the linker, CVPACK will sort the subsection
table into this order and read the subsections in this order by seeking to the correct location. The net
effect is that packing will be less efficient but will work.

CVPACK will write the Symbol and Type OMF back to the file in the following order. CodeView
requires that the sstModule entries be first and sequential in the subsection directory. For
performance reasons, it is recommended that the order of the subsections in the file match the order
of the subsection directory entries.

For signatures prior to NB09, the packed file has the following subsections and ordering.

NBxx signature

lfoDir directory offset

sstModule1 Module 1

. .

sstModulen Module n

sstAlignSym1 Module 1

sstSrcModule1 Module 1

sstAlignSymn Module n

sstSrcModulen Module n

sstGlobalPub Global Publics

sstGlobalSym Global Symbols

sstLibraries Libraries

sstGlobalTypes Global Types

Directory

NBxx signature if OMF

Symbolic Debug Information Page 6 of 89

executable

lfoBase offset of base if OMF

executable

For NB09 signatures, the packed file has the following subsections and ordering.

NBxx signature

lfoDir directory offset

sstModule1 Module 1

. .

sstModulen Module n

sstAlignSym1 Module 1

sstSrcModule1 Module 1

sstAlignSymn Module n

sstSrcModulen Module n

sstGlobalPub Global Publics

sstGlobalSym Global Symbols

sstLibraries Libraries

sstGlobalTypes Global Types

sstStaticSym Static Symbols

sstFileIndex File Index

sstOffsetMap16
sstOffsetMat32

Directory

NBxx signature

lfoBase offset

SubSection Types (sst...)

All values not defined are reserved for future use.
Symbolic Debug Information Page 7 of 89

sstModule 0x120

sstTypes 0x121

sstPublic 0x122

sstPublicSym 0x123

sstSymbols 0x124

sstAlignSym 0x125

sstSrcLnSeg 0x126

sstSrcModule 0x127

sstLibraries 0x128

sstGlobalSym 0x129

sstGlobalPub 0x12a

sstGlobalTypes 0x12b

sstMPC 0x12c

sstSegMap 0x12d

sstSegName 0x12e

sstPreComp 0x12f

unused 0x130

sstOffsetMap16 0x131

sstOffsetMap32 0x132

sstFileIndex 0x133

sstStaticSym 0x134

(0x0120) sstModule

This describes the basic information about an object module including code segments, module name,
and the number of segments for the modules that follow. Directory entries for sstModules precede all
other subsection directory entries.

2 2 2 2 * *

ovlNumber iLib cSeg Style SegInfo Name

Symbolic Debug Information Page 8 of 89

ovlNumber Overlay number

iLib Index into sstLibraries subsection if this module was linked from a library

cSeg Count of the number of code segments this module contributes to

Style Debugging style for this module. Currently only "CV" is defined. A module can have only one
debugging style. If a module contains debugging information in an unrecognized style, the
information will be discarded.

SegInfo Detailed information about each segment that code is contributed to. This is an array of cSeg
count segment information descriptor structures.

Name Length-prefixed name of module

SegInfo is a structure that describes each segment to which a module contributes code. It is formatted
as follows:

2 2 4 4

Seg pad offset cbSeg

Seg Segment that this structure describes

pad Padding to maintain alignment This field is reserved for future use and must be emitted as
zeroes.

offset Offset in segment where the code starts

cbSeg Count of the number of bytes of code in the segment

(0x0121) sstTypes

The linker emits one of these subsections for every object file that contains a $$TYPES segment.
CVPACK combines all of these subsections in to an sstGlobalTypes subsection and deletes the
sstTypes tables. The sstTypes table contains the contents of the $$TYPES segment except that
addresses within the $$TYPES segment have been fixed by the linker. See also sstPreComp.

(0x0122) sstPublic

The linker fills each subsection of this type with an entries for the public symbols of a module. The
CVPACK utility combines all of the sstPublics subsections into an sstGlobalPub subsection. This
table has been replaced with the sstPublicSym but is retained for compatibility with previous linkers.

2/4 2 2 *

offset seg type name

offset Offset of public within segment. This will be a 16-bit offset unless the executable is a 32-bit
exe. Note that if any public symbols are 16:32 model, then all publics are emitted as 16:32 addresses.
Symbolic Debug Information Page 9 of 89

seg Segment index

type Type index of the symbol. This will be zero if the module was compiled without CodeView
information

name Length-prefixed name of public

(0x0123) sstPublicSym

This table replaces the sstPublic subsection. The format of the public symbols contained in this table
is that of an S_PUB16 or S_PUB32 symbol, as defined in Sections 2.3 and 2.4. This allows an
executable to contain both 16:16 and 16:32 public symbols for mixed-mode executable files. As with
the symbols sections the public section records must start on a 4 byte boundary.

(0x0124) sstSymbols

The linker emits one of these subsections for every object file that contains a $$SYMBOLS segment.
The sstSymbols table contains the contents of the $$SYMBOLS segment, except that addresses
within the $$SYMBOLS segment have been fixed by the linker. CVPACK moves global symbols
from the sstSymbols subsection to the sstGlobalSum subsection during packing. When the remaining
symbols are written executables, the subsection type is changed to sstAlignSym.

(0x0125) sstAlignSym

CVPACK writes the remaining unpacked symbols for a module back to the executable in a
subsection of this type. All symbols have been padded to fall on a long word boundary and the
lexical scope linkage fields have been initialized.

(0x0126) sstSrcLnSeg

The linker fills in each subsection of this type with information obtained from any LINNUM records
in the module. This table has been replaced with the sstSrcModule but is retained for compatibility
with previous linkers. CVPACK rewrites sstSrcLnSeg tables to sstSrcModule tables.

* 2 2 *

name seg cPair line/offset

name Length-prefixed name of source file

seg Segment

cPair Count of number of line number offset pairs to follow

line/offset Line/offset pairs. This pair consists of the line number followed by the offset of the start of
the code for that line within the segment. All offsets are relative to the beginning of the segment, not
the start of the contribution of the module to the segment. For example, if the module contributes to
segment _TEXT starting at offset 0x0100, and the code offset of the first line number is 0x0010
relative to the module, it will show up in the subsection as 0x0110. The offsets are 16 bits if the
executable is a 16:16 executable. If any segment in the executable is 16:32 model, then all offsets in
the line/offset pairs are 32 bit offsets.
Symbolic Debug Information Page 10 of 89

(0x0127) sstSrcModule

This table describes the source line number to addressing mapping information for a module. The
table permits the description of a module containing multiple source files with each source file
contributing code to one or more code segments. The base addresses of the tables described below
are all relative to the beginning of the sstSrcModule table.

Module header

Information for source file 1

Information for segment 1

Information for segment 2

Information for source file 2

Information for segment 1

Information for segment 2

The module header structure describes the source file and code segment organization of the module.

2 2 4*cFile 8*cSeg 2*cSeg

cFile cSeg baseSrcFile start/end seg

cFile The number of source files contributing code to segments

cSeg The number of code segments receiving code from this module

baseSrcFile This is an array of base offsets from the beginning of the sstSrcModule table

start/end An array of two 32-bit offsets per segment that receives code from this module. The first
offset is the offset within the segment of the first byte of code from this module. The second offset is
the ending address of the code from this module. The order of these pairs corresponds to the ordering
of the segments in the seg array. Zeroes in these entries means that the information is not known and
the file and line tables described below need to be examined to determine if an address of interest is
contained within the code from this module.

seg An array of segment indices that receive code from this module. If the number of segments is not
even, two pad characters are inserted to maintain natural alignment.

The file table describes the code segments that receive code from each source file.
Symbolic Debug Information Page 11 of 89

2 2 4*cSeg 8*cSeg 2 *

cSeg pad baseSrcLn start/end cbName Name

cSeg Number of segments that receive code from this source file. If the source file contributes code
multiple times to a segment, this is reflected in this count.

pad Pad field used to maintain alignment. This field is reserved for future use and must be emitted as
zero.

baseSrcLn An array of offsets for the line/address mapping tables for each of the segments that
receive code from this source file.

start/end An array of two 32-bit offsets per segment that receives code from this module. The first
offset is the offset within the segment of the first byte of code from this module. The second offset is
the ending address of the code from this module. The order of these pairs corresponds to the ordering
of the segments in the seg array. Zeroes in these entries means that the information is not known and
the file and line tables described below need to be examined to determine if an address of interest is
contained within the code from this module.

cbName Count of the number of bytes in source file name

Name Source file name. This can be a fully or partially qualified path name.

The line number to address mapping information is contained in a table with the following format.
The preferred ordering for this table is by offset order. Line number and offsets must be unique.

2 2 4*cPair 2*cPair

Seg cPair offset linenumber

Seg Segment index for this table

cPair Count of the number of source line pairs to follow

offset An array of 32-bit offsets for the offset within the code segment of the start of the line
contained in the parallel array linenumber.

linenumber This is an array of 16-bit line numbers for the numbers of the lines in the source file that
cause code to be emitted to the code segment. This array is parallel to the offset array. If cPair is not
even, then a zero word is emitted to maintain natural alignment in the sstSrcModule table.

(0x0128) sstLibraries

There can be at most one sstLibraries SubSection. The format is an array of length-prefixed names.
These names define all the library files used during linking. The order of this list defines the library
index number (see sstModules subsection). The first entry should be empty (i.e., zero-length string)
since library indices are 1-based.

(0x0129) sstGlobalSym
Symbolic Debug Information Page 12 of 89

This subsection contains globally compacted symbols. The format of the table is a header specifying
the symbol and address hash functions, the length of the symbol information, the length of the
symbol hash function data, and the length of address hash function data. This is followed by the
symbol information followed by the symbol hash tables followed by the address hash tables. When
the pack utility writes the sstGlobals subsection, each symbol is zero-padded such that the following
symbol starts on a long boundary and the length field is adjusted by the pad count. Note that symbol
and/or address hash data can be discarded and the globally packed symbols linearly searched. Hash
function index 0 means no hash data. See Section 7.5 for more information about the hashing
functions.

The header has the following format:

2 2 4 4 4

symhash addrhash cbSymbol cbSymHash cbAddrHash

symhash Index of the symbol hash function

addrhash Index of the address hash function

cbSymbol Count of the number of bytes in the symbol table

cbSymHash Count of the number of bytes in the symbol hash table

cbAddrHash Count of the number of bytes in the address hashing table

Starting with the NB09 signature files, the sstGlobalSym table can contain S_ALIGN symbols to
maintaing 4k alignment of symbols. Also, starting with NB09 signature files, the sstGlobal can
contain S_PROCREF and S_DATAREF symbols to global procedures and to global data symbols
that would not otherwise have been globally packed because of symbol type mismatches. See
Section 2.6 for more inforation about the S_PROCREF and S_DATAREF symbols.

(0x012a) sstGlobalPub

This subsection contains the globally compacted public symbols from the sstPublics. The format of
the table is a header specifying the symbol and address hash functions, the length of the symbol
information, the length of the symbol hash function data, and the length of address hash function
data. This is followed by the symbol information followed by the symbol hash tables followed by the
address hash tables. When the pack utility writes the sstGlobals subsection, each symbol is zero-
padded such that the following symbol starts on a long boundaryand the length field of the symbol is
adjusted by the pad count. Note that symbol and/or address hash data can be discarded and the
globally packed symbols be linearly searched in low-memory situations. Hash function index 0
means no hash data. See Section 7.5 for more information about the hashing functions.

The header has the following format:

2 2 4 4 4

symhash addrhash cbSymbol cbSymHash cbAddrHash

symhash Index of the symbol hash function

Symbolic Debug Information Page 13 of 89

addrhash Index of the address hash function

cbSymbol Count of the number of bytes in the symbol table

cbSymHash Count of the number of bytes in the symbol hash table

cbAddrHash Count of the number of bytes in the address hashing table

Starting with the NB09 signature files, the sstGlobalSym table can contain S_ALIGN symbols to
maintaing 4k alignment of symbols.

They contain S_ALIGN symbol records to maintain 4K alignment of tables. These Note also that
sstGlobalPub table contains S_PROCREF symbols.

(0x012b) sstGlobalTypes

This subsection contains the packed type records for the executable file. The first long word of the
subsection contains the number of types in the table. This count is followed by a count-sized array of
long offsets to the corresponding type record. As the sstGlobalTypes subsection is written, each type
record is forced to start on a long word boundary. However, the length of the type string is NOT
adjusted by the pad count. The remainder of the subsection contains the type records. This table is
invalid for NB05 signatures.

Types are 48K aligned as well as naturally aligned, so linear traversal of the type table is non-trivial.
The 48K alignment means that no type record crosses a 48K boundary.

flags types table flag

cType count of the number of types

offType[cType] offset of each type See note below.

type string 0 type string for type index 0x1000

type string 1 type string for type index 0x1001

type string n type string for type index 0x1000 +

n

Note: for NB07 and NB08 executables, the type string offset is from the beginning of the subsection
table. For NB09 executables, the type string offset is from the first type record of the sstGlobalTypes
subsection. Using the offset from the first type record simplifies demand loading of the
sstGlobalTypes table.

The types table flags entry has the following format:

3 1

unused signature
Symbolic Debug Information Page 14 of 89

unused Reserved for future use. Must be emitted as zeroes

signature Global types table signature.

(0x012c) sstMPC

This table is emitted by the Pcode MPC program when a segmented executable is processed into a
non-segmented executable file. The table contains the mapping from segment indices to frame
numbers.

2 2*cSeg

cSeg mpSegFrame

cSeg Count of the number of segments converted

mpSegFrame Segment-to-frame mapping table. A segmented address seg:off is converted to a frame

by

mpSegFrame[segment-1]*16 + offset

(0x012d) sstSegMap

This table contains the mapping between the logical segment indices used in the symbol table and
the physical segments where the program was loaded

There is one sstSegMap per executable or DLL.

2 cSeg count of the number of segment

descriptors in table

2 cSegLog count of the number of logical

segment descriptors

20 SegDesc 0 First segment descriptor

20 SegDesc N cSeg'th segment descriptor

cSeg The total number of segment descriptors

cSegLog The total number of logical segments. All group descriptors follow the logical segment
descriptors. The number of group descriptors is given by cSeg - cSegLog.

SegDescN Array of segment descriptors. Information about a logical segment can be found by using
logical segment number - 1 as an index into this array. The 1 is subtracted because the logical
segment number is 1 based.
Symbolic Debug Information Page 15 of 89

Each element of the segment descriptor array has the following format:

2 2 2 2 2 2 4 4

flags ovl group frame iSegName iClassName offset cbseg

flags descriptor flags bit field. See below for details.

ovl The logical overlay number.

group The group index into the descriptor array. The group index must either be 0 or cSegLog <=
group < cSeg.

frame This value has different meanings depending upon the values of fAbs and fSel in the flags bit
array and ovl:

fAbs fSel ovl Operation

0 0 0 Frame is added to PSP + 0x10 if not a .com file
0 0 0 Frame is added to PSP if it is a .com file
0 0 != 0 Frame is added to current overlay base
1 0 x Frame is absolute address
0 1 x Frame contains a selector

iSegName The byte index of the segment or group name in the sstSegName table. A value of 0xffff
indicates there is no name.

iClassName The byte index of the class name in the sstSegName table. A value of 0xffff indicates
there is no name.

offset Byte offset of the logical segment within the specified physical segment. If fGroup is set in
flags, offset is the offset of the group in the physical segment. Currently, all groups define physical
segments so offset will be zero for groups.

cbSeg Byte count of the logical segment or group.

The descriptor flags bit field flags has the following format:

:3 :1 :2 :1 :1 :4 :1 :1 :1 :1

res fGroup res fAbs fSel res f32Bit fExecute fWrite fRead

res Reserved. and set to zero.

fGroup If set, the descriptor represents a group. Since groups are not assigned logical segment
numbers, these entries are placed after the logcial segment descriptors in the descriptor array.

fAbs frame represents an absolute address.

fSel frame represents a selector.

f32Bit The descriptor describes a 32-bit linear address.

Symbolic Debug Information Page 16 of 89

fExecute The segment is executable.

fWrite The segment is writable.

fRead The segment is readable.

(0x012e) sstSegName

The sstSegName table contains all of the logical segment and class names. The table is an array of
zero-terminated strings. Each string is indexed by its beginning from the start of the table. See
sstSegMap above.

(0x012f) sstPreComp

The linker emits one of these sections for every OMF object that has the $$TYPES table flagged as
sstPreComp and for every COFF object that contains a .debug$P section. During packing, CVPACK
processes modules with a types table having the sstPreComp index before modules with types table
having the sstTypes index.

(0x0131) sstOffsetMap16

This table provides a mapping from logical to physical offsets. This mapping is applied between the
logical to physical mapping described by the seg map table.

4 16 *
cSeg

cSeg map

cSeg Count of the number of physical segments

map Array of mapping information for each physical segment

4 2* 2 * cRangeOff 4
cRangeLog

cRangeLog rgoffLog rgbiasLog crangePhys ->

2* 2*
crangePhys crangePhys

rgoffPhys rgbiasPhys

crangeLog Count of logical offset ranges

rgoffLog Array of logical offsets

rgbiasLog Array of logical -> physical bias

crangePhys Count of physical offset ranges

Symbolic Debug Information Page 17 of 89

rgoffPhys Array of physical offsets

rgbiasPhys Array of physical -> logical bias

/* M00 REVIEW richards: keithv: Please supply more details about table usage */

(0x0132) sstOffsetMap32

This table provides a mapping from logical to physical offsets. This mapping is applied between the
logical to physical mapping described by the seg map table.

4 18 *
cSeg

cSeg map

cSeg Count of the number of physical segments

map Array of mapping information for each physical segment

4 4* 4* 4
cRangeLog cRangeOff

cRangeLog rgoffLog rgbiasLog crangePhys ->

2* 4*
crangePhys crangePhys

rgoffPhys rgbiasPhys

crangeLog Count of logical offset ranges

rgoffLog Array of logical offsets

rgbiasLog Array of logical -> physical bias

crangePhys Count of physical offset ranges

rgoffPhys Array of physical offsets

rgbiasPhys Array of physical -> logical bias

/* M00 REVIEW richards: keithv: Please supply more details about table usage */

(0x0133) sstFileIndex

This subsection contains an list of all of the sources files that contribute code to any module
(compiland) in the executable. File names are partially qualified relative to the compilation directory.
Symbolic Debug Information Page 18 of 89

2 2 2 * cMod 2* 4 * cRef *
cModules

cMod cRef ModStart cRefCnt NameRef Names

cMod Count of the number of modules in the executable

cRef Count of the total number of file name references

ModStart Array of indices into the NameOffset table for each module. Each index is the start of the
file name references for each module.

cRefCnt Number of file name references per module

NameRef Array of offsets into the Names table. For each module, the offset to first referenced file
name is at NameRef[ModStart] and continues for cRefCnt entries.

Names List of zero terminated file names. Each file name is partially qualified relative to the
compilation directory.

(0x0134) sstStaticSym

This subsection is structured exactly like the sstGlobalPub and sstGlobalSym subsections. It contains
S_PROCREF for all static functions as well as S_DATAREF for static module level data and non-
static data that could not be included (due to type conflicts) in the sstGlobalSym subsection.

Hash table and sort table descriptions

The NB09 and NB11 signature CodeView information contains hash/sort tables in the
sstGlobalSym, sstGlobalPub, and sstStaticSym subsections.

Name hash table (symhash == 10):

The symbol name hash table uses the following checksum algorithm to generate the hash.

byt_toupper(b) <- (b&0xDF)

dwrd_toupper(dw) <- (dw&0xDFDFDFDF)

cb = {Number of characters in the name}

lpbName = {pointer to the first character of the name}

ulEnd = 0;

while ( cb & 3 ) {

ulEnd |= byt_toupper ( lpbName [ cb - 1 ] );

ulEnd <<= 8;

cb -= 1;
Symbolic Debug Information Page 19 of 89

cul = cb / 4;

lpulName = lpbName;

for ( iul = 0; iul < cul; iul++ ) {

ulSum ^= dwrd_toupper(lpulName[iul]);

_lrotl ( ulSum, 4 );

ulSum ^= ulEnd;

The hash bucket number is derived from ulSum by taking the modulo of ulSum with the total
number of hash buckets.

The format of the table is as follows.

2 cHash(n) Number of hash buckets

2 Alignment Filler to preserve alignment

4n Hash Table[n] Each ulong entry is a file offset

from the beginning of the chain
table to the first chain item for each
hash bucket.

4n Bucket Counts[n] Each ulong entry is the count of

items in the chain for each hash
bucket.

8m Chain table[m] Each entry is a pair of dwords. The

first dword is the file offset of the
referenced symbol from the
beginning of the symbols. The
second dword is the checksum of
the referenced symbol generated by
the above algorithm.

n = the number of hash buckets

m = the number of symbols (with names) = the number of entries in the chain table

Address sort table (addrhash == 12):

The address sort table is a grouping of logical segments (or sections) where each symbol reference
within the segment/section is sorted by its segment/section relative offset.

The format of the table is as follows.

Symbolic Debug Information Page 20 of 89

2 cSeg(n) Number of logical

segments/sections

2 Alignment Filler to preserve alignment

4n Segment Table[n] Each ulong entry is a file offset

from the beginning of the offset
table to the first offset item for each
segment/section.

4n Offset Counts[n] Each ulong entry is the count of

items in the offset table for each
segment.

8m Offset Table[m] Each entry is a pair of dwords. The

first dword is the file offset of the
referenced symbol from the
beginning of the symbols. The
second dword is the
segment/section relative offset of
the referenced symbol in memory.

n = the number of segments/sections

m = the number of symbols (with addresses) = the number of entries in the offset table

$$SYMBOLS and $$TYPES Definitions

$$TYPES Definition

COFF

COFF OBJECT FILES:

Type information appears in a COFF object file format as initialized data sections. The attributes for
the sections are:

NAME: .debug$T

Attributes: Read Only, Discardable, Initialized Data

As with OMF the first four bytes in the types section must contain a valid signature and agree with
the signature in the symbol table.

$$SYMBOLS Definition

COFF

Symbol information appears in separate sections. The attributes of the section are:

Name: .debug$S
Symbolic Debug Information Page 21 of 89

Attributes: Read Only, Discardable, Initialized Data

There may be multiple symbol sections in an object. The first symbol section to appear in the object
file must NOT be associated with a comdat section and must contain a valid signature. If a comdat
section is present in the object then the symbol information for that comdat should be in a separate
symbol section associated with the text comdat section. Symbol sections associated with comdats
must not contain a signature.

Lexical scope linkage

The model of a program envisioned by this document is that programs have nested scopes. The
outermost scope is module scope which encompasses all of the symbols not defined within any inner
(lexical) scope. Symbols and types defined at one scoping level are visible to all scopes nested
within it. Symbols and types defined at module scope are visible to all inner scopes.

The next level of scoping is "function" scope, which in turn contains lexical blocks (including other
functions scopes) that can be further nested. Nested lexical scopes are opened by a procedure,
method, thunk, with, or block start symbol. They are closed by the matching block-end symbol.

In general, symbol searching within a module's symbol table is performed in the following manner.
The lexical scope that contains the current program address is searched for the symbol. If the symbol
is not found within that scope, the enclosing lexical scope is searched. This search is repeated
outward until the symbol is found or module scope is searched unsuccessfully. Note that lexical
scopes at the same depth level are not searched. As an optimization for CodeView, symbols that
open a lexical scope have fields that contain offsets from the beginning of the symbols for the
module that point to the parent of the scope, the next lexical scope that is at the same scoping level
and the S_END symbol that closes this lexical scope.

The pParent, pNext and pEnd fields described below are filled in by CVPACK and should be
emitted as zeroes by the language processor.

Field Linkage

pParent Used in local procedures, global procedures,

thunk start, with start, and block start symbols. If
the scope is not enclosed by another lexical
scopes, then pParent is zero. Otherwise, the
parent of this scope is the symbol within this
module that opens the outer scope that encloses
this scope but encloses no other scope that
encloses this scope. The pParent field contains
the offset from the begining of the module's
symbol table of the symbol that opens the
enclosing lexical scope.

pNext Used in start search local procedures, global

procedures, and thunk start symbols. The pNext
field, along with the start search symbol, defines a
group of lexically scoped symbols within a
symbol table that are contained within a code
segment or PE section. For each segment or
section represented in the symbol table, there is a
start search symbol that contains the offset from
Symbolic Debug Information Page 22 of 89

the start of the symbols for this module to the first

procedure or thunk contained in the segment.
Each outermost lexical scope symbol has a next
field containing the next outermost scope symbol
contained in the segment. The last outermost
scope in the symbol table for each segment has a
next field of zero.

pEnd This field is defined for local procedures, global

procedures, thunk, block, and with symbols. The
end field contains the offset from the start of the
symbols for this module to the matching block
end symbol that terminates the lexical scope.

Logical segments
When the linker emits address information about a symbol, it is done in a segment:offset format. The
segment is a logical segment index assigned by the linker and the offset is the offset from the
beginning of the logical segment. The physical address is assigned by the operating system when the
program is loaded.

For PE formatted executables, the segment field is interpreted as the PE section number.

Numeric leaves
When the symbol or type processor knows that a numeric leaf is next in the symbol or type record,
the next two bytes of the symbol or type string are examined. If the value of these two bytes is less
than LF_NUMERIC (0x8000), then the two bytes contain the actual numeric value. If the value is
greater than or equal to LF_NUMERIC (0x8000), then the numeric data follows the two-byte leaf
index in the format specified by the numeric leaf index. It is the responsibility of routines reading
numeric fields to handle the potential non alignment of the data fields. See the Section 4 on numeric
leaves for details.

Types Indices
All Symbol and Type records which reference records in the $$TYPES table must use valid non-zero
type indices. For public symbols a type index of 0x0000 (T_NOTYPE) is permitted.

Since many types (relating to hardware and language primitives) are common, type index values less
than 0x1000 (CV_FIRST_NONPRIM) are reserved for a set of predefined primitive types. A list of
predefined types and their indices are defined in this document in Section 5. Type indices of 0x1000
and higher are used to index into the set of non-primitive type definitions in the module's $$TYPES
segment. Thus 0x1000 is the first type, 0x1001 the second, and so on. Non-primitive type indices
must be sequential and contain no gaps in the numbering. Type indices are now a 32-bit quantity and
the valid range is 0x001000 to 0xffffff (224 - 1) with the top 8 bits reserved and must be 0.

General
Format of Symbol Records

Data in the $$SYMBOLS segment is a stream of variable length records with the general format:
Symbolic Debug Information Page 23 of 89

2 2 *

length index data...

length Length of record, excluding the length field

index Type of symbol

data Data specific to each symbol format

The symbol records are described below. Numbers above the fields indicate the length in bytes, and
* means variable length for that field.

Symbol indices are broken into five ranges. The first range is for symbols whose format does not
change with the compilation model of the program or the target machine. These include register
symbols, user-defined type symbols, and so on. The second range of symbols are those that contain
16:16 segmented addresses. The third symbol range is for symbols that contain 16:32 addresses.
Note that for flat model programs, the segment is replaced with the section number for PE executable
files. The fourth symbol range is for symbols which are specific to the MIPS architecture/compiler.
The fifth range is for CodeView optimization.

The symbol records are formatted such that most fields fall into natural alignment if the symbol
length field is placed on a long word boundary. For all symbols, the variable length data is at the end
of the symbol structure. Note specifically that fields that contain data in potentially nonaligned
numeric fields must either pay the load penalty or first do a byte wise copy of the data to a memory
that is in natural alignment. Refer to Section 4 for details about numeric leaves.

16:16 compilers do not have to emit padding bytes between symbols to maintain natural alignment.
The CVPACK utility places the symbols into the executable files in natural alignment and zero pads
the symbol to force alignment. The length of each symbol is adjusted to account for the pad bytes.
16:32 compilers must align symbols on a long word boundary.

Provisions for enabling future implementation of register tracking and a stack machine to perform
computation on symbol addresses are provided in the symbols. When the symbol processor is
examining a symbol, the length field of the symbol is compared with the offset of the byte following
the end of the symbol name field. If these are the same, there is no stack machine code at the end of
the symbol. If the length and offset are different, the byte following the end of the symbol name is
examined. If the byte is zero, there is no stack machine code following the symbol. If the byte is not
zero, then the byte indexes into the list of stack machine implementations and styles of register
tracking. If stack machine code is present, the address field of the symbol becomes the initial value
of the stack machine. Microsoft does not currently emit or process stack machine code or register
tracking information. The opcodes and operation of the stack machine has not been defined.

Symbol Indices

*[Note: All symbol records that included one or more CV_typ_t fields have been renamed by having
"_16t" appended to their original names. For instance, the symbol record for S_BPREL32 that
included a 16-bit CV_typ_t (now known as CV_typ16_t) is now S_BPREL32_16t. The records that
were so changed all have indices (record type fields) with the 0x1000 bit set. Records that did not
contain CV_typ_t fields were left unchanged.]

0x0001 S_COMPILE Compile flags symbol

Symbolic Debug Information Page 24 of 89

0x0005 S_SSEARCH Start search

0x0006 S_END End block, procedure, with, or thunk

0x0007 S_SKIP Skip - Reserve symbol space

0x0008 S_CVRESERVE Reserved for CodeView internal use

0x0009 S_OBJNAME Specify name of object file

0x000a S_ENDARG Specify end of arguments in function symbols

0x000b S_COBOLUDT Microfocus COBOL user-defined type

0x000c S_MANYREG Many register symbol

0x000d S_RETURN Function return description

0x000e S_ENTRYTHIS Description of this pointer at entry

0x1001 S_REGISTER Register variable

0x1002 S_CONSTANT Constant symbol

0x1003 S_UDT User-defined type

0x1004 S_COBOLUDT Microfocus COBOL user-defined type

0x1005 S_MANYREG Many register symbol

0x1006 S_BPREL32 BP relative 16:32

0x1007 S_LDATA32 Local data 16:32

0x1008 S_GDATA32 Global data 16:32

0x1009 S_PUB32 Public symbol 16:32

0x100a S_LPROC32 Local procedure start 16:32

0x100b S_GPROC32 Global procedure start 16:32

0x0206 S_THUNK32 Thunk start 16:32

0x0207 S_BLOCK32 Block start 16:32

0x0208 S_WITH32 With start 16:32

0x0209 S_LABEL32 Label 16:32

0x020a S_CEXMODEL32 Change execution model 16:32

0x100c S_VFTTABLE32 Virtual function table path descriptor 16:32

Symbolic Debug Information Page 25 of 89

0x100d S_REGREL32 16:32 offset relative to arbitrary register

0x100e S_LTHREAD32 Local Thread Storage data

0x100f S_GTHREAD32 Global Thread Storage data

0x1010 S_LPROCMIPS Local procedure start MIPS

0x1011 S_GPROCMIPS Global procedure start MIPS

0x0400 S_PROCREF Reference to a procedure

0x0401 S_DATAREF Reference to data

0x0402 S_ALIGN Page align symbols

Non-modal Symbols
(0x0001) Compile Flag

This symbol communicates to CodeView compile time information on a per module basis, such as
the language and version number of the language processor , the ambient model for code and data,
and the target processor.

2 2 1 3 *

length S_COMPILE machine flags version

machine enumeration specifying target processor. Values not specified below are reserved.

0x00 Intel 8080

0x01 Intel 8086

0x02 Intel 80286

0x03 Intel 80386

0x04 Intel 80486

0x05 Intel Pentium

0x06 Intel Pentium Pro

0x10 MIPS R4000

0x11 Reserved for future MIPS processor

0x12 Reserved for future MIPS processor

0x20 MC68000

0x21 MC68010
Symbolic Debug Information Page 26 of 89

0x22 MC68020

0x23 MC68030

0x24 MC68040

0x30 DEC Alpha

0x40 PPC601
0x41 PPC603
0x42 PPC604
0x43 PPC620

flags flags showing compile time options

Language :8
PCodePresent :1

FloatPrecision :2
FloatPackage :2
AmbientData :3
AmbientCode :3

Mode32 :1 Compiled for 32 bit addresses

Reserved :4

Language enumeration

0C
1 C++
2 Fortran
3 Masm
4 Pascal
5 Basic
6 Cobol
7 - 255 Reserved

Ambient code and data memory model enumeration

0 Near

1 Far
2 Huge

3 - 7 Reserved

Floating package enumeration

0 Hardware processor (80x87 for Intel 80x86 processors)

1 Emulator
2 Altmath

3 Reserved

The FloatPrecision flag is set to 1 if the compiler follows the ANSI C floating point precision rules.
Symbolic Debug Information Page 27 of 89

This is specified to Microsoft C compilers by setting the -Op option.

version Length-prefixed string specifying language processor version. Language processors can
place additional data in version string if desired.

(0x1001) Register

This symbol record describes a symbol that has been enregistered. Provisions for enabling future
implementation tracking of a symbol into and out of registers is provided in this symbol. When the
symbol processor is examining a register symbol, the length field of the symbol is compared with the
offset of the byte following the symbol name field. If these are the same, there is no register tracking
information. If the length and offset are different, the byte following the end of the symbol name is
examined. If the byte is zero, there is no register tracking information following the symbol. If the
byte is not zero, then the byte indexes into the list of stack machine implementations and styles of
register tracking. Microsoft does not currently emit or process register tracking information.

2 2 4 2 * *

length S_REGISTER @type register name tracking

@type The type of the symbol

register Enumerate of the registers in which the symbol value is stored. This field is treated as two
bytes. The high order byte specifies the register in which the high order part of the value is stored.
The low byte specifies the register for the low order part of the value. If the value is not stored in two
registers then high order regisr field contains the enumerate value for no register. For register
enumeration values, see Section 6. The register index enumeration is specific to the processor model
for the module.

name Length-prefixed name of the symbol stored in the register

tracking Register tracking information. Format unspecified.

(0x1002) Constant

This record is used to output constants and C enumerations. If used to output an enumeration, then
the type index refers to the containing enum.

2 2 4 * *

length S_CONSTANT @type value name

@type Type of symbol or containing enum

value Numeric leaf containing the value of symbol

name Length-prefixed name of symbol

(0x1003) User-defined type

This specifies a C typedef or user-defined type, such as classes, structures, unions, or enums.
Symbolic Debug Information Page 28 of 89

2 2 4 *

length S_UDT @type name

@type Type of symbol

name Length-prefixed name of the user defined type

(0x0005) Start Search

These records are always the first symbol records in a module's $$SYMBOL section. There is one
Start Search symbol for each segment (PE section) to which the module contributes code. Each Start
Search symbol contains the segment (PE section) number and $$SYMBOL offset of the record of
the outermost lexical scope in this module that physically appears first in the specified segment of
the load image. This referenced symbol is the symbol used to initiate context searches within this
module. The Start Search symbols are inserted into the $$SYMBOLS table by CVPACK and must
not be emitted by the language processor.

/* M00 REVIEW - Davidgra: are scopes sorted into offset order */

2 2 4 2

length S_SSEARCH sym off segment

sym off $$SYMBOL offset of the procedure or thunk record for this module that has the lowest
offset for the specified segment. See Section 1.2 on lexical scope linking.

segment Segment (PE section) that this Start Search refers to

(0x0006) End of Block

Closes the scope of the nearest preceding Block Start, Global Procedure Start, Local Procedure Start,
With Start, or Thunk Start definition.

2 2

length S_END

(0x0007) Skip Record

This record reserves symbol space for incremental compilers. The compiler can reserve a dead space
in the OMF for future expansions due to an incremental build. This symbol and the associated
reserved space is removed by the CVPACK utility.

2 2 *

length S_SKIP skip data

skip data Unused data. Use the length field that precedes every symbol record to skip this record.
Symbolic Debug Information Page 29 of 89

(0x0008) CodeView Internal

The symbol is internally used by CodeView and never appears in the executable. Its format is
unspecified.

(0x0009) Object File Name

This symbol specifies the name of the object file for this module.

2 2 4 *

length S_OBJNAME signature name

signature Signature for the CodeView information contained in this module. If the object file
contains precompiled types, then the signature will be checked against the signature in the
LF_PRECOMP type record contained in the $$TYPES table for the user of the precompiled types.
The signature check is used to detect recompilation of the supplier of the precompiled types without
recompilation of all of the users of the precompiled types. The method for computing the signature is
unspecified. It should be sufficiently robust to detect failures to recompile.

name Length prefixed name of the object file without any path information prepended to the name.

(0x000a) End of Arguments

This symbol specifies the end of symbol records for the formal arguments for a function. Use of this
symbol is optional for OMF and is required for MIPS compiled code. In OMF format, the end of
arguments can also be deduced from the fact that arguments for a function have positive offset from
the frame pointer.

2 2

length S_ENDARG

(0x1004) COBOL User-defined Type

This record is used to define a user-defined type for the Microfocus Cobol compiler. This record
cannot be moved into the global symbol table by CVPACK.

2 2 4 *

length S_COBOLUDT @type name

@type Type of symbol

name Length-prefixed name of the user defined type

(0x1005) Many Registers

This record is used to specify that a symbol is stored in a set of registers.

Symbolic Debug Information Page 30 of 89

2 2 4 1 1* *
count

length S_MANYREG @type count reglist name

@type Type index of the symbol

count Count of the register enumerates that follow

reglist List of registers in which the symbol is stored. The registers are listed high order register first.

name Name of the symbol

(0x000d) Function Return

This symbol us used to describe how a function is called, the return value if any is returned and how
the stack is cleaned up.

2 2 2 1 *

length S_RETURN flags style data

flags Flags for function call

cstyle :1 push varargs right to left if true

rsclean :1 returnee stack cleanup if true

unused :14

style Function return style

0x00 void return

0x01 return value is in registers specified in data

0x02 indirect caller allocated near

0x03 indirect caller allocated far

0x04 indirect returnee allocated near

0x05 indirect returnee allocated far

data Data required by function return style.

If style is 0x01, then data is the format

1 1*
count
Symbolic Debug Information Page 31 of 89

count reglist

count Count of the number of registers

reglist Registers (high order first) containing the value

(0x000e) this at Method Entry

This record is used to describe the this pointer at entry to a method. It is really a wrapper for another
symbol that describes the this pointer.

2 2 *

length S_ENTRYTHIS symbol

symbol Full symbol including length and symbol type fields that describes the this pointer.

Symbols for 16:32 Segmented and 32-bit Flat Architectures

(0x1006) BP Relative 16:32

This symbol specifies symbols that are allocated on the stack for a procedure. For C/C++, these
include the actual parameters to a function and the local nonstatic variables of functions.

2 2 4 4 *

length S_BPREL32 offset @type name

offset Signed offset relative to BP. If offset is 0, then the symbol was assigned to a register or never
instantiated by the optimizer and cannot be evaluated because its location is unknown.

@type Type of the symbol

name Length-prefixed name of the symbol

(0x1007) Local Data 16:32

These symbols are used for data that is not exported from a module. In C/C++, symbols that are
declared static are emitted as Local Data symbols. Symbols that are emitted as Local Data cannot be
moved by CVPACK into the global symbol table for the executable file.

2 2 4 4 2 *

length S_LDATA32 @type offset segment name

@type Type index of the symbol.

offset Offset portion of the symbol address.

Symbolic Debug Information Page 32 of 89

segment Segment portion of the symbol. address

name Length-prefixed name of symbol

(0x1008 Global Data Symbol 16:32 )

This symbol record has the same format as the Local Data 16:32 except that the record type is
S_GDATA32. For C/C++, symbols that are not specifically declared static are emitted as Global
Data Symbols and can be compacted by CVPACK into the global symbol table.

(0x1009) Public 16:32

This symbol has the same format as the Local Data 16:32 symbol. Its use is reserved to symbols in
the Publics table emitted by the linker into the Symbol and Type OMF portion of the executable file.

(0x100a) Local Procedure Start 16:32

This symbol record defines local (file static) procedure definition. For C/C++, functions that are
declared static to a module are emitted as Local Procedure symbols. Functions not specifically
declared static are emitted as Global Procedures (see below.)

2 2 4 4 4 4 4

length symbol pParent pEnd pNext proc debug ->

length start

4 4 4 2 1 *

debug @proctype offset segment flags name

end

symbol S_LPROC32 or S_GPROC32.

pParent See the section on lexical scope linking

pEnd See the section on lexical scope linking

pNext See the section on lexical scope linking

proc length Length in bytes of this procedure

debug start Offset in bytes from the start of the procedure to the point where the stack frame has
been set up. Parameter and frame variables can be viewed at this point.

debug end Offset in bytes from the start of the procedure to the point where the procedure is ready to
return and has calculated its return value, if any. Frame and register variables can still be viewed.

@proctype Type of the procedure type record

offset Offset portion of the procedure address

Symbolic Debug Information Page 33 of 89

segment Segment portion of the procedure address

flags Procedure flags:

fpo :1 true if function has frame pointer omitted

interrupt :1 true if function is interrupt routine

return :1 true if function performs far return

never :1 true if function never returns

unused :4

name Length-prefixed name of procedure

(0x100b) Global Procedure Start 16:32

This symbol is used for procedures that are not specifically declared static to a module. The format is
the same as the Local Procedure Start 16:32 symbol (see above.)

(0x0206) Thunk Start 16:32

This record is used to specify any piece of code that exists outside a procedure. It is followed by an
End record. The thunk record is intended for small code fragments. and a two byte length field is
sufficient for its intended purpose.

2 2 4 4 4 4 2

length S_THUNK32 pParent pEnd pNext offset segment

2 1 * *

thunk ordinal name variant

length

pParent See the section on lexical scope linking

pEnd See the section on lexical scope linking

pNext See the section on lexical scope linking

offset Offset portion of the thunk address

segment Segment portion of the thunk address

thunk length Length in bytes of this thunk

ordinal Ordinal specifying the type of thunk

0 notype

1 adjustor
Symbolic Debug Information Page 34 of 89

2 vcall

3 pcode

name Length-prefixed name of thunk

variant Variant field, depending on value of ordinal. If ordinal is notype, there is no variant field. If
ordinal is adjustor, the variant field is a two-byte signed value specifying the delta to be added to the
this pointer, followed by the length prefixed name of the target function. If the ordinal is vcall, then
the variant field is a two-byte signed displacement into the virtual table. If ordinal is pcode, the
variant is the seg:offset of the pcode entry point.

(0x0207) Block Start 16:32

This symbol specifies the start of an inner block of lexically scoped symbols. The lexical scope is
terminated by a matching S_END symbol.

2 2 4 4 4 4 2 *

length S_BLOCK32 pParent pEnd length offset segment name

pParent See the section on lexical scope linking.

pEnd See the section on lexical scope linking.

length Length in bytes of the scope of this block

offset Offset portion of the segmented procedure address

segment Segment portion of the segmented procedure address

name Length-prefixed name of the block

(0x0208) With Start 16:32

2 2 4 4 4 4 2 *

length S_WITH32 pParent pEnd length offset segment expr

pParent See the section on lexical scope linking

pEnd See the section on lexical scope linking

length Length in bytes of the scope of the with block.

offset Offset portion of the segmented address of the start of the block

segment Segment portion of the segmented address of the start of the block

expr Length-prefixed ASCII string, evaluated at run time, of the expression used in the with
statement.
Symbolic Debug Information Page 35 of 89

(0x0209) Code Label 16:32

2 2 4 2 1 *

length S_LABEL32 offset segment flags name

offset Offset portion of the segmented address of the start of the block

segment Segment portion of the segmented address of the start of the block

flags Label flags. This uses the same flag definition as in the S_LPROC16 symbol record.
fpo :1 true if function has frame pointer omitted

interrupt :1 true if function is interrupt routine

return :1 true if function performs far return

never :1 true if function never returns

unused :4

name Length prefixed name of label

(0x020a) Change Execution Model 16:32

This record is used to notify the debugger that, starting at the given code offset and until the address
specified by the next Change Execution Model record, the execution model is of the specified type.
The native execution model is assumed in the absence of Change Execution Model records

2 2 4 2 2 *

length S_CEXMODEL32 offset segment model variant

offset Offset portion of start of the block

segment Segment portion of the start of block

model The execution model.

0x00 Not executable code (e.g., a table)

0x01 Compiler generated jump table

0x02 Padding for data

0x03 - 0x1f Reserved for specific noncode types.

0x20 Native model (no processor specified)

0x21 Microfocus Cobol (unused in 16:32)

0x22 Code padding for alignment

Symbolic Debug Information Page 36 of 89

0x23 Code

0x24 - 0x3f Reserved

0x40 Pcode (Reserved)

variant Variable data dependent upon the execution model field. If the variant record contains
segment or offset information, then CVPACK and CodeView must be modified to process the
segment information.

The other models do not have variant fields.

(0x100c) Virtual Function Table Path 16:32

This record is used to describe the base class path for the virtual function table descriptor.

2 2 4 4 4 2

length S_VFTTABLE32 @root @path offset segment

@root The type index of the class at the root of the path

@path Type index of the record describing the base class path from the root to the leaf class for the
virtual function table.

offset Offset portion of start of the virtual function table

segment Segment portion of the virtual function table

(0x100d) Register Relative 16:32

This symbol specifies symbols that are allocated relative to a register.

2 2 4 4 2 *

length S_REGREL32 offset @type register name

offset Signed offset relative to register.

@type Type of the symbol

register Register enumerates on which the symbol is based. Note that the register field can specify a
pair of register such as ES:EBX

name Length-prefixed name of the symbol

(0x100e) Local Thread Storage 16:32

These symbols are used for data declared with the __thread storage attribute that is not exported
from a module. In C/C++, __thread symbols that are declared static are emitted as Local Thread
Storage 16:32 symbols. Symbols that are emitted as Local Thread Storage 16:32 cannot be moved by
Symbolic Debug Information Page 37 of 89

CVPACK into the global symbol table for the executable file.

2 2 4 4 2 *

length S_LTHREAD32 @type offset segment name

@type type index

offset offset into thread local storage

segment segment of thread local storage

name length prefixed name

(0x100f) Global Thread Storage 16:32

This symbol record has the same format as the Local Thread Storage 16:32 except that the symbol
type is S_GTHREAD32. For C/C++, __thread symbols that are not specifically declared static are
emitted as Global Thread Storage 16:32 symbols and can be compacted by CVPACK into the global
symbol table.

Symbols for MIPS Architectures

(0x1010) Local Procedure Start MIPS

The symbol records define local (file static) procedure definition. For C/C++, functions that are
declared static to a module are emitted as Local Procedure symbols.

2 2 4 4 4 4 4

length symbol pParent pEnd pNext length debug ->

start

4 4 4 4 4

debug int save fp save int save fp save ->

end mask mask offset offset

4 4 2 1 1 *

@proctype offset seg retreg frame name

pointer reg

symbol S_LPROCMIPS or S_GPROCMIPS

pParent See the section on lexical scope linking

pEnd See the section on lexical scope linking

Symbolic Debug Information Page 38 of 89

pNext See the section on lexical scope linking

length Length in bytes of this procedure

debug start Offset in bytes from the start of the procedure to the point where the stack frame has
been set up. Parameter and frame variables can be viewed at this point.

debug end Offset in bytes from the start of the procedure to the point where the procedure is ready to
return and has calculated its return value, if any. Frame and register variables can still be viewed. If
the procedure has multiple exits, then this field is zero.

int save mask Integer register save mask

fp save mask Floating point register save mask

int save offset Offset from sp to the integer register save area

fp save offset Offset from sp to the floating point register save area

@proctype Type index of the procedure type record

offset Offset portion of the address of the start of the procedure

segment Segment portion of the address of the start of the procedure

retreg Index of the register that contains the return address. If this register is 31 and the integer
register save mask indicates that the register has been saved, then the return address is in the integer
register save area.

framepointer Frame pointer register if not zero

name Length prefixed name of procedure

(0x1011) Global Procedure Start MIPS

This symbol is used for procedures that are not specifically declared static to a module. The format is
the same as the Local Procedure Start 16:32 symbol (see above.)

Symbols for CVPACK Optimization

(0x0400) Procedure Reference

This symbol in inserted into the global and static symbol tables to reference a procedure. It is used so
that the symbol procedure can be found in the hashed search of the global or static symbol table.
Otherwise, procedures could be found only by searching the symbol table for every module.

2 2 4 4 2

length S_PROCREF checksum offset module

checksum Checksum of the referenced symbol name. The checksum used is the one specified in the
header of the sstGlobalSym or sstStaticSym subsections. See Section 7.4 for details of the subsection
Symbolic Debug Information Page 39 of 89

headers.

offset Offset of the procedure symbol record from the beginning of the $$SYMBOL table for the
module.

module Index of the module that contains this procedure record

(0x0401) Data Reference

This symbol in inserted into the global and static symbol tables to reference data. It is used so that
the symbol procedure can be found in the hashed search of the global or staticsymbol table.
Otherwise, data symbols could be found only by searching the symbol table for every module.

2 2 4 4 2

length S_DATAREF checksum offset module

checksum Checksum of the referenced symbol name

offset Offset of the procedure symbol record from the beginning of the $$SYMBOL table for the
module.

module Index of the module that contains this procedure record

(0x0402) Symbol Page Alignment

This symbol is inserted by CVPACK to pad symbol space so that the next symbol will not cross a
page boundary.

2 2 *

length S_ALIGN pad

pad Unused data. Use the length field that precedes every symbol record to skip this record. The pad
bytes must be zero. For sstGlobalSym and sstGlobalPub, length of the pad field must be at least
sizeof (long). There must be an S_Align symbol at the end of these tables with a pad field containing
0xffffffff. The sstStaticSym table does not have this requirement.

Types Definition Segment ($$TYPES)

A $$TYPES segment may appear in linkable modules. It provides descriptions of the types of the
symbols found in the $$PUBLICS and $$SYMBOLS debug section for the module.

Type Record
A type record has the format

2 *
Symbolic Debug Information Page 40 of 89

length type string

length The length in bytes of the following type string. This count does not include the length field.

Type String
A type string is a series of consecutive leaf structures:

2 * 2 * 2 *

leaf data leaf data ... leaf data

leaf LF_... index, as described below

data Data specified to each leaf type

No LF_... index can have a value of 0x0000. The leaf indices are separated into four ranges
according to the use of the type record. The first range is for the type records that are directly
referenced in symbols. The second range is for type records that are not referenced by symbols but
instead are referenced by other type records. All type records must have a starting leaf index in these
first two ranges.

The third range of leaf indices is used to build up complex lists such as the field list of a class type
record. No type record can begin with one of the leaf indices in this range.

The fourth ranges of type indices are used to represent numeric data in a symbol or type records.
These leaf indices are greater than 0x8000. At the point that the type or symbol processor is
expecting a numeric field, the next two bytes in the type record are examined. If the value is less than
0x8000, then the two bytes contain the numeric value. If the value is greater than 0x8000, then the
data follows the leaf index in a format specified by the leaf index. See the Section 4 for a detailed
description of the numeric leaf indices.

Because of the method used to maintain natural alignment in complex lists, no leaf index can have a
value greater than or equal to 0xf000. Also, no leaf index can have a value such that the least
significant 8 bits of the value is greater than or equal to 0xf0.

*[Note: All type records that included one or more CV_typ_t fields have been renamed by having
"_16t" appended to their original names. For instance, the symbol record for LF_MODIFIER that
included a 16-bit CV_typ_t (now known as CV_typ16_t) is now LF_MODIFIER_16t. The records
that were so changed all have indices (record type fields) with the 0x1000 bit set. Records that did
not contain CV_typ_t fields were left unchanged.]

Leaf indices for type records that can be referenced from symbols:

0x1001 LF_MODIFIER

0x1002 LF_POINTER

0x1003 LF_ARRAY

0x1004 LF_CLASS
Symbolic Debug Information Page 41 of 89

0x1005 LF_STRUCTURE

0x1006 LF_UNION

0x1007 LF_ENUM

0x1008 LF_PROCEDURE

0x1009 LF_MFUNCTION

0x000a LF_VTSHAPE

0x100a LF_COBOL0

0x000c LF_COBOL1

0x100b LF_BARRAY

0x000e LF_LABEL

0x000f LF_NULL

0x0010 LF_NOTTRAN

0x100c LF_DIMARRAY

0x100d LF_VFTPATH

0x100e LF_PRECOMP

0x0014 LF_ENDPRECOMP

0x100f LF_OEM

0x0016 LF_TYPESERVER

Leaf indices for type records that can be referenced from other type records:

0x1200 LF_SKIP

0x1201 LF_ARGLIST

0x1202 LF_DEFARG

0x1203 LF_FIELDLIST

0x1204 LF_DERIVED

0x1205 LF_BITFIELD

0x1206 LF_METHODLIST

0x1207 LF_DIMCONU
Symbolic Debug Information Page 42 of 89

0x1208 LF_DIMCONLU

0x1209 LF_DIMVARU

0x120a LF_DIMVARLU

0x020c LF_REFSYM

Leaf indices for fields of complex lists:

0x1400 LF_BCLASS

0x1401 LF_VBCLASS

0x1402 LF_IVBCLASS

0x0403 LF_ENUMERATE

0x1403 LF_FRIENDFCN

0x1404 LF_INDEX

0x1405 LF_MEMBER

0x1406 LF_STMEMBER

0x1407 LF_METHOD

0x1408 LF_NESTTYPE

0x1409 LF_VFUNCTAB

0x140a LF_FRIENDCLS

0x140b LF_ONEMETHOD

0x140c LF_VFUNCOFF

0x140d LF_NESTTYPEEX

0x140e LF_MEMBERMODIFY

Leaf indices for numeric fields of symbols and type records:

0x8000 LF_NUMERIC

0x8000 LF_CHAR

0x8001 LF_SHORT

0x8002 LF_USHORT

0x8003 LF_LONG
Symbolic Debug Information Page 43 of 89

0x8004 LF_ULONG

0x8005 LF_REAL32

0x8006 LF_REAL64

0x8007 LF_REAL80

0x8008 LF_REAL128

0x8009 LF_QUADWORD

0x800a LF_UQUADWORD

0x800b LF_REAL48

0x800c LF_COMPLEX32

0x800d LF_COMPLEX64

0x800e LF_COMPLEX80

0x800f LF_COMPLEX128

0x8010 LF_VARSTRING

0xf0 LF_PAD0

0xf1 LF_PAD1

0xf2 LF_PAD2

0xf3 LF_PAD3

0xf4 LF_PAD4

0xf5 LF_PAD5

0xf6 LF_PAD6

0xf7 LF_PAD7

0xf8 LF_PAD8

0xf9 LF_PAD9

0xfa LF_PAD10

0xfb LF_PAD11

0xfc LF_PAD12

0xfc LF_PAD13
Symbolic Debug Information Page 44 of 89

0xfe LF_PAD14

0xff LF_PAD15

Member attribute field

Several of the type records below reference a field attribute bit field. This bit field has the following
format:

access :2 Specifies the access protection of the item

0 No access protection

1 Private

2 Protected

3 Public

mprop :3 Specifies the properties for methods

0 Vanilla method

1 Virtual method

2 Static method

3 Friend method

4 Introducing virtual method

5 Pure virtual method

6 Pure introducing virtual method

7 Reserved

pseudo :1 True if the method is never instantiated by the compiler

noinherit :1 True if the class cannot be inherited

noconstruct :1 True if the class cannot be constructed

compgenx :1 True if the method is instantiated by the compiler

reserved :7

Leaf Indices Referenced from Symbols

(0x1001) Type Modifier

This record is used to indicate the const,r volatile and unaligned properties for any particular type.
Symbolic Debug Information Page 45 of 89

2 4 2

LF_MODIFIER @index attribute

@index type index of the modified type

attribute const :1 const attribute.

volatile :1 volatile attribute.
unaligned :1 unaligned attribute.

reserved :13

(0x1002) Pointer

This record is the generic pointer type record. It supports the C++ reference type, pointer to data
member, and pointer to method. It also conveys the const and volatile pointer information

2 4 4 *

LF_POINTER @type attribute variant

@type Type index of object

pointed to

attribute Consists of five bit fields:

ptrtype :5 Ordinal specifying mode

of pointer

0 Near

1 Far

2 Huge

3 Based on segment
(OBSOLETE)

4 Based on value

5 Based on segment of value

(OBSOLETE)

6 Based on address of
symbol (OBSOLETE)

7 Based on segment of
Symbolic Debug Information Page 46 of 89

symbol address
(OBSOLETE)

8 Based on type

9 Based on self
(OBSOLETE)

10 Near 32 bit pointer

11 Far 32 bit pointer

12 64 bit pointer

13-31 Reserved

ptrmode :3 Ordinal specifying

pointer mode

0 Pointer

1 Reference

2 Pointer to data member

3 Pointer to method

4-7 Reserved

isflat32 :1 True if 16:32 pointer

volatile :1 True if pointer is volatile

const :1 True if pointer is const

unaligned :1 True if pointer is unaligned

restrict :1 True if pointer is restricted

unused :19 Unused and reserved

variant variant portion of the

record, depending upon the
pointer type

based on segment -
Segment value

based on type- Index of

type followed by length-
prefixed name

based on self - Nothing

Symbolic Debug Information Page 47 of 89

based on symbol - Copy of

symbol record including
length field

pointer to data member -

Union specifying pointer to
data member

pointer to method- Union

specifying pointer to
method

The union specifying the pointer to data member has the format:

4 2

@class format

class Type index of containing class

format 0 16:16 data for class with no virtual functions or virtual bases.

1 16:16 data for class with virtual functions.

2 16:16 data for class with virtual bases.

3 16:32 data for classes w/wo virtual functions and no virtual bases

4 16:32 data for class with virtual bases.

5 16:16 near method nonvirtual bases with single address point

6 16:16 near method nonvirtual bases with multiple address points

7 16:16 near method with virtual bases

8 16:16 far method nonvirtual bases with single address point

9 16:16 far method nonvirtual bases with multiple address points

10 16:16 far method with virtual bases

11 16:32 method nonvirtual bases with single address point

12 16:32 method nonvirtual bases with multiple address points

13 16:32 method with virtual bases

The pointer to data member and pointer to method have the following formats in memory. In the
following descriptions of the format and value of the NULL pointer, * means any value.
Symbolic Debug Information Page 48 of 89

Ø (00) 16:16 pointer to data member for a class with no virtual functions or bases.

mdisp

mdisp Displacement to data. NULL is 0xffff

Ø (01) 16:16 pointer to data member for a class with virtual functions.

mdisp

mdisp Displacement to data. NULL is 0

Ø (02) 16:16 pointer to data member for a class with virtual bases.

2 2 2

mdisp pdisp vdisp

mdisp displacement to data

pdisp this pointer displacement to virtual base table pointer

vdisp displacement within virtual base table. NULL value is (,,0xffff)

Ø (03) 16:32 near pointer to data member for a class with and without virtual functions and no
virtual bases

mdisp

mdisp Displacement to data. NULL is 0x80000000

Ø (04) 16:32 near pointer to data member for a class with virtual bases.

4 4 4

mdisp pdisp vdisp

mdisp displacement to data

pdisp this pointer displacement to virtual base table pointer

Symbolic Debug Information Page 49 of 89

vdisp displacement within virtual base table. NULL value is (,,0xffffffff)

Ø (05) 16:16 pointer to near member function for a class with no virtual functions or bases and a
single address point

off

off near address of method. NULL is 0

Ø (06) 16:32 pointer to near member function for a class with no virtual bases with multiple address
points

2 2

off disp

off offset of function

disp displacement of address point. NULL is (0,*)

Ø (07) 16:16 pointer to near member function for a class with virtual bases

2 2 2 2

off mdisp pdisp vdisp

off offset of function

mdisp displacement to data

pdisp this pointer displacement to virtual base table pointer

vdisp displacement within virtual base table. NULL value is (0,*,*,*)

Ø (08) 16:16 pointer to far member function for a class with no virtual bases and a single address
point

2 2

off seg

off offset of function

disp displacement of address point. NULL is (0:0)

Ø (09) 16:16 pointer to far member function for a class with no virtual bases and multiple address
points
Symbolic Debug Information Page 50 of 89

2 2 2

off seg disp

off offset of function

seg segment of function

disp displacement of address point. NULL is (0:0,*)

Ø (10) 16:16 pointer to far member function for a class with virtual bases

2 2 2 2 2

off seg mdisp pdisp vdisp

off offset of function

seg segment of function

mdisp displacement to data

pdisp this pointer displacement to virtual base table pointer

vdisp displacement within virtual base table. NULL value is (0,*,*,*)

Ø (11) 16:32 pointer to member function for a class with no virtual bases and a single address point

off

off offset of function. NULL is 0L

Ø (012) 16:32 pointer to member function for a class with no virtual bases and multiple address
points

4 4

off disp

off offset of function

disp displacement of address point. NULL is (0L:0L)

Ø (13) 16:32 pointer to member function for a class with virtual bases
Symbolic Debug Information Page 51 of 89

4 4 4 4

off mdisp pdisp vdisp

off offset of function

mdisp displacement to data

pdisp this pointer displacement to virtual base table pointer

vdisp displacement within virtual base table. NULL value is (0L,*,*,*)

(0x1003) Simple Array

2 4 4 * *

LF_ARRAY @elemtype @idxtype length name

@elemtype Type index of each array element

@idxtype Type index of indexing variable

length Length of array in bytes

name Length-prefixed name of array

(0x1004) Classes

The format for and classes is as follows:

2 2 2 42 4 4 * *

leaf count property @field @dList @vshape length name

leaf LF_CLASS or LF_STRUCTURE

count Number of elements in the class or structure. This count includes direct, virtual, and indirect
virtual bases, and methods including overloads, data members, static data members, friends, and so
on.

property Property bit field

packed :1 Structure is packed

ctor :1 Class has constructors and/or destructors
overops :1 Class has overloaded operators
isnested :1 Class is a nested class
cnested :1 Class contains nested classes
opassign :1 Class has overloaded assignment
opcast :1 Class has casting methods
Symbolic Debug Information Page 52 of 89

fwdref :1 Class/structure is a forward (incomplete) reference

scoped :1 This is a scoped definition

reserved:8

@field Type index of the field list for this class.

@dList Type index of the derivation list. This is output by the compiler as 0x0000 and is filled in by
the CVPACK utility to a LF_DERIVED record containing the type indices of those classes which
immediately inherit the current class. A zero index indicates that no derivation information is
available. A LF_NULL index indicates that the class is not inherited by other classes.

@vshape Type index of the virtual function table shape descriptor

length Numeric leaf specifying size in bytes of the structure

name Length-prefixed name this type

(0x1005) Structures

Structures have the same format as classes. Structure type records are used exclusively by the C
compiler. The C++ compiler emits both class and structure records depending upon the declaration.

(0x1006) Unions

The format for a Union is as follows:

2 2 2 42 * *

LF_UNION count property @field length name

count Number of fields in the union

property Property bit field.

@field Type index of field list.

length Numeric leaf specifying size in bytes of the union

name Length-prefixed name of union

(0x1007) Enumeration

The format for an enum is as follows:

2 2 2 4 4 *

LF_ENUM count property @type @fList name

count Number of enumerates

Symbolic Debug Information Page 53 of 89

property Property bit field.

@type Underlying type of enum

@field Type index of field list.

name Length-prefixed name of enum

(0x1008) Procedure

2 4 1 1 2 4

LF_PROCEDURE @rvtype call reserved #parms @arglist

@rvtype Type index of the value returned by the procedure

call Calling convention of the procedure

0 Near C (arguments pushed right to left, caller pops arguments)

1 Far C

2 Near pascal (arguments pushed left to right, callee pops arguments)

3 Far pascal

4 Near fastcall

5 Far fastcall

6 Reserved

7 Near stdcall

8 Far stdcall

9 Near syscall

10 Far syscall

11 This call

12 MIPS call

13 Generic

14-255 Reserved

#parms Number of parameters

@arglist Type index of argument list type record

Symbolic Debug Information Page 54 of 89

(0x1009) Member Function

2 4 4 4 1 1

LF_MFUNCTION @rvtype @class @this call res ->

2 4 4

#parms @arglist thisadjust

@rvtype Type index of the value returned by the procedure

@class Type index of the containing class of the function

@this Type index of the this parameter of the member function. A type of void indicates that the
member function is static and has no this parameter.

call Calling convention of the procedure. See Procedure description.

res Reserved. Must be emitted as zero.

#parms Number of parameters. This count does not include the this parameter.

arglist List of parameter specifiers. This list does not include the this parameter.

thisadjust Logical this adjustor for the method. Whenever a class element is referenced via the this
pointer, thisadjust will be added to the resultant offset before referencing the element.

(0x000a) Virtual Function Table Shape

This record describes the format of a virtual function table. This record is accessed via the
vfunctabptr in the member list of the class which introduces the virtual function. The vfunctabptr is
defined either by the LF_VFUNCTAB or LF_VFUNCOFF member record. If LF_VFUNCTAB
record is used, then vfunctabptr is at the address point of the class. If LF_VFUNCOFF record is
used, then vfunctabptr is at the specified offset from the class address point. The underlying type of
the pointer is a VTShape type record. This record describes how to interpret the memory at the
location pointed to by the virtual function table pointer.

2 2 4 bits

LF_VTSHAPE count descriptor

repeated

count Number of descriptors

descriptor A four-bit ordinal describing the entry in the virtual table

0 Near
1 Far
2 Thin
Symbolic Debug Information Page 55 of 89

3 Address point displacement to outermost class. This is at entry[-1] from table address
4 Far pointer to metaclass descriptor. This is at entry[-2] from table address

5 Near32

6 Far32
7 - 15 Reserved

(0x100a) Cobol0

This record has been reserved for the Microfocus COBOL compiler.

2 4 *

LF_COBOL0 @parent data

@parent Type index of the parent type

data Data

(0x000c) Cobol1

This record has been reserved for the Microfocus COBOL compiler.

2 *

LF_COBOL1 data

data Data

(0x100b) Basic Array

2 4

LF_BARRAY @ type

type Type of each element of the array

(0x000e) Label

This is used for assembler labels where there is no typing information about the label.

2 2

LF_LABEL mode

mode Addressing mode of the label

Symbolic Debug Information Page 56 of 89

0 Near label

4 Far label

(0x000f) Null

This is used where the symbol requires a type record but the data content is null.

LF_NULL

(0x0010) Not Translated

This is used when CVPACK encounters a type record that has no equivalent in the CV4.0 format.

LF_NOTTRANS

(0x100c) Multiply Dimensioned Array

This record is used to describe a multiply dimensioned array.

2 4 4 *

LF_DIMARRAY @utype @diminfo name

@utype Underlying type of the array

@diminfo Index of the type record containing the dimension information

name Length-prefixed name of the array

(0x100d) Path to Virtual Function Table

This record is used to describe the path to the virtual function table.

2 4 4 * count

LF_VFTPATH count bases

count Count of number of bases in the path to the virtual function table

bases Type indices of the base classes in the path

(0x0013) Reference Precompiled Types

Symbolic Debug Information Page 57 of 89

This record specifies that the type records are included from the precompiled types contained in
another module in the executable. A module that contains this type record is considered to be a user
of the precompiled types. When emitting to a COFF object the section name should be .debug$P
rather than .debug$T. All other attributes should be the same.

2 4 4 4 *

LF_PRECOMP start count signature name

start Starting type index that is included. This number must correspond to the current type index in
the current module

count count of the number of type indices included. After including the precompiled types, the type
index must be start + count

signature Signature for the precompiled types being referencedbythis module. The signature will be
checked against the signature in the S_OBJNAME symbol record and the LF_ENDPRECOMP type
record contained in the $$TYPES table of the creator of the precompiled types. The signature check
is used to detect recompilation of the supplier of the precompiled types without recompilation of all
of the users of the precompiled types. The method for computing the signature is unspecified. It
should be sufficiently robust to detect failures to recompile.

name Name of the module containing the precompiled types. This name must match the module
name in the S_OBJNAME symbol emitted by the compiler for the object file containing the
precompiled types.

(0x0014) End of Precompiled Types

This record specifies that the preceding type records in this module can be referenced by another
module in the executable. A module that contains this type record is considered to be the creator of
the precompiled types. The subsection index for the $$TYPES segment for a precompiled types
creator is emitted as sstPreComp instead of sstTypes so that the CVPACK can pack the precompiled
types creators before the users. Precompiled types must be emitted as the first type records within the
$$TYPES segment and must be self-contained. That is, they cannot reference a type record whose
index is greater than or equal to the type index of the LF_ENDPRECOMP type record.

2 4

LF_ENDPRECOMP signature

signature Signature of the precompiled types. The signatures in the S_OBJNAME symbol record,
the LF_PRECOMP type record and this signature must match.

(0x100f) OEM Generic Type

This record is supplied to allow third party compiler vendors to emit debug OMF information in an
arbitrary format and still allow CVPACK to be able to process the record. CVPACK processes this
record by performing a left to right depth first recursive pack of the records specified by indices
below. The remainder of the data is copied without alteration.
Symbolic Debug Information Page 58 of 89

2 2 2 4 4* *
count

LF_OEM OEM recOEM count indices data

OEM Microsoft assigned OEM identifier

recOEM OEM assigned record identifier. These record identifiers are unique per assigned OEM.

count number of type indices that follow

indices Type indices

data remainder of type record.

(0x0016) Reference Typeserver

This type record is used to indicate that all type records must be retrieved from the specified Program
Data Base (PDB).

2 4 4 *

LF_TYPESERVER signature age name

signature Signature of the PDB. The method of computing this signature is unspecified. The
signature must be verified against the signature in the PDB by using the TypesQuerySignature API
call.

age Age of program data base The method of computing this age is unspecified. The age must be
verified against the age in the PDB by using the TypesQueryAge API call.

name Length prefixed full path name of program data base

Type Records Referenced from Type Records

(0x1200) Skip

This is used by incremental compilers to reserve space for future indexes.

2 4 *

LF_SKIP index pad

index In processing $$TYPES, the index counter is advanced to index count, skipping all
intermediate indices. This is the next valid index.

pad Space reserved for incremental compilations. Note that this record is removed by the link/pack
utility so there is no requirement for maintaining natural alignment for this record.
Symbolic Debug Information Page 59 of 89

(0x1201) Argument List

2 4 4*argcount

LF_ARGLIST argcount indices

argcount Count of number of indices in list

indices List of type indices for describing the formal parameters to a function or method.

(0x1202) Default Argument

2 4 *

LF_DEFARG @index expression

index Type index of resulting expression

expression Length-prefixed string of supplied default

(0x1203) Field List

A field list contains the descriptors of the fields of a structure, class, union, or enumeration. The field
list is composed of zero or more subfields. Because of the requirement for natural alignment, there
may be padding between elements of the field list. As a program walks down the field list, the
address of the next subfield is calculated by adding the length of the previous field to the address of
the previous field. The byte at the new address is examined and if it is greater than 0xf0, the low four
bits are extracted and added to the address to find the address of the next subfield. These padding
fields are not included in the count field of the class, structure, union, or enumeration type records. If
the field list is broken into two or more pieces by the compiler, then the last field of each piece is a
LF_INDEX with the type being the index of the continuation record. The LF_INDEX and LF_PADx
fields of the field list are not included in field list count specified in the class, structure, union, or
enumeration record. See Section 3.5 for field list elements

2 * * ... * 2 *

leaf data pad ... pad leaf data

(0x1204) Derived Classes

This type record specifies all of the classes that are directly derived from the class that references this
type record.

2 4 4*count

LF_DERIVED count @type

count Number of types in the list

Symbolic Debug Information Page 60 of 89

@type Type indices of the classes that directly inherit from the class that references this type record

(0x1205) Bit Fields

Bit fields are represented by an entry in the field list that indexes a bit field type definition.

2 42 1 1

LF_BITFIELD @type length position

@type Type index of the field

length The length in bits of the object

position Starting position (from bit 0) of the object in the word.

(0x1206) Method List

2 2 2 4 4

LF_MLIST attribute pad0 @type vtab offset

optional

repeated

attribute Attribute of the member function

pad0 Two bytes of padding for native alignment on type index to follow, must be 0.@type Type
index of the procedure record for this occurrence of the function.

vtab offset Present only when property attribute is introducing virtual (optional). Offset in vtable of
the class which contains the pointer to the function.

Once a method has been found in this list, its symbol is found by qualifying the method name with
its class (T::name) and then searching the symbol table for a symbol by that name with the correct
type index. Note that the number of repeats is determined by the subleaf of the field list that
references this LF_MLIST record.

(0x1207) Dimensioned Array with Constant Upper Bound

This record is used to describe a dimensioned array with default lower bound and constant upper
bound. The default lower bound is language specific.

2 42 2 s*rank

LF_DIMCONU @index rank bound

@index Type of the index

Symbolic Debug Information Page 61 of 89

rank Number of dimensions

bound Constants for the upper bound of each dimension of the array. Each constant is of the size s
specified by @index.

(0x0209) Dimensioned Array with Constant Lower and Upper Bounds

This record is used to describe a dimensioned array with constant lower and upper bound.

2 42 2 2*s*rank

LF_DIMCONLU @index rank bound

@index Type of the index

rank Number of dimensions

bound Pairs of constants for the lower and upper bound of each dimension of the array. Each
constant is of the size s specified by @index. The ordering is lower bound followed by upper bound
for each dimension.

(0x020a) Dimensioned Array with Variable Upper Bound

This record is used to describe a dimensioned array with default lower bound and variable upper
bound. The default lower bound is language specific.

2 4 4 rank

LF_DIMVARU rank @index @var

rank Number of dimensions

@index Type of the index

@var Array of type index of LF_REFSYM record describing the variable upper bound. If one
dimension of the array is variable, then all dimensions must be described using LF_REFSYM
records.

(0x020b) Dimensioned Array with Variable Lower and Upper Bounds

This record is used to describe a dimensioned array with variable lower and upper bound.

2 4 4 2*rank

LF_DIMVARLU rank @index var

rank Number of dimensions

@index Type of the index

Symbolic Debug Information Page 62 of 89

@var Array of type indices of LF_REFSYM records describing the variable lower and upper
bounds. If one dimension of the array is variable, then all dimensions must be described using
LF_REFSYM records. The order is lower bound followed by upper bound for each dimension.

(0x020c) Referenced Symbol

This record is used to describe a symbol that is referenced by a type record. The record is defined
because type records cannot reference symbols or locations in the $$SYMBOLS table because global
symbol compaction will move symbols.

2 *

LF_REFSYM sym

sym Copy of the referenced symbol including the length field

Subfields of complex lists

Currently, the only complex list that uses the following leaf indices is the field list of a structure,
class, union, or enumeration.

(0x1400) Real Base Class

This leaf specifies an real base class. If a class inherits real base classes, the corresponding REAL
Base Class records will precede all other member records in the field list of that class. Base class
records are emitted in left to right declaration order for real bases.

2 42 *

LF_BCLASS attribute @type offset

attribute Member attribute bit field

@type Index to type record of the class. The class name can be obtained from this record.

offset Offset of subobject that represents the base class within the structure.

(0x1401) Direct Virtual Base Class

This leaf specifies directly inherited virtual base class. If a class directly inherits virtual base classes,
the corresponding Direct Virtual BaseClass records will follow all Real Base Class member records
and precede all other member records in the field list of that class. Direct Virtual Base class records
are emitted in bottommost left-to-right inheritance order for directly inherited virtual bases.

2 2 4 4 * *

LF_VBCLASS attribute @btype @vbtype vbpoff vboff

attribute Member attribute bit field

Symbolic Debug Information Page 63 of 89

@btype Index to type record of the direct or indirect virtual base class. The class name can be
obtained from this record.

@vbptype Type index of the virtual base pointer for this base

vbpoff Numeric leaf specifying the offset of the virtual base pointer from the address point of the
class for this virtual base

vboff Numeric leaf specifying the index into the virtual base displacement table of the entry that
contains the displacement of the virtual base. The displacement is relative to the address point of the
class plus vbpoff.

(0x1402) Indirect Virtual Base Class

This leaf specifies indirectly inherited virtual base class. If a class indirectly inherits virtual base
classes, the corresponding Indirect Virtual Base Class records will follow all Real Base Class and
Direct Virtual Base Class member records and precede all other member records in the field list of
that class. Direct Virtual Base class records are emitted in bottommost left-to-right inheritance order
for virtual bases.

2 2 4 4 * *

LF_IVBCLASS attribute @btype @vbtype vbpoff vboff

attribute Member attribute bit field

@btype Index to type record of the direct or indirect virtual base class. The class name can be
obtained from this record.

@vbptype Type index of the virtual base pointer for this base

vbpoff Numeric leaf specifying the offset of the virtual base pointer from the address point of the
class for this virtual base

vboff Numeric leaf specifying the index into the virtual base displacement table of the entry that
contains the displacement of the virtual base. The displacement is relative to the address point of the
class plus vbpoff.

(0x0403) Enumeration Name and Value

This leaf specifies the name and value of an enumerate within an enumeration.

2 2 * *

LF_ENUMERATE attribute value name

attribute Member attribute bit field

value Numeric leaf specifying the value of enumerate

name Length-prefixed name of the member field.

Symbolic Debug Information Page 64 of 89

(0x1403) Friend Function

This leaf specifies a friend function

2 2 4 *

LF_FRIENDFCN pad0 @type name

pad0 Two bytes of padding for native alignment on type index to follow, must be 0.

@type Index to type record of the friend function.

name Length prefixed name of friend function

(0x1404) Index To Another Type Record

2 2 4

LF_INDEX pad0 @index

pad0 Two bytes of padding for native alignment on type index to follow, must be 0.

index Type index. This field is emitted by the compiler when a complex list needs to be split during
writing.

(0x1405) Data Member

This leaf specifies nonstatic data members of a class.

2 2 4 * *

LF_MEMBER attribute @type offset name

attribute Member attribute bit field

@type Index to type record for field

offset Numeric leaf specifying the offset of field in the structure

name Length-prefixed name of the member field

(0x1406) Static Data Member

This leaf specifies static data member of a class. Once a static data member has been found in this
list, its symbol is found by qualifying the name with its class (T::name) and then searching the
symbol table for a symbol by that name with the correct type index.

2 2 4 *
Symbolic Debug Information Page 65 of 89

LF_STMEMBER attribute @type name

@type Index to type record for field

attribute Member attribute bit field

name Length-prefixed name of the member field.

(0x1407) Method

This leaf specifies the overloaded member functions of a class. This type record can also be used to
specify a non-overloaded method but is inefficient. The LF_ONEMETHOD record should be used
for non-overloaded methods.

2 2 4 *

LF_METHOD count @mList name

count Number of occurrences of function within the class. If the function is overloaded then there
will be multiple entries in the method list.

@mList Type index of method list

name Length-prefixed name of method

(0x1408) Nested Type Definition

This leaf specifies nested type definition with classes, structures, unions, or enums.

2 2 4 *

LF_NESTEDTYPE pad0 @index name

pad0 Two bytes of padding for native alignment on type index to follow, must be 0.

@index Type index of nested type

name Length-prefixed name of type

(0x1409) Virtual Function Table Pointer

This leaf specifies virtual table pointers within the class. It is a requirement that this record be
emitted in the field list before any virtual functions are emitted to the field list.

2 2 4

LF_VFUNCTAB pad0 @type

Symbolic Debug Information Page 66 of 89

pad0 Two bytes of padding for native alignment on type index to follow, must be 0.

@type Index to the pointer record describing the pointer. The pointer will in turn have a
LF_VTSHAPE type record as the underlying type. Note that the offset of the virtual function table
pointer from the address point of the class is always zero.

(0x040b) Friend Class

This leaf specifies a friend class.

2 2 4

LF_FRIENDCLS pad0 @type

pad0 Two bytes of padding for native alignment on type index to follow, must be 0.

@type Index to type record of the friend class. The name of the class can be obtained from the
referenced record.

(0x140b) One Method

This record is used to specify a method of a class that is not overloaded.

2 2 4 4 *

LF_ONEMETHOD attribute @type vbaseoff name

attribute Method attribute

@type Type index of method

vbaseoff Offset in virtual function table if introducing virtual method. If the method is not an
introducing virtual, then this field is not present.

name Length prefixed name of method

(0x140c) Virtual Function Offset

This record is used to specify a virtual function table pointer at a non-zero offset relative to the
address point of a class.

2 2 4 4

LF_VFUNCOFF pad0 @type offset

pad0 Two bytes of padding for native alignment on type index to follow, must be 0.

@type Type index of virtual function table pointer

offset Offset of virtual function table pointer relative to address point of class.
Symbolic Debug Information Page 67 of 89

(0x140d) Nested Type Extended Definition

This leaf specifies nested type definition with classes, structures, unions, or enums and includes the
protection attributes that are missing in LF_NESTEDTYPE.

2 2 4 *

LF_NESTEDTYPEEX attribute @type name

attribute Nested type attribute (protection fields are valid)

@type Type index of nested type

name Length-prefixed name of type

(0x040f) Member Modification

This leaf specifies the modification of the protection of a member or method in a sub class.

2 2 4 *

LF_MEMBERMODIFY attribute @type name

attribute New protection attributes

@type Type index of base class that introduced the member

name Length-prefixed name of member

Format of Reserved Types

Types 0 - 4095 (0 - 0x0fff) are reserved. These values are interpreted as bit fields with the following
sizes and meanings.

11 10 - 8 7-4 3 2-0

reserved mode type reserved size

type Type

0x00 Special

0x01 Signed integral value

0x02 Unsigned integral value
0x03 Boolean
0x04 Real

0x05 Complex
0x06 Special2
Symbolic Debug Information Page 68 of 89

0x07 Really int value

0x08 Reserved

0x09 Reserved

0x0a Reserved

0x0b Reserved

0x0c Reserved

0x0d Reserved

0x0e Reserved

0x0f Reserved for CodeView expression evaluator use

size Enumerated value for each of the types

Type = special

0x00 No type

0x01 Absolute symbol

0x02 Segment

0x03 Void

0x04 Basic 8-byte currency value

0x05 Near Basic string

0x06 Far Basic string

0x07 Untranslated type from CV 3.x format

Type = signed/unsigned integral and Boolean values

0x00 1 byte

0x01 2 byte

0x02 4 byte

0x03 8 byte

0x04 Reserved

0x05 Reserved

0x06 Reserved
Symbolic Debug Information Page 69 of 89

0x07 Reserved

Type = real and complex

0x00 32 bit

0x01 64 bit

0x02 80 bit

0x03 128 bit

0x04 48 bit

0x05 Reserved

0x06 Reserved

0x07 Reserved

Type = special2

0x00 Bit

0x01 Pascal CHAR

Type = Really int

0x00 Char

0x01 Wide character

0x02 2 byte signed integer

0x03 2 byte unsigned integer

0x04 4 byte signed integer

0x05 4 byte unsigned integer

0x06 8 byte signed integer

0x07 8 byte unsigned integer

mode Mode
0x00 Direct; not a pointer
0x01 Near pointer
0x02 Far pointer
0x03 Huge pointer

0x04 32 bit near pointer

0x05 32 bit far pointer

Symbolic Debug Information Page 70 of 89

0x06 64 bit near pointer

0x07 Reserved

Primitive Type Listing

Special types

T_NOTYPE 0x0000 Uncharacterized type (no type)

T_ABS 0x0001 Absolute symbol

T_SEGMENT 0x0002 Segment type

T_VOID 0x0003 Void

T_PVOID 0x0103 Near pointer to void

T_PFVOID 0x0203 Far pointer to void

T_PHVOID 0x0303 Huge pointer to void

T_32PVOID 0x0403 32 bit near pointer to void

T_32PFVOID 0x0503 32 bit far pointer to void

T_64PVOID 0x0603 64 bit pointer to void

T_CURRENCY 0x0004 Basic 8 byte currency value

T_NBASICSTR 0x0005 Near Basic string

T_FBASICSTR 0x0006 Far Basic string

T_NOTTRANS 0x0007 Untranslated type record from CV 3.x format

T_BIT 0x0060 Bit

T_PASCHAR 0x0061 Pascal CHAR

Character types

T_CHAR 0x0010 8-bit signed

T_UCHAR 0x0020 8-bit unsigned

T_PCHAR 0x0110 Near pointer to 8-bit signed

T_PUCHAR 0x0120 Near pointer to 8-bit unsigned

T_PFCHAR 0x0210 Far pointer to 8-bit signed

T_PFUCHAR 0x0220 Far pointer to 8-bit unsigned

Symbolic Debug Information Page 71 of 89

T_PHCHAR 0x0310 Huge pointer to 8-bit signed

T_PHUCHAR 0x0320 Huge pointer to 8-bit unsigned

T_32PCHAR 0x0410 16:32 near pointer to 8-bit signed

T_32PUCHAR 0x0420 16:32 near pointer to 8-bit unsigned

T_32PFCHAR 0x0510 16:32 far pointer to 8-bit signed

T_32PFUCHAR 0x0520 16:32 far pointer to 8-bit unsigned

T_64PCHAR 0x0610 64 bit pointer to 8 bit signed

T_64PUCHAR 0x0620 64 bit pointer to 8 bit unsigned

Really a character types

T_RCHAR 0x0070 real char

T_PRCHAR 0x0170 near pointer to a real char

T_PFRCHAR 0x0270 far pointer to a real char

T_PHRCHAR 0x0370 huge pointer to a real char

T_32PRCHAR 0x0470 16:32 near pointer to a real char

T_32PFRCHAR 0x0570 16:32 far pointer to a real char

T_64PRCHAR 0x0670 64 bit pointer to a real char

Wide character types

T_WCHAR 0x0071 wide char

T_PWCHAR 0x0171 near pointer to a wide char

T_PFWCHAR 0x0271 far pointer to a wide char

T_PHWCHAR 0x0371 huge pointer to a wide char

T_32PWCHAR 0x0471 16:32 near pointer to a wide char

T_32PFWCHAR 0x0571 16:32 far pointer to a wide char

T_64PWCHAR 0x0671 64 bit pointer to a wide char

Really 16 bit integer types

T_INT2 0x0072 really 16 bit signed int

T_UINT2 0x0073 really 16 bit unsigned int

Symbolic Debug Information Page 72 of 89

T_PINT2 0x0172 near pointer to 16 bit signed int

T_PUINT2 0x0173 near pointer to 16 bit unsigned int

T_PFINT2 0x0272 far pointer to 16 bit signed int

T_PFUINT2 0x0273 far pointer to 16 bit unsigned int

T_PHINT2 0x0372 huge pointer to 16 bit signed int

T_PHUINT2 0x0373 huge pointer to 16 bit unsigned int

T_32PINT2 0x0472 16:32 near pointer to 16 bit signed int

T_32PUINT2 0x0473 16:32 near pointer to 16 bit unsigned int

T_32PFINT2 0x0572 16:32 far pointer to 16 bit signed int

T_32PFUINT2 0x0573 16:32 far pointer to 16 bit unsigned int

T_64PINT2 0x0672 64 bit pointer to 16 bit signed int

T_64PUINT2 0x0673 64 bit pointer to 16 bit unsigned int

16-bit short types

T_SHORT 0x0011 16-bit signed

T_USHORT 0x0021 16-bit unsigned

T_PSHORT 0x0111 Near pointer to 16-bit signed

T_PUSHORT 0x0121 Near pointer to 16-bit unsigned

T_PFSHORT 0x0211 Far pointer to 16-bit signed

T_PFUSHORT 0x0221 Far pointer to 16-bit unsigned

T_PHSHORT 0x0311 Huge pointer to 16-bit signed

T_PHUSHORT 0x0321 Huge pointer to 16-bit unsigned

T_32PSHORT 0x0411 16:32 near pointer to 16 bit signed

T_32PUSHORT 0x0421 16:32 near pointer to 16 bit unsigned

T_32PFSHORT 0x0511 16:32 far pointer to 16 bit signed

T_32PFUSHORT 0x0521 16:32 far pointer to 16 bit unsigned

T_64PSHORT 0x0611 64 bit pointer to 16 bit signed

T_64PUSHORT 0x0621 64 bit pointer to 16 bit unsigned

Symbolic Debug Information Page 73 of 89

Really 32 bit integer types

T_INT4 0x0074 really 32 bit signed int

T_UINT4 0x0075 really 32 bit unsigned int

T_PINT4 0x0174 near pointer to 32 bit signed int

T_PUINT4 0x0175 near pointer to 32 bit unsigned int

T_PFINT4 0x0274 far pointer to 32 bit signed int

T_PFUINT4 0x0275 far pointer to 32 bit unsigned int

T_PHINT4 0x0374 huge pointer to 32 bit signed int

T_PHUINT4 0x0375 huge pointer to 32 bit unsigned int

T_32PINT4 0x0474 16:32 near pointer to 32 bit signed int

T_32PUINT4 0x0475 16:32 near pointer to 32 bit unsigned int

T_32PFINT4 0x0574 16:32 far pointer to 32 bit signed int

T_32PFUINT4 0x0575 16:32 far pointer to 32 bit unsigned int

T_64PINT4 0x0674 64 bit pointer to 32 bit signed int

T_64PUINT4 0x0675 64 bit pointer to 32 bit unsigned int

32-bit long types

T_LONG 0x0012 32-bit signed

T_ULONG 0x0022 32-bit unsigned

T_PLONG 0x0112 Near pointer to 32-bit signed

T_PULONG 0x0122 Near pointer to 32-bit unsigned

T_PFLONG 0x0212 Far pointer to 32-bit signed

T_PFULONG 0x0222 Far pointer to 32-bit unsigned

T_PHLONG 0x0312 Huge pointer to 32-bit signed

T_PHULONG 0x0322 Huge pointer to 32-bit unsigned

T_32PLONG 0x0412 16:32 near pointer to 32 bit signed

T_32PULONG 0x0422 16:32 near pointer to 32 bit unsigned

T_32PFLONG 0x0512 16:32 far pointer to 32 bit signed

Symbolic Debug Information Page 74 of 89

T_32PFULONG 0x0522 16:32 far pointer to 32 bit unsigned

T_64PLONG 0x0612 64 bit pointer to 32 bit signed

T_64PULONG 0x0622 64 bit pointer to 32 bit unsigned

Really 64-bit integer types

T_INT8 0x0076 64-bit signed int

T_UINT8 0x0077 64-bit unsigned int

T_PINT8 0x0176 Near pointer to 64-bit signed int

T_PUINT8 0x0177 Near pointer to 64-bit unsigned int

T_PFINT8 0x0276 Far pointer to 64-bit signed int

T_PFUINT8 0x0277 Far pointer to 64-bit unsigned int

T_PHINT8 0x0376 Huge pointer to 64-bit signed int

T_PHUINT8 0x0377 Huge pointer to 64-bit unsigned int

T_32PINT8 0x0476 16:32 near pointer to 64 bit signed int

T_32PUINT8 0x0477 16:32 near pointer to 64 bit unsigned int

T_32PFINT8 0x0576 16:32 far pointer to 64 bit signed int

T_32PFUINT8 0x0577 16:32 far pointer to 64 bit unsigned int

T_64PINT8 0x0676 64 bit pointer to 64 bit signed int

T_64PUINT8 0x0677 64 bit pointer to 64 bit unsigned int

64-bit integral types

T_QUAD 0x0013 64-bit signed

T_UQUAD 0x0023 64-bit unsigned

T_PQUAD 0x0113 Near pointer to 64-bit signed

T_PUQUAD 0x0123 Near pointer to 64-bit unsigned

T_PFQUAD 0x0213 Far pointer to 64-bit signed

T_PFUQUAD 0x0223 Far pointer to 64-bit unsigned

T_PHQUAD 0x0313 Huge pointer to 64-bit signed

T_PHUQUAD 0x0323 Huge pointer to 64-bit unsigned

Symbolic Debug Information Page 75 of 89

T_32PQUAD 0x0413 16:32 near pointer to 64 bit signed

T_32PUQUAD 0x0423 16:32 near pointer to 64 bit unsigned

T_32PFQUAD 0x0513 16:32 far pointer to 64 bit signed

T_32PFUQUAD 0x0523 16:32 far pointer to 64 bit unsigned

T_64PQUAD 0x0613 64 bit pointer to 64 bit signed

T_64PUQUAD 0x0623 64 bit pointer to 64 bit unsigned

32-bit real types

T_REAL32 0x0040 32-bit real

T_PREAL32 0x0140 Near pointer to 32-bit real

T_PFREAL32 0x0240 Far pointer to 32-bit real

T_PHREAL32 0x0340 Huge pointer to 32-bit real

T_32PREAL32 0x0440 16:32 near pointer to 32 bit real

T_32PFREAL32 0x0540 16:32 far pointer to 32 bit real

T_64PREAL32 0x0640 64 pointer to 32 bit real

48-bit real types

T_REAL48 0x0044 48-bit real

T_PREAL48 0x0144 Near pointer to 48-bit real

T_PFREAL48 0x0244 Far pointer to 48-bit real

T_PHREAL48 0x0344 Huge pointer to 48-bit real

T_32PREAL48 0x0444 16:32 near pointer to 48 bit real

T_32PFREAL48 0x0544 16:32 far pointer to 48 bit real

T_64PREAL48 0x0644 64 bit pointer to 48 bit real

64-bit real types

T_REAL64 0x0041 64-bit real

T_PREAL64 0x0141 Near pointer to 64-bit real

T_PFREAL64 0x0241 Far pointer to 64-bit real

T_PHREAL64 0x0341 Huge pointer to 64-bit real

Symbolic Debug Information Page 76 of 89

T_32PREAL64 0x0441 16:32 near pointer to 64 bit real

T_32PFREAL64 0x0541 16:32 far pointer to 64 bit real

T_64PREAL64 0x0641 64 bit pointer to 64 bit real

80-bit real types

T_REAL80 0x0042 80-bit real

T_PREAL80 0x0142 Near pointer to 80-bit real

T_PFREAL80 0x0242 Far pointer to 80-bit real

T_PHREAL80 0x0342 Huge pointer to 80-bit real

T_32PREAL80 0x0442 16:32 near pointer to 80 bit real

T_32PFREAL80 0x0542 16:32 far pointer to 80 bit real

T_64PREAL80 0x0642 64 bit pointer to 80 bit real

128-bit real types

T_REAL128 0x0043 128-bit real

T_PREAL128 0x0143 Near pointer to 128-bit real

T_PFREAL128 0x0243 Far pointer to 128-bit real

T_PHREAL128 0x0343 Huge pointer to 128-bit real

T_32PREAL128 0x0443 16:32 near pointer to 128 bit real

T_32PFREAL128 0x0543 16:32 far pointer to 128 bit real

T_64PREAL128 0x0643 64 bit pointer to 128 bit real

32-bit complex types

T_CPLX32 0x0050 32-bit complex

T_PCPLX32 0x0150 Near pointer to 32-bit complex

T_PFCPLX32 0x0250 Far pointer to 32-bit complex

T_PHCPLX32 0x0350 Huge pointer to 32-bit complex

T_32PCPLX32 0x0450 16:32 near pointer to 32 bit complex

T_32PFCPLX32 0x0550 16:32 far pointer to 32 bit complex

T_64PCPLX32 0x0650 64 bit pointer to 32 bit complex

Symbolic Debug Information Page 77 of 89

64-bit complex types

T_CPLX64 0x0051 64-bit complex

T_PCPLX64 0x0151 Near pointer to 64-bit complex

T_PFCPLX64 0x0251 Far pointer to 64-bit complex

T_PHCPLX64 0x0351 Huge pointer to 64-bit complex

T_32PCPLX64 0x0451 16:32 near pointer to 64 bit complex

T_32PFCPLX64 0x0551 16:32 far pointer to 64 bit complex

T_64PCPLX64 0x0651 64 bit pointer to 64 bit complex

80-bit complex types

T_CPLX80 0x0052 80-bit complex

T_PCPLX80 0x0152 Near pointer to 80-bit complex

T_PFCPLX80 0x0252 Far pointer to 80-bit complex

T_PHCPLX80 0x0352 Huge pointer to 80-bit complex

T_32PCPLX80 0x0452 16:32 near pointer to 80 bit complex

T_32PFCPLX80 0x0552 16:32 far pointer to 80 bit complex

T_64PCPLX80 0x0652 64 bit pointer to 80 bit complex

128-bit complex types

T_CPLX128 0x0053 128-bit complex

T_PCPLX128 0x0153 Near pointer to 128-bit complex

T_PFCPLX128 0x0253 Far pointer to 128-bit complex

T_PHCPLX128 0x0353 Huge pointer to 128-bit real

T_32PCPLX128 0x0453 16:32 near pointer to 128 bit complex

T_32PFCPLX128 0x0553 16:32 far pointer to 128 bit complex

T_64PCPLX128 0x0653 64 bit pointer to 128 bit complex

Boolean types

T_BOOL08 0x0030 8-bit Boolean

T_BOOL16 0x0031 16-bit Boolean

Symbolic Debug Information Page 78 of 89

T_BOOL32 0x0032 32-bit Boolean

T_BOOL64 0x0033 64-bit Boolean

T_PBOOL08 0x0130 Near pointer to 8-bit Boolean

T_PBOOL16 0x0131 Near pointer to 16-bit Boolean

T_PBOOL32 0x0132 Near pointer to 32-bit Boolean

T_PBOOL64 0x0133 Near pointer to 64-bit Boolean

T_PFBOOL08 0x0230 Far pointer to 8-bit Boolean

T_PFBOOL16 0x0231 Far pointer to 16-bit Boolean

T_PFBOOL32 0x0232 Far pointer to 32-bit Boolean

T_PFBOOL32 0x0233 Far pointer to 64-bit Boolean

T_PHBOOL08 0x0330 Huge pointer to 8-bit Boolean

T_PHBOOL16 0x0331 Huge pointer to 16-bit Boolean

T_PHBOOL32 0x0332 Huge pointer to 32-bit Boolean

T_PHBOOL64 0x0333 Huge pointer to 64-bit Boolean

T_32PBOOL08 0x0430 16:32 near pointer to 8 bit boolean

T_32PFBOOL08 0x0530 16:32 far pointer to 8 bit boolean

T_32PBOOL16 0x0431 16:32 near pointer to 16 bit boolean

T_32PFBOOL16 0x0531 16:32 far pointer to 16 bit boolean

T_32PBOOL32 0x0432 16:32 near pointer to 32 bit boolean

T_32PFBOOL32 0x0532 16:32 far pointer to 32 bit boolean

T_32PBOOL64 0x0433 16:32 near pointer to 64-bit Boolean

T_32PFBOOL64 0x0533 16:32 far pointer to 64-bit Boolean

T_64PBOOL08 0x0630 64 bit pointer to 8 bit boolean

T_64PBOOL16 0x0631 64 bit pointer to 16 bit boolean

T_64PBOOL32 0x0632 64 bit pointer to 32 bit boolean

T_64PBOOL64 0x0633 64 bit pointer to 64-bit Boolean

Symbolic Debug Information Page 79 of 89

Register Enumerations
When the compiler emits a symbol that has been enregistered, the symbol record specifies the
register by a register enumeration value. The enumeration is unique to each hardware architecture
supported.

Intel 80x86/80x87 Architectures

0 none

8-bit registers

1 AL
2 CL
3 DL
4 BL
5 AH
6 CH
7 DH
8 BH

16-bit registers

9 AX
10 CX
11 DX
12 BX
13 SP
14 BP
15 SI
16 DI

32-bit registers

17 EAX
18 ECX
19 EDX
20 EBX
21 ESP
22 EBP
23 ESI
24 EDI

Segment registers

25 ES
26 CS
27 SS
28 DS
29 FS
30 GS

Special cases
Symbolic Debug Information Page 80 of 89

31 IP
32 FLAGS
33 EIP
34 EFLAGS

PCODE Registers

40 TEMP
41 TEMPH
42 QUOTE
43-47 Reserved

System Registers

80 CR0
81 CR1
82 CR2
83 CR3
90 DR0
91 DR1
92 DR2
93 DR3
94 DR4
95 DR5
96 DR6
97 DR7

Register extensions for 80x87

128 ST(0)
130 ST(2)
131 ST(3)
132 ST(4)
133 ST(5)
134 ST(6)
135 ST(7)
136 CONTROL
137 STATUS
138 TAG
139 FPIP
140 FPCS
141 FPDO
142 FPDS
143 ISEM
144 FPEIP
145 FPEDO

Motorola 68000 Architectures

0 Data register 0
1 Data register 1
2 Data register 2
3 Data register 3
4 Data register 4
Symbolic Debug Information Page 81 of 89

5 Data register 5
6 Data register 6
7 Data register 7
8 Address register 0
9 Address register 1
10 Address register 2
11 Address register 3
12 Address register 4
13 Address register 5
14 Address register 6
15 Address register 7
16 CV_R68_CCR
17 CV_R68_SR
18 CV_R68_USP
19 CV_R68_MSP
20 CV_R68_SFC
21 CV_R68_DFC
22 CV_R68_CACR
23 CV_R68_VBR
24 CV_R68_CAAR
25 CV_R68_ISP
26 CV_R68_PC
27 reserved
28 CV_R68_FPCR
29 CV_R68_FPSR
30 CV_R68_FPIAR
31 reserved
32 Floating point 0
33 Floating point 1
34 Floating point 2
35 Floating point 3
36 Floating point 4
37 Floating point 5
38 Floating point 6
39 Floating point 7
40 reserved
41 CV_R68_MMUSR030
42 CV_R68_MMUSR
43 CV_R68_URP
44 CV_R68_DTT0
45 CV_R68_DTT1
46 CV_R68_ITT0
47 CV_R68_ITT1
48 - 50 reserved
51 CV_R68_PSR
52 CV_R68_PCSR
53 CV_R68_VAL
54 CV_R68_CRP
55 CV_R68_SR[
56 CV_R68_DR[
57 CV_R68_TC
58 CV_R68_AC
59 CV_R68_SCC
60 CV_R68_CAL
61 CV_R68_TT0
Symbolic Debug Information Page 82 of 89

62 CV_R68_TT1
63 reserved
64 CV_R68_BAD0
65 CV_R68_BAD1
66 CV_R68_BAD2
67 CV_R68_BAD3
68 CV_R68_BAD4
69 CV_R68_BAD5
70 CV_R68_BAD6
71 CV_R68_BAD7
72 CV_R68_BAC0
73 CV_R68_BAC1
74 CV_R68_BAC2
75 CV_R68_BAC3
76 CV_R68_BAC4
77 CV_R68_BAC5
78 CV_R68_BAC6
79 CV_R68_BAC7

MIPS Architectures
Integer Register

0 NoRegister
10 IntZero
11 IntAT
12 IntV0
13 IntV1
14 IntA0
15 IntA1
16 IntA2
17 IntA3
18 IntT0
19 IntT1
20 IntT2
21 IntT3
22 IntT4
23 IntT5
24 IntT6
25 IntT7
26 IntS0
27 IntS1
28 IntS2
29 IntS3
30 IntS4
31 IntS5
32 IntS6
33 IntS7
34 IntT8
35 IntT9
36 Int KT0
37 IntKT1
38 IntGP
39 IntSP
Symbolic Debug Information Page 83 of 89

40 IntS8
41 IntRA
42 Int Lo
43 Int Hi

50 Fir
51 PSR

60 floating point register 0

61 floating point register 1
62 floating point register 2
63 floating point register 3
64 floating point register 4
65 floating point register 5
66 floating point register 6
67 floating point register 7
68 floating point register 8
69 floating point register 9
70 floating point register 10
71 floating point register 11
72 floating point register 12
73 floating point register 13
74 floating point register 14
75 floating point register 15
76 floating point register 16
77 floating point register 17
78 floating point register 18
79 floating point register 19
80 floating point register 20
81 floating point register 21
82 floating point register 22
83 floating point register 23
84 floating point register 24
85 floating point register 25
86 floating point register 26
87 floating point register 27
88 floating point register 28
89 floating point register 29
90 floating point register 30
91 floating point register 31

92 Floating point status register

Alpha Axp Architecture

0 CV_ALPHA_NOREG

10 CV_ALPHA_FltF0
11 CV_ALPHA_FltF1
12 CV_ALPHA_FltF2
13 CV_ALPHA_FltF3
14 CV_ALPHA_FltF4
15 CV_ALPHA_FltF5
16 CV_ALPHA_FltF6
Symbolic Debug Information Page 84 of 89

17 CV_ALPHA_FltF7
18 CV_ALPHA_FltF8
19 CV_ALPHA_FltF9
20 CV_ALPHA_FltF10
21 CV_ALPHA_FltF11
22 CV_ALPHA_FltF12
23 CV_ALPHA_FltF13
24 CV_ALPHA_FltF14
25 CV_ALPHA_FltF15
26 CV_ALPHA_FltF16
27 CV_ALPHA_FltF17
28 CV_ALPHA_FltF18
29 CV_ALPHA_FltF19
30 CV_ALPHA_FltF20
31 CV_ALPHA_FltF21
32 CV_ALPHA_FltF22
33 CV_ALPHA_FltF23
34 CV_ALPHA_FltF24
35 CV_ALPHA_FltF25
36 CV_ALPHA_FltF26
37 CV_ALPHA_FltF27
38 CV_ALPHA_FltF28
39 CV_ALPHA_FltF29
40 CV_ALPHA_FltF30
41 CV_ALPHA_FltF31

42 CV_ALPHA_IntV0
43 CV_ALPHA_IntT0
44 CV_ALPHA_IntT1
45 CV_ALPHA_IntT2
46 CV_ALPHA_IntT3
47 CV_ALPHA_IntT4
48 CV_ALPHA_IntT5
49 CV_ALPHA_IntT6
50 CV_ALPHA_IntT7
51 CV_ALPHA_IntS0
52 CV_ALPHA_IntS1
53 CV_ALPHA_IntS2
54 CV_ALPHA_IntS3
55 CV_ALPHA_IntS4
56 CV_ALPHA_IntS5
57 CV_ALPHA_IntFP
58 CV_ALPHA_IntA0
59 CV_ALPHA_IntA1
60 CV_ALPHA_IntA2
61 CV_ALPHA_IntA3
62 CV_ALPHA_IntA4
63 CV_ALPHA_IntA5
64 CV_ALPHA_IntT8
65 CV_ALPHA_IntT9
66 CV_ALPHA_IntT10
67 CV_ALPHA_IntT11
68 CV_ALPHA_IntRA
69 CV_ALPHA_IntT12
70 CV_ALPHA_IntAT
Symbolic Debug Information Page 85 of 89

71 CV_ALPHA_IntGP
72 CV_ALPHA_IntSP
73 CV_ALPHA_IntZERO

74 CV_ALPHA_Fpcr
75 CV_ALPHA_Fir
76 CV_ALPHA_Psr
77 CV_ALPHA_FltFsr
78 CV_ALPHA_SoftFpcr

Motorola/IBM PowerPC Architecture

PowerPC General Registers ( User Level )

1 CV_PPC_GPR0
2 CV_PPC_GPR1
3 CV_PPC_GPR2
4 CV_PPC_GPR3
5 CV_PPC_GPR4
6 CV_PPC_GPR5
7 CV_PPC_GPR6
8 CV_PPC_GPR7
9 CV_PPC_GPR8
10 CV_PPC_GPR9
11 CV_PPC_GPR10
12 CV_PPC_GPR11
13 CV_PPC_GPR12
14 CV_PPC_GPR13
15 CV_PPC_GPR14
16 CV_PPC_GPR15
17 CV_PPC_GPR16
18 CV_PPC_GPR17
19 CV_PPC_GPR18
20 CV_PPC_GPR19
21 CV_PPC_GPR20
22 CV_PPC_GPR21
23 CV_PPC_GPR22
24 CV_PPC_GPR23
25 CV_PPC_GPR24
26 CV_PPC_GPR25
27 CV_PPC_GPR26
28 CV_PPC_GPR27
29 CV_PPC_GPR28
30 CV_PPC_GPR29
31 CV_PPC_GPR30
32 CV_PPC_GPR31

PowerPC Condition Register ( User Level )

33 CV_PPC_CR
34 CV_PPC_CR0
35 CV_PPC_CR1
36 CV_PPC_CR2
37 CV_PPC_CR3
Symbolic Debug Information Page 86 of 89

38 CV_PPC_CR4
39 CV_PPC_CR5
40 CV_PPC_CR6
41 CV_PPC_CR7

PowerPC Floating Point Registers ( User Level )

42 CV_PPC_FPR0
43 CV_PPC_FPR1
44 CV_PPC_FPR2
45 CV_PPC_FPR3
46 CV_PPC_FPR4
47 CV_PPC_FPR5
48 CV_PPC_FPR6
49 CV_PPC_FPR7
50 CV_PPC_FPR8
51 CV_PPC_FPR9
52 CV_PPC_FPR10
53 CV_PPC_FPR11
54 CV_PPC_FPR12
55 CV_PPC_FPR13
56 CV_PPC_FPR14
57 CV_PPC_FPR15
58 CV_PPC_FPR16
59 CV_PPC_FPR17
60 CV_PPC_FPR18
61 CV_PPC_FPR19
62 CV_PPC_FPR20
63 CV_PPC_FPR21
64 CV_PPC_FPR22
65 CV_PPC_FPR23
66 CV_PPC_FPR24
67 CV_PPC_FPR25
68 CV_PPC_FPR26
69 CV_PPC_FPR27
70 CV_PPC_FPR28
71 CV_PPC_FPR29
72 CV_PPC_FPR30
73 CV_PPC_FPR31

PowerPC Floating Point Status and Control Register ( User Level )

74 CV_PPC_FPSCR

PowerPC Machine State Register ( Supervisor Level )

75 CV_PPC_MSR

PowerPC Segment Registers ( Supervisor Level )

76 CV_PPC_SR0
77 CV_PPC_SR1
78 CV_PPC_SR2
79 CV_PPC_SR3
80 CV_PPC_SR4
Symbolic Debug Information Page 87 of 89

81 CV_PPC_SR5
82 CV_PPC_SR6
83 CV_PPC_SR7
84 CV_PPC_SR8
85 CV_PPC_SR9
86 CV_PPC_SR10
87 CV_PPC_SR11
88 CV_PPC_SR12
89 CV_PPC_SR13
90 CV_PPC_SR14
91 CV_PPC_SR15

For all of the special purpose registers add 100 to the SPR# that the
Motorola/IBM documentation gives with the exception of any imaginary
registers.

PowerPC Special Purpose Registers ( User Level )

99 CV_PPC_PC (imaginary register)

100 CV_PPC_MQ (MPC601)
101 CV_PPC_XER
104 CV_PPC_RTCU (MPC601)
105 CV_PPC_RTCL (MPC601)
108 CV_PPC_LR
109 CV_PPC_CTR

110 CV_PPC_COMPARE (part of XER, internal to debugger only)

111 CV_PPC_COUNT (part of XER, internal to debugger only)

PowerPC Special Purpose Registers ( Supervisor Level )

118 CV_PPC_DSISR
119 CV_PPC_DAR
122 CV_PPC_DEC
125 CV_PPC_SDR1
126 CV_PPC_SRR0
127 CV_PPC_SRR1
372 CV_PPC_SPRG0
373 CV_PPC_SPRG1
374 CV_PPC_SPRG2
375 CV_PPC_SPRG3
280 CV_PPC_ASR (64bit implementations only)
382 CV_PPC_EAR
287 CV_PPC_PVR
628 CV_PPC_BAT0U
629 CV_PPC_BAT0L
630 CV_PPC_BAT1U
631 CV_PPC_BAT1L
632 CV_PPC_BAT2U
633 CV_PPC_BAT2L
634 CV_PPC_BAT3U
635 CV_PPC_BAT3L
636 CV_PPC_DBAT0U
637 CV_PPC_DBAT0L
638 CV_PPC_DBAT1U
Symbolic Debug Information Page 88 of 89

639 CV_PPC_DBAT1L
640 CV_PPC_DBAT2U
641 CV_PPC_DBAT2L
642 CV_PPC_DBAT3U
643 CV_PPC_DBAT3L

PowerPC Special Purpose Registers Implementation Dependent ( Supervisor Level )

Doesn't appear that IBM/Motorola has finished defining these.

1044 CV_PPC_PMR0 (MPC620)

1045 CV_PPC_PMR1 (MPC620)
1046 CV_PPC_PMR2 (MPC620)
1047 CV_PPC_PMR3 (MPC620)
1048 CV_PPC_PMR4 (MPC620)
1049 CV_PPC_PMR5 (MPC620)
1050 CV_PPC_PMR6 (MPC620)
1051 CV_PPC_PMR7 (MPC620)
1052 CV_PPC_PMR8 (MPC620)
1053 CV_PPC_PMR9 (MPC620)
1054 CV_PPC_PMR10 (MPC620)
1055 CV_PPC_PMR11 (MPC620)
1056 CV_PPC_PMR12 (MPC620)
1057 CV_PPC_PMR13 (MPC620)
1058 CV_PPC_PMR14 (MPC620)
1059 CV_PPC_PMR15 (MPC620)

1076 CV_PPC_DMISS (MPC603)

1077 CV_PPC_DCMP (MPC603)
1078 CV_PPC_HASH1 (MPC603)
1079 CV_PPC_HASH2 (MPC603)
1080 CV_PPC_IMISS (MPC603)
1081 CV_PPC_ICMP (MPC603)
1082 CV_PPC_RPA (MPC603)

1108 CV_PPC_HID0 (MPC601, MPC603, MPC620)

1109 CV_PPC_HID1 (MPC601)
1110 CV_PPC_HID2 (MPC601, MPC603, MPC620) (IABR)
1111 CV_PPC_HID3 (Not Defined)
1112 CV_PPC_HID4 (Not Defined)
1113 CV_PPC_HID5 (MPC601, MPC603, MPC620) (DABR)
1114 CV_PPC_HID6 (Not Defined)
1115 CV_PPC_HID7 (Not Defined)
1116 CV_PPC_HID8 (MPC620) (BUSCSR)
1117 CV_PPC_HID9 (MPC620) (L2CSR)
1118 CV_PPC_HID10 (Not Defined)
1119 CV_PPC_HID11 (Not Defined)
1120 CV_PPC_HID12 (Not Defined)
1121 CV_PPC_HID13 (MPC604) (HCR)
1122 CV_PPC_HID14 (Not Defined)

Symbol and Type Format for Microsoft Executables

Appendix A. Revision History

Symbolic Debug Information Page 89 of 89

11/3/92 stewk incorporated langapi changes (including

jimsch's on MIPS)

10/92 stewk cloned langapi omfdeb version

12/92 a-rossg general revision for accuracy

12/01/95 dans add new type records, member attrs

03/05/96 dans fix LF_ONEMETHOD error re

introducing virtual functions and their
offsets.

9/4/96 dans 32-bit type indices, 32-bit only