Re: GDB and ARM Frame Pointer strangeness

[Ian Lance Taylor <ian at wasabisystems dot com>]

Steven Johnson <sjohnson@neurizon.net> writes:

> 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.

Sounds like an unpleasant situation.  I've never tried to use gdb at
this stage of things.  I've also never used gdb with JTAG.  If I were
in your shoes I would be using console output or perhaps a real JTAG
tool.  I wouldn't try gdb until I had something marginally working on
the board.  gdb isn't that great for bare hardware--it really expects
some sort of program to exist.

> The problem is, we want to use GDB to start "investigating" our
> hardware and to start testing our boot code.  But whilever it is
> making these spurious uncontrolled writes to invalid memory addresses,
> it is preventing us from doing this, because they crash our Target
> CPU.

At the risk of pointing out the completely obvious, if writes to
invalid memory addresses crash the CPU, you've got a real problem if
you are running any type of user code.

> Because our "stub" is really a PC, and it is translating the GDB
> Remote Serial Protocol into ARM JTAG operations, it doesnt know
> anything specific about the hardware, it is designed to function with
> any ARM7TDMI chip with this interface.  So it is inappropriate for it
> to filter addresses, because it has no notion of what addresses are
> valid and what are not.

I think it would be entirely appropriate for this tool to read some
sort of memory map, and filter addresses on that basis.

> Yes, if the CPU wasnt crashing and it was
> advising us that an invalid memory location was accessed we could
> report that data appropriately to GDB. (Although im not clear what
> data you return in answer to a memory read when the address is
> invalid).

The stub returns an E response (a read from valid memory would result
in the actual data).

> In summary, if there is no ABI that GDB knows about in use, it is
> invalid for GDB to assume a register is the Frame Pointer and then to
> start de-referencing it.  The same can be said for the stack pointer
> on architectures that do not have a "Hardware" stack pointer, but just
> use an arbitrary register as one.

gdb isn't written for such environments.  It expects stack frames and
frame pointers.  When it first attaches, it tries to figure out what
the stack frame looks like.  gdb doesn't have an "assembly mode" in
which it presumes that code is not in any sort of function context.

> Setting the ABI to "none" doesn't appear to do anything.  Should it?

I don't think so.  Changing the ABI in general doesn't do much.  For
some targets it affects stuff like where parameters should be passed.
Setting the ABI to "none" means that gdb has no information about the
ABI at all.

> At
> the very least there needs to be some control over these "high level"
> operations so that "low level" things can be debugged without
> interference from them.

Sounds reasonable to me: an assembly mode.  Of course, somebody has to
volunteer to do the work.

Ian