[Chicken-hackers] Thoughts on gdb as a debugger for Chicken

[Tony Sidaway]

I've been thinking about the problem of producing a good, efficient
debugger for Chicken.  As I'm familiar with gdb and it's universally
available I'm concentrating on using gdb to examine the internal C
code.

gdb has a machine interface (GDB/MI) that makes it easy to run gdb as
a component of a larger system.  For instance you could use it to
build a debugging library in a high level language such as Scheme.
This is still in development but it seems to support at least the
capabilities of the normal gdb cli (command line interface).  The
basic mode of operation is to fork a new process and execute gdb with
"-interpreter=mi".  Commands can then be sent through gdb's stdin and
data (including output from the program being debugged) received
through its stdout.  This in my opinion resolves the question of
whether gdb *could* be used as the core of a debugger for Chicken.  I
will now address the question of whether it *should* be used for that
purpose.

The first thing to say about gdb is that it's more or less universally
available, so it's a good fit for Chicken.  It also supports the C
language, which is the underlying language of Chicken.  The gcc
compiler produces C debugging information when the "-g" option is
used, and gdb can interpret this information in any native format.

In its turn, compiled Chicken code provides a lot of information at
runtime that should be accessible to a debugger.  For instance the
symbol table is accessible by calling
runtime.c:CHICKEN_global_lookup(), which returns a gc_root for the
bound object.  C_trace calls in the generated code enable a source
debugger to map the C source (which can be retained by using the "-k"
option to csc) to the Chicken source file.  It might also be possible
to program debugger support by use of an appropriate hook on the
runtime.c:C_trace() function.

So it would be possible to write a high level debugger that sets a
breakpoint on a Scheme statement by looking up the corresponding
location in the C code and using gdb to set a breakpoint in the C
code, and it should be possible to examine the value of a Scheme
variable by instructing gdb to obtain a gc_root as described above,
and then inspect the object and report its contents in a
context-sensitive manner.

I'm not sure if it would be possible to program watchpoints.  It ought
to be possible in principle, I suppose, by recomputing the watched
addresses after each garbage collection.

There are other advantages to using gdb instead of having Chicken
perform its own instrumentation.  Firstly the overhead is much lower;
source level debuggers have been instrumenting C code for decades now
and the technology is pretty mature. It's efficient and fairly
unobtrusive.  Secondly the program being debugged isn't overly warped
by instrumentation--what you see is more or less what would happen in
an uninstrumented program.

As a first step to investigating this possibiluty, I think I'll work
on producing a low level gdb egg for Chicken.  This will probably
support basic GDB-MI operations.