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.