Re: how to use libgdb ?

[Scott Moser <ssmoser at us dot ibm dot com>]

On Thu, 19 Sep 2002, Daniel Jacobowitz wrote:

> On Thu, Sep 19, 2002 at 09:38:40AM +0530, Biswapesh Chattopadhyay wrote:
> > Hi list
> >
> > I'm one of the developers of Anjuta (http://anjuta.sf.net/), an IDE for
> > GNOME. Currently, we are using a spawned subprocess for GDB interaction.
> > This works fairly well, but obviously a shared library with a nice (and
> > reasoinably stable) API would be very helpful for IDE developers. So, my
> > question is: if GDB build process already builds libgdb.a, would any
> > patches to make it build a shared libgdb.so be accepted into the main
> > tree ? It might be very useful, for example, for gnome-debug, which is
> > an upcoming component for debugging applications using a nice GUI
> > interface. This might speed up the responsiveness and enable us to do
> > more advanced stuff (such as tracing multiple threads simultaneously).
>
> They would probably not be accepted - or useful, since we don't plan to
> maintain a stable ABI.  What we do maintain is a stable
> machine-parseable interface - MI.  See the documentation or list
> archives for more about that if you're not familiar with it.

   While its not my place to say whether or not the patches would be
accepted, I do think they would be at least somewhat useful.
   The ABI doesn't need to be stable right away, or even any time in the
near future.  But it does seem like some people have an interest in
seeing a libGDB in the short term and for sure in the long term.
   I can think of many benefits to moving gdb to a small application
that gains gets all its functionality from a library, but can't think of
many cons.
   pros:
      allow other projects to use libgdb.so (while they know that it is
not a stable backwards compatible ABI)
      performance and functionality gains over the fork and pipe method
for those apps.
      through the use of libgdb.so by early adopters, learning what
people would use it for, how they would use it... so that a better
stable ABI *could* be made later.
      allow plugins/extensions to gdb to be written in a much more cross
platform manner.

   cons:
      implied ABI stability.

   My feeling is that the pros outweigh the cons in this situation.  the
implied ABI stability is only *implied*.  One suggestion to make sure no
one thinks that you're implying it is would be to just printf inside _init() of
that library with something like the following if the main executable
isn't named gdb:
   "This is not a stable ABI.  You probably shouldn't be using it unless
you *really* know what you're doing.  And even then, maybe you shouldn't
be using it.  Also, this code is GPL, if your application uses it, then
it are bound to the terms of the GPL."

   What would it really hurt to have take this step now?  Please feel
free add more negitive affects of doing this, maybe I'm just missing
something.

Scott Moser
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
(512) 838-1533   T/L: 678-1533
ssmoser@us.ibm.com , internal zip: 9812