Re: Library interface to GDB

[Andrew Cagney <ac131313@cygnus.com>]

Martin Baulig wrote:

> 
> The gdb source code (4.18) contains a file gdb/doc/libgdb.texi which has
> been last modified in November 1993. This libgdb ist last mentioned in the
> ChangeLogs in 1994/95. In the internals manual I finally found a note that
> this "project" was aborted. On the other hand, I still find some references
> to it at least the Makefile.in, but I remember having seen something about
> it in the code itself.


Yes, if you look carefully at the code you'll probably notice many
things that have been structured in strange or mysterious ways.  I just
deleted several of them (the functions in question were empty):

Tue May 25 15:20:58 1999  Andrew Cagney  <cagney@amy.cygnus.com>

        * main.c (init_proc, proc_remove_foreign): Delete function.
        * inftarg.c (child_mourn_inferior): Update. Delete call to
        proc_remove_foreign().
        * top.c (gdb_init): Update. Delete call to init_proc().

My understanding (third hand?) is that at the time (back in '94/95)
libgdb proved to be one of those `good ideas'.  The sort of thing that
sounds good after one too many drinks :-)  What did come from it,
though, was a number of goals that would allow GDB to evolve into a more
powerful architecture better suited for things like GUI's.

To give a real example:

Elena, Stan (and many others) have just released the re-worked GDB that
includes an event loop (it is often referred to as async).  An event
loop is the sort of basic infrastructure needed in a debugger if it is
ever going to function correctly within a GUI or be embedded in a
library.  Without it, when blocked waiting for a target, the debugger
_IGNORES_ all other input sources (such as its CORBA interface).

As a testament to the quality of this work, it was completed in a way
that allows GDB to continue to function on all the existing
host-X-target combinations.

It would be interesting to know how many of the ``libgdb''
implementations people have so far put forward actually addressed this
fairly fundamental technical issue.


> What is the current status for libgdb, is it still supported or already
> removed or whatever ... ?


That project, as you note, was aborted long ago.  Many people have,
however, set out and achieved similar goals with varying degrees of
success.


> Basically I want to write a GNOME frontend for gdb, but not just
> "yet another gdb frontend", but *the* gdb frontend. Ideally it should
> export all its functionallity through CORBA so you can also use it in
> other projects like GNU Emacs, KDE or whatever.


With respect to CORBA, I see that one person mentioned that they had
implemented an interface by coding a parser of GDB's output.  To me,
this sounds like taking things in the wrong direction.  It is the sort
of solution used when talking to an unchanging legacy system.  GDB,
while old, is neither un-changing nor legacy :-)  GDB's  CLI is
definitely going to continue to evolve.

If there is going to an interface added to GDB then I think that it
should be implemented in a way that lends its self to maintainability
over a longer time frame.  While a CORBA interface is flavor of the
month, I believe that other people have different (although potentially
related) ideas. RMS, for instance, has pointed out that GDB should have
an interface that allowed scheme/guile to be integrated (as the official
scripting language).

(I like others have further thoughts on this but this e-mail is a big
enough chunk for now :-)

	enjoy,
		Andrew