This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: gdb + perl
- From: Andrew Cagney <cagney at gnu dot org>
- To: Kip Macy <kmacy at fsmware dot com>
- Cc: gdb at sources dot redhat dot com
- Date: Wed, 04 Feb 2004 12:00:08 -0500
- Subject: Re: gdb + perl
- References: <20040130153706.N34716@demos.bsdclusters.com>
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