SPRING 1981 [312,315] COLLECTION 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. Glenn Everhart