From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32741 invoked by alias); 20 Apr 2007 20:00:14 -0000 Received: (qmail 32723 invoked by uid 22791); 20 Apr 2007 20:00:12 -0000 X-Spam-Check-By: sourceware.org Received: from return.false.org (HELO return.false.org) (66.207.162.98) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 20 Apr 2007 21:00:08 +0100 Received: from return.false.org (localhost [127.0.0.1]) by return.false.org (Postfix) with ESMTP id 38B054B26F; Fri, 20 Apr 2007 15:00:06 -0500 (CDT) Received: from caradoc.them.org (dsl093-172-095.pit1.dsl.speakeasy.net [66.93.172.95]) by return.false.org (Postfix) with ESMTP id F2C8B4B26D; Fri, 20 Apr 2007 15:00:05 -0500 (CDT) Received: from drow by caradoc.them.org with local (Exim 4.63) (envelope-from ) id 1HezH2-0007Tu-QL; Fri, 20 Apr 2007 16:00:04 -0400 Date: Fri, 20 Apr 2007 20:00:00 -0000 From: Daniel Jacobowitz To: Thiago Jung Bauermann Cc: gdb ml Subject: Re: plugin interface for GDB Message-ID: <20070420200004.GB28401@caradoc.them.org> Mail-Followup-To: Thiago Jung Bauermann , gdb ml References: <1177098228.20179.10.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1177098228.20179.10.camel@localhost.localdomain> User-Agent: Mutt/1.5.15 (2007-04-09) X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2007-04/txt/msg00127.txt.bz2 On Fri, Apr 20, 2007 at 04:43:48PM -0300, Thiago Jung Bauermann wrote: > I am interested in developing a plugin interface for GDB, and would > like to know what are your thoughts about it. Would you find such > feature useful? Would it be integrated into GDB? I don't think it very likely that we would add a C plugin interface. We've discussed the disadvantages many times before. But at the same time, I'm very interested in a "plugin"-like system using a scripting language. You can find a discussion about using Python earlier in this year's archives. In my opinion the main difference is the character of the interface; using a scripting language has plenty of inherent advantages, plus it makes it clear that you do not get to grub around in any other bit of GDB, period, no matter how clever you think you are. > - enable seamless debugging of programs written in multiple languages > (Java + C, Python + C, etc) (in fact, this is the reason I need the > plugin interface.) What does this have to do with a plugin? That is, why is a plugin useful for it, rather than additional support in GDB proper? It's a very vague problem statement - an interesting one, though. > - lessens the need to maintain custom GDBs. You just use a standard GDB > and write a plugin (or use an existing one). If you decide to upgrade > GDB, you won't need to port your code and not even recompile the > plugin (ideally, if we manage to design a resilient interface). > > - allow people outside of the core GDB team to implement distribute and > test their plugins without modifying GDB. > > - lowers the bar to creating modifications to GDB (exposes a well > defined interface, so there's no need to learn the ins and outs of > GDB to write the plugin you need/want) Remember, we want GDB contributors! That's the whole point - getting people to contribute. So for things that would be generally useful, which all of the above are, helping people do them without contributing to GDB is entirely the wrong way round. I do not believe that you can come up with an abstraction layer big enough to be useful that is not a significant maintenance burden for the GDB developers. I've been surprised before, though! -- Daniel Jacobowitz CodeSourcery