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 recording, for any purpose without the express written permission of Microsoft.