From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19792 invoked by alias); 4 Feb 2004 17:00:08 -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 19782 invoked from network); 4 Feb 2004 17:00:07 -0000 Received: from unknown (HELO localhost.redhat.com) (216.129.200.20) by sources.redhat.com with SMTP; 4 Feb 2004 17:00:07 -0000 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 9D5702B92; Wed, 4 Feb 2004 12:00:08 -0500 (EST) Message-ID: <40212518.3080706@gnu.org> Date: Wed, 04 Feb 2004 17:00:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030820 MIME-Version: 1.0 To: Kip Macy Cc: gdb@sources.redhat.com Subject: Re: gdb + perl References: <20040130153706.N34716@demos.bsdclusters.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-02/txt/msg00027.txt.bz2 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