From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32754 invoked by alias); 3 Dec 2005 02:41:41 -0000 Received: (qmail 32505 invoked by uid 22791); 3 Dec 2005 02:41:41 -0000 X-Spam-Check-By: sourceware.org Received: from thunder.netspace.net.au (HELO mail.netspace.net.au) (203.10.110.71) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 03 Dec 2005 02:41:39 +0000 Received: from [192.168.0.10] (220-253-18-66.VIC.netspace.net.au [220.253.18.66]) by mail.netspace.net.au (Postfix) with ESMTP id 919014ACC4 for ; Sat, 3 Dec 2005 13:41:34 +1100 (EST) Message-ID: <439105DF.5040708@netspace.net.au> Date: Sat, 03 Dec 2005 02:41:00 -0000 From: Russell Shaw User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.11) Gecko/20050914 Debian/1.7.11-1 MIME-Version: 1.0 Cc: gdb@sourceware.org Subject: Re: [RFC] plugin/extension interface 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> In-Reply-To: <20051203023154.GA22527@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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/msg00019.txt.bz2 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. Months ago, i added a remote protocol for a hardware in-circuit emulator and was going to write a chapter documenting how to add a target protocol to gdb. My questions on how best to add this to gdb in cvs got no response whatsoever. Now i've lost all interest.