Re: plugin interface for GDB

[Thiago Jung Bauermann <bauerman@br.ibm.com>]

On Fri, 2007-04-20 at 12:57 -0700, Brian Dessent wrote:
> > Scott Moser's idea was to have very basic plugin support (loading and
> > unloading), and leave to the plugin writer the work of searching which
> > internal GDB functions he'd need to use and directly call them from the
> > plugin code. I am more inclined to go into a different direction, which
> > is to provide an abstraction layer which would expose functionality
> > which is potentially useful for a plugin.
> 
> You should read the recent threads about adding scripting support to
> gdb.  The one from several months ago
> <http://sourceware.org/ml/gdb/2007-01/threads.html#00126> seemed to
> mostly converge on Python, with tcl and guile as runners up.
> 
> To me it seems like it would be a lot easier to go in that direction
> than to actually allow for plugins in the sense of dynamically loading a
> shared module of compiled code.

I saw that thread. It's certainly very desirable functionality. My
problem is that maybe it would meet my needs, maybe not. Like I just
mentioned in a message to Daniel, we'll be looking at lots of data. I'm
not sure what would be the performance of that...

Also, we have a lot of C code which we'll integrate with GDB, so a layer
of interpreted language is unnecessary to us and just adds complexity.

>   In either case, you have to implement
> some kind of API that exposes the internals of gdb to the plugin or the
> script, and in either case you can extend the functionality of gdb in
> pretty much arbitrary ways.

Agreed. Both features overlap a lot in terms of functionality provided
to users, but I'm afraid they are not completely equivalent. I think
this discussion is a good opportunity to try to determine this.

>   But in the case of scripting you don't have
> ABI headaches to worry about,

You mean keeping binary compatibility with plugins accross different GDB
versions? That's a nice goal, but not worth worrying about too much, I
think.

>  and  it increases accessilbility since you
> can express relatively high level concepts easily in just a short amount
> of python script, compared to having to code the same amount of
> functionality with a C plugin.

Agreed.
-- 
[]'s
Thiago Jung Bauermann
Software Engineer
IBM Linux Technology Center