This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: plugin interface for GDB
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