From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13811 invoked by alias); 4 Feb 2004 04:13:43 -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 13801 invoked from network); 4 Feb 2004 04:13:41 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 4 Feb 2004 04:13:41 -0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1AoEPz-0003m7-FN; Tue, 03 Feb 2004 23:13:39 -0500 Date: Wed, 04 Feb 2004 04:13:00 -0000 From: Daniel Jacobowitz To: Kip Macy Cc: Kevin Buettner , gdb@sources.redhat.com Subject: Re: gdb + perl Message-ID: <20040204041339.GA14314@nevyn.them.org> Mail-Followup-To: Kip Macy , Kevin Buettner , gdb@sources.redhat.com References: <20040130153706.N34716@demos.bsdclusters.com> <20040130193848.B41210@demos.bsdclusters.com> <20040203140551.53a2052c@saguaro> <20040203192253.D36518@demos.bsdclusters.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040203192253.D36518@demos.bsdclusters.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2004-02/txt/msg00018.txt.bz2 Throwing in my two cents. On Tue, Feb 03, 2004 at 07:30:59PM -0800, Kip Macy wrote: > I happen to really *not like* perl. However, this is targeted at the > developers at my company who predominantly do like perl. I don't know > what would be the ideal language. I've actually started ocaml support. > As far as mainstream scripting languages go, I would've chosen python. > I've structured the such that the only real work is writing a parser > for MI output in the target language. I export the MI functionality and > callback mechanism through a language independent interface. Great... > I would add support for guile if doing so would get the FFI code > incorporated into mainline GDB. Greater.... > > I haven't looked at your work at all yet. Do you think it would be > > possible to develop an extension language API that could be used by > > perl as well as other extension languages? > > That wouldn't be a giant leap. And really awesome. Kip, have you / could you file the copyright assignment paperwork for GDB? That's a necessary first step to including any code. > > That way, it'd be possible > > to do extension language plugins, of which your work would be one. > > It'd also be possible (and easier) to maintain the code you've written > > independent of mainline GDB. > > On a more general note I'd like to see loadable module support added to > GDB. This would allow people to maintain GDB extensions independently of > GDB. There are a number of things that I see adding to GDB that are only > interesting if you have a very large complex system and hence would > never be interesting for the majority of GDB users. We've talked about this before. There are a couple of problems; the biggest is that the only advantage of a loadable plugin over a source patch is if you think you can use it to play games with the GPL. The biggest disadvantages of plugins are that you have to develop an API that lets the plugins do what they want to do. GDB really isn't laid out that way. Now, if you happen to have a brilliant idea on how to make it work... :) The most frequent need for "plugins" that I encounter is custom module loaders; the Linux kernel's, XFree86's, et cetera. This could be done with a sufficiently well-integrated scripting language, and that's a safer and simpler way to do it. I took a look at your documentation, but not your code. Basically, it looks like you are creating a Perl binding to the MI interface - right? In recent versions of GDB (6.0, but not 5.3), there is a console command "interpreter-exec" that can be used to have a little dialog with with another interpreter; either the MI or console interpreters. That may simplify your changes. It would be really neat if you could expose MI directly and then implement the rest on the Perl side as functions which issue and parse MI; then you wouldn't need to add to each binding when new MI commands are added. That may be what you do already for all I know :) -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer