From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6886 invoked by alias); 4 Feb 2004 17:36:40 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 6869 invoked from network); 4 Feb 2004 17:36:38 -0000 Received: from unknown (HELO demos.bsdclusters.com) (69.55.225.36) by sources.redhat.com with SMTP; 4 Feb 2004 17:36:38 -0000 Received: from demos.bsdclusters.com (demos [69.55.225.36]) by demos.bsdclusters.com (8.12.8p1/8.12.8) with ESMTP id i14HaZ08035654; Wed, 4 Feb 2004 09:36:35 -0800 (PST) (envelope-from kmacy@fsmware.com) Received: from localhost (kmacy@localhost) by demos.bsdclusters.com (8.12.8p1/8.12.8/Submit) with ESMTP id i14HaZN9035650; Wed, 4 Feb 2004 09:36:35 -0800 (PST) X-Authentication-Warning: demos.bsdclusters.com: kmacy owned process doing -bs Date: Wed, 04 Feb 2004 17:36:00 -0000 From: Kip Macy X-X-Sender: kmacy@demos.bsdclusters.com To: Andrew Cagney cc: gdb@sources.redhat.com Subject: Re: gdb + perl In-Reply-To: <40212518.3080706@gnu.org> Message-ID: <20040204092828.G92534@demos.bsdclusters.com> References: <20040130153706.N34716@demos.bsdclusters.com> <40212518.3080706@gnu.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2004-02/txt/msg00030.txt.bz2 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 > >