This is the mail archive of the gdb@sourceware.cygnus.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Library interface to GDB


Stan Shebs wrote:

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

How do other GUIs (DDD, VIDE, etc) currently interface with GDB ?
Through a library interface (shared or static) ?
Through operating system inter-process communications ?
By faking user input command lines ?
Some other means which is beyond my limited mind to think of ?

I would have thougt that libgdb would be the obvious choice but if it has been in
limbo for a while then there must be another method.

Brendan Simon.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]