MULTI-TASK DDT SYMBOLIC DEBUGGER
	N O T A    B E N E

  DDT22M is a debugger that will let you debug very large
programs with DDT. It is a separate conditionally
assembled version of DDT which you link with DDTMU into a debugging
task named DDT22M (it MUST run under that task name).
To use the package, you link your task normally but adding also
a small program called DDTKNL whose purpose in life is to
communicate with a version of DDT22M that is already active when
you start your task. (See the comments at the front of DDTKNL.)
Then DDT22M gains control again and allows you to issue DDT commands
to map to your task. Where DDT maps to your task directly, the main
RESTRICTION is that your task must NOT MOVE in physical memory while
DDT is debugging it. When DDT uses (as it can) send and receive data
exclusively for access to the other task, no special precautions are
needed.
	In DDT normal "virtual mapping" mode, DDT is actually addressing
arbitrary PHYSICAL MEMORY which happens to be occupied by the task it is
set to debug. If the task moves, DDT does not know that and it
will not do sensible things. Note that if you get a BPT! breakpoint
anytime after the initial startup of the task to be debugged (it is
normal to get one at first once the task is initialized, so you can
tell DDT to map to it and then Go to start it and get the DDT
task into a fixed wait loop) it probably means your task has
moved. You can remap to it by another UL'tsknam' command to DDT
but must be a bit careful. An automatic UL'tsknam' is done at all
breakpoints, but this does not guarantee the task will not be moved
after DDT locates it.
	The UL command works for RSX11M, RSX11M+, IAS, and RSX11D.
    To use, first link your program with DDTKNL/DA. That would be
a link of form (assuming sources and objects in [3,177]):
   TASK/FP/CP=INPUT1,INPUT2,...,[3,177]DDTKNL/DA
and will allow your task to be run under DDT control.
	Now run DDT22M. Use a command like
RUN [3,177]DDT22M/TASK=DDT22M (install the task on IAS!)
which will force the task name to be right. Be sure the system
is fairly quiet since you don't want stuff moving around.
Now DDT will type a message and await your starting it.
Type $G (ESC, G) to start the DDT task up. It will sit
there and await a message from your task now.
	Now run your task. it will send a message to DDT and suspend
itself, so DDT will restart and should type a BPT! (or some such)
message. Now use the $UM command to turn on the DDT virtual map, and then
enter breakpoints and finally you may type $G to start your
task up again. Your task will now run and appear to be controlled
by DDT.
	A word of caution: the terminal is not attached, so don't type
too fast or DDT may not get your typed characters. If MCR sees
them they will produce error messages; nothing to worry about
but a nuisance. DDT probably won't understand a partial command
either. It may be a good idea to be sure DDT's priority is higher
than your task's. DDT22M priority in [3,177] will default to
50, which will usually be OK. You may want to set your terminal
/FDX to use this stuff. (Not needed in IAS)
    It is possible to assemble DDT22 to attach its console LUNs
by defining AT$$$ (see the source) but this could cause problems
if the task being debugged wants to use the terminal, so the default
is not to attach in DDT. Systems with pairs of nearby termimals may
want to run the two tasks from different ones. In IAS, this could
prevent the communication from working right, but the terminal handler
there allows type-ahead even with no attached LUNs so the right
solution there is not to attach TI:.
			Glenn Everhart.  11/19/80

	APPENDIX, 11/24/80

	DDTMU is now debugged (as near as I can tell) and seems to work OK
when properly used. The normal RSX11M, M+, and IAS default will be that DDT
will automatically map to the task being debugged, so that no UL'tsknam'
command need normally be given. Also, this is repeated at each message from
the task (each trap normally) so that DDT will be less likely to screw up
if the task moves. You still need the UM command to turn on using the
mapping registers set up for you. The UV command gets you back top
the normal DDT maps. Normal use is to install DDT22M, then
run DDT22M, then type $G to start it. (If DDT22M is built to issue its
own $G you need not type one here; MCR will see it since DDT22M will
already be idling and awaiting intertask messages.)
	Then run your program and then DDT22M will issue a BPT message.
Now map to the task by typing $UM. (This acts as an enable for the
intertask sends/receives for examining the task you are debugging too,
even in "pure send/receive" mode.)
Now enter your breakpoints and type $G to start the task being debugged.
Proceed normally thru the debug cycle.
You are now done. When your task exits, abort DDT22M.
	NOTE
	DDT22M gets at physical memory to get at the task being
debugged. While doing so, it operates at priority 7 for a few
instructions to access the APRs and during that time any aborts in the
code can be causes to crash the system. DDT checks that addresses are
even but really has no means to test further for legality, especially
where the space accessed is not really supposed to be available to it.
Therefore whenever DDT is in virtual-map mode (i.e., after any $UM commands
not cancelled by $UV commands), be CAREFUL not to give any addresses not
in the task's address space. If the task is nearly 32K long, DDT will
not get into trouble since it loads PDRs too with 4K R/W access codes
and will therefore point somewhere valid in physical memory. The only
real liklihood of trouble comes where either you are debugging a privileged
task or one that has an unused APR somewhere and you make a reference
to the addresses covered by it. Most of the time even that will be all
right since the physical address will normally exist somewhere (initially
DDT loads the virtual APR images from its own APR contents), but once
in a while it can be screwy...especially if you have been inserting random
numbers into PAR0 thru PAR7.
 DDT makes some attempt (if you give it the right size of your machine
in the build command) to protect against illegal memory access and
will then just omit the memory access.
A DDT that can do all this will allow a user to totally violate
system security if he knows enough; NOTHING is safe from DDT!!!!!
	There is a special assembly parameter in DDTKNL that allows
you to build a task that sends a message to DDT22M that gets it to
exit. You may want to install such a task to allow easier ending
of a debug session.
	If it is feasible, I suggest building DDT22M as either an
unprivileged or a /PR:0 task and mapping it to the I/O page via a device
common rather than simply building it mapped to the executive
as the command files now do. That will make accidental screwing up
the running executive a bit harder and will not impair the
debugger's functionality AT ALL. On the other hand, be aware that
ANYBODY can use the techniques DDT does to map to an I/O page common
and make himself privileged even from a NONPRIVILEGED task. It might
be safer to leave DDT22M as an uninstalled task, privileged, so
it will only run for privileged people. This depends on how many
untrustwothy users you have, of course...

			Glenn Everhart