Re: plugin interface for GDB

[Daniel Jacobowitz <drow@false.org>]

On Fri, Apr 20, 2007 at 04:43:48PM -0300, Thiago Jung Bauermann wrote:
> I am interested in developing a plugin interface for GDB, and would
> like to know what are your thoughts about it. Would you find such
> feature useful?  Would it be integrated into GDB?

I don't think it very likely that we would add a C plugin interface.
We've discussed the disadvantages many times before.  But at the same
time, I'm very interested in a "plugin"-like system using a scripting
language.  You can find a discussion about using Python earlier in
this year's archives.

In my opinion the main difference is the character of the interface;
using a scripting language has plenty of inherent advantages, plus it
makes it clear that you do not get to grub around in any other bit of
GDB, period, no matter how clever you think you are.

> - enable seamless debugging of programs written in multiple languages
>   (Java + C, Python + C, etc) (in fact, this is the reason I need the
>   plugin interface.)

What does this have to do with a plugin?  That is, why is a plugin
useful for it, rather than additional support in GDB proper?  It's a
very vague problem statement - an interesting one, though.

> - lessens the need to maintain custom GDBs. You just use a standard GDB
>   and write a plugin (or use an existing one). If you decide to upgrade
>   GDB, you won't need to port your code and not even recompile the
>   plugin (ideally, if we manage to design a resilient interface).
> 
> - allow people outside of the core GDB team to implement distribute and
>   test their plugins without modifying GDB.
>   
> - lowers the bar to creating modifications to GDB (exposes a well
>   defined interface, so there's no need to learn the ins and outs of
>   GDB to write the plugin you need/want)

Remember, we want GDB contributors!  That's the whole point - getting
people to contribute.  So for things that would be generally useful,
which all of the above are, helping people do them without
contributing to GDB is entirely the wrong way round.

I do not believe that you can come up with an abstraction layer big
enough to be useful that is not a significant maintenance burden for
the GDB developers.  I've been surprised before, though!

-- 
Daniel Jacobowitz
CodeSourcery