Re: GDB support for Flash memory programming

[Russell Shaw <rjshaw@netspace.net.au>]

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.