This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gdb + perl


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]