From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5099 invoked by alias); 24 May 2006 22:07:47 -0000 Received: (qmail 5089 invoked by uid 22791); 24 May 2006 22:07:46 -0000 X-Spam-Check-By: sourceware.org Received: from intranet.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.6) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 24 May 2006 22:07:45 +0000 Received: (qmail 3262 invoked from network); 24 May 2006 22:07:43 -0000 Received: from unknown (HELO localhost) (jimb@127.0.0.2) by mail.codesourcery.com with ESMTPA; 24 May 2006 22:07:43 -0000 To: Russell Shaw Cc: gdb@sourceware.org Subject: Re: GDB support for Flash memory programming References: <4473BEC6.7050308@netspace.net.au> From: Jim Blandy Date: Thu, 25 May 2006 00:22:00 -0000 In-Reply-To: <4473BEC6.7050308@netspace.net.au> (Russell Shaw's message of "Wed, 24 May 2006 12:02:46 +1000") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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/msg00356.txt.bz2 Russell Shaw writes: > Jim Blandy wrote: >> One of the problems GDB has in the embedded development world is its >> lack of support for loading programs into flash memory. After some >> conversation amongst ourselves to weed out patently stupid stuff (none >> of the text below is mine... hey), we at CodeSourcery put together the >> following proposal for general comments and criticism. We'd like to >> reach consensus on what the user interface should be >> before we worry about implementation details --- possible remote >> protocol changes, and so on --- so let's leave those topics aside for >> the time being. >> What do folks think? >> --- >> Background >> Flash memory is a popular form of non-volatile memory... > > 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. Well, how the solution should be structured in the code is going to be an interesting point of discussion. But as I say to Steven, we'd like to get feedback on the user interface first. Would the interface as proposed be useful in the work you're doing now?