Specifications

Debugging and Testing Tools
9.3 OpenVMS AXP System-Code Debugger (AXP Only)
• Examine and modify the values of variables
• In some cases, test the effect of modifications without having to edit the
source code, recompile, and relink
Because the OpenVMS AXP System-Code Debugger is a symbolic debugger, you
can specify variable names, routine names, and so on, precisely as they appear
in the source code. Using the OpenVMS AXP System-Code Debugger, you can
display the source code where the software is executing and step through the
source code, line by line.
You can use this debugger to debug code with the following languages:
•C
• Bliss
• VAX MACRO
Note
A Bliss compiler is not available for OpenVMS AXP.
The OpenVMS AXP System-Code Debugger recognizes the syntax, data typing,
operators, expressions, scoping rules, and other constructs of a given language.
If your program is written in more than one language, you can change the
debugging context from one language to another during a debugging session. For
information about how to use the OpenVMS AXP System-Code Debugger and how
it differs from the OpenVMS Debugger, see the OpenVMS AXP Device Support:
Developer’s Guide. For information about OpenVMS Debugger commands, see the
OpenVMS Debugger Manual.♦
9.4 System Dump Analyzer
The System Dump Analyzer utility (SDA) helps you determine the cause of
system failures. You invoke this utility specifying a system crash dump file,
which is a copy of memory at the time of a system crash. SDA reads the
dump file; then, it formats and displays the contents of the file. In addition to
information contained in the dump file, SDA reads the system’s symbol table file.
You can specify that SDA read the symbols that define many of the system’s data
structures, including those in the I/O database.
You can also use SDA to analyze a running system. To do this, you need change-
mode-to-kernel (CMKRNL) privilege. This option is useful for examining the
stack and memory of a process stalled in a scheduler state.
If you are examining a dump file, SDA displays the immediate cause of the crash.
You can then use SDA to diagnose how the error occurred. For example, you can
use SDA commands to locate the line of code that signaled the bugcheck and
to find the line of code (usually on the stack) that caused the error. Then, you
can examine device drivers, linker maps, and system maps to locate the module
where the line of code came from. Once the module has been identified, you can
examine the module code to pinpoint the problem.
9–9