gdb + perl

[Andrew Cagney]

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