kc@rna.UUCP (Kaare Christian) (12/24/84)
I recently reviewed Mark Williams csd (C Source Debugger) for PC magazine. The review was submitted in early Oct. and it has not yet appeared. Should be in print "real soon now." csd is a source language debugger that works with (and is sold with) Mark Williams C compiler for the IBM PC. Since csd is written in C, it may be available for other environments. csd will not work with other vendor's C compilers. Programs to be debugged must be compiled specially. You cannot debug LARGE model programs or programs that use the 8087. You also cannot debug programs that use modules from other language systems. (Note: MWC86 lets you use the large model, it emulates the 8087 or generates 8087 code, and it lets you link to obj files from other language systems via standard dos object files. csd's failure to support these compiler extensions doesn't make me think less of the product.) You debug a program by running it from withing the csd "shell." Programs compiled for debugging will also run independently, the difference is the size of the symbol table. I liked csd, but with a few reservations. I think its an excellent "learn to program in C" tool, and a respectable debugger. csd is easy to use. It uses the function keys for most commands, and has a useful info display system. csd has most of the functionality of dbx, but it is easier to use. It doesn't have any machine language features. (Don't we all need to peek at memory sometimes?) There are three separate display screens: 1. The execution screen. This is displayed while your program is running. 2. The debugging screen. This screen shows source code in its top half, and expressions in the bottom. When you encounter a tracepoint, the source window automagically scrolls to the trapped line. The expression window lets you enter any legal C expression or subr. It checks syntax as you type things in. This can be aggravating, and it can be neat. You can set a tracepoint on an expression and the program will halt when the expression changes value. 3. The history window shows a list of all of your recently encountered tracepoints. I didn't find it to be very useful, but it probably would be helpful for some types of debugging. csd is a great browsing program. You can set tracepoints at the beginning and end of subrs. and look at their local variables. You can put traces in loops and watch things change. You can trace "loop invariants" in the expression window and the program will stop if the supposed invariant changes. You can also impose sanity checking on pointers by entering a range test in the expression window and then tracing that expression. Problem 1: Tracing expressions causes the traced program to run slowly. This is because the program traps after each C statement so that csd can check to see if a traced expression has changed its value. I measured the speed-down at over 1000x. If you trace an expression, a loop that used to take 1 ms. will now take a second. I/O bound routines slow down less than CPU bound, because the expression tracing is off during calls to dos. Tracing statements doesn't slow down execution speed. Problem 2: Weirdness with the stack is a common C problem, but I didn't have any luck in getting csd to help me find those problems. A program that ran out of stack when running outside of csd worked fine in csd because more space was available. You can't debug it using csd if it isn't broken. A subr that expected an argument (but wasn't getting it) blew up csd's stack trace facility. Just when you need it ... In my opinion, csd provides a good reason to pay the premium for MWC86. I would strongly recommend csd for people learning C. A friend of mine (C novice) who tried csd explored pointer arithmetic and pointer dereferencing in the expression window. After a few minutes he began to understand pointers, a subject that had previously seemed mysterious. MWC86 is a unixlike compiler. It supports the unix options, all of the standard Unix subrs and many system calls, etc. MWC86 supports dos pathnames, standard command line arguments can be stored in PCDOS shell variables, its easy to use (No bulky batch files) and works well. Its a complete C implementation. I looked at a Lattice C manual a few days ago. The list of differences between Lattice C and K+R C seemed large, and then in browsing through the reference section I discovered further incompatibilities between Lattice and K+R. I don't have similar reservations about Mark Williams compiler. Comments, further questions, etc. are welcome. Kaare Christian The Rockefeller U. uucp:cmcl2!rna!kc bell:212-570-7672