Alan Boxall
Alan Boxall
Date of Issue: December 15,1995
32-bit Object Module Format General Requirements
Appendix A. LX Format Debug Section Description
Synopsis:
Abstract
This document describes the format of the debug information generated by the compiler and used by the debugger to allow source level debugging.
| Notice |
|---|
|
The official version of this document is kept in the file HLLDBG LIST3820 on the DOC LEXTRAN disk. To obtain a copy of this official version, contact the owner. Other formats available are:
Users of this document are personally responsible for using the official version and for verifying that any copies of the document, in whole or in part, are of the official version. If this document is not a copy of the official version, it is obsolete. |
The HLL Debug Tables described in this this document are generated by the following compilers:
The following debuggers from IBM make use of the HLL Debug Tables.
The tables are designed to support multiple languages. however, only the compilers listed above are currently supported by the IBM VisualAge Debugger. References to other languages, including PL/X(1), are general in nature and imply no specific product plans.
Additional copies of this document, if required, should be requested from the author, whose address is on the title page.
IBM reserves the right to change the HLL Debug Tables as required to support the IBM languages Tools products.
The HLL Debug Tables are organized into three segments:
The record formats described in the remainder of this document are read from the EXE and DLL executable files generated by the Linker. The Linker program copies the records from the compiler generated object files without modification, except for FIXUPPs, and saves the "HLL Style" information in the Debug section directory (see Appendix A. "LX Format Debug Section Description"). The PM Debugger reads the information, as required during a debug session, after the executables have been loaded.
The remainder of this document first discusses the information IBM VisualAge Debugger expects in the standard 32-bit Object Module Format records, then the format of the debugger specific records.
The 32-bit Object Module Format (OMF-32) defines the records contained in the OBJ file, the primary output of the HLL compilers and primary source of debug information (after Linker processing) for PMD.
The OBJ file contains all
of the information required by PMD to allow a user
to debug a HLL program at the source code and/or listing level.
The OMF-32 record types required by the debugger listed in
Figure 1..
Figure 1. Debugger Required OMF-32 Record Types
| Record
Type | Record
Name |
Information |
|---|---|---|
| 91 | PUBDEF | type information. |
| 8C | EXTDEF | type information. |
| B0 | COMDEF | type information. |
| 88 | COMENT | debug style information. |
| 96 | LNAMES | debug segment names. |
| 99 | SEGDEF | debug segment definitions. |
| A0, A1 | LEDATA | $$SYMBOLS and $$TYPES segments. |
| 9D | FIXUPP | must be present for symbols and types LEDATA records. |
| 95 | LINNUM | line number / offset table. |
The $$SYMBOLS, $$TYPES, and LINNUM records are defined in "Symbol Scope Table", "Type Table", and "Line Number Table", respectively. PMD dependencies on the other record types are described in the sections that follow.
Standard PUBDEF and EXTDEF records for public variables are expected. The TypInd (Type Index) field is assumed null for all records. It is not used by PM Debugger.
The PUBDEF and EXTDEF records contain all the external symbols defined or referenced in the user program. EXTDEF records are for unresolved references.
Standard COMDEF records are allowed for communal variables. The TypInd field is the same as that for PUBDEF/EXTDEF records.
The names in the PUBDEF/EXTDEF/COMDEF records may be mangled names if a C++ program has been compiled; therefore, must be "interpreted" using a compiler supplied demangler routine. If the "full" mangled name exceeds the space available in a record, only the class and function name can be derived from the mangled name. Argument information may be incomplete.
A COMENT record with Comment Class x'A1' (Symbolic Debug Information) must be present in the OBJ with the following commentary byte string:
where the first byte is the binary version number; the second and third bytes are the ASCII codes for the characters 'H' and 'L'. 1 was the orginal version. Version 2 is an interim version number, used only for early alloc_text pragma support. Starting with version 3, the version number in this record will match the version number in the document title.
A COMENT record with Comment Class x'A2' (Link Pass) must be present with subclass value of 1, as documented in the OMF-32 definition.
Note: This record is optional, but improves linkage editor performance.
A standard LNAMES record must be in the OBJ. It should include LNAMES for:
Standard SEGDEF records must be present for both the symbols segment and the types segment.
The record order is chosen so that linkage editor passes through an object module are minimized. The following order must be maintained for proper passing of the debug information to the executable module.
Identifier record(s)
Link Pass one records
Link pass separator
Link pass two records
Terminator
The Symbol Scope Table contains the symbolic information required by the debugger to display and alter a program's "local" variables. The Symbol Scope Table (SST) contains the local (automatic or stack) variables and non-public static variables for a program, including the scoping information for those variables. Public variables are contained in the PUBDEF, COMDEF, or EXTDEF records. They are assumed to have a "program-wide" scope.
The $$SYMBOLS (DEBSYM) records are built by each HLL compiler to communicate the Symbol Scope Table to PM Debugger via the Linker. These records are stored in the OBJ file by the compilers when the compilers' debug option is specified by the user. The Linker copies the records to the Debug section of the EXE file for reference by PMD while the program is being debugged by the user. The $$SYMBOLS records are stored in the OBJ as LEDATA records, whose format is described in the OMF-32(2) Definition, with a segment index pointing to the SEGDEF record for $$SYMBOLS (SegName = '$$SYMBOLS'; ClassName = 'DEBSYM').
Each LEDATA record can contain no more than 1024 bytes, including a checksum byte. It is recommended that records be ended at "logical" boundaries between sub-records. The Linker will copy the records to the .EXE file in the order stored in the OBJ file. PMD will read the records in the order stored in the .EXE file, concatenating each record to the previous to make a contiguous table in storage. The "Symbol Scope Table records" in the .EXE file are not loaded with the program when the program is started by OS/2.
Note: All "offsets" must have a companion FIXUPP record immediately following the containing LEDATA record. See the OMF-32 Definition for details. Typically, sub-record types Proc and Static contain segment offsets.
Figure 2. Symbol Scope Table Record Format
+---------------------------------------+
| LEDATA Header |
| |
+---------------------------------------+
| |
| Symbol Table Sub-Records |
| |
| |
| |
| |
| |
| |
+---------+-----------------------------+
| Check |
| Sum |
+---------+
The Symbol Scope Table is a collection of sub-records organized to provide a representation of the program in the OBJ file containing this Symbol Scope Table, as shown in Figure 2.. See the OMF-32 Definition for a description of the LEDATA Header. The order of the individual sub-records is important. PMD determines the scope of automatic and non-public static variables based on the order of the sub-records. See Figure 4. for a "typical" Symbol Scope Table organization. A Compile Unit Information record must be the first sub-record. A Change Default Segment sub-record must precede the first Procedure sub-record.
The Symbol Scope Table is designed to support complete debugging of nested blocks. The Symbol Scope Table Sub-Records are designed to support the scoping rules of C and PL/I.
Note: It is assumed here that other HLL compiler scoping rules are similar and can be represented within the structure described here.
The format of the Symbol Scope Table Sub-Record is shown in Figure 3.. The "Type" field identifies the type of sub-record. Each sub-record has a unique format as described in Figure 5. through Figure 28.. Each sub-record is length-prefixed with an encoded-length of one or two bytes, with the length (Len) field containing the number of bytes in the sub-record (excluding the length field byte(s)). PMD interprets the encoded-length as follows:
FirstByte = *(LenFldPtr++);
if (FirstByte & 0x80)
{
SecondByte = *LenFldPtr;
Length = ((FirstByte & 0x7F) << 8) + SecondByte;
}
else
{
Length = FirstByte;
}
Figure 3. Symbol Scope Table Sub-Record -- General Format
+----+----+-------------------------------------------------+
| Len|Type| Sub-Record Specific Data |
| | | |
+----+----+-------------------------------------------------+
0 1 2
or 2 3
The supported sub-record types (hex values) are:
Figure 4. Symbol Scope Table Sub-Record -- Typical Organization for C
-- C example -- -- Symbol Scope Subrecords --
CuInfo (Compile Unit Information)
ChangSeg (Change Default Segment)
1
2 int A; Static (A)
3 main (void) Proc (main)
4
5 { Begin (Block0)
6 int A,X; Auto (A)
7 } Auto (X)
8 End (Block0)
9 End (Proc_main)
10
11 static int X; Static (X)
12
13 P1 (int B, int X) Proc (P1)
14 Auto (B)
15 Auto (X)
16 { Begin (Block0)
17 static int D; Static (D)
18 { Begin (Block1)
19 int B; Auto (B)
20 } End (Block1)
21 } End (Block0)
22 End (Proc_P1)
23
24 static int E; Static (E)
25
26 P2 (void) Proc (P2)
27
28 { Begin (Block0)
29 Auto (A)
30 int A; End (Block0)
31 } End (proc_P2)
CuInfo (Compile Unit Information)
Note:
Along with main, P1 and p2, A in line 2 will also be shown as Public
symbol in PUBDEF.
|
Figure 5. Symbol Scope Table Sub-Record -- Begin
+----+----+-------------------+-------------------+
| Len|Type| segment offset | Length of block |
| | | | |
+----+----+-------------------+-------------------+
0 1 2 6 A
or 2 3 7 B
.-+----+------------------------+
|Len | Name of Block |
|Name| |
.-+----+------------------------+
A B
or B C
Figure 6. Symbol Scope Table Sub-Record -- Procedure, Entry, Member Function
+----+----+-------------------+---------+-------------------+-
| Len|Type| segment offset | Type | Length of Proc |
| | | | Index | |
+----+----+-------------------+---------+-------------------+-
0 1 2 6 8 C
or 2 3 7 9 D
.-+---------+-------------------+---------+----+-
|Length of| Length of prologue| Class |Near|
| Prologue| plus Body | Type |/Far|
.-+---------+-------------------+---------+----+-
C E 12 14 15
D F 13 15 16
.-+----+------------------------+
|Len | Name of Procedure |
|Name| |
.-+----+------------------------+
15 16
16 17 or 18
Figure 7. Symbol Scope Table Sub-Record -- End
+----+----+
| Len|Type|
| | |
+----+----+
0 1 2
or 2 3
Figure 8. Symbol Scope Table Sub-Record -- Auto
+----+----+-------------------+---------+----+-------------------+
| Len|Type| Offset Into Stack | Type |Len | Symbol Name |
| | | Frame | Index |Name| |
+----+----+-------------------+---------+----+-------------------+
0 1 2 6 8 9
or 2 3 7 9 A
Figure 9. Symbol Scope Table Sub-Record -- Static
+----+----+-------------------+---------+---------+----+-------------------+
| Len|Type| Segment offset | Segment | Type |Len | Symbol Name |
| | | | Address| Index |Name| |
+----+----+-------------------+---------+---------+----+-------------------+
0 1 2 6 8 A B
or 2 3 7 9 B C or D
Figure 10. Symbol Scope Table Sub-Record -- TLS
+----+----+-------------------+---------+---------+----+-------------------+
| Len|Type| Offset into thread| reserved| Type |Len | Symbol Name |
| | | local storage | | Index |Name| |
+----+----+-------------------+---------+---------+----+-------------------+
0 1 2 6 8 A B
or 2 3 7 9 B C or D
Figure 11. Symbol Scope Table Sub-Record -- CodeLabel
+----+----+-------------------+----+----+-------------------+
| Len|Type| Segment offset |Near|Len | Symbol Name |
| | | |/Far|Name| |
+----+----+-------------------+----+----+-------------------+
0 1 2 6 7 8
or 2 3 7 8 9
Figure 12. Symbol Scope Table Sub-Record -- Reg
+----+----+---------+----+----+-------------------+
| Len|Type| Type | Reg|Len | Symbol Name |
| | | Index | No.|Name| |
+----+----+---------+----+----+-------------------+
0 1 2 4 5 6
or 2 3 5 6 7
8-bit registers
16-bit registers
32-bit registers
Segment registers
Special cases
Register extensions for 8087/287/387
Figure 13. Symbol Scope Table Sub-Record -- RegRelative
+----+----+--------+------------+--------+-.
|Len |Type|Register|Offset from | Type | ...
| | | Number | Register | Index |
+----+----+--------+------------+--------+-.
0 1 2 4 8 A
or 2 3 5 9 B
.-+----+------------------------+
|Len | Name of Symbol |
|Name| |
.-+----+------------------------+
A B
or B C
Figure 14. Symbol Scope Table Sub-Record -- Constant
+----+----+---------+------+------------+----+-------------------+
| Len|Type| Type |Len | Value |Len | Symbol Name |
| | | Index |Value | |Name| |
+----+----+---------+------+------------+----+-------------------+
0 1 2 4 5 5 6 + Len Value
or 2 3 5 6 6 7 + Len Value
+
Len Value
To be supplied in a future draft, if required.
To be supplied in a future release, if required.
Figure 15. Symbol Scope Table Sub-Record -- ChangSeg
+----+----+---------+---------+
| Len|Type| Segment | Reserved|
| | | Number | |
+----+----+---------+---------+
0 1 2 4
or 2 3 5
Figure 16. Symbol Scope Table Sub-Record -- Typedef
+----+----+---------+----+-------------------+
| Len|Type| Type |Len | Symbol Name |
| | | Index |Name| |
+----+----+---------+----+-------------------+
0 1 2 4 5
or 2 3 5 6
Figure 17. Symbol Scope Table Sub-Record -- Public
+----+----+-------------------+---------+---------+----+-------------------+
| Len|Type| Segment offset | Segment | Type |Len | Symbol Name |
| | | | Address| Index |Name| |
+----+----+-------------------+---------+---------+----+-------------------+
0 1 2 6 8 A B
or 2 3 7 9 B C
This sub-record is required for languages that support direct symbolic references to "minor" (nested) structures and/or "elements" (members) of a structure. In addition, RPG will use this sub-record for the above constructs. The sub-record is used as a "target" for Member or Table sub-records. PMD uses the Public sub-record as a substitute PUBDEF record to obtain location and type information.
Figure 18. Symbol Scope Table Sub-Record -- Member
+----+----+-------------------+----+-----------------+
| Len|Type| Offset to |Len | Symbol Name |
| | | Subrecord |Name| |
+----+----+-------------------+----+-----------------+
0 1 2 6 7
or 2 3 7 8
Note: A Member sub-record will be the "target" of another Member sub-record if "minor" structures containing elements exist within a "major" structure." Only one Public/Static/Automatic sub-record will exist for each "major" structure"
Figure 19. Symbol Scope Table Sub-Record -- Based
+----+----+-------------------+---------+----+-----------+
| Len|Type| Offset to |Type |Len | Name |
| | | Subrecord | Index |Name| |
+----+----+-------------------+---------+----+-----------+
0 1 2 6 8 9
or 2 3 7 9 A
Figure 20. Symbol Scope Table Sub-Record -- Based with Member
+----+----+-------------------+---------+-------------------+----+-----------“
| Len|Type| Offset to |Type | Offset from |Len | Name |
| | | Subrecord | Index | Base |Name| |
+----+----+-------------------+---------+-------------------+----+-----------•
0 1 2 6 8 C D
or 2 3 7 9 D E
Figure 21. Symbol Scope Table Sub-Record -- Array Symbol Record
+----+----+---------+-------------------+
| Len|Type|Type | Offset to symbol |
| | | Index | of ODO object |
+----+----+---------+-------------------+
0 1 2 4 8
or 2 3 5 9
Figure 22. Symbol Scope Table Sub-Record -- Tag
+----+----+---------+----+-----------+
| Len|Type| Type |Len | Name |
| | | Index |Name| |
+----+----+---------+----+-----------+
0 1 2 4 5
or 2 3 5 6
Figure 23. Symbol Scope Table Sub-Record -- Map
+----+----+--------+--------+-------+-----------+
| Len|Type| Len (1)|Name |Len (2)|External |
| | | Name | |Name |Known Name |
+----+----+--------+--------+-------+-----------+
0 1 2 3 3 + 4 +
or 2 3 4 4 + 5 +
Len(1) Len(1)
Figure 24. Symbol Scope Table Sub-Record -- Table
+----+----+-------------+---------+---------+-------------+----+--------------+
| Len|Type| Segment | Segment | Type |Index Offset |Len | Symbol Name |
| | | offset | Address| Index |to subrecord |Name| |
+----+----+-------------+---------+---------+-------------+----+--------------+
0 1 2 6 8 A E F
or 2 3 7 9 B F 10
Note: These two constructs are similiar to arrays except the index to the table is maintained internally in storage; therefore, must be referenced by a separate Public/Static sub-record.
Figure 25. Symbol Scope Table Sub-Record -- CuInfo
+----+----+----+----+-------------------+---------------------------------------+-
| Len|Type|Comp|Len | Compiler Options | Compiler Data |
| | | ID |Opts| | |
+----+----+----+----+-------------------+---------------------------------------+-
0 1 2 3 4 8 10
or 2 3 4 5 9 11
+---------------------------------------+
| Timestamp |
| |
+---------------------------------------+
10 18
or 11 19
Note: Not used by PMD
Figure 26. Symbol Scope Table Sub-Record -- Tag2
+----+----+----------+----+---------------+
|Len |Type| Type |Len | Name |
| | | Index |Name| |
+----+----+----------+----+---------------+
0 1 2 4 5
or 2 3 5 6 or 7
Figure 27. Symbol Scope Table Sub-Record -- AutoScoped
+----+----+-------------+-----------+-----------+-.
|Len |Type|Offset into |Source File|Source File| ...
| | |Stack Frame | Index |Line No. |
+----+----+-------------+-----------+-----------+-.
0 1 2 6 8 C
or 2 3 7 9 D
.-+---------+----+------------------------+
| Type |Len | Name of Symbol |
| Index |Name| |
.-+---------+----+------------------------+
D F 10
or E 10 11
Figure 28. Symbol Scope Table Sub-Record -- StaticScoped
+----+----+-------+---------+----------+-----------+-.
|Len |Type|Segment|Segment |Source |Source File| ...
| | |Offset |Address |File Index| Line No. |
+----+----+-------+---------+----------+-----------+-.
0 1 2 6 8 A E
or 2 3 7 9 B F
.-+---------+----+------------------------+
| Type |Len | Name of Symbol |
| Index |Name| |
.-+---------+----+------------------------+
E 10 11
or F 11 12
The Type Table contains all the invariant information required to describe complex ("non-primitive") variables. A Type Table Entry (or sub-record) is built for every unique complex variable type in the user program (Type Table Entries may be reused for more than one variable if the variables' attributes are exactly alike). The entries may be generated as the symbol information is added to the various OMF records (see "Symbol Scope Table"). No specific order is assumed by PMD. The data is always located using the type index contained in the PUBDEF, EXTDEF, COMDEF, $$SYMBOLS or $$TYPES records, as defined in "Type Index Formats".
The $$TYPES (DEBTYP) records are used by each HLL compiler to communicate the Type Table information to PM Debugger, via the Linker. These records are stored in the OBJ file by the compilers when the compilers' debug option is specified by the user. The Linker copies the records to the Debug section of the EXE file for reference by PMD while the program is being debugged by the user. The $$TYPES records are stored in the OBJ as LEDATA records, whose format is described in the OMF-32 Definition, with a segment index pointing to the SEGDEF record for $$TYPES (SegName = '$$TYPES'; ClassName = 'DEBTYP').
Each LEDATA record can contain no more than 1024 bytes, including a checksum byte. It is recommended that records be ended at "logical" boundaries within the definition of the data below. The Linker will copy the records to the .EXE file in the order stored in the OBJ file. PMD will read the records in the order stored in the .EXE file, concatenating each record to the previous to make a contiguous table in storage. The "type table records" in the .EXE file are not loaded with the program when the program is started by OS/2.
Note: All "offsets" must have a companion FIXUPP record immediately following the containing LEDATA record. See the OMF-32 Definition for details.
Figure 29. Type Table Record Format
+---------------------------------------+
| LEDATA Header |
| |
+---------------------------------------+
| Type Table Entries (or Sub-Records) |
| |
| |
| |
| |
| |
| |
+---------+-----------------------------+
| Check |
| Sum |
+---------+
An overview of a Type Table Record is shown in Figure 29.. See the OMF-32 Definition for a description of the LEDATA Header. Each Type Table Entry consists of one or more sub-records, as shown in Figure 30.. The length of the sub-record is a two byte value containing only the number of data bytes. This number does not include the two bytes for the length field.
Note: The first byte in the subrecord, set to be 01 for linkable in Version 1, has been removed.
The Sub-Record Specific Data consists of fixed format information followed by varying length individual data items identified by a one byte Field IDentifier (FID) preceding the data. The data may also be a type index to another sub-record for a Type Table Entry.
Figure 30. Type Table Entry Sub-Record -- General Format
+-----------+----+----+-----------------------------+
| Length of |Type|Type| Sub-Record Specific Data |
| Sub-Record| |Qual| |
+-----------+----+----+-----------------------------+
0 2 3 4
Figure 31. illustrates the the Sub-Record Specific Data, including the Type and Type Qualifier fields, in the same format the Type data is defined in "Type Table Entry Definitions".
Figure 31. Type Table Entry Sub-Record -- Specific Data Format
1 1 varying 1 varying 1 varying bytes
+----+----+----//---+----+-------------------+-//-+----+-------------------+
|Type|Type|Fixed Fmt| FID| Data identified | | FID| Data identified |
| |Qual| Data | | by FID | | | by FID |
+----+----+----//---+----+-------------------+-//-+----+-------------------+
<--------------------- Repeated --------------------->
The unique type table entries for each variable type are defined in "Type Table Entry Definitions". The values for the Type are defined in "Primitive Types Values" and "Complex Types Values".
The Type Index (TypInd) field has two formats.
PMD interprets the Type Index in these records as follows:
FirstByte = *(TypeFldPtr++);
if (FirstByte & 0x80)
{
SecondByte = *TypeFldPtr;
TypeIndex = ((FirstByte & 0x7F) << 8) + SecondByte;
}
else
{
TypeIndex = FirstByte;
}
Note: The only known case where a one byte Type Index can be stored is for a TypInd=0 in EXTDEF.
Names in type sub-records have two types of length-prefixes. Names preceded by a FID_String byte continue to have single-byte length prefixes. Names not preceded by a FID_String, noted with "ENC" in the "Field Length" column, contain an encoded-length prefix of one or two bytes, with the length field containing the number of bytes in the Name (excluding the length field byte(s)). PMD interprets the encoded-length as follows:
FirstByte = *(LenFldPtr++);
if (FirstByte & 0x80)
{
SecondByte = *LenFldPtr;
Length = ((FirstByte & 0x7F) << 8) + SecondByte;
}
else
{
Length = FirstByte;
}
A symbolic variable is considered "primitive" if the variable can be fully described by a single value (i.e., extended information contained in a Type Table Entry is not required). The Type Index for a primitive variable must have a value less than 255, decimal.
The Primitive Type values are defined below. Note: Near is defined as offset_32. Far is defined as segment_48. They are stored in the Type Index field as defined in "Type Index Formats".
DEC HEX DESCRIPTION
===== ===== ===============
128 80 8 bit signed
129 81 16 bit signed
130 82 32 bit signed
132 84 8 bit unsigned
133 85 16 bit unsigned
134 86 32 bit unsigned
136 88 32 bit real
137 89 64 bit real
138 8A 80 bit real
140 8C 64 bit complex
141 8D
128 bit complex
142 8E 160 bit complex
144 90 8 bit boolean
145 91 16 bit boolean
146 92 32 bit boolean
148 94 8 bit character
149 95 16 bit characters
150 96 32 bit characters
151 97 void
152 98 15 bit unsigned
153 99 24 bit unsigned
154 9A 31 bit unsigned
155 9B 64 bit signed (long_long)
156 9C 64 bit unsigned
160 A0 near pointer to 8 bit signed
161 A1 near pointer to 16 bit signed
162 A2 near pointer to 32 bit signed
164 A4 near pointer to 8 bit unsigned
165 A5 near pointer to 16 bit unsigned
166 A6 near pointer to 32 bit unsigned
168 A8 near pointer to 32 bit real
169 A9 near pointer to 64 bit real
170 AA near pointer to 80 bit real
172 AC near pointer to 64 bit complex
173 AD near pointer to 128 bit complex
174 AE near pointer to 160 bit complex
176 B0 near pointer to 8 bit boolean
177 B1 near pointer to 16 bit boolean
178 B2 near pointer to 32 bit boolean
180 B4 near pointer to 8 bit character
181 B5 near pointer to 16 bit character
182 B6 near pointer to 32 bit character
183 B7 near pointer to void
184 B8 near pointer to 15 bit unsigned
185 B9 near pointer to 24 bit unsigned
186 BA near pointer to 31 bit unsigned
187 BB near pointer to 64 bit signed
188 BC near pointer to 64 bit unsigned
DEC HEX DESCRIPTION
===== ===== ===============
192 C0 far pointer to 8 bit signed
193 C1 far pointer to 16 bit signed
194 C2 far pointer to 32 bit signed
196 C4 far pointer to 8 bit unsigned
197 C5 far pointer to 16 bit unsigned
198 C6 far pointer to 32 bit unsigned
200 C8 far pointer to 32 bit real
201 C9 far pointer to 64 bit real
202 CA far pointer to 80 bit real
204 CC far pointer to 64 bit complex
205 CD far pointer to 128 bit complex
206 CE far pointer to 160 bit complex
208 D0 far pointer to 8 bit boolean
209 D1 far pointer to 16 bit boolean
210 D2 far pointer to 32 bit boolean
212 D4 far pointer to 8 bit character
213 D5 far pointer to 16 bit character
214 D6 far pointer to 32 bit character
215 D7 far pointer to void
216 D8 far pointer to 15 bit unsigned
217 D9 far pointer to 24 bit unsigned
218 DA far pointer to 31 bit unsigned
219 DB far pointer to 64 bit signed
220 DC far pointer to 64 bit unsigned
If a symbolic variable is not one of the "primitive" types defined in "Primitive Types Values", it is considered a "non-primitive" or complex variable. The Type Index for a complex variable must have a value greater than 511, decimal, (starting at 512 and up), that is a dynamically (as OMF records and $$TYPES sub-records are built) generated index into the $$TYPES records to a Type Table Entry.
The complex variable type values are defined, in hex notation, below. The type qualifier values are defined in each sub-record in "Type Table Entry Definitions".
Special sub-record types
The Field ID values are used in the Type Table Sub-Records to identify the contents and number of byte(s) that follow immediately. (With the exception of FID_nil and FID_void, see note below)
The Field ID values are defined, in hex notation, as follows:
Note: The names correspond to the Type Table Entry definitions in "Type Table Entry Definitions".
Figure 32. Type Table Entry Sub-Record - Area
| Type (0x55) | Type Qual. | Field Name | Field Length (bytes) | Field Data Description |
|---|---|---|---|---|
| Area (fixed) | 0x00 |
|
|
|
|
|
| FID_span | 1 | Refer to "Field ID Values". |
|
|
| Size of area | 1, 2 or 4 | Size in bytes, field length depends on the preceding FID_span value |
| Area - adjustable | 0x02 |
|
| Descriptor is provided by PL/I. |
Bit Value Data Description
=== ===== ========================
0 0 row major
1 column major
1 0 unpacked array
1 packed array
2 0 no descriptor required
1 descriptor provided
3 0 fixed length array
1 variable length array
4-7 reserved
Figure 33. Type Table Entry Sub-Record - Array
| Type (0x78) | Type Qual. | Field Name | Field Length (bytes) | Field Data Description |
|---|---|---|---|---|
| Array | See bit map above |
|
|
|
|
|
| Size of array | 4 | Size in bytes |
|
|
| FID_index | 1 | Refer to "Field ID Values". |
|
|
| Bounds | 2 | This index identifies a sub-record containing the high and low bounds |
|
|
| FID_index | 1 | Refer to "Field ID Values". |
|
|
| Type index | 2 | Type Index of the elements in the array |
|
|
| FID_string | 1 | Refer to "Field ID Values". |
|
|
| Name | N/A | Length-prefixed Name of array. The first 1 byte determines the length of the name. |
Bit Value Data Description
=== ===== ========================
0 0 not a virtual class
1 is_virtual
1-7 reserved
Figure 34. Type Table Entry Sub-Record - Base Class
| Type (0x41) | Type Qual. | Field Name | Field Length (bytes) | Field Data Description |
|---|---|---|---|---|
| Base Class | See bit map above |
|
|
|
|
|
| Protection | 1 | 0=Private, 1=Protected, 2=Public |
|
|
| Field type | 2 | Type index of class record |
|
|
| FID_span | 1 | Refer to "Field ID Values" |
|
|
| Offset | 1, 2 or 4 | The field's offset in bytes from the start of class(field length determined by preceding FID_span) |
Bit Value Data Description
=== ===== ========================
0 0 non-varying
1 varying
1 0 unsigned
1 signed
2 0 byte alignment
1 word alignment
3 0 display as string of 0 and 1
1 display as a value
4 0 no descriptor required
1 descriptor provided
5-7 reserved
Figure 35. Type Table Entry Sub-Record - Bit string
| Type (0x5C) | Type Qual. | Field Name | Field Length (bytes) | Field Data Description |
|---|---|---|---|---|
| Bit String - fixed | See bit map above |
|
|
|
|
|
| Offset | 1 | Starting position (from bit 0) of the string in a byte or word depends on bit 2 in type qualifier |
|
|
| FID_span | 1 | Refer to "Field ID Values". |
|
|
| Size of the bit string | 1, 2 or 4 | Size in bits, field length determined by preceding FID_span |
| Bit String - varying | See bit map above |
|
|
|
|
|
| Offset | 1 | Starting position (from bit 0) of the string in a byte or word depends on bit 2 in type qualifier |
|
|
| FID_span | 1 | Refer to "Field ID Values". |
|
|
| Max allowable size of the bit string | 1, 2 or 4 | Size in bits, field length determined by preceding FID_span |
| Bit String - adjustable | See bit map above |
|
| Descriptor provided by PL/I. |
Figure 36. Type Table Entry Sub-Record - Character String
| Type (0x60) | Type Qual. | Field Name | Field Length (bytes) | Field Data Description |
|---|---|---|---|---|
| Character string (fixed) | 0x00 |
|
|
|
|
|
| FID_span | 1 | Refer to "Field ID Values". |
|
|
| Size of string | 1, 2 or 4 | Size in bytes, field length depends on the preceding FID_span value |
| Character string - varying (length prefixed) | 0x01 |
|
|
|
|
|
| FID_span | 1 | Refer to "Field ID Values". |
|
|
| Max. length | 1,2 or 4 | Max. allowable length in bytes, field length depends on the preceding FID_span value |
| Character string - adjustable | 0x02 |
|
| Descriptor provided by PL/I. |
| Character string - (null terminated) | 0x03 |
|
|
|
|
|
| FID_span | 1 | Refer to "Field ID Values". |
|
|
| Max. length | 1,2 or 4 | Max. allowable length in bytes, field length depends on the preceding FID_span value |
| Character string - DBCS | 0x04 |
|
|
|
|
|
| FID_span | 1 | Refer to "Field ID Values". |
|
|
| Max. length | 1,2 or 4 | Max. allowable length in bytes, field length depends on the preceding FID_span value |
| Character string - DBCS edited | 0x05 |
|
| To be completed in the next draft |
Bit Value Data Description
=== ===== ========================
0 0 not a structure
1 is_struct
1 0 not a DTS class
1 is_DTS_class
2 0 not a placeholder for linker
1 is_place_holder
(not used by PM Debugger)
3-7 reserved
Figure 37. Type Table Entry Sub-Record - Class
| Type (0x40) | Type Qual. | Field Name | Field Length (bytes) | Field Data Description |
|---|---|---|---|---|
| Class | See bit map above |
|
|
|
|
|
| Size of Class | 4 | Size in bytes |
|
|
| Class Item count | 2 | Number of items in class |
|
|
| Index to class item list | 2 | This index identifies a sub-record containing a list of class items |
|
|
| Name | ENC | Length prefixed name of class tag. This name may be mangled; therefore, it must be "interpreted" using a compiler supplied demangler routine. |
|
|
|
|
| The following three data items are present only if is_DTS_class=1. |
|
|
| SOMClassMajor | 2 | SOM Class Major version |
|
|
| SOMClassMinor | 2 | SOM Class Minor version |
|
|
| SOMClassName | ENC | Length prefixed name of SOM class Name. This name may be mangled; therefore, it must be "interpreted" using a compiler supplied demangler routine.? |
| List (0x7F) | 0x01 |
|
|
|
|
|
|
|
| Repeat begins (for number of class items) |
|
|
| FID_index | 1 | Refer to "Field ID Values". |
|
|
| Class Item Type | 2 | Type index (5 different complex types: Class Definition, Base Class, Friend, Member Function, Class Member) |
|
|
|
|
| Repeat ends |
Figure 38. Type Table Entry Sub-Record - Class Definition
| Type (0x43) | Type Qual. | Field Name | Field Length (bytes) | Field Data Description |
|---|---|---|---|---|
| Class Definition | 0x00 |
|
|
|
|
|
| Protection | 1 | 0=Private, 1=Protected, 2=Public |
|
|
| Field type | 2 | Type number of the typedef record |
|
|
| Defining class type | 2 | Type of defining class |
Bit Value Data Description
=== ===== ========================
0 0 non-static
1 is_static
1 0 not virtual table ptr
1 is_vtbl_ptr
2 0 not virtual base ptr
1 is_vbase_ptr
3 0 non_const
1 Const
4 0 non_volatile
1 volatile
5 0 not self_ptr
1 is_self_ptr
6-7 reserved
Figure 39. Type Table Entry Sub-Record - Class Member
| Type (0x46) | Type Qual. | Field Name | Field Length (bytes) | Field Data Description |
|---|---|---|---|---|
| Class Member | See bit map above |
|
|
|
|
|
| Protection | 1 | 0=Private, 1=Protected, 2=Public |
|
|
| Field type | 2 | Type index (it may be primitive or complex) |
|
|
| FID_span | 1 | Refer to "Field ID Values" |
|
|
| Offset | 1, 2 or 4 | The field's offset in bytes from the start of class(field length determined by preceding FID_span) |
|
|
| Name | ENC | If is_static is set, the first Nlen /Name will be the name of the static symbol in the Symbol Scope Table. This name may be mangled; therefore, it must be "interpreted" using a compiler supplied demangler routine. |
|
|
| Name | ENC | The name of the member. This name may be mangled; therefore, it must be "interpreted" using a compiler supplied demangler routine. |
Bit Value Data Description
=== ===== ========================
0 0 16
1 32
1 0 near
1 far
2-7 reserved
Note:
16 near = offset-16
16 far = segment-32
32 near = offset-32
32 far = segment-48
Figure 40. Type Table Entry Sub-Record - Code label
| Type (0x72) | Type Qual. | Field Name | Field Length (bytes) | Field Data Description |
|---|---|---|---|---|
| Code label | See bit map above |
|
| No data expected. |
Bit Value Data Description
=== ===== ========================
0 0 args pushed left to right
1 args pushed right to left
1 0 called program (callee) pops args
1 caller pops args
2 0 16
1 32
3 0 near
1 far
4 0 fixed number of parameters
1 variable number of parameters
5 0 OS/2 calling convention
1 private calling convention
6-7 reserved
Note:
16 near = offset-16
16 far = segment-32
32 near = offset-32
32 far = segment-48
Bit Value Data Description
=== ===== ========================
0 0 passed by address
1 passed by value
1 0 no descriptor required
1 descriptor provided
2-7 reserved
Figure 41. Type Table Entry Sub-Record - Entry
| Type (0x53) | Type Qual. | Field Name | Field Length (bytes) | Field Data Description |
|---|---|---|---|---|
| Entry | See bit map above |
|
|
|
|
|
| Parameter count | 2 | Number of parameters |
|
|
| Max. parameter count | 2 | Max. number of parameters allowable |
|
|
| FID_index | 1 | Refer to "Field ID Values". |
|
|
| Type Index | 2 | Type index of the value returned by the entry |
|
|
| FID_index | 1 | Refer to "Field ID Values". |
|
|
| Index to types list | 2 | This index identifies a sub-record containing a list of type indexes for the parameters. |
| List (0x7F) | 0x04 |
|
|
|
|
|
|
|
| Repeat begins (for number of parameters in an entry) |
|
|
| Flag | 1 | See bit map above |
|
|
| FID_index | 1 | Refer to "Field ID Values". |
|
|
| Type index | 2 | Parameter's type index (it may be primitive or complex) |
|
|
|
|
| Repeat ends |
Figure 42. Type Table Entry Sub-Record - Enum
| Type (0x7B) | Type Qual. | Field Name | Field Length (bytes) | Field Data Description |
|---|---|---|---|---|
| Enum | 0x00 |
|
|
|
|
|
| FID_index | 1 | Refer to "Field ID Values". |
|
|
| Type index | 2 | Element's data type |
|
|
| FID_index | 1 | Refer to "Field ID Values". |
|
|
| Type index | 2 | This index identifies a list sub-record of name and index for each element. |
|
|
| FID_span | 1 | Refer to "Field ID Values". |
|
|
| Starting (minimum) index | 1, 2 or 4 | Beginning index, field length determined by preceding FID_span |
|
|
| FID_span | 1 | Refer to "Field ID Values". |
|
|
| Ending (maximum) index | 1, 2 or 4 | Field length determined by preceding FID_span |
|
|
| FID_string | 1 | Refer to "Field ID Values". |
|
|
| Name | N/A | Length-prefixed name of the enum tag, first 1 byte determines the length |
| List (0x7F) | 0x03 |
|
|
|
|
|
|
|
| Repeat begins (for number of items in enum) |
|
|
| FID_string | 1 | Refer to "Field ID Values". |
|
|
| Name | N/A | Length-prefixed Name of element, first 1 byte determines the length |
|
|
| FID_span | 1 | Refer to "Field ID Values". |
|
|
| Element's index | 1, 2 or 4 | Index, field length determined by preceding FID_span |
|
|
|
|
| Repeat ends |
Figure 43. Type Table Entry Sub-Record - File
| Type (0x67) | Type Qual. | Field Name | Field Length (bytes) | Field Data Description |
|---|---|---|---|---|
| File | 0x00 |
|
| No data expected. |
Bit Value Data Description
=== ===== ========================
0 0 16
1 32
1 0 near
1 far
2-7 reserved
Note:
16 near = offset-16
16 far = segment-32
32 near = offset-32
32 far = segment-48
Figure 44. Type Table Entry Sub-Record - Format label
| Type (0x65) | Type Qual. | Field Name | Field Length (bytes) | Field Data Description |
|---|---|---|---|---|
| Format label | See bit map above |
|
| No data expected. |
Bit Value Data Description
=== ===== ========================
0 0 friend_function
1 friend_class
1-7 reserved
Figure 45. Type Table Entry Sub-Record - Friend
| Type (0x42) | Type Qual. | Field Name | Field Length (bytes) | Field Data Description |
|---|---|---|---|---|
| Friend | See bit map above |
|
|
|
|
|
| Field type | 2 | Type index of class record if it is a friend class, and it is a type index of a function record if it is a friend function. |
|
|
| Name | ENC | Length-prefixed Name of Friend Function. This name may be mangled; therefore, it must be "interpreted" using a compiler supplied demangler routine. |
Bit Value Data Description
=== ===== ========================
0 0 args pushed left to right
1 args pushed right to left
1 0 called program (callee) pops args
1 caller pops args
2 0 16
1 32
3 0 near
1 far
4 0 fixed number of parameters
1 variable number of parameters
5 0 OS/2 calling convention
1 private calling convention
6-7 reserved
Note:
16 near = offset-16
16 far = segment-32
32 near = offset-32
32 far = segment-48
Bit Value Data Description
=== ===== ========================
0 0 passed by address
1 passed by value
1 0 no descriptor required
1 descriptor provided
2-7 reserved
Figure 46. Type Table Entry Sub-Record - Function
| Type (0x54) | Type Qual. | Field Name | Field Length (bytes) | Field Data Description |
|---|---|---|---|---|
| Function | See bit map above |
|
|
|
|
|
| Parameter count | 2 | Number of parameters |
|
|
| Max. parameter count | 2 | Max. number of parameters allowable |
|
|
| FID_index | 1 | Refer to "Field ID Values". |
|
|
| Type Index | 2 | Type index of the value returned by the function |
|
|
| FID_index | 1 | Refer to "Field ID Values". |
|
|
| Index to types list | 2 | This index identifies a sub-record containing a list of type indexes for the parameters. |
| List (0x7F) | 0x04 |
|
| List not used by PM Debugger |
|
|
|
|
| Repeat begins (for number of parameters in a function) |
|
|
| Flag | 1 | See bit map above |
|
|
| FID_index | 1 | Refer to "Field ID Values". |
|
|
| Type index | 2 | Parameter's type index (it may be primitive or complex) |
|
|
|
|
| Repeat ends |
Figure 47. Type Table Entry Sub-Record - Graphic
| Type (0x62) | Type Qual. | Field Name | Field Length (bytes) | Field Data Description |
|---|---|---|---|---|
| Graphic string (fixed) | 0x00 |
|
|
|
|
|
| FID_span | 1 | Refer to "Field ID Values". |
|
|
| Size of string | 1, 2 or 4 | Size in bytes, field length depends on the preceding FID_span value |
| Graphic string - varying (length prefixed) | 0x01 |
|
|
|
|
|
| FID_span | 1 | Refer to "Field ID Values". |
|
|
| Max. length of string | 1, 2 or 4 | Max allowable length in bytes, field length depends on the preceding FID_span value |
| Graphic string - adjustable | 0x02 |
|
| Descriptor provided by PL/I. |
Figure 48. Type Table Entry Sub-Record - Logical
| Type (0x56) | Type Qual. | Field Name | Field Length (bytes) | Field Data Description |
|---|---|---|---|---|
| Logical (Fortran 4) | 0x01 |
|
| No data expected. |
| Logical (Fortran 1) | 0x02 |
|
| No data expected. |
Figure 49. Type Table Entry Sub-Record - Macro
| Type (0x59) | Type Qual. | Field Name | Field Length (bytes) | Field Data Description |
|---|---|---|---|---|
| Macro | 0x00 |
|
|
|
|
|
| FID_span | 1 | Refer to "Field ID Values". |
|
|
| Length of macro definition | 1, 2 or 4 | Length in bytes, field length depends on the preceding FID_span value |
|
|
| Definition | N/A | String of macro definition |
Bit Value Data Description
=== ===== ========================
0 0 non-static
1 static
1 0 non-inline
1 inline
2 0 non-const
1 const
3 0 non-volatile
1 volatile
4 0 non-virtual
1 virtual
5-7 reserved
Figure 50. Type Table Entry Sub-Record - Member Function
| Type (0x45) | Type Qual. | Field Name | Field Length (bytes) | Field Data Description |
|---|---|---|---|---|
| Member Function | See bit map above |
|
|
|
|
|
| Protection | 1 | 0=Private, 1=Protected, 2=Public |
|
|
| Function Type | 1 | 0 = regular member fcn, 1 = constructor, 2 = destructor |
|
|
| Type Index | 2 | Type Index of function sub-record |
|
|
| FID_span | 1 | Refer to "Field Id Values" |
|
|
| VirtNo | 4 | For virtual fcns, the index into the virtual table. This field and the defining FID_span field are present only if the virtual type qualifier bit is set. |
|
|
| Name | ENC | Name of the function. This name may be mangled; therefore, it must be "interpreted" using a compiler supplied demangler routine. If this name is mangled, it is an "abbreviated" mangled name, meaning the class information has been excluded from the name. |
Bit Value Data Description
=== ===== ========================
0 0 no vbases
1 has vbases
1 0 no mult-inh
1 has mult-inh
2 0 non-const
1 const
3 0 non-volatile
1 volatile
4-7 reserved
Figure 51. Type Table Entry Sub-Record - Member Pointer
| Type (0x49) | Type Qual. | Field Name | Field Length (bytes) | Field Data Description |
|---|---|---|---|---|
| Member Pointer | See bit map above |
|
|
|
|
|
| Child type | 2 | Type of the member that may be pointed at |
|
|
| Class type | 2 | Type of the class that may be pointed at |
|
|
| Representation type | 2 | Actual type being used to represent this pointer to member type. |
Figure 52. Type Table Entry Sub-Record - Picture
| Type (0x61) | Type Qual. | Field Name | Field Length (bytes) | Field Data Description |
|---|---|---|---|---|
| Picture | 0x00 |
|
|
|
|
|
| FID_span | 1 | Refer to "Field ID Values". |
|
|
| Length of picture string | 1, 2 or 4 | Size in bytes, field length depends on the preceding FID_span value |
|
|
| Picture string | N/A | Compiler supplied string describing variable. Used for number of COBOL-specific data types. Requires COBOL supplied expression evaluation routines to correctly interpret. |
Bit Value Data Description
=== ===== ========================
0 0 16
1 32
1 0 near
1 far
2-7 reserved
Note:
16 near = offset-16
16 far = segment-32
32 near = offset-32
32 far = segment-48
Figure 53. Type Table Entry Sub-Record - Pointer
| Type (0x7A) | Type Qual. | Field Name | Field Length (bytes) | Field Data Description |
|---|---|---|---|---|
| Pointer | See bit map above |
|
|
|
|
|
| FID_index | 1 | Refer to "Field ID Values". |
|
|
| Type | 2 | Type Index - the type of data the pointer points to |
|
|
| FID_string | 1 | Refer to "Field ID Values". |
|
|
| Name | N/A | Optional name of pointer. The first 1 byte determines the length of the name. |
Bit Value Data Description
=== ===== ========================
0 0 args pushed left to right
1 args pushed right to left
1 0 called program (callee) pops args
1 caller pops args
2 0 16
1 32
3 0 near
1 far
4 0 fixed number of parameters
1 variable number of parameters
5 0 OS/2 calling convention
1 private calling convention
6-7 reserved
Note:
16 near = offset-16
16 far = segment-32
32 near = offset-32
32 far = segment-48
Bit Value Data Description
=== ===== ========================
0 0 passed by address
1 passed by value
1 0 no descriptor required
1 descriptor provided
2-7 reserved
Figure 54. Type Table Entry Sub-Record - Procedure
| Type (0x75) | Type Qual. | Field Name | Field Length (bytes) | Field Data Description |
|---|---|---|---|---|
| Procedure | See bit map above |
|
|
|
|
|
| Parameter count | 2 | Number of parameters |
|
|
| Max. parameter count | 2 | Max. number of parameters allowable |
|
|
| FID_index | 1 | Refer to "Field ID Values". |
|
|
| Type Index | 2 | Type index of the value returned by the procedure |
|
|
| FID_index | 1 | Refer to "Field ID Values". |
|
|
| Index to types list | 2 | This index identifies a sub-record containing a list of type indexes for the parameters. |
| List (0x7F) | 0x04 |
|
|
|
|
|
|
|
| Repeat begins (for number of parameters in a procedure) |
|
|
| Flag | 1 | See bit map above |
|
|
| FID_index | 1 | Refer to "Field ID Values". |
|
|
| Type index | 2 | Parameter's type index (it may be primitive or complex) |
|
|
|
|
| Repeat ends |
Figure 55. Type Table Entry Sub-Record - Reference
| Type (0x48) | Type Qual. | Field Name | Field Length (bytes) | Field Data Description |
|---|---|---|---|---|
| Reference | 0x00 |
|
|
|
|
|
| Field type | 2 | Type number of the reference type |
Bit Value Data Description
=== ===== ========================
0 0 unpacked (zoned)
1 packed
1 0 real
1 complex
2 0 fixed
1 float
3 0 binary
1 decimal
4-7 reserved
Figure 56. Type Table Entry Sub-Record - Scalars
| Type (0x51) | Type Qual. | Field Name | Field Length (bytes) | Field Data Description |
|---|---|---|---|---|
| Scalars | See bit map above |
|
|
|
|
|
| Index | 2 | A primitive type |
|
|
| Precision | 1 | Number of significant digits for packed decimal and floating point. Or number of significant bytes for zoned decimal. |
|
|
| Scale factor | 1 | 128 + scale factor |
Figure 57. Type Table Entry Sub-Record - Set of
| Type (0x52) | Type Qual. | Field Name | Field Length (bytes) | Field Data Description |
|---|---|---|---|---|
| Set | 0x00 |
|
|
|
|
|
| Type index | 2 | Base type |
|
|
| Name | N/A | Length-prefixed name of set's tag. First 1 byte determines the length of the name. |
Bit Value Data Description
=== ===== ========================
0 0 16
1 32
1 0 near
1 far
2-7 reserved
Note:
16 near = offset-16
16 far = segment-32
32 near = offset-32
32 far = segment-48
Figure 58. Type Table Entry Sub-Record - Stack
| Type (0x57) | Type Qual. | Field Name | Field Length (bytes) | Field Data Description |
|---|---|---|---|---|
| Stack | See bit map above |
|
|
|
|
|
| Size of stack | 4 | Size in bytes |
|
|
| Name | N/A | Length prefixed name of the stack (first 1 byte determines the length) |
Bit Value Data Description
=== ===== ========================
0-1 reserved
2 0 not a placeholder for linker
1 is_place_holder
(not used by PM Debugger)
3-7 reserved
Figure 59. Type Table Entry Sub-Record - Structure/Union/Record
| Type (0x79) | Type Qual. | Field Name | Field Length (bytes) | Field Data Description |
|---|---|---|---|---|
| Structure, Union | See bit map above |
|
|
|
|
|
| Size of structure | 4 | size in bytes |
|
|
| field count | 2 | Number of fields in structure |
|
|
| FID_index | 1 | Refer to "Field ID Values". |
|
|
| Index to types list | 2 | This index identifies a sub-record containing a list of field types. See type list below. |
|
|
| FID_index | 1 | Refer to "Field ID Values". |
|
|
| Index to names list | 2 | This index identifies a sub-record containing a list of field names and offset. See name list below. |
|
|
| FID_string | 1 | Refer to "Field ID Values". |
|
|
| Name | N/A | Length-prefixed Name of Structure Tag. First 1 byte determines the length of the name. |
| List (0x7F) | 0x01 |
|
|
|
|
|
|
|
| Repeat begins (for number of items in structure) |
|
|
| FID_index | 1 | Refer to "Field ID Values". |
|
|
| Field type | 2 | Type index (it may be primitive or complex) |
|
|
|
|
| Repeat ends |
| List (0x7F) | 0x02 |
|
|
|
|
|
|
|
| Repeat begins (for number of items in structure) |
|
|
| FID_string | 1 | Refer to "Field ID Values". |
|
|
| Name | N/A | Length-prefixed Name of the field, first 1 byte determines the length. |
|
|
| FID_span | 1 | Refer to "Field ID Values". |
|
|
| Offset | 1, 2 or 4 | The field's offset in bytes from the start of structure (field length determined by preceding FID_span) |
|
|
|
|
| Repeat ends |
Figure 60. Type Table Entry Sub-Record - Subrange
| Type (0x6F) | Type Qual. | Field Name | Field Length (bytes) | Field Data Description |
|---|---|---|---|---|
| Subrange | 0x00 |
|
|
|
|
|
| Element's type | 2 | Type index |
|
|
| FID_span | 1 | Refer to "Field ID Values". |
|
|
| Starting value | 1 ,2 or 4 | The starting value, or low bound in an array (field length determined by preceding FID_span) |
|
|
| FID_span | 1 | Refer to "Field ID Values". |
|
|
| Ending value | 1 ,2 or 4 | The ending value, or high bound in an array (field length determined by preceding FID_span) |
|
|
| Name | N/A | Length-prefixed Name, first 1 byte determines the length. |
Figure 61. Type Table Entry Sub-Record - User Defined Type
| Type (0x5D) | Type Qual. | Field Name | Field Length (bytes) | Field Data Description |
|---|---|---|---|---|
| User defined type | 0x00 |
|
|
|
|
|
| FID_index | 1 | Refer to "Field ID Values". |
|
|
| Type index | 2 | This index identifies a type previously defined (it may be primitive or complex) |
|
|
| FID_string | 1 | Refer to "Field ID Values". |
|
|
| Name | N/A | The name assigned to that type, first 1 byte determines the length |
The Line Number Table provides the information necessary to associate an offset into a program segment with either a specific line in the source file or listing file. If both source and listing information is provided, the debugger will synchronize multiple views of the program.
The Line Number Table is actually a collection of individual tables containing unique information required by the debugger to correctly map the executable output of the compiler to the source code for an application. Each table begins in a new OMF-32 LINNUM record and may span multiple LINNUM records, if the information exceeds the maximum record size defined in the 32-bit Object Module Format (1024). The tables within the Line Number Table are organized as illustrated in Figure 62.:
The LINNUM records must appear in ascending order of segment index. If the Line Number Entries for a logical segment exceed the maximum size of a LINNUM record, the "continuation" LINNUM records must immediately follow the first LINNUM record and contain the same Base Segment index value. The "continuation" LINNUM records do not contain a "First Entry."
If a logical segment does not contain any executable code, no LINNUM record should be generated for that segment.
The Line Number Entries for each logical segment must be sorted in ascending order by offset. More than one entry with different offsets may exist for the same source line number; however, multiple entries with different source line numbers for the same offset may NOT exist.
The Line Number Table is organized as follows:
Figure 62. Line Number Table -- Overview
+---------------------------------------+
| Header |
+---------------------------------------+
| First Entry (special) |
+---------------------------------------+
| |
| File Names Table |
/// (may span mult. LINNUM records) ///
| |
+---------------------------------------+
| Header |
+---------------------------------------+
| First Entry (special) |
+---------------------------------------+
| |
| Path Table |
/// (may span mult. LINNUM records) ///
| |
+---------------------------------------+
| Header |
+---------------------------------------+
| First Entry (special) |
+---------------------------------------+
| |
| Line Number Entries |
/// (may span mult. LINNUM records) ///
| |
| |
+---------------------------------------+
| . |
/// . ///
| . |
+---------------------------------------+
| Header |
+---------------------------------------+
| First Entry (special) |
+---------------------------------------+
| |
| Line Number Entries |
/// (may span mult. LINNUM records) ///
| |
| |
+---------------------------------------+
The LINNUM Header format is:
Figure 63. Line Number Table Record -- Header
1 2 1 1 or 2 (bytes)
+----+---------+---------+---------+
| |Rec |Base |Base |
| 95 | Length | Group | Segment|
| | | | |
| | | | |
+----+---------+---------+---------+
The First Entry format is:
Figure 64. Line Number Table First Entry
+-------------------+---------+---------+
0 | Line Number = 0 | Entry | Reserved|
| | Type | |
+-------------------+---------+---------+
4 | Count of Table | Segment Number |
| Entries | |
+-------------------+-------------------+
8 | File Names Table Size or |
| Address of Logical Segment |
+---------------------------------------+
C
Each Line Number Entry has one of the following formats:
Figure 65. Line Number Entries
Entry Type = 0x00 - Source Line Numbers
+---------------------------------------+
0 | Source File | Source File |
| Line Number | Index |
+---------------------------------------+
4 | Offset into Segment |
| |
+---------------------------------------+
8
Entry Type = 0x01 - Listing Statement Numbers
+---------------------------------------+
0 | Listing File Line Number |
| |
+---------------------------------------+
4 | Listing File Statement Number |
| |
+---------------------------------------+
8 | Offset into Segment |
| |
+---------------------------------------+
C
Entry Type = 0x02 - Source and Listing File Information
+---------------------------------------+
0 | Source File | Source File |
| Line Number | Index |
+---------------------------------------+
4 | Listing File Line Number |
| |
+---------------------------------------+
8 | Listing File Statement Number |
| |
+---------------------------------------+
C | Offset into Segment |
| |
+---------------------------------------+
10
The data items in the different format Line Number Entries are:
The Path Table immediately follows the File Names Table, starting in a separate LINNUM record. Path Information can not reside in an OBJ without Source or Listing information.
Note: Not used by PM Debugger.
Entry Type = Path Table
+---------------------------------------+
0 | Offset into Segment |
| |
+-------------------+-------------------+
4 | Path Code | Source File |
| | Index |
+-------------------+-------------------+
8
Note: Path Table entries must be sorted by offset.
Note: The path code is two bytes long only to force word boundaries for each entry, to improve code efficiency.
The File Names Table is the first LINNUM record in an obj file.
The File Names Table contains the names of the primary source file, the source files, INCLUDEd by the primary source file and, if listing file line numbers or statement numbers are supplied (see "Line Number Table"), the name of the listing file.
+-------------------+-------------------+-------------------+-.
| First Displayable | Number Displayable| Number of Source |
| Char in List Line| Chars in List Line| and Listing Files |
+-------------------+-------------------+-------------------+-.
0 4 8 C
.-+----+------------------------+-//-+----+-------------------+-.
|Len | Name of File |....|Len | Name of File |
|Name| | |Name| |
.-+----+------------------------+-//-+----+-------------------+-.
C D
.-+----+------------------------+
|Len | Listing File Name |
|Name| |
.-+----+------------------------+
Note: Not used by PM Debugger.
Note: Not used by PM Debugger.
Notes:
The Debug Section of the OS/2 Warp LX executable file contains symbolic debug information, which is NOT loaded by the OS/2 Loader. The Debug Section begins and ends with the NB04 signature (ASCII char string). The Debug Section is generated whenever the /DEbug (or /COdeview) option is specified to the Linker.
Note: NB00 format debug information may also be generated if OBJs are linked containing ONLY non-HLL style debug information. The directory header contains only a 2-byte count of number of directory entries. Differently formatted and/or additional subsections will exist for NB00 signatures, consistent with existing 16-bit Microsoft-compatible debug information; however, all offset/length fields will be four bytes long, instead of two bytes.
Legend for the following information
DB - byte - char DW - word - unsigned short DD - double - unsigned long
The Directory information (the block of information at the end of the Debug section pointed to by the offset pointer following the leading NB04 signature, or the Offset/Length fields in the EXE/DLL header) has the following format:
Include structure name = NB04_DEBUG_DIRINFO
00 DW number of bytes in DNT directory structure
(currently 8 - 0x0008)
02 DW number of bytes in the DNT entry
(currently 12 - 0x000c)
04 DD number of directory entries
followed by the array of DNT structures (entries) containing:
Include structure name = NB04_DEBUG_DIR
00 DW sst subsection type 02 DW Module index number (1-based) 04 DD Offset of start of debug subsection 08 DD size of section in bytes
The sstModules section (type 0x101) of an EXE/DLL file with an NB04 signature has the following format:
Include structure name = NB04_DEBUG_MOD_32
00 DW Code Segment Base
02 DD Code Segment offset
06 DD Code Segment length
0A DW Overlay number
0C DW Index into sstLibraries subsection, or 0 if non-library module
The next 2 bytes indicate the number of Segments to follow
(Total number of segments)
0 or 1 indicate a single segment for the module n where n>1
indicates n-1 additional segment structs exist (see below)
0E DB Low order byte of number of segments
0F DB High order byte of number of segments
10 DW Debug Style ('HL" for HLL debug tables, 'CV' or 00 for
CodeView)
12 DW Version Number of format (containing two-character codes of
the form ('00 01' or '00 03' for HL; '00 00' or '00 01' may be
present for CV?)
14 DB Length prefixed name of module (1 byte length)
after the name, the following three fields will be repeated for any
additional segments that may exist for the module. The NOPackcode
Linker option should be used if multiple code segments exist for a
module (using the PACKCode option (default if NOPackcode isn't
specified) may combine separate segments created by the compiler;
therefore, preventing the debugger from being able to locate the
original logical segments).
Addition segment structs have the following format:
Include structure name = DEBUG_SEGINFO_32
00 DW Code Segment number 02 DD Code Segment offset 06 DD Code Segment length 0A Repeat above three data areas per Number of Segments above
The sstPublics subsection (type 0x102) has the following format for NB04 Debug sections:
Include structure name = PUBLIC_32
00 DD Offset 04 DW Segment 06 DW Type Index 08 DB Length prefixed name of symbol (1 byte length)
The sstType subsection (type 0x103) contains the HLL Debug Format Type records, as emitted by the compiler in the OBJ file. If a sstType subsection does not exist for a module, the type records have been "packed" into a single sstType section for the Linker created module "$$HL04" (see also the new ILINK DBGP(ACK) option).
Note: If object files containing older versions of debug information are also linked, modules may have also been created with names "$$HL01" and/or "$$HL03"
The sstSymbols subsection (type 0x104) contains the HLL Debug Format Symbol Scope Table records, as emitted by the compiler in the OBJ file.
The sstLibraries subsection (type 0x106) contains an array of length- prefixed names (one-byte length) of all the library files used during the link step. The order of this list defines the library index number in the sstModules subsection. The use of this list allows removal of redundant library names in the Modules subsection. The first entry should be empty (i.e., zero-length string) since library indices are 1-based.
The sstHLLSrc subsection (type 0x10B) contains the HLL Debug Format Line Number Tables, as emitted by the compiler in the OBJ file.
| End of Document |
|---|
(1) IBM Internal Use Only systems language
(2) 32-bit Object Module Format defined in OS/2 2.0 documentation