This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: GDB support for flash: implementation
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