From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7205 invoked by alias); 6 Nov 2002 15:55:53 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 7194 invoked from network); 6 Nov 2002 15:55:52 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 6 Nov 2002 15:55:52 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 189TSR-00016H-00; Wed, 06 Nov 2002 10:55:11 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 189SXq-0002wj-00; Wed, 06 Nov 2002 10:56:42 -0500 Date: Wed, 06 Nov 2002 07:55:00 -0000 From: Daniel Jacobowitz To: "Howell, David P" Cc: Scott Moser , gdb-patches@sources.redhat.com Subject: Re: [PATCH] plugin patch Message-ID: <20021106155642.GA11098@nevyn.them.org> Mail-Followup-To: "Howell, David P" , Scott Moser , gdb-patches@sources.redhat.com References: <331AD7BED1579543AD146F5A1A44D5251279DE@fmsmsx403.fm.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <331AD7BED1579543AD146F5A1A44D5251279DE@fmsmsx403.fm.intel.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2002-11/txt/msg00100.txt.bz2 On Wed, Nov 06, 2002 at 07:47:13AM -0800, Howell, David P wrote: > > On Mon, 28 Oct 2002, Scott Moser wrote: > > > Below is a patch to add plugin support to GDB. It exports a fairly > > simple programmable interface for people to extend the functionality > of > > GDB via runtime loaded shared libraries in ways that may not fit with > > the direction of the main GDB tree (not cross-platform, not stable, > > niche audience...). > For folks like myself that are working on an alternate architecture or > runtime support components (in this case NGPT threads) this would be > very useful, as I can see several info commands that I would like to > add for M:N user mode scheduling state and LWP state display that would > be unique to NGPT and it's implementation. > > Instead of having to add this to the standard gdb as a one-off for NGPT, > I can use the standard gdb and design them as plug-ins to be loaded only > > when debugging NGPT applications. This feels a lot cleaner and could be > applied for other gdb features/architectures to keep the core as small > and efficient as possible, loading additional support/features on demand > only when needed. You've both given good arguments in support of a general plugin architecture. No one's objecting to the theory (except possibly the FSF... who this might need to be cleared with). I object to the implementation, however. Scott, I'm sure you have a plugin or two in mind. What interfaces do they need? What other interfaces would be useful? I want plugins to have a defined interaction with GDB, not be able to call into any global function. If I were you, I'd still want this, because then we won't break your plugins willy-nilly. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer