debugger options tied to configure options - wish

Vladimir Prus vladimir at
Sun Feb 3 16:11:29 UTC 2008

On Sunday 03 February 2008 15:50:08 kitts wrote:
> On Sunday 03 Feb 2008 3:53:45 pm Vladimir Prus wrote:
> > > When developing for embedded systems typically apart from the usual debug
> > > and release build, there are debug for ram and debug for flash. ie. the
> > > code may be executed in RAM or in ROM and the linker script is differrent
> > > in each case.
> > > Second, we typically use a gdbinit script and this script is again
> > > differrent for RAM and ROM (where it first needs to program the flash
> > > before starting execution)
> >
> > You really should be using current version of GDB together with remote
> > stub that supports flash write -- in which case it will be totally
> > transparent for you;-)

[offlist, as it's a bit offtopic]

> This is interesting news. Is there somewhere i can read more about it? Is it 
> smart enough to figure out the memory type of the target and either copy to 
> RAM or do a flash write on the load instruction? How is the flash write 
> algorithm supplied to it?

There are two sides of the story. 

On the stub side, the actual programming algorithm should be implemented in
code. (Whether the stub has that code compiled in, or loads DLLs with the code,
is not important). The stub should also know where the flash is, and important
properties -- like block size -- though it possibly can autodetect it.
Finally, the stub is supposed to provide an XML memory map to gdb, over standard
remote connection.

On the gdb side, if GDB got memory map from the stub, and you issue 'load'
command and gdb sees that the memory being written in flash, it will use
different commands, specifically designed for flash writing. 

The details can be found at
(memory map format) and
(vFlash* packets)

For a shameless plug, Sourcery G++ comes with support for
a number of JTAG units, including progrmaming flash, see

- Volodya

More information about the KDevelop mailing list