Re: GDB support for flash: implementation

[Jim Blandy <jimb at codesourcery dot com>]

Daniel Jacobowitz <drow@false.org> writes:
> 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.

Wow.  I hadn't thought about that at all.

It seems like the stub should be able to check the affected memory
type before it does each write.  And if the stub can produce errors
reliably in response to attempts to write the wrong sort of memory (X
and M to flash, vFlashWrite to non-flash), then GDB would know it
needed to refresh its map.

Certainly if we've got a map, there need to be user mechanisms for
viewing it and correcting it.