Re: gdb + perl

[Kip Macy <kmacy at fsmware dot com>]

It was clear just by looking at the dispatch table in mi-cmd.c that the
MI implementation wasn't even as complete as the documentation. However,
fleshing out the MI as the need arises seemed much cleaner than any of
the alternatives. I am actually quite happy with the MI infrastructure
itself. I'd be happy to flesh out needed bits of the implementation over
time.

			-Kip




On Wed, 4 Feb 2004, Andrew Cagney wrote:

> Kip,
>
> This comes up often.  The theory is roughly as follows:
>
> - At present MI is implemented using a hybrid of internal grubbing and
> relatively clean interfaces.  It has warts and all:
>
> -- the breakpoint code is a mess (and further changes will just make it
> worse)
> -- the disassembler is relatively clean
> -- the varobj code is relatively clean (but needs a frame ID overhaul)
> -- the stop code and event handling is a mess
> -- the lack async in targets hurts
> -- it doesn't use observers
>
> - The MI interface is tested (relative to the CLI it's very well tested)
>
> - The intent is for the MI to split into a thin vineer (the MI cli) and
> a "libgdb" like interface.
>
> If anyone is going to look to binding GDB to their favorite interpreter
> they will also need to work on MI and its internal interfaces.  I think
> they would reasonably be expected to contribute the binding code to the FSF.
>
> (Before you ask, GDB's licence won't be changed from GPL :-)
>
> If you're looking for an example of how to not do things, study Red
> Hat's Insight.  It grubs around with all sorts of GDB internals, it
> pokes fingers where they should never go.  Something aproaching a clean
> integration would be a significant task (I'm working on the legal hurdle).
>
> Andrew
>
>