Specifications

Debugging a Device Driver
11.2 Using the OpenVMS AXP System-Code Debugger
Breakpoints always stick to the debugger that set them. For example, if you set
a breakpoint at location ‘‘A’’ with XDELTA, and then you issue the command 1;K
(switch INI$BRK to the system-code debugger) and ;R (start using the system-
code debugger). Then, from the system-code debugger, you set a breakpoint at
location ‘‘B’’. If the system executes the breakpoint at A, XDELTA will report a
breakpoint, and the remote debugger will see nothing (though you could switch
the system-code debugger by issuing the XDELTA ;R command). If the system
executes the breakpoint at B, the system-code debugger will get control and
report a breakpoint (you cannot switch to XDELTA).
Notice that if you examine location A with the system-code debugger, or location
B with XDELTA, you will see a BPT instruction, not the instruction that was
originally there. This is because neither debugger has any information about the
breakpoints set by the other debugger.
One useful way to use both debuggers together is when you have a system that
exhibits a failure only after hours or days of heavy use. In this case, you can
boot the system with the system-code debugger enabled (8000), but with XDELTA
the default (0002) and with initial breakpoints enabled (0004). When you reach
the initial breakpoint, set an XDELTA breakpoint at a location that will only
be reached when the error occurs. Then proceed. When the error breakpoint is
reached, possibly days later, then you can set up a remote system to debug it and
issue the ;R command to XDELTA to switch control to the system-code debugger.
Here is another technique for use when you do not know where to put an error
breakpoint as previously mentioned. Boot the system with only the 8000 flag.
When you see that the error has happened, halt the system and initiate an IPL
14 interrupt, as you would to start XDELTA. The target kernel will get control
and wait for a connection for the system-code debugger.
11.2.4 Setting Up the Host System
To set up the host system, you need access to all system images and drivers that
are loaded (or can be loaded) on the target system. You should have access to a
result disk or a copy of the following directories:
SYS$LOADABLE_IMAGES:
SYS$LIBRARY:
SYS$MESSAGE:
You need all the .EXE files in those directories. The .DSF files are available with
the OpenVMS AXP source listings kit.
Optionally, you need access to the source files for the images to be debugged. The
system-code debugger will look for the source files in the directory where they
were compiled. If your build machine and host machine are different, you must
use the SET SOURCE command to point the system-code debugger to location
of the source code files. For an example of the SET SOURCE command, see
Section 11.4.2. For more information about using the SET SOURCE command,
see OpenVMS Debugger Manual.
To make the connection, you must set up the logical DBGHK$IMAGE_PATH,
which must be set up as a search list to the area where the system images are
kept. For example, if the copies are in the following directories,
11–7