From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10780 invoked by alias); 24 May 2006 02:03:35 -0000 Received: (qmail 10759 invoked by uid 22791); 24 May 2006 02:03:32 -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; Wed, 24 May 2006 02:02:53 +0000 Received: from [192.168.0.10] (220-253-109-214.VIC.netspace.net.au [220.253.109.214]) by mail.netspace.net.au (Postfix) with ESMTP id 6E7B149FC0 for ; Wed, 24 May 2006 12:02:46 +1000 (EST) Message-ID: <4473BEC6.7050308@netspace.net.au> Date: Wed, 24 May 2006 08:03:00 -0000 From: Russell Shaw User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20060205 Debian/1.7.12-1.1 MIME-Version: 1.0 Cc: gdb@sourceware.org Subject: Re: GDB support for Flash memory programming References: In-Reply-To: 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: 2006-05/txt/msg00346.txt.bz2 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. I practically finished my patch a year ago and tested it (it still had some bugs), but haven't done anything with it since (i'll get back to it after solving another problem related to gdb). 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.