libGDB architecture

Ovidiu Predescu
Tue Aug 31 17:40:00 GMT 1999


Sorry for being so late, but only now I had some time to read through the
libGDB architecture proposal thread.

Andrew, please correct me if I'm wrong here. My understanding of the proposal
is that we'll have an abstract layer on top of GDB that receives commands
through an input stream and spits out the GDB internal structures in a given
format, that could easily be changed to meet one's particular needs. There are
at least two obvious advantages for such an approach: (1) there is no need to
change much of the GDB's internals in order to support it and (2) a libGDB
client could be implemented in any language, since there's no coupling between
the two layers.

Here are some of my observations of what's going on so far.

>From the the work that Jim Ingham, Tom Tromey, Keith Seitz, Martin Hunt and
others did inside Cygnus on the gdbtk interface, from my previous experience
with a Perl prototype and the current Python integration work we're doing here
and from the work that Martin Baulig is doing on the Guile interface, it looks
like we need a more tightly coupled interface with GDB. It seems that what we
really need is the ability to have access to the internal GDB structures and
functions directly and not through an additional layer, which adds a certain
amount of burden in how you deal with GDB internals.

It also looks like there is a lot of code duplication in all these glue layers.
Things like getting the backtrace, finding the function name given a pc and
lots more are copied from various places in GDB in all these clients. This is
not a good thing since it doesn't promote code reuse. In addition, fixing a bug
somewhere requires fixes in the other places that copied the code.

This happens because GDB's code does not make a clear distinction between the
parts that do actual computation and the ones that print out the results. I
think we should try to separate the two parts and have computation functions
and associated printing functions. Computation functions should just create
structures or set-up global values that are used later on by the printing
functions. These would just walk on existing structures and print out their

With this approach it's a lot easier to glue on top of GDB clients like gdbtk,
Guile, Python or whatever else, because all we have to do then is just export
the functions that we need using SWIG and they automagically appear as native
functions in the interpreted languages that SWIG supports (Tcl, Guile, Python,
Perl and even Java).

The next thing after this is to figure out a way to have all these languages
share code and data between them. Imagine that there is a piece of code which
you need in Guile, but you don't want to rewrite it in Python in order to be
able to use it. Having the ability to call Guile code from Python and passing
back and forth data in and from your favorite language would be very nice. The
idea is to have people scripting GDB in Perl, Guile, Tcl or Python, all at
once, from the same binary. This would be the true freedom of the user ;-)! But
this is a completely different story...

Does the approach of separating the functionality inside GDB sound reasonable?
I know that there's a lot more work than what Andrew proposed but I think this
will help us a lot in the long run.


Ovidiu Predescu <>  (inside HP's firewall only)

More information about the Gdb mailing list