From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32389 invoked by alias); 3 Dec 2005 03:13:18 -0000 Received: (qmail 32366 invoked by uid 22791); 3 Dec 2005 03:13:17 -0000 X-Spam-Check-By: sourceware.org Received: from cumulus.netspace.net.au (HELO mail.netspace.net.au) (203.10.110.72) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 03 Dec 2005 03:13:16 +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 3D4817BBB2 for ; Sat, 3 Dec 2005 14:13:11 +1100 (EST) Message-ID: <43910D47.2070300@netspace.net.au> Date: Sat, 03 Dec 2005 03:13: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> <439105DF.5040708@netspace.net.au> <20051203024500.GA22826@nevyn.them.org> In-Reply-To: <20051203024500.GA22826@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/msg00021.txt.bz2 Daniel Jacobowitz wrote: > On Sat, Dec 03, 2005 at 01:41:35PM +1100, Russell Shaw wrote: > >>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. > > [Off-topic here, but] > > I can't even remember seeing messages from you on this topic; a certain > amount of persistance is always called for in GDB development. > > However, in general, I've come to believe that GDB shouldn't continue > to add support for new remote protocols. What we need is a nice, > open-source framework for gdb remote <-> other remote conversion. The way gdb works, when i type: target avrjtagice -d /dev/ttyS2, gdb uses (or registers) using: void _initialize_remote_jtag (void). It really looks like gdb is "loading" the module. If the functions (or framework) used in these target interfaces are documented, the problems would be solved with little other than a bit of documentation work. I couldn't use the default target protocol, because i wasn't interfacing to an end target. I was interfacing to an ICE debugger (that already had its own protocol) for the target. I did it to replace the current hack of having an extra program on the pc that converts between the default gdb target protocol, and this ICE- specific protocol. The conversion hack was extremely slow, clumsy, fault-intolerant, and error-prone. With the specific interface in gdb, the performance was wonderful, and new gdb commands can be easily registered for this ICE, that are only accessible after the command "target avrjtagice -d /dev/ttyS2" is performed (like an emacs minor mode or whatever). Currently, the files for these specific interfaces are just chucked into gdb-6.3/gdb/ (such as remote-e7000.c). What's really needed is a separate sub-directory for each of these remote-interface protocol files, and a well documented api for what functions to use within them. The api already exists, just look in any db-6.3/gdb/remote*.c. One of the subdirectories can be devoted to the generic target protocol where the comms is to the end embedded system, instead of an intermediate debugger box.