Re: gdb + perl

[Kip Macy <kmacy at fsmware dot com>]

> 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.

I did that a couple years ago hoping to get in some fixes that I did for
thread support on FreeBSD. Does it still apply, or does one have to
renew it every year?

> > 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.

The code seems pretty well abstracted with various subsystem
initializers. It has something resembling object hierarchies, but
written in C. If anything there is periodically too much layering.
Neither I, nor my employer, have any issue with the GPL when it
comes to areas that are not part of their value add. Their toolchain,
although critical to their functioning, is not part of their value add.

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

I'm in no rush. However, I'm happy that you are at least receptive to
the idea.

> 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.

The motivation for me would be similar to that of mod_{perl, python,
ocaml} for apache. It allows to have a stock system GDB but load in
custom functionality on the fly. I could see something mainstream like
perl or python being accepted in the stock version, but as much I like
ocaml it is fairly obscure. There is a lot of functionality that could
be added to the debugger when one gets beyond the strict notion of
symbol lookups. I readily admit that the "ROI" on the complexity
of adding dynamic loading might not be adequate. Nonetheless, if the
loader could just call the appropriate "_initialize" functions in the
module just the way gdb does at startup for its subsystems, that might
be all you need.

>
> 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?

That is where most of the work is, however, that is not all. This is the
gross part, I actually link in libperl. This isn't the "right" approach
from engineering perspective. However, I'm looking at it from a social
engineering perspective. I wanted to not alter the way GDB was used at
all and yet allow perl to be used in a fashion similar to gdb macro
scripts. I export 2 functions to perl

1) "ext_mi_command" which takes an mi command plus args as a string
and returns what the MI would output to the console.

2) "register_callback" which takes the name of function, its help
string, the number of args, and array containing each of the types.

The drawback to this synchronous approach is it is only good for triage.
It doesn't handle the case of breakpoints being hit. In my defense
triage seems like something much easier to automate. In addition this is
not not be the final implementation. I'm trying to move developers over
to using perl. This is initially more an effort of social engineering
than of technical engineering. In 6 months if I've been successful and
developers feel a need to automated breakpoint debugging I envision a
new architecture, where instead of:

|---------------------------|
|            _________      |
|            |       |      |
| GDB       <-> Perl |      |
|            |_______|      |
|___________________________|



We could have:


|--------------------|    |---------------------|
|       GDB          |    |      Perl           |
|                  <------->                    |
|                    |    |                     |
|                    |    |                     |
|--------------------|    |---------------------|

This will:
1) allow us to avoid the symbol and header collision
garbage that I have to deal with when linking in perl

2) support live debugging automation for triaging problems
on systems to wedged to dump core - but still up enough to
use breakpoints

3) Eliminate any language specific stubs

>
> In recent versions of GDB (6.0, but not 5.3),

Although I made my changes available on 6.0, our in-house GDB is 5.3
for the moment.

> 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.

I'm not familiar with that - I hope I can use that, but I'd almost
certainly have to slice things up somewhat differently. This might ease
my path towards the second architecture. However, it isn't obvious how
that would support a callback mechanism necessary for adding to the
actual command set as define does.

> 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 :)

It is, modulo some "1.0" issues.

Thanks for your support. I appreciate the thoughtful consideration.

			-Kip