This submission contains a DDT with many extensions
and the ability to handle debugs from a separate task under RSX/IAS.
It also contains two tape control programs, one able to read files
from Data General RDOS tapes (DGT) and another able to write
files that can be read by RDOS on Data General equipment.
An earlier version without ability to read DG generated tapes is included
as BIGTAPE. All functions are in DGT, which can handle 7 or 9 track
DG tapes.
DDT FROM A SEPARATE TASK
(ALSO STILL WORKS AS PART OF YOUR TASK; BOTH VERSIONS HAVE
MANY NEW FUNCTIONS)
DDT is able to debug one task from another now, symbolically.
That is, this version of DDT may be built as a separate task and
the task being debugged is then linked with a small (about 200 words)
DDT "kernel" (called, appropriately enough, DDTKNL) which controls
execution. DDT itself does most of the work of debugging and supports
a very large and powerful array of commands. These include the
ability to read symbol table files, memory watchpoints, breakpoints,
single stepping, examining numbers in any format including floating
point, setting variables, defining labels, looking at assembly language,
or examining memory image files. The ability to examine core image files is
present to permit DDT to be used (reading the symbol table) to allow
an effective SYMBOLIC OPEN on RSX11M.SYS files or TASK IMAGE files or
crash dump files. (Yes, you may now pretty much discard ZAP once
DDT is installed.)
DDT can debug several tasks at a time, keeping separate sets
of breakpoints, conditional breakpoint controls, watchpoints, etc.
for each task being debugged (up to a limit set at the time of assembly
of DDTMU by setting a number of tasks; the initial maximum is 16 tasks
at a time). It uses the debug kernel to control breakpoints. To access
task space, it can either do its own mapping (fairly fast but a bit
dangerous in a heavily swapping system), or use the debug kernel
also for that (slower, but safe and not noticeable except during single
stepping or searches). User control of the options is at runtime if
they are included at assembly time. It is possible to build a DDT
thatdoes not have access to arbitrary system memory and runs nonprivileged
in case that is desired.
All normal DDT options for building DDT in with your task are
still present, and there is no difference of commands in the two
flavors of DDT.
A simple code profiler is included in DDT which allows you
to specify a base address to "profile" (PRFBAS) and a shift count
to shift addresses down. If DDT is put into single step mode, a
DDT array called PRFHST will be incremented in the bin determined
by the PC of the instruction. The calculation finds the word to
increment by computing (PC-PRFBAS) shifted down by the "shift count"
bits. If the result fits into PRFHST, the PRFHST word is incremented.
Normal DDT commands may be used to display PRFHST after you get
the program to stop.
To generate DDT, type @DDTBLD and answer the questions. In
IAS you will need to use the MCR version of indirect. If this is
installed as ...IND, you can use a command like "IND @DDTBLD" to
run it. Many options are supported, and you can generate DDT for
use in the task, or in a separate task. The profiler is described
by the sysgen further.
Because DDT is now able to run in a separate task, it is possible
to do some fancy things like reading symbol tables that were too
costly before. Since many users are FORTRAN programmers, a
public domain program is included which was slightly modified from
a version at Institute for Cancer Research which can read FORTRAN
.LST files and taskbuilder .MAP files and construct a symbol table
file. This program is designed primarily to make the symbol file for
FDT, a FORTRAN debugger that is also included. However, it can also make
up a pseudo- .STB file that DDT can read and which gives separate
names to each FORTRAN line number, statement label (where possible),
and makes all variable and array names effectively global so DDT will
know, once it opens the symbol table file, where they are. This
permits DDT to set a breakpoint symbolically on any FORTRAN line number
so that you can debug FORTRAN programs symbolically at a fairly high
level if you can find as few as 200 words in your task's space for
the debug kernel.
DDTBLD.CMD will ask questions and allow DDT to be built, in any
of various flavors, for IAS, RSX11M, or RSX11M+. If you have DOS, RT11,
HT11, or other systems, DDT will work (though not from a separate task
and not able to read .STB files), even on an LSI-11. It is a useful
debug tool on any PDP11. (For you hackers, there is a conditional
assembly in the DDT22.MAC source that allows DDT to treat ISD
declarations like GSD declarations if you can get an .STB file created
that will contain internal symbols.)
NOTE TO IAS USERS
DDT22M is fairly critical if built to allow access to arbitrary
memory. Because IAS mapping information is stored in task headers all
over memory, DDT22M MUST be in $UM mode before you start up a DDT
task so its initial attempt to find the tasks it is debugging will
succeed. If this is not so, it can crash your system. I build
DDT22M on IAS (using the MCR indirect command processor) with arbitrary
access disabled, which gives a much safer operation, if a bit slower;
send/receive data is used as the exclusive path to the target tasks.
RSX11M is a bit safer from DDT22M, but even there I default it to
use send/receive to avoid shuffling/swapping problems.
I have found that in full timesharing IAS both DDT and the
task must run realtime for the suspends and resumes to work. I don't
know why, but the workaround is to run both realtime. In IAS 3.1
you may be able to build the tasks with the /SR switch to get them
to work. This switch doesn't exist for V3.0. The build file will
ask if you have IAS V3.1 and assemble a very VERY silghtly different
DDT22M if you do.
I don't know if the /SR switch works; IAS V3.1 hasn't arrived
our way at this writing.
DGT and DGWRIT are separate tasks; see the DGWRIT.FLX source
(in FLECS, so the FORTRAN version is supplied for those not having the
FLECS preprocessor in house) to see how to put DGWRIT together. DGT
works off console commands and is pretty much a manual tool. Its
only virtue is that it works. There is a file called DGWRT7 whose
intent is to allow you to write 7 track tapes a DG machine can read.
Don't mix them; DG does some things differently from DEC on 7 track
tape and messing around was needed.
The FDT and FDTSYM files on the tape are the FORTRAN debugging
tool from Institute for Cancer Research, but with the FDTSYM as a mod
of their TRACE program to generate symbol tables. There are rumors the
package has some problems on 11M systems; should be solid in IAS.
For amusement, I have added also another F4P debug aid called
FPODT (FPODT and PREPRC are the sources pertaining to FPODT) which
goes through a task image and changes all references to $SEQC to
traps. A module in your task (which must first call it to initialize
and all of whose FORTRAN programs must be compiled with /TR:ALL) then
allows single steps, variable examine/modify, or breakpoints. It
does not allow starting from new places as FDT and DDT do. However,
it can be used along with either FDT or DDT. Just depends how much you
are willing to do to find the bugs. FPODT single stepping would go from
one trap to the next, so does not need to set the T bit and ought to
be faster than single stepping with FDT or DDT, even in your task
image, since it steps FORTRAN lines, not instructions.
The TPCDIR program here can list directories of TPC container
images of FLX tapes, and even extract files from such images, one at
a time. The main use is to avoid a separate tape pass to make a directory
when making tape copies.
A new version of the MSX system is included. It works under RSX11M+
now and has several bugs fixed so that it is much better tested. Note when
building it that the security categories in MXSTLS should be set up as
you really want them...the system will block data transfers where military
security policy is violated and the present sources are experimental and have
several invalid possible transfers with those security categories. The
MXTST module is the test program which illustrates its use. It should be
interesting to those who want to experiment with what trying to use a
secure kernel is like, especially on distributed systems. Note the stand
alone version is considerably less tested than the RSX version, but the
basic mechanisms, mapping, and I/O are known to be good. Be careful of
using directives like MODSTT in secure kernel systems; they only work
from libraries or if your task has "ignore multilevel security"
privileges. Also, you need the asynchronous I/O privilege to allow any
I/O to be logically asynchronous in a secure system. Device ownership
may be implemented by adding a special category for "device" to the
special category list of the device and that of its owner.
Also included is a version of Michael Lampi's XMIT program that has
been built to run under IAS V3. (Should be OK in V3.1 but can't test yet.)
The IAS code has been mostly conditioned, and the RSX11M version also took
less CPU than the original. However, RSX11M and RSX11M+ users may have to
do a bit of retrofitting. It may be the IAS version will work in 11M too
but it's terminal I/O is via read/write, not via AST for input, relying
on the full duplex driver to keep characters around. Reducing CPU load
has been a primary concern.