From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27952 invoked by alias); 3 Dec 2005 02:41:18 -0000 Received: (qmail 27904 invoked by uid 22791); 3 Dec 2005 02:41:18 -0000 X-Spam-Check-By: sourceware.org Received: from eastrmmtao05.cox.net (HELO eastrmmtao05.cox.net) (68.230.240.34) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 03 Dec 2005 02:41:17 +0000 Received: from white ([68.9.65.164]) by eastrmmtao05.cox.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with ESMTP id <20051203024109.GAID14098.eastrmmtao05.cox.net@white>; Fri, 2 Dec 2005 21:41:09 -0500 Received: from bob by white with local (Exim 3.36 #1 (Debian)) id 1EiNKa-0002nq-00; Fri, 02 Dec 2005 21:40:56 -0500 Date: Sat, 03 Dec 2005 02:41:00 -0000 From: Bob Rossi To: Jim Blandy , Mark Kettenis , gdb@sourceware.org Subject: Re: [RFC] plugin/extension interface Message-ID: <20051203024056.GA10592@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> <20051202233207.GA19812@nevyn.them.org> <8f2776cb0512021657i3f780f77sb1294b51753ffaaa@mail.gmail.com> <20051203023154.GA22527@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051203023154.GA22527@nevyn.them.org> 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/msg00018.txt.bz2 On Fri, Dec 02, 2005 at 09:31:54PM -0500, Daniel Jacobowitz wrote: > On Fri, Dec 02, 2005 at 04:57:01PM -0800, Jim Blandy wrote: > > On 12/2/05, Daniel Jacobowitz wrote: > > > And every one of these things you've described doing with debuggers, > > > would require a _DIFFERENT_ plugin interface. It would be a nightmare > > > to add this to today's GDB! > > > > Oh, I figured we'd just let the plugin code #include GDB's headers > > directly, so they could get at whatever they wanted. > > > > ... okay, that does sound like a nightmare. > > Now we're communicating :-) > > For the record, here's my overall point in this thread. We have some > very good abstraction layers already: in particular, I'm talking about > the remote protocol, and the MI/interpreters mechanism. I want GDB to > be more extensible, but I believe that those protocols are the best way > to do it. They both have limitations for this kind of use, because > they aren't used that way yet; but what we need to do is commit to > using them, then bite the bullet and begin improving them to meet our > needs. > > That way we can keep the interfaces coherent, and hopefully, > documented at or above today's levels. I know my role in GDB isn't as big as most others in this thread, but for what it's worth, I fully agree with this position. Bob Rossi