Re: gdb + perl

[Daniel Jacobowitz <drow@mvista.com>]

Throwing in my two cents.

On Tue, Feb 03, 2004 at 07:30:59PM -0800, Kip Macy wrote:
> I happen to really *not like* perl. However, this is targeted at the
> developers at my company who predominantly do like perl.  I don't know
> what would be the ideal language. I've actually started ocaml support.
> As far as mainstream scripting languages go, I would've chosen python.
> I've structured the such that the only real work is writing a parser
> for MI output in the target language. I export the MI functionality and
> callback mechanism through a language independent interface.

Great...

> I would add support for guile if doing so would get the FFI code
> incorporated into mainline GDB.

Greater....

> > I haven't looked at your work at all yet.  Do you think it would be
> > possible to develop an extension language API that could be used by
> > perl as well as other extension languages?
> 
> That wouldn't be a giant leap.

And really awesome.  Kip, have you / could you file the copyright
assignment paperwork for GDB?  That's a necessary first step to
including any code.

> > That way, it'd be possible
> > to do extension language plugins, of which your work would be one.
> > It'd also be possible (and easier) to maintain the code you've written
> > independent of mainline GDB.
> 
> On a more general note I'd like to see loadable module support added to
> GDB. This would allow people to maintain GDB extensions independently of
> GDB. There are a number of things that I see adding to GDB that are only
> interesting if you have a very large complex system and hence would
> never be interesting for the majority of GDB users.

We've talked about this before.  There are a couple of problems; the
biggest is that the only advantage of a loadable plugin over a source
patch is if you think you can use it to play games with the GPL.  The
biggest disadvantages of plugins are that you have to develop an API
that lets the plugins do what they want to do.  GDB really isn't laid
out that way.

Now, if you happen to have a brilliant idea on how to make it work...
:)

The most frequent need for "plugins" that I encounter is custom module
loaders; the Linux kernel's, XFree86's, et cetera.  This could be done
with a sufficiently well-integrated scripting language, and that's
a safer and simpler way to do it.

I took a look at your documentation, but not your code.  Basically, it
looks like you are creating a Perl binding to the MI interface - right?

In recent versions of GDB (6.0, but not 5.3), there is a console
command "interpreter-exec" that can be used to have a little dialog
with with another interpreter; either the MI or console interpreters. 
That may simplify your changes.  It would be really neat if you could
expose MI directly and then implement the rest on the Perl side as
functions which issue and parse MI; then you wouldn't need to add to
each binding when new MI commands are added.  That may be what you do
already for all I know :)

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer