GDB and ARM Frame Pointer strangeness

Steven Johnson
Tue Jun 8 23:47:00 GMT 2004

Whether some stubs can check memory ranges or not will depend on the 
stub, its complexity, its implementation and the hardware its running on.

We are using an ARM with a JTAG Interface for Debugging.  Our Stub does 
not run in the hardware, it runs on a PC and communicates to the 
hardware over the JTAG Interface.  Now what any particular 
implementation of the ARM Core is going to do when it accesses invalid 
memory is undefined.  In our case, the processor just dies, going into 
an infinite wait for the memory to respond.

At any rate, this is all beside the point, and does not address the problem.

The problem is, that GDB will try and de-reference a register, assuming 
it is a Frame Pointer.  When in fact, at that point in time it is no 
such thing.  Processors do not define "Frame Pointers" some define 
"Stack Pointers" but commonly, as is the case for ARM and PowerPC, the 
stack pointer is just the "suggested" register to use for such.  ABI's 
define "Frame Pointers" and that is fine, provided you are using an ABI 
that GDB knows about, and the processor has been initialised for that ABI.

In our case, when we reset the target, the target is at the point of 
executing the instruction in the reset vector.  This is truly the 
beginning of the world.  We can and need to debug from this state.  But 
the way GDB stands at the moment, it is unusable to debug a system that 
is running up from a hardware reset condition.

Everything might be ok, if you are using a software interface that you 
have "burned and learned" to get executing and which has set up your 
environment for you, but we have the ability to debug right from a 
hardware reset, the registers are in this state completley random.  
There is no ABI in use, and it is inapproriate for GDB to "assume" at 
this stage that it can dereference R11 and that that register contains 
the frame pointer.

Unless what is being told to me is GDB V6.1 is not a debugger that is 
usefull for debugging low level assembler programs (with custom ABI's). 
Which if it is the case, is a retrograde step from GDB V5.

Im not asking for anyone to do the fix for me, I am quite capable of 
doing the fix, what I am after is some "rational" discussions on the 
issue so that I can effect the "correct" fix, not just a cop out of 
blaming it on the stub.  Its been a while since I participated in 
GDB/Insight development, but ive never had this sort of "cop out" 
response before, and I am not very impressed by it.  The GDB list used 
to be well respected for the open and friendly dialogue.  The first 
response I got ammounted to "you are stupid, its your stubs fault".  
Without even bothering to listen to the root of the query.

"If your stub is going to fall down like this I recommend having the
stub initialize registers to point to memory that won't trap when read."

Is very dismissive, and does not appreciate the fact that my stub does not, and will never, initialsie anything.  I want the target as raw as possible.  Everything the stub does to initialise the target is another area where you have a difference between the program under Debug and the program under Live conditions.  Wherever possible I believe these should be removed.  The only initialisation of the processor I want is that which is done by my executing program under debug.  Otherwise I would be potentially masking defects in my own code, by performing those operations from the stub.

How about giving me some credit for an understanding of debuging embedded targets before replying with dismissive answers that do not address the real problems.

Even when we set the ABI to "none" GDB still does this undesirable "FP" dereferencing.

Steven Johnson
Embedded Systems Engineer for 18 Years.

Mark Salter wrote:

>>>>>>Steven Johnson writes:
>>I have yet to come across a stub that validates memory addresses.  Stubs 
>>are usually Lean and Mean.  What criteria would a stub use to validate 
>>the memory addresses?
>Pretty much all of the ones I have seen are protected against bad
>memory accesses. For instance, RedBoot stubs use the most usual
>mechanism whereby a fault handler is used to catch accesses which
>throw a cpu exception. The stub is in a much better position to
>determine if a memory space access is valid or not. GDB only knows
>about memory occupied by the program being debugged. A user may
>also want to access h/w registers at addresses not known by GDB.

More information about the Gdb mailing list