From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21556 invoked by alias); 3 Dec 2005 04:05:30 -0000 Received: (qmail 21549 invoked by uid 22791); 3 Dec 2005 04:05:29 -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 04:05:29 +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 3B29649E73 for ; Sat, 3 Dec 2005 15:05:24 +1100 (EST) Message-ID: <43911985.9050901@netspace.net.au> Date: Sat, 03 Dec 2005 04:05: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: <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> <43910D47.2070300@netspace.net.au> <20051203033336.GA23537@nevyn.them.org> In-Reply-To: <20051203033336.GA23537@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/msg00023.txt.bz2 Daniel Jacobowitz wrote: > On Sat, Dec 03, 2005 at 02:13:11PM +1100, Russell Shaw wrote: > >>The way gdb works, when i type: target avrjtagice -d /dev/ttyS2, >>gdb uses (or registers) using: void _initialize_remote_jtag (void). > > Incorrect; that happens at GDB startup. > >>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. > > Not unless we declared them a public interface. That means supporting > them, preserving compatibility, et cetera. We are not prepared to do > that. Well that's just too bad. It's the best way to go. Atleast i can support my own private gdb and cut the cruft that's been holding it back for years. >>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. > > I would need to know a lot more about these problems, but it is very > likely that they are problems with the conversion program - not with > the concept. If they were problems with the remote protocol, we would > be interested in fixing them. The very concept of making a protocol conversion program act like an end target is totally flawed. First there's the tediousness of starting and initializing the converter program and comms from it to the debugger box. Then the gdb<->debugger comms must be established. Then the debugger<->embedded-system comms and setup needs to be established using gdb. Any hang-ups in the converter program or debugger means redoing the whole process. The whole chain is extra slow because round-trip comms thru gdb<->converter<->debugger<->target-system is limited by the context switching of the pc between the gdb and converter processes. There is also the extra tediousness of debugging the converter program and trying to feed it with comms data using gdb, at the same time as having yet another gdb to debug the actual converter. The second problem is that ICE hardware and other debuggers have various specific commands such as for setting ICE hardware parameters, selecting memory spaces, setting breakpoint paramteters, and a ton of other stuff that a generic protocol has no hope of addressing. I found that by registering my own commands with add_com(), i can do all kinds of excellent things such as spit out on the gdb output window a tabulated list of the fuse settings in a microcontroller, or display and set the current ICE hardware settings. With a defined interface for vendors to control specific debugger hardware, gdb would get a lot more interest and move lightyears ahead. All i've seen is stagnation ever since i've had an interest in gdb 5 years ago.