From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11383 invoked by alias); 2 Dec 2005 23:13:27 -0000 Received: (qmail 11376 invoked by uid 22791); 2 Dec 2005 23:13:26 -0000 X-Spam-Check-By: sourceware.org Received: from eastrmmtao03.cox.net (HELO eastrmmtao03.cox.net) (68.230.240.36) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 02 Dec 2005 23:13:23 +0000 Received: from white ([68.9.65.164]) by eastrmmtao03.cox.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with ESMTP id <20051202231155.EJQX29285.eastrmmtao03.cox.net@white>; Fri, 2 Dec 2005 18:11:55 -0500 Received: from bob by white with local (Exim 3.36 #1 (Debian)) id 1EiK5O-0002iS-00; Fri, 02 Dec 2005 18:13:02 -0500 Date: Fri, 02 Dec 2005 23:13:00 -0000 From: Bob Rossi To: Jim Blandy Cc: Mark Kettenis , gdb@sourceware.org Subject: Re: [RFC] plugin/extension interface Message-ID: <20051202231302.GA10388@white> References: <439090FE.8040502@st.com> <200512021936.jB2JaZ6n014666@elgar.sibelius.xs4all.nl> <8f2776cb0512021412n17d2a8b2rf8cb4a48daa9449e@mail.gmail.com> <200512022241.jB2Mf3Fk024314@elgar.sibelius.xs4all.nl> <8f2776cb0512021507m52b9d491gd4ddc0ceaab594ba@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8f2776cb0512021507m52b9d491gd4ddc0ceaab594ba@mail.gmail.com> User-Agent: Mutt/1.5.9i Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2005-12/txt/msg00014.txt.bz2 On Fri, Dec 02, 2005 at 03:07:29PM -0800, Jim Blandy wrote: > On 12/2/05, Mark Kettenis wrote: > > I really doubt that. Short term it'd only increase the load since we > > have to build the plug-in interface. Long term, we still have to > > maintain that interface. We'll also get lots of support questions > > where the problems are really with the third party plugins, but where > > the bug reporter conveniently forgets to mention that he's using a > > third party plugin. Let's keep people out of our address space if > > they don't want to commit themselves to providing sources and manpower > > to maintain those sources. > > The only qualification I'd make here is that GDB's current internal > organization isn't very friendly to this kind of stuff. A plug-in > interface that could engender the kind of stuff I'm describing would > have to be pretty clean, high-level, and documented. I could > certainly see the argument that it's too much work to bring things to > the point where they could bring about the benefits. I'm already in the long process of creating a level on top of GDB using MI that allows another process to do anything it wants with GDB. IMO, that is already the clean, high-level, documented interface that other applications should use to communicate with GDB. If the interface needs to change, that's where the effort should go. I don't think providing any other plugin interface besides what's described above even makes sense since it would be duplicating the effort. Bob Rossi