This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: GDB and ARM Frame Pointer strangeness
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.
Regards
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.
--Mark