A Simple and Extensible Graphical DebuggerBy David Hanson and Jeffrey Korn, Princeton University
Summary by Gordon Galligher
Most debuggers have not changed over the years, other than get more complicated to use. They are very hard to port to new operating systems and languages and are very complex. To combat this problem, David Hanson and Jeffrey Korn (son of David, the originator of the Korn shell) have written an extensible and portable debugger with a graphical user interface.
The designers learned from the past mistakes of debugger writers in that they have kept the debugger's internals down to a minimum. Otherwise a debugger would be needed for the debugger! They have implemented a NUB portion, which is a minimal API consistent for all languages, and a Debugger, which is the same for all languages. The Debugger talks to the NUB, and they even implemented the ability to remotely communicate between the Debugger and the NUB (they communicate via sockets). The NUB can also be embedded into the code itself (i.e., link in the NUB library at the link stage of the program, and then the NUB will invoke the Debugger when the application launches). There is an implementation of the NUB that can work through the /proc filesystem.
The system is called DEET, for Desktop Error Elimination Tool (which is also the name of a semipopular pesticide). The implementation language embedded into DEET is written in TKSH, which is a superset of Tk and Ksh. Jeffrey Korn mentioned that writing it as a superset of the Korn shell was simply to make it easy for the people who write Korn shell scripts to also write debugger tools. He also mentioned that he wanted to go home for the holidays.
Having the configuration language written in TKSH provides DEET with excellent interactive support (via ksh) and a graphical interface (via Tk). It also makes it easy for the compiler to periodically save its state, because it simply has to write a shell script that can then be reinvoked to continue the debugging session later!
There are some drawbacks to the existing implementation that should be fixed in the future. It cannot interrupt a target, it cannot attach to an already running target, and it cannot work with core files. If the program goes off into never-never land and never reaches a breakpoint, the only way to get back into the Debugger is to restart it and then set more breakpoints. Because DEET cannot attach to an already running process, DEET must be used to start the process and then debug it or have the compiled-in NUB launch DEET. It has the ability to work with various core files, but the support is not yet implemented.
It is very extensible and compact-800 lines for DEET itself and 1,500 lines for the User Interface of DEET. Compare this to the tens of thousands of lines for a debugger such as GDB. There is a reference port of a NUB that knows how to communicate with GDB, so if the program can be debugged with GDB, then it can be minimally debugged with DEET.
The DEET program can be obtained via the following URL: https://www.cs.princeton.edu/~jlk/deet. DEET is written in TKSH, which can be purchased/obtained from AT&T.
Originally published in ;login: Vol. 22, No.2, April 1997.
Last changed: May 28, 1997 pc