Specifications

Debugging a Device Driver
11.2 Using the OpenVMS AXP System-Code Debugger
If the system-code debugger is already connected, the ;R command transfers
control to the system-code debugger, and optionally changes the password
that must be presented the next time a system-code debugger tries to make
a connection. This new password does not last across a boot of the target
system.
• n;K Change inibrK behavior
If optional argument n is 1, future calls to INI$BRK will result in a
breakpoint being taken by the system-code debugger. If the argument is 0, or
no argument is specified, future calls to INI$BRK will result in a breakpoint
being taken by XDELTA.
Sysgen Parameters
• DBGTK_SCRATCH
This new parameter specifies how many pages of memory are allocated
for the system-code debugger. This memory is allocated only if system-
code debugging is enabled with the 8000 boot flag (described earlier in
this section). Usually, the default value of 1 is adequate; however, if the
system-code debugger issues an error message, increase this value.
• SCSNODE
Identifies the target kernel node name for the system-code debugger. See
Section 11.2.3.1 for more information.
11.2.3.1 Making Connections Between the Target Kernel and the System-Code Debugger
It is always the system-code debugger that initiates a connection to the
target kernel. When the system-code debugger initiates this connection,
the target kernel accepts or rejects the connection based on whether the
remote debugger presents it with a node name and password that matches
the password in the target system (either the default password from the
SYS$SYSTEM::DBGTK$CONFIG.SYS file, or a different password specified
via XDELTA). The system-code debugger gets the node name from the SCSNODE
Sysgen parameter.
The target kernel can accept a connection from the system-code debugger anytime
the system is running below IPL 22, or if XDELTA is in control (at IPL 31)
However, the target kernel actually waits at IPL 31 for a connection from the
system-code debugger in two cases: When it has no existing connection to
a system-code debugger and (1) It receives a breakpoint caused by a call to
INI$BRK (including either of the initial breakpoints), or (2) when you issue a 1;R
or -1;R command from XDELTA.
11.2.3.2 Interactions between XDELTA and the Target Kernel/System-Code Debugger
XDELTA and the target kernel are integrated into the same system. Normally,
you choose to use one or the other. However, XDELTA and the target kernel can
be used together. This section explains how they interoperate.
The 0002 boot flag controls which debugger (XDELTA or the target kernel) gets
control first. If it is not set, the target kernel gets control first, and it is not
possible to use XDELTA without rebooting. If it is set, XDELTA gets control first,
but you can use XDELTA commands to switch to the system-code debugger and to
switch INI$BRK behavior such that the system-code debugger gets control when
INI$BRK is called.
11–6