Re: GDB and ARM Frame Pointer strangeness

[Richard Earnshaw <Richard.Earnshaw@arm.com>]

On Thu, 2004-06-10 at 05:37, Steven Johnson wrote:
> OK, Ill break it down.
> 1. We are not using a stub running on our target.
> 2. We are using the ARM7TDMI JTAG DEBUG Interface, in the context of 
> "stub" we have a program running on a PC that translates the GDB Remote 
> Serial Protocol into ARM JTAG Debug Commands.
> 
> The exact reason why the target is crashing is obscure, we are using a 
> SOC, and there arent any real bus state pins one can probe to determine 
> the CPU state, and on recovery into a mode where we can inspect things 
> again, everything is reset.  The best information we have at the moment 
> is, if we access an invalid (unmapped) memory location the processor 
> enters a state, which we have not been able to recover from without a 
> hardware reset.  Our current guess is it goes into an infinite bus cycle 
> waiting for the memory to respond.  The chip does have Memory Mapped IO 
> that can wait indefinately on the state of an external XWAIT pin.  But 
> what we know for sure, is that immedialtely after reset, a read to an 
> invalid memory address crashes the processor, and the only way we have 
> found to recover is a hard reset.

I suspect the easiest thing to do here is to emulate the memory aborts. 
The way to do this is to construct a virtual memory map in the stub that
describes the valid regions of memory.  Then *every* memory access by
the debugger is checked against the map by the stub which then simulates
an abort if the address isn't valid.  It's a bit slower than having the
hardware do it, but it should make things much more robust.  The number
of entry points in the stub that access memory is quite limited, so it
shouldn't be too much work to track them down.

R.