MULTI-TASK DDT SYMBOLIC DEBUGGER N O T A B E N E This program is NEW and not thoroughly tested. Bugs may appear and you may have to tailor it to your liking. However, since all DDT functionality is unaltered and the multi-user features only appear if MU$DBG is defined at DDT assembly (and are only usable if that DDT is linked with DDTMU), this software is included. It should help those who have only small amounts of address space left in their tasks below 32K. The DDTKNL module requires only 133 words (decimal) if hardware floating point support i are needed if floating point is to be supported. The scheme used is a last resort where you don't have enough address space to insert a normal debugger (even Octal debugging Tool -ODT). However, you may like DDT enough to use it generally. Look at the DDT source for documents. The first part contains a brief manual section, and the code is the final reference for conditionals, etc. Also buried in DDT source is how to get it to have an effective "memory breakpoint" which basically single steps through the program and monitors a memory cell to see if it changes and breaks if it does. The code is there but a conditional assembly normally excludes it. Use with some care, but use this stuff. If there are any problems, let me know and I'll try to fix them. Glenn Everhart 206-1, RCA GSD Engineering Staff Rt. 38, Cherry Hill, N.J. 08358 (609)-338-6022 home: (609)-261-3709 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. The main RESTRICTION of this is that your task must NOT MOVE in physical memory while DDT is debugging it. 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 Bad Entry 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. I may do an automatic UL'tsknam' later on, but am reluctant to just now since that will introduce incompatibilities with IAS which is used at sites I wish to support. Also, that is a bandaid because there is no guarantee the task will not be moved after it is located. In IAS users have to locate the task physically themselves and set virtual mapping registers for DDT. In RSX11M and RSX11M+ I have code to do the mapping by task name. 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 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 BE0000 (or some such) message. Now use the $UL'tsknam' command to map DDT to your task, 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 60, which will usually be OK. You may want to set your terminal /FDX to use this stuff. 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 and M+ 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. Then run your program and then DDT22M will issue a BPT message. Now map to the task by typing $UM. In IAS, set mapping registers PAR0 thru PAR7 manually. Now enter your breakpoints and type $G to start the task being debugged. Proceed noormally 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. Note too that not all of virtual address space is mapped via the Kernel I APRs in RSX11M+; the $UK command maps to those APRs and not to the Kernel D space APRs. These must be mapped in manually (just examine the hardware registers and copy into PAR0 thru PAR7). Also, 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!!!!! I expect to fix up the DBG11M routine sometime to support automatic mapping to IAS tasks someday. Just now it'll have to wait... I MIGHT (if there is enough reason) fix up DDT to use Spawns so it can exit when the tasks it spawns exit. However, that will be further off; manually aborting DDT isn't all that hard and the fixed DDT22M task name is a bit of a kludge too. Maybe I'll think of a way to have more than one of these at a time someday. 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.