Trailing-Edge
-
PDP-10 Archives
-
BB-H348C-RM_1982
-
swskit-v21/documentation/mcb-xdt.doc
There are no other files named mcb-xdt.doc in the archive.
W A R N I N G !
This document was shipped with the DECnet-20 V1.0 SWSKIT.
No work has been done to verify that XDT will work in the same way
for DECnet-20 V2.0. Read and use this document at your own risk.
How to run a DN20 under XDT
---------------------------
The DN20 can be run under XDT, the RSX-11S Executive Debugging Tool,
for diagnostic purposes. This allows the specialist to examine or modify
MCB (Multifunction Communications Base - the sub-operating system for the
DN20 under RSX-11S), and to set breakpoints in the system. Use of XDT
requires access to the DN20's DL11 interface; this can be done through
DNBOOT as shown below. XDT's syntax is similar to that of ODT (the analagous
product for debugging RSX-11S user tasks); ODT is described in the IAS/RSX-11
ODT Reference Manual (DEC-11-OIODA-B-D). Another, general discussion of how
to use XDT is contained in Section 3.4.1.2 in the RSX-11M/S Guide to Writing
an I/O Driver (AA-2600D-TC). (It is suggested that one or both of these
references be read before continuing with this document.) There are several
general things to note about using XDT:
1. Use of XDT disables the DN20's crash dump facility. Instead of dumping its
registers and halting on an error interrupt, the DN20 will go into XDT mode and
await commands from the user. If the DN20 is dumped through NETCON at this
time, its registers will be lost.
2. When XDT is entered, it is entered stand-alone; all other software processes
are suspended and the -11 runs with interrupts disabled. Any data coming into
any non-NPR devices (ones which operate through CSRs rather than directly off
the UNIBUS; all DN20 devices except the DMC and DTE are non-NPR) will be lost.
Also, the DTE will not maintain its keep-alive count, so that to the -20 the
DN20 will appear to have gone down. If the DN20 is restarted from a breakpoint,
the DTE protocol will have to be re-initialized through DNBOOT; this will kill
all active logical links.
3. XDT on entry at system startup will operate with memory mapping off. When
it is entered from a breakpoint or interrupt, it will have memory mapping en-
abled. This discrepancy (as is also noted below) should be considered when
setting up breakpoints.
Enabling XDT in a DN20 System Image
-----------------------------------
To run XDT in a DN20, the .SYS file which is loaded by NETCON must be
patched. Follow this procedure:
FILDDT
------
FILDDT>EN(ABLE) DAT(A MODE)
-- ---
FILDDT>EN(ABLE) PAT(CHING)
-- ---
FILDDT>GET (filespec for the .SYS file)
[filespec LOADED]
$$C where $ is ESC or ALTMODE
---
350'4/ 17024,,1263 17704,,1263
------ -----------
(the above replaces the DN20 system image's regular transfer
address with that of XDT)
^Z
--
Bringing Up an XDT System
-------------------------
1. Start two jobs (which will be referred to as "DN" and "OP"). Both jobs
must have WHEEL or OPERATOR privileges enabled.
2. Enter to job DN:
$DNBOOT
------
DNBOOT>LISTEN DL1:
-----------
DNBOOT>TALK
----
[ENTER ^E TO RETURN TO DNBOOT COMMAND LEVEL]
(see the HLP file for DNBOOT for further explanation)
3. Enter to job OP:
$OPR
---
OPR>TAKE (a copy of NCP.CMD which you have modified to refer to the XDT system
as its LOAD-FILE)
4. After a while, the following dialog should occur on job DN:
XDT: 22
XDT>$6/ (a negative number or 0) 1004
--- ----
(this will set the stack pointer to a reasonable value for
RSX-11S initialization)
Set up your breakpoints here (see below).
Then enter:
XDT>G (this will not echo)
-
Your XDT system will then come up as a DN20 system usually does.
Setting Initial Breakpoints
---------------------------
When the DN20 goes into XDT upon bringing the system up (above), it does so
prior to invoking the RSX-11S base of the DN20 system. XDT is therefore run-
ning standalone at this time, and does not use memory mapping. All addresses
given to XDT must therefore be physical addresses in the first 28K words of
core. This will restrict you as to where your initial breakpoints may be set
in the DN20 system image; refer to the partition map in DN20A.DOC for exactly
where the 28K line falls (physical address 160000). Moreover, because the
XDT breakpoint table will compare (mapped) VIRTUAL addresses when the break-
point is finally hit, real breakpoints cannot be easily set at this time. An
example of how to set an initial "breakpoint" is given below:
You want to set a breakpoint at (virtual) address 127466 (this is an arbitrary
address in page 5 for the sake of this example) in NETACP. Because NETACP,
like all MCB processes, is mapped into page 5 during DN20 execution, its
virtual base is 120000. Its physical base (for the partition it is loaded
into) is 52000. Therefore, the physical address corresponding to the desired
breakpoint is
127466-120000+52000=61466
When XDT is invoked, you can perform the following dialog:
XDT>61466/ 012705 3
------ -
where 12705 is the original contents of location 61466, and 3 is a
PDP-11 BPT (breakpoint trap) instruction, which XDT normally uses to
mark a breakpoint location. Note that because you have not used the
XDT "B" command, this location will NOT be identified as a breakpoint.
Once the DN20 has started and the "breakpoint" has been hit, you can perform the
following dialog:
BE: 127466 "BE" stands for "breakpoint error": invalid BPT instruction
XDT>$7/ 127470 Q-2@ ***NO <CR>***
--- ----
This prints out the PC (register 7) which will point past the
end of the BPT instruction. The PC contents are backed up two
bytes to address the instruction again (Q stands for whatever
number was just typed out), and XDT is requested to display
the instruction (the @ means "indirect").
127466 / 000003 12705
-----
The instruction is changed back to its original form.
XDT>.;B A real breakpoint is set up here (optional). Note that any
--- other breakpoints IN NETACP can also be set here, using their
virtual addresses.
XDT>P XDT is instructed to proceed.
Setting Mapped Breakpoints
--------------------------
Once XDT has been entered from a running DN20 system (usually through an
initial breakpoint, although XDT will be in the same state on a system crash),
breakpoints may be set using virtual addresses. It is only necessary that
the physical code, into which the breakpoint is going, be mapped at the time
the breakpoint is set. This may be done by changing the appropriate
mapping register, setting the breakpoint, and restoring the mapping register.
If you are going to put breakpoints into several area which are indepen-
dently mapped, however, (e.g., the Comm Exec and one or more processes), one
VERY IMPORTANT QUALIFICATION must be noted: Since XDT removes BPT markers for
all active breakpoints when any breakpoint is hit, and restores them all when
told to proceed, and since XDT ALWAYS uses virtual addresses,
ALL ACTIVE BREAKPOINTS MUST BE IN AREAS WHICH ARE MAPPED WHEN
ANY BREAKPOINT IS HIT.
If any breakpoint is unmapped, XDT assumes it is there and 1) the virtual
address which is supposed to contain the breakpoint will end up with a BPT
in it, and 2) the physical address which actually does contain the breakpoint
will eventually be given the instruction which the BPT wiped out. This is
guaranteed to spoil anyone's day; WATCH OUT. (A way to get around this problem
is to set a breakpoint at symbol $PDDSP+42 (36234 in the 3A system), which is
used to map in an MCB process. At the time this breakpoint (which is always
mapped) is hit, a new process will have been mapped in; if it is the right one,
as you can determine from PAR 5 (172352), the desired breakpoints can be set.)
In the DN20 system, the only system areas containing executable code which
are mapped in and out are the MCB processes mapped into page 5. All other exec-
utive areas are either data-only or are constantly mapped into the executive
address space. User programs can never be breakpointed by XDT; RSX-11S inter-
cepts the trap and aborts the task normally.