Re: GDB support for flash: implementation

[Daniel Jacobowitz <drow@false.org>]

On Tue, Jun 06, 2006 at 01:03:23PM +1100, Steven Johnson wrote:
> A problem I see with this, is targets where the memory map changes on
> the fly, for example, my ARM target starts with Flash mapped at address
> 0x0, for 512K (for booting).  Some time later, flash is remapped to
> another address, say 0x40000000 for 512K and some SRAM is mapped down to
> 0x0 for 16K.  If GDB thought Flash was still at 0x0 after this it would
> be wrong, and "The target HAS come along and surprised us later".  There
> would need to be some mechanism for the stub to say "Things changed,
> reinitialise".  How a stub would detect this or tell GDB about it, is
> another issue, but at least GDB needs to be able to re-sync when a
> target changes its memory arrangement in any significant way.
> 
> This is one reason why i preferred a "map" style command, so that if
> things like this changed, the person doing the debug could force the
> necessary changes onto GDB's understanding of the target, if required. 
> I don't mind the "automatic" retrieval of info from a stub, but it
> should be able to be over-ridden if required.

Good point.  I'm going to have to think about this.  I don't really
want to give up on the idea, but it may need a little work.

Jim, this may be a persuasive argument in favor of separating the
memory map from the features, as you were talking about earlier.
I still don't like the idea, but my current mental model isn't wired
for virtual memory.

-- 
Daniel Jacobowitz
CodeSourcery