SubSection Types (sst...)

All values not defined are reserved for future use.

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


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.

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.

(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.

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

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

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


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.

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.

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 * cRangeLog

2 * cRangeOff

4

cRangeLog

rgoffLog

rgbiasLog

crangePhys

->


2 * crangePhys

2 * 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 */

(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 * cRangeLog

4 * cRangeOff

4

cRangeLog

rgoffLog

rgbiasLog

crangePhys

->


2 * crangePhys

4 * 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.

2

2

2 * cMod

2 * cModules

4 * cRef

*

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.