This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GDB support for Flash memory programming


Jim Blandy wrote:
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?

I've been stuck on desktop programming for months, so i haven't done embedded stuff for ages. Anything that improves the situation for embedded targets would be good.

A characteristic of micro-controller embedded targets is multiple memory
spaces, such as small ones just for programming device config. fuses etc.
As well as being read/write or read-only, the spaces can vary in width.
Some may be 8-bit, while others are 16-bit or more. Whether this needs
improving, i can't tell until i get into gdb hacking again.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]