Re: how to use libgdb ?

[Daniel Jacobowitz <drow at mvista dot com>]

On Thu, Sep 19, 2002 at 11:00:37AM -0500, Scott Moser wrote:
> 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.

The point is that there will never be a stable ABI.  Speaking just for
myself, I don't want a hack like this that we can never support.  We
have a machine interface - MI - and it should give you everything you
need; if you think communication with GDB has any performance
implications, you need to think about it a little more.  If you think
there are functionality gains from bypassing MI then MI should be
extended.

For plugins, the right thing to do is to _first_ define an ABI to
export to plugins, and then export it portably via (say) a table of
function pointers.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer