Debug Symbol Files

< BACK  NEXT >
[oR]

One of the more puzzling aspects of debugging is the role of symbol files. Symbol files falls into two categories: OS and driver.

Operating System Symbols

With the release of each version (i.e., service pack) of Windows 2000, Microsoft releases the public symbols for that build. Public symbols are essentially the information that could have been gleaned from the linker's load map, except that they are in debugger-readable format. The information is read, used, and displayed by the debugger during a stack trace operation, a trace or step operation, or when evaluating and setting breakpoints.

Microsoft does not publish private symbol information for its operating systems. Such information is deemed proprietary, and unless a bug were being chased in the OS itself, it is not particularly helpful. The public symbol information, however, is quite useful and is a recommended installation for application as well as driver debugging.

OS symbols are unique to each build (service pack) of an OS. Always install the symbols for the base OS first by using the Windows 2000 Customer Support Diagnostics CD. Then, after a service pack is applied to the OS, locate the symbol file for the service pack (the location varies based on where the update is obtained) and install it over the existing OS symbols.

By default, OS symbols install into a directory %SystemRoot%\Symbols. The debugger must point to appropriate directories for a given debug session. For WinDbg, the symbol path can be configured from the Options dialog of the View menu, Symbols tab.

Driver Symbols

The driver symbols are created when the driver source compiles and links. The symbols for a driver (as for the OS itself) fall into public and private categories. The public symbols provide link map information (correlating function names and addresses), while the private symbols information includes source-line linkage, data type definitions (e.g., typedefs), and static declarations (functions and data).

To generate public symbol information for a driver, the link switch /pdb:"filename" can be used. To generate private symbol information, the compiler switch /Zi is used. The slick Edit and Continue feature should not be used for driver development. Linker and compiler switches can be set for a command-line build (e.g., using the BUILD utility) or from Visual Studio if the IDE is used.

Incidentally, the generation of public and private symbols is a separate issue from the inclusion of symbol data into a binary distribution file. While it is obvious that a debug (checked) build of a driver should include symbol generation, it is less obvious, but nonetheless critical, that symbol information be generated for a release build. The symbol information (.PDB or .DBG files) should then be archived, but not distributed, with the released binary driver. (The REBASE utility's -x switch can be used to strip a binary (.SYS) file of its symbol data.)

As with the OS symbol data, the debugger must be informed of the path of the driver symbol data.

< BACK  NEXT >


The Windows 2000 Device Driver Book(c) A Guide for Programmers
The Windows 2000 Device Driver Book: A Guide for Programmers (2nd Edition)
ISBN: 0130204315
EAN: 2147483647
Year: 2000
Pages: 156

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