debugger options tied to configure options - wish

kitts kitts.mailinglists at
Sun Feb 3 12:50:08 UTC 2008

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;-)

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?

> > I currently use the cmake build system (the lack of a cmake plugin
> > requires me to manually reconfigure the build) and i can switch the
> > linker scripts but i also need to edit project options to use the other
> > gdbinit.
> >
> > So, would it be possible to link the debugger settings with the build
> > system settings, assuming that the cmake plugin in future will allow to
> > have multiple build folders/settings similar to the automake plugin.
> The current (vague) plan is to have 'debugger configuration' thing, where
> the 'application' can be either binary, or a target in the build system. In
> the latter case, it would be reasonable to grab as much data as possible
> from the build system. OTOH, I'm not quite sure that "ROM/RAM" option is a
> standard thing in any build system nowdays. Probably, we can use Python
> scripting to do different thing depending on the linker script used by the
> target being debugged.

The other way would be to copy the appropriate init script into the build dir 
when configuring and use it. But then in the KDevelop's debugger 
configuration we should pass the path to the build dir which can vary. If 
that can be a variable like ${CMAKE_BINARY_DIR}/gdbinit then it is possible.

More information about the KDevelop mailing list