Re: plugin interface for GDB

[Daniel Jacobowitz <drow at false dot org>]

On Fri, Apr 20, 2007 at 06:21:11PM -0300, Thiago Jung Bauermann wrote:
> I agree that a plugin interface and a scripting language overlap a lot
> in terms of functionality. I'm not sure it would cut it in my specific
> case... I'm looking at something which will potentially need to examine
> 10's of GB of inferior memory in some cases and I'm a bit worried about
> the performance. If there was already scripting language support in GDB,
> I could do some benchmarks. It's quite possible that the overhead of the
> scripting language would be low or acceptable. But right now I don't
> want to work (probably a lot) on developing such support only to find
> out it won't meet my performance needs... :-)

Well, it's going to get developed eventually in either case.  If you
can't write things fast enough in Python, Python itself lets you load
C modules to do the real work; the question is how fast GDB can
provide memory access to the Python layer.  And I think the answer is
roughly as fast as GDB could get at it directly.

> We want to add support in GDB to debug both IBM's JVM and programs
> running on top of it at the same time. It could go into GDB proper,
> except that we need to keep our modifications internal and I want to
> minimize the burden of porting the code to new GDB releases, so I don't
> want to mess too much with the guts of GDB. (objectionable motivation, I
> know. But these are the constraints I need to work with).

Not surprising constraints.  The trick, for you and for us, is to
minimize the amount of it is local to IBM and specific to the JVM.

> As I said, a plugin interface is a good answer to that need, and I'll
> probably do such interface even if only to keep it internal.
> 
> I believe there are other people in the same situation as mine. I've
> seen messages here stating something like "I'm using an old version of
> GDB because I customized it and still didn't port the code to a newer
> version". A plugin interface would help those people.

This, you see, is the part I don't believe.  I think that a _perfect_
plugin interface would help.  You get to draw your own conclusions on
how likely that is :-)

> > 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!
> 
> I think you'd be surprised. :-)
> 
> I was. In a very short time we were able to come up with a working
> prototype which provides very little functionality (basically, just
> interaction with the user and peek inferior memory) but at the same time
> is enough to meet some of our needs.
> 
> Of course there's a long way to go from there, and code will start
> getting more complex. But if it's useful enough, the maintenance burden
> is bearable.

The question is what you need, and how easy it is to expose in another
way.  I did a prototype of Guile integration in just a couple of days
that did basically the same amount you've got here; and if I'd done it
in Python (being a language I can actually write things in, unlike the
staggering around I do in Guile), it could even have been useful.

-- 
Daniel Jacobowitz
CodeSourcery