info-vax@ucbvax.ARPA (10/30/84)
From: Robert Wells <rwells@bbn-spca> I got a demo last week of CDEBUG from OASYS, Inc., 60 Aberdeen Ave., Cambridge, MA 02138 (617)491-4180. CDEBUG is a C source level symbolic debugger available across a range of operating systems and machines including VMS, 4.2BSD, MS-DOS, and various 68000 systems. CDEBUG was developed by Complete Software Inc. and costs $2500 for vax binaries, $500 for ibmpc binaries. They offer separate versions for both VAX C and Whitesmiths C on VMS. The demo I got was quite impressive; CDEBUG understands the C data structures in your program better than any debugger I have ever seen. You can type in complicated data references involving arrays, fields in structures, etc., and it does command completion on each component so you don't have to do much real typing. It prints pointer values symbolically when it can; probably the most impressive point in the demo for me was when we typed the value of a pointer, and it came out as something like "x[5] in frame 3", i.e. it figured out automatically and quickly that it was pointing into a calling stack frame, and which element of a local array it was pointing at. It handles stack backtraces and examining previous frames quite nicely. CDEBUG is strongest on knowing data structures, but you can also set breakpoints, tracepoints (print msg and keep going), and single step. Ordinarily you can only break/trace/step on function entry/exit, but with recompilation you can get breakpoints at the line/statement level. It has a strong facility for calling routines from the debugger, and even doing debugging recursively on those routines. It has a whole journalling and command file facility that lets you stop a debugging session and later replay it back to where you were, or a bit before if you edit the command file; very nice for those times when you go one step past the problem. CDEBUG has two operational components: a preprocessor and a runtime library. The preprocessor analyses your code and introduces symbol tables as initialized data structures with names that start with "_0" through "_9"; breakpoints are done by introducing calls to a debugger break function at breakable points. The user provides a configuration file that lists all the source files, and this is used by the preprocessor to construct a master symbol table that links together all the symbol tables for the files. The runtime library parses user commands, handles the symbol tables, and fields breakpoints; you can also link with the system debugger and shift between debugging at symbolic and machine levels. There are hooks in the runtime library for fielding ^C and machine traps, and it does this on VMS. The complete source for the runtime library along with the binaries is available for $5000, and a target market they are very interested in is cross compilers, where the preprocessor and compiler are on the vax or 68000 host, and the runtime library and program are on some target microprocessor. On VMS the developer claims that the overhead typically runs ~40% increase in object size, and ~100% increase in speed, with a considerable variance related to program style. For most programs a big speed factor is that the preprocessor normally strips out register declarations, as it needs an address to be able to examine a variable in the debugger. You only preprocess the modules you wish to be able to see in the debugger, and you have considerable control over what the preprocessor does. I think the biggest disadvantage of CDEBUG is that it requires you to setup your program for debugging in advance, by running this preprocessor as part of compilation on parts of the program that you wish to debug; but that isn't so different from compiling with a debugging switch turned on. Because extra code is introduced, the debugging objects may have noticably altered timings even when you are not actually debugging, but up to a factor of two seems tolerable for most programs. One may end up maintaining two sets of objects, one for debugging and one for benchmarking. The main facility missing is a capability to print out source code lines, particularly the lines associated with breakpoints and single-stepping, and an ability to view selected sections of the source to help pick good places for breakpoints. It seems to know where all the possible breakpoints are in terms of file and linenumber, so this shouldn't be too hard. Like most other debuggers it doesn't normally work hard to handle programs that have handlers for ^C and traps themselves, or that do fancy screen handling; but even with the binary only version you get the sources for the system interface routines the debugger uses for trap handling and terminal i/o, so one can hack in special code for special programs. There may be other infelicities that I did not notice in the demo but will find in using it. I expect that we will buy a copy of CDEBUG for our development VMS machine, and may also buy a source copy to port to a currently unsupported machine for which we are doing C development. It looks like a good product to me. OASYS also offers a number of other C development tools. I have no relation to either OASYS or Complete Software, except as a potential customer. -Robert
info-vax@ucbvax.ARPA (10/30/84)
From: Paul Schauble <Schauble@MIT-MULTICS.ARPA>
Does anyone know of a symbolic debugger that works with the VMS C
compiler?
Thanks,
Paul