Mark Williams csd

[Kaare Christian]

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