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 (or ...DDT if built that way).
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.
	Normally, you will use the send/receive data directives to
communicate between tasks, which permits normal debug operation without
special system action. DDT can map to the physical memory your target
task occupies though, but with some restrictions in use.
	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.
	For IAS you will need to run both DDT22M and your target task
as "realtime" tasks to debug them. This is a restriction which will
probably not be lifted.
    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:.
	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.
That will make accidental screwing up the running executive a bit
harder and will not impair the debugger's functionality AT ALL.
If using only send-receive mode, DDT may be built with arbitrary mapping
disabled and with the automatic mapping-to-task disabled, and it will
run correctly even without mapping to the I/O page.
	Execute DDTBLD.CMD to build DDT; it asks a lot of questions and
assumes you have an I/O page common called EXTCOM that maps over APR 7
installed. A command like (for M+) SET /PAR=EXTCOM:177600:200:DEV
in STARTUP.CMD will set up this partition, though one must build a
common .TSK and .STB file for TKB. A simple file like
	.TITLE EXTCOM
	.PSECT Z$.IO$,RW,D	;DUMMY .PSECT NAME TO AVOID CONFLICTS
IOPAG::
	.BLKW	4095.	;DON'T USE 4096. IF TKB BUG. THIS GETS EVERYTHING.
	.END
can be assembled and built.
The build file would then just be
EXTCOM/-HD/PI,,EXTCOM=EXTCOM
/
STACK=0
UNITS=0
PAR=EXTCOM
//
	In RSX11M you would need a SET /MAIN=EXTCOM:177600:200:DEV
command and an INS [1,1]EXTCOM in your STARTUP.CMD, and in IAS
the TKB file changes and the task is installed in PAR=$$$EXT as
a common.
			Glenn Everhart