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
From ac131313@cygnus.com Fri May 28 00:28:00 1999
From: Andrew Cagney <ac131313@cygnus.com>
To: gdb@sourceware.cygnus.com
Subject: Re: GDB meeting, Silicon Valley 1999-05-14
Date: Fri, 28 May 1999 00:28:00 -0000
Message-id: <374E4596.46F09793@cygnus.com>
References: <199905110256.TAA08098@andros.cygnus.com>
X-SW-Source: 1999-q2/msg00125.html
Content-length: 1704

Stan Shebs wrote:
> If you can't make it, I expect that we will post a
> summary of the meeting afterwards.

Stan is away on holidays.

I thought I posted the below several days ago, but unfortunately, it is
now looking like it didn't go out :-(

The below was drafted by Stan.  I've since edited it slightly and am now
posting it.

	sorry for the delay,
		Andrew

--

Last Friday (1999-05-14) a group of GDB hackers and other
interested parties got together to discuss the maintenance
of GDB.  The meeting was held at HP's Cupertino CA campus,
and included the following participants:

       Andrew Cagney (cagney@cygnus.com)
       J. T. Conklin (jtc@redbacknetworks.com)
       Robert Dewar (dewar@gnat.com)
       Klee Dienes (klee@apple.com)
       Wes Embry (wes@sgi.com)
       Paul Hilfinger (hilfingr@CS.Berkeley.edu)
       David Metcalfe (crdjm@sgi.com)
       Paul Sanville (sanville@flytrap.cup.hp.com)
       Stan Shebs (shebs@cygnus.com)
       Richard Stallman (rms@gnu.org)
       Mike Vermeulen (mev@cup.hp.com)
       Sanjay Waghray (sw@home.com)
       Todd Whitesel (toddpw@wrs.com)

Much of the discussion focussed on the technical directions
that have been discussed in this forum already (multi-architecture,
multi-process, async debug).  There was also discussion of
using Guile with GTK to build the standard windowed interface
for GDB.

We did agree to form a "steering committee" for GDB.  This
committee (having a size and form similar to the existing GCC
committee) would focus on overall policy for GDB. Day-to-day
maintenance issues would generally continue as before.
Committee membership was not decided at this meeting, and will
be worked out in the coming weeks.

--
From martin@home-of-linux.org Fri May 28 01:32:00 1999
From: Martin Baulig <martin@home-of-linux.org>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: Library interface to GDB
Date: Fri, 28 May 1999 01:32:00 -0000
Message-id: <86hfoxegy4.fsf@localhost.uni-trier.de>
References: <86k8tu9pyj.fsf@localhost.uni-trier.de> <374E319F.54921BD7@cygnus.com>
X-SW-Source: 1999-q2/msg00126.html
Content-length: 902

Andrew Cagney <ac131313@cygnus.com> writes:

> 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).

Yes, I agree. It's nice to have a CORBA interface for gdb, but that should
be separeted from the actual gdb distribution - this can for instance be
handled by applications like dryad.

However, a guile interface really sounds good - especially since this is
the official scripting language. Maybe I can give it a try ...

-- 
Martin Baulig - martin@home-of-linux.org - http://www.home-of-linux.org
From jkamdar@emc.com Fri May 28 07:38:00 1999
From: Jayesh Kamdar <jkamdar@emc.com>
To: Martin Baulig <martin@home-of-linux.org>
Cc: Andrew Cagney <ac131313@cygnus.com>, gdb@sourceware.cygnus.com
Subject: Re: Library interface to GDB
Date: Fri, 28 May 1999 07:38:00 -0000
Message-id: <374EAA39.FCBEBB58@emc.com>
References: <86k8tu9pyj.fsf@localhost.uni-trier.de> <374E319F.54921BD7@cygnus.com> <86hfoxegy4.fsf@localhost.uni-trier.de>
X-SW-Source: 1999-q2/msg00127.html
Content-length: 1547

Sorry for the ignorance ( I am not a developer) but is COBRA an GUI
interface to GDB ?  Is it available on all platforms ?  And where can I
get it from ?  And also, then what is xxgdb, isn't it a GUI gdb ?

Thanks,
Jayesh

Martin Baulig wrote:
> 
> Andrew Cagney <ac131313@cygnus.com> writes:
> 
> > 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).
> 
> Yes, I agree. It's nice to have a CORBA interface for gdb, but that should
> be separeted from the actual gdb distribution - this can for instance be
> handled by applications like dryad.
> 
> However, a guile interface really sounds good - especially since this is
> the official scripting language. Maybe I can give it a try ...
> 
> --
> Martin Baulig - martin@home-of-linux.org - http://www.home-of-linux.org

-- 
_________________________________________________________
    Contrary to popular belief, UNIX is user friendly.
It's just very particular about who it makes friends with
_________________________________________________________
Jayesh Kamdar (Email: jkamdar@emc.com)
EMC Corp.
171 South St., Hopkinton, MA 01748
Ph.: 800-445-2588 x2464  Fax: 508-435-8824
From ovidiu@cup.hp.com Fri May 28 09:04:00 1999
From: Ovidiu Predescu <ovidiu@cup.hp.com>
To: Martin Baulig <martin@home-of-linux.org>
Cc: Andrew Cagney <ac131313@cygnus.com>, gdb@sourceware.cygnus.com
Subject: Re: Library interface to GDB 
Date: Fri, 28 May 1999 09:04:00 -0000
Message-id: <199905281604.JAA12819@hpcll563.cup.hp.com>
References: <86hfoxegy4.fsf@localhost.uni-trier.de>
X-SW-Source: 1999-q2/msg00128.html
Content-length: 2866

On 28 May 1999 10:28:35 +0200, Martin Baulig <martin@home-of-linux.org> wrote:

> Andrew Cagney <ac131313@cygnus.com> writes:
> 
> > 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).
> 
> Yes, I agree. It's nice to have a CORBA interface for gdb, but that should
> be separeted from the actual gdb distribution - this can for instance be
> handled by applications like dryad.
> 
> However, a guile interface really sounds good - especially since this is
> the official scripting language. Maybe I can give it a try ...

IMO libgdb should provide more than a simple interface to the gdb commands.
Ideally it should provide an object-oriented view of the GDB internal
structures. All the GDB structures that are used internally by GDB, frames,
symbols, values, breakpoints and so on, would become classes and would have
methods that operate on them.

If these objects are exported in a scripting language then writing extensions
would be very easy, since you have access to GDB's internals. For example you
could imagine an interface to the outside world that uses the HTTP protocol and
returns the data in an XML format. You could relatively easy build a graphical
user interface that's running in Netscape, just replace the output format of
the data to use HTML instead of XML. Or you can write a Corba interface that
exports these GDB objects or provides an API for building GUIs.

In the WDB project ( http://www.hp.com/esy/lang/tools/Debuggers/WDB/index.html )
we are working on integrating Python into GDB and exporting the GDB structures
as first class objects in it. Python ( http://www.python.org ) is an interpreted
object-oriented language with very powerful capabilities and rich libraries.

With this layer built on top of GDB, you can use a language bridge to export
the Python objects into other languages like Guile or Perl. The Python objects
would appear as native objects in these languages so you could send messages in
a transparent way from Perl or Guile to an object whose implementation is
written in Python. If the bridge is multi-directional, the other way are also
possible, invoking Guile or Perl methods from Python. Such an idea is already
implemented by the ILU project (see ftp://ftp.parc.xerox.com/pub/ilu/ilu.html ).

This way we basically give our users the language of their choice to implement
extensions.

Greetings,
-- 
Ovidiu Predescu <ovidiu@cup.hp.com>
http://www.geocities.com/SiliconValley/Monitor/7464/