How to Use Multi-Task DDT

	DDT is a symbolic assembly language level debugger for PDP11
which normally is included in a task image by specifying its name
on the input side of a taskbuild with the /DA switch to indicate that
it is a user debug aid. It allows one to examine code and see it, or
enter it as code, to enter symbols, and resolve addresses relative
to symbols. Thus, one normally needs only a map to use it, not
necessarily assembly listings. (One may predefine a short file with
global symbols and append it to the DDT symbol table and avoid even
the need to use a link map.)
	One pays for this power in memory; DDT may require as much as
5K of memory, which may not be available in a large task image. Even
the DEC debugger, ODT, which is a strictly octal debugger, requires
1K to 2K of task space. Thus it is comparatively frequent to have a
program too big to debug. That's unfortunate because the big programs
are usually the ones most needing to have a debug aid to help sort
out why they don't work.
	DDT22M (M for Multi-tasking, 22 for 22 bit addressing) is
a special task which includes a version of DDT and a control
program in one task, and a very short (128 words minimum, or
396 words for support of the ability to debug floating point
with examination and display of floating point contexts in floating
accumulators) "kernel" debugger in the task that is to be debugged.
It operates by going around some of the walls placed by the operating
system in RSX and IAS systems. In this scheme, DDT is able to examine
or modify the target task's address space directly, and controls
execution of the target by interaction with the kernel debugger. This
frees all examination and display functions from the target task's
address space and permits debug of all but the most pathologically
huge programs.
	To generate the system, DDT22 must be assembled with the
parameter MU$DBG defined, and linked with DDTMU. The task name must
be DDT22M, so only one such task may exist at a time. The DDT22M task
is normally built with floating point support too if the machine
has FPP instructions (or the Floating Point Emulator available on
DECUS RSX SIG tapes for RSX11M or IAS). This permits examination or
modification of memory in Floating Point format. The debug kernel
may be assembled with $D$FPU defined if the target task's floating
accumulators are to be available to the debugger.
	The debug kernel DDTKNL must be assembled, with or without
$D$FPU defined, to link into the target task.
	NOTE: if using RSX11M+, define K$ID when assembling
DDT22, and if using either RSX11M or RSX11M+, it is desirable
to define R$XMDB and assemble with [1,1]EXEMC/ML when assembling
DDT22, and with only the definition when assembling DDTMU. The
file DDTPRM should be used and edited for your system.
	DDT22M is linked with DDTMU and DDT22/DA as its main
inputs. The target task is linked with DDTKNL/DA as an input
file. Given these preparations, you are ready to debug your
code. Note that DDTKNL will trap all odd address traps,
illegal instructions, segmentation errors, and breakpoints.
It, AND DDT22, must be edited to handle non-RSX EMT or TRAP
instructions.  (See the source; such changes are not recommended.)
Be sure to use the /FP switch in taskbuild if your DDTKNL has
$D$FPU defined.
	Now install DDT22M or use a command like

RUN DDT22M/TASK=DDT22M

to run the task with the required task name DDT22M. The DDT task will
announce its presence and sit there. Type $G ($ means "escape" hereafter
and may be eaten by the terminal for some terminals (like LA120, VT100,
VT52) but will still work even though it does not echo. This starts
the DDT22M task up and leaves the terminal free.
	Now you may start your target task in whatever way you like.
When your target task comes in, DDT will be re-activated. If you
built with R$XMDB defined, DDT is automatically mapped to your
task at every message from it (which could permit use of one
DDT22M for several tasks; the RCVBUF area has the RAD50 task name
in its start. However, this will not be further discussed.).
	The DDT22M task may map with either of 2 address spaces
now. Initially it is in its own space. To allow examination
of the target's space, type the $UM command. To return to the
DDT space, type $UV. (Remember "$"="escape", not just dollar sign.)
Normal procedure is to type $UM, then set breakpoints (or single
step mode), then type $G first to start your program. You MUST
use the $UM command before beginning the target task if any breakpoints
are to be set.
	When you hit a breakpoint, DDT symbols R0 through R5, SP,
PC, and U.PSW are the target's registers, and DDT symbols AC0 thru
AC5 and FPSTAT are the target's floating accumulators if DDTKNL
had floating support. These may be examined as you would under
normal DDT. To examine DDT's registers, you must use the $UV
command and examine D.R0 thru D.R5, D.SP, and D.PC. Remember to
use the $UM command before proceeding. The normal $P command will
proceed from breaks normally. Single stepping may be done when
not in $UM mode, but this is not recommended since you could forget
what you're looking at.
	Once in DDT you may at any time get DDT to exit by typing
BYE$G. However, if your target task exits (normally or otherwise)
DDT22M won't know. Normal action is to abort DDT22M from the console
when done with it. The command to do this is

ABO DDT22M

which will end the session.
	Almost all DDT commands work in this system. The only major
exception is that the instruction$X command will not work and DDT
will type a ? if you try it. It is not at all clear what it would
mean to allow instruction execution in DDT context and not in
target context, or how to allow it in target context without large
additions to DDTKNL. Also, once you type the initial $G to DDT22M
when it first starts, all subsequent $G or $P commands are interpreted
as target addresses, and the DDT22M task itself is in an idle loop
awaiting intertask messages from the target.