Re: GDB support for flash: implementation

[Steven Johnson <sjohnson at sakuraindustries dot com>]

Daniel Jacobowitz wrote:

>On Mon, Jun 05, 2006 at 05:02:38PM -0400, Daniel Jacobowitz wrote:
>  
>
>>Jim and I were talking about this earlier and didn't really come to a
>>conclusion.  I don't like Eflash; I think it's unnecessarily
>>complicated, and that it would actually be simpler to ask the target
>>to tell us where its flash is.
>>    
>>
>
>Jim asked me to expand on this.
>
>What Eflash would basically do would be return a piece of the
>target's memory map.  So we've always got a little bit of that
>map when we need it, and there's a temptation to hold on to it
>and get a better picture of the target as we go along.  But that's
>a bad temptation, because of the incompleteness; so why not
>sidestep it and build the map up front?
>
>Either way, at least in some cases, the map will be incomplete.
>For instance, it may not indicate where all RAM and I/O devices
>are.  But this way at least we know where all the flash devices are.
>The target won't come along and surprise us later.
>  
>
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.

Steven J