Re: GDB support for Flash memory programming

[Jim Blandy <jimb@codesourcery.com>]

Russell Shaw <rjshaw@netspace.net.au> 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?