whm@arizona.UUCP (07/28/83)
Several weeks ago I posted a query for information on debuggers. The information I received fell into two categories: information about papers, and information about actual programs. The information about papers was basically subsumed by two documents: an annotated bibliography, and soon-to-be-published conference proceedings. The information about programs was quite diverse and somewhat lengthy. The basic gold mine of current ideas on debugging is the Proceedings of the ACM SIGSOFT/SIGPLAN Symposium on High-Level Debugging which was held in March, 1983. Informed sources say that it is scheduled to appear as vol. 8, no. 4 (1983 August) of SIGSOFT's Software Engineering Notes and as vol. 18, no. 8 (1983 August) of SIGPLAN Notices. All members of SIGSOFT and SIGPLAN should receive copies sometime in August. Mark Johnson at HP has put together a pair of documents on debugging. They are: "An Annotated Software Debugging Bibliography" "A Software Debugging Glossary" I believe that a non-annotated version of this bibliography appeared in SIGPLAN in February 1982. The annotated bibliography is the basic gold mine of "pointers" about debugging. Mark can be contacted at: Mark Scott Johnson Hewlett-Packard Laboratories 1501 Page Mill Road, 3U24 Palo Alto, CA 94304 415/857-8719 Arpa: Johnson.HP-Labs@RAND-RELAY USENET: ...!ucbvax!hplabs!johnson Two books were mentioned that are not currently included in Mark's bibliography: "Algorithmic Debugging" by Ehud Shapiro. It has information on source-level debugging, debuggers in the language being debugged, debuggers for unconventional languages, etc. It is supposedly available from MIT Press. (From dixon.pa@parc-maxc) "Smalltalk-80: The Interactive Programming Environment" A section of the book describes the system's interactive debugger. (This book is supposedly due in bookstores on or around the middle of October. A much earlier version of the debugger was briefly described in the August 1981 BYTE.) (From Pavel@Cornel.) Ken Laws (Laws@sri-iu) sent me an extract from "A Bibliography of Automatic Programming" which contained a number of references on topics such as programmer's apprentices, program understanding, programming by example, etc. The following section sites specific debuggers. This section is comprised of excerpts from letters from various people along with what I know of the various programs. A number of the contributions related to programs described in SIGSOFT/SIGPLAN Symposium proceedings and those items are not_ included. These items are in no particular order. ------ From: steinberg@rutgers An interesting system is the Cornell Program Synthesizer, described by Tim Teitelbaum in an article, I think in CACM sometime about 2 or 3 years ago [CACM Sep '81]. This is a program development environment, with a structure oriented editor, for a subset (VERY sub) of PL/I. The system has a debugging mode where it splits the screen into three areas: one is for normal I/O to/from the program, one shows each variable as it is changed and gives the new value, and one shows the program and moves the cursor around to show what statement is executing. You can single step, seeing each statement pointed at before it is executed and seeing any effect on the variables as it happens. There are more detailed options but that gives you the flavor of the system. We use it for our introductory course and find it very effective. ------- From: spaf.gatech@udel-relay [A system of interest may be] DBG, the symbolic debugger used on Prime 50-series computers. It works with all of their high-level languages on compiled code, allows checkpointing, procedure tracing (including recursive procedures), source level type statements, variable watchlists, single stepping of operations, mixing of languages, and lots of other nice features. ------ From: kurtk@ucbcad CDC (Control Data Corp.) has what they dub Cyber Interactive Debug. It's a 'source' code related debugger (display variables by name, assign new values, goto a statement label, breakpoints, etc.) The only thing that makes it incomplete is that you cannot display source code LINES with the debugger. You need a listing of your program to effectively use it. Even so, I don't know how I managed to survive so long as a programmer without it. ------ From: tekchips!wm Some people in my group here at Tektronix have developed an interactive debugger/editor/incremental compiler for Pascal called Magpie. From what I have seen itis quite impressive. They are finishing up writing a paper on it. [teklabs!mayers is alleged to have some information on this but I didn't follow it up.] ------- From: sbq.oregon-grad@rand-relay If you haven't already heard from them, you ought to ask Intel for information on Debug-432, V2.0 (you would probably not be interested in any version of the product prior to V2.0). This is a symbolic debugger for Ada programs which run on Intel's iAPX-432. I worked on this product before I left Intel. It had quite a bit of *useful* functionality. It was a good debugger, modulo the hardware it was required to run on. The debugger was required to solve some interesting problems. It is probably one of the first symbolic *Ada* debuggers and it is also a "systems level" debugger for the 432. [ogcvax!ssovax!andrew was mentioned as a possible contact for further information.] ------ From: steinberg@rutgers The Interlisp debugger has had some extensions made to make use of the bitmapped screen and window-oriented software and mouse on the various "D-machines" - Xerox Dolphin, Dorado, etc. (They are personal Lisp machines.) In a break, you can get the stack displayed in a window, as a list of function names. If you bug one, you get another window that shows the variable bindings in that stack frame. If you bug one of the bindings you can either set, edit, or inspect the value, using the standard Interlisp-D "inspect" package, which is a display oriented system for inspecting/editing data structures. Of course, as with all LISP debuggers, this is written in the language it debugs. ------ From: dagobah!mis There's a general debugger for UNIX available from Third Eye Software -- Peter Rowell in Mt View. You have to hack the compiler to produce the right symbol table stuff. [I believe it is called cdb.] ------ From: guyton@rand-unix Be sure and check out the Mesa debugger (Xerox Alto and later processors), and the ZLisp debugger of Symbolics. ------ From: ihuxn!res I have worked with an interactive debugging environment with which you may be interested. It is called the Program Control System (PCS) on the IBM TSS systems (TSS, not TSO). It provided symbolic debugging features for FORTRAN and ASM programs. As to references: the IBM publication GC28-2001-9 (probably way out of date) contains a section entitled "Program Control" in Section 3. This gives a pretty fair discussion of the facilities of PCS and examples of their use. Also, Appendix B of IBM publication GC28-2025-5 (another antique from my IBM Manual Shelf) covers the use of PCS with FORTRAN programs. ------ From: leichter@yale A number of years ago I developed an interactive programming/debugging environment for SNOBOL (actually for SITBOL) called APLBOL. The user interface is essentially identical to APL's (hence the name), including the ability to stop inside of functions, examine local variables, change code on the fly, continue, etc. In the last year or so, I started playing with it again and cleaned it up quite a bit. ------ A number of people mentioned IBM's PL/1 interactive debugger, commonly known as PLIC. This was on one of the first systems that I ever used and I've missed the capabilities it had ever since. It is a very well polished product and was very addictive. If you ever have to write PL/1 on an IBM system, demand it. ------ From: cs.werner@utexas-20 A program which might interest you isn't a debugger but a development aid developed by EXXON around 78 in Florham Park, N.J., and EPRCO, Houston. It was a graphics system where you could develop a top down flow-chart with the light-pen. The system would then generate the equivalent code in PL/1. The only way, I'd ever volunteer to produce a flow-chart for a production system, which has to go through a lot of maintenance over the years. I have no idea if they ever published it, but I'd imagine, someone must have given a presentation at some conference. ------ From: Halbert.PA@PARC-MAXC In 1978 I wrote a screen-oriented debugger for MacLisp for my bachelor's thesis at MIT. It is called DIDL. It has breakpoints, single-stepping, stop when condition satisfied, patches, etc. It shows you where you are, in context, in the source code. Not many people ever used it because it needed a little tuning and fixing up, and doesn't run very fast, but a few of my friends used it when they had very recalcitrant bugs that could not be discovered using the more conventional debuggers. [Dan sent me a copy of his thesis and I was impressed with it. Suggested reading for those interested in screen- oriented debugging.] -- I worked at BBN for several years, and used a debugger called BDDT. It wasn't a display debugger, and had some limitations on its capabilities, but was quite useful. It suffered from a not-so-great command interface. More details on request. It was written in BCPL (why not?). -- Several interesting debuggers were developed at Stanford many years ago. RAID, a PDP-10 assembly language debugger, is particularly nice, with many fancy display features. BAIL is a debugger for the SAIL language. ------- Many thanks to those who took the time to reply. Bill Mitchell The University of Arizona whm.arizona@rand-relay arizona!whm