From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10568 invoked by alias); 24 May 2006 22:17:54 -0000 Received: (qmail 10554 invoked by uid 22791); 24 May 2006 22:17:53 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Wed, 24 May 2006 22:17:50 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1Fj1fm-0002kn-Qd; Wed, 24 May 2006 18:17:46 -0400 Date: Thu, 25 May 2006 00:39:00 -0000 From: Daniel Jacobowitz To: Russell Shaw Cc: gdb@sourceware.org Subject: GDB and remote protocols Message-ID: <20060524221746.GA10396@nevyn.them.org> Mail-Followup-To: Russell Shaw , gdb@sourceware.org References: <4473BEC6.7050308@netspace.net.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4473BEC6.7050308@netspace.net.au> User-Agent: Mutt/1.5.11+cvs20060403 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: 2006-05/txt/msg00357.txt.bz2 This is a bit tangential to the poll Jim's conducting, so I've changed the subject. On Wed, May 24, 2006 at 12:02:46PM +1000, Russell Shaw wrote: > I've done all this stuff for the AVR by adding my own comms handling > and memory-space/type handling code to gdb for communicating with a > specific jtag ice. > > IMO, the generic stub thing should only be used for targets that > receive the commands without any intermediate ICE/debugger hardware > (these targets interpret gdb commands with their own software). > > IMO, every supported hardware device (jtag debuggers etc) should > have their own directory in gdb. It is much easier to take advantage > of specific debugger features, instead of relying on lowest common > denominator features of the generic gdb stub shim thing. Shims add > unnecessary delay and cludginess because of the extra layer of comms > overhead. We've talked about this before. I take the opposite view, and I think the GDB community has been mostly moving in that direction. One of my biggest motivations is that when GDB has extra code to support a particular ICE, it is extremely unlikely that anyone making changes can test with that ICE, and the code rots quickly. Most of the ones we've got in the source tree right now are in pretty bad shape. My last six months of GDB work can basically be described by: - Make the one remote protocol (remote.c) more powerful, so that it is not restricted to lowest common denominator features, e.g. support for autodetecting register sets. - Make the remote protocol more efficient where the communication overhead is a problem. Large packet size negotiation and quicker feature probing are the subject of my current project, qSupported, which I hope to have done Real Soon. Another project I've got going would provide the infrastructure for binary memory reads from the target (complementing the X packet for writes). > The code handled all the memory spaces the jtag ice supported, as well > hardware and software breakpoints, and self diagnostics. Code could be > uploaded and downloaded from the jtag ice, new jtag firmware uploaded etc. > It is easy to add your own gdb commands, which only exist when your specific > extension is enabled in gdb. This is something we're obviously hearing needs to be supported. But there's other ways to do it: for instance, having the stub report its ICE name, and GDB search a local database for command files associated with that target name, and do all the commands in a scripting language. Wouldn't that be nicer than having to build a custom GDB binary? But, of course, it only gets done when someone works on it. [In theory you could even download commands from the stub; but that presents some security questions that it might be best to simply avoid.] -- Daniel Jacobowitz CodeSourcery