Re: Library interface to GDB

[Stan Shebs <shebs@cygnus.com>]

   From: Martin Baulig <martin@home-of-linux.org>
   Date: 27 May 1999 23:12:52 +0200

Hi, I'm just catching up with my mail.  It looks like everything has been
pretty well discussed already, so I'll throw in a couple extra points.

   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.

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

There were actually two projects that went on - one was Cygnus' first
attempt to build a GUI (which failed to produce anything usable and
was killed off), and then later Cygnus had a contract to enable GDB
to work as a component of a fancy parallel debugging system.  For both
of these "libgdb" was a nice-to-have, not a requirement, so you ended
up with the situation you see now, where things were started but not
finished.

So right now libgdb work is in limbo.  Since I figured it would
restart someday, I left the docs and other bits in, so people wouldn't
have to reinvent any wheels.  There seems to be a resurgence of
interest in adding different kinds of frontends to GDB, so this seems
like a good time to get moving on it again...

   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.

The GNU project would like to see somebody do the GDB + Guile + gtk +
Gnome combination, so if you work on that, you will have people
cheering you on.  An internal GDB API ("libgdb") is not a base
requirement for this, but to me is simply good software engineering -
since you will end up with both a command-line interface and a
compiled-in GUI, libgdb will be the result of factoring the code into
interface and debugger subsystems.

As for the design of the API, Ovidiu's message is a good discussion of
a key point, namely, that the API should be object-oriented.  Not in a
literal sense, since there needs to be a plain C implementation of it,
but logically, since GDB maintains large amounts of internal state,
and a reasonable API would be expressed in terms of operations on the
objects that make up that state.

								Stan
From shebs@cygnus.com Mon Jun 07 17:20:00 1999
From: Stan Shebs <shebs@cygnus.com>
To: kettenis@wins.uva.nl
Cc: gdb@sourceware.cygnus.com
Subject: Re: Debugging dynamically linked executables
Date: Mon, 07 Jun 1999 17:20:00 -0000
Message-id: <199906080020.RAA11496@andros.cygnus.com>
References: <199905081445.QAA06947@delius.kettenis.nl>
X-SW-Source: 1999-q2/msg00142.html
Content-length: 895

   Date: Sat, 8 May 1999 16:45:39 +0200 (CEST)
   From: Mark Kettenis <kettenis@wins.uva.nl>

   AFAICT it is not possible to make gdb stop at the first instruction
   that will be executed for a dynamically linked executable (which will
   probably be the first instruction of the dynamic linker).  

   [...]

   I was thinking about adding an option (suggested name
   stop-on-startup), so that people could say "set stop-on-startup 1".

   Would this be acceptable?

I read this, and got a sense of deja' vu (not dejagnu :-) ) about
having discussed this with Richard Henderson and Ulrich Drepper at
some point, in connection with debugging dynamic loaders...

In any case, the idea of a stop-on-startup option seems reasonable
to me.  Since it's not a normal user option, you would probably want
to put it into the "obscure" class, perhaps even make it a maintenance
command.

							Stan