Re: Library interface to GDB

[Jim Blandy <jimb@cygnus.com>]

>    How do other GUIs (DDD, VIDE, etc) currently interface with GDB ?
> 
> Usually by running GDB as a subprocess and controlling all the command
> input and output.  This works better than one might imagine, since the
> GDB commands were specified on the back of the stone tablets that
> Moses brought down from Mt Sinai, and thus don't change often :-), and
> the output has a fairly consistent form as well.

For what it's worth:

I haven't actually had great experiences with this.  Once I tried to
browse a Binary File Descriptor with DDD, and it choked on the
structure, treating the last few dozen members as one big long member
with lots of commas.  I didn't debug it, but it looked pretty clearly
like a parsing problem.

I've run into similar problems trying to use GDBTk with a simulator
--- GDB didn't produce quite what GDBTk was expecting, so GDBTk hung.
If I remember correctly, Jim Ingham (tech lead for GDBTk) has also
said that he has found the approach to be unreliable.

I think that interfaces based on parsing are generally not robust.
The small-scale problem is solveable --- it's not difficult to make
each piece of output GDB produces parseable --- but the large-scale
problem of knowing all the messages GDB could possibly produce at a
certain point is very difficult.

I think it's really bad news to have code parsing output intended for
humans.  A debugger GUI should use an API, not AI. :)