Re: GDB and ARM Frame Pointer strangeness

[Steven Johnson <sjohnson at neurizon dot net>]

OK,
let me restate the problems as I see it.

1. Whats is the FP register when the target does not use a standard ABI?
2. If there is no FP register, or no standard ABI in use, how can what 
GDB does when it de-references a register, without being instructed to  
by the person controlling the debugger be considered as correct?
3. It is a pipe dream to say "all stubs should be immune to bad memory 
reads" its certainly an ideal goal, but unfortuantely it can not always 
be achieved.
4. Surely its not to much to expect that a person debugging a target can 
connect to the target, read the registers, write a single memory 
location, read another and disconnect without there being any more 
operations being performed than that on the target.
5. I understand that at some level, a person debugging might key in the 
wrong value or de-reference a pointer that is invalid, but that is in 
the control of the person debugging.
6. I understand if you ask GDB to perform a complex operation like a 
backward stack trace, that it needs to dereference the frame and stack 
pointer.

Suggestions I have to address the issue are:
1. If the ABI is set to "none" then operations like "backward stack 
trace" and any other "FP" relative operation shouldnt do anything, 
except tell the user of GDB, "cant backward stack trace, no ABI in use:.
2. Instead of continually resetting the Frame Cache when a memory write 
occurs, mark the frame cache as "invalid" and then when the next 
operation that requires the frame cache executes, reset it then.  (This 
would be more efficient in any event.)

Also, the code in question uses a "deprecated" global variable, It would 
seem that point 2 in the suggestions above would allow the use of this 
deprecated global to be removed.

Andrew Cagney wrote:

> > 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. 
>
>
> There's nothing special about the state of the inferior immediatly 
> after a reset.  R11 (just like any other register) could become 
> corrupt at any moment in the program's execution, and equally could 
> always be valid after a reset.

I understand an FP could become "corrupted" at any time (which to me 
suggests it shouldnt be dereferenced unless specifically requested by 
the person debugging, because they are performing a FP related 
operation).  However I fail to see how a register can have valid FP 
contents after a "power on" reset or hard reset, ever.  There isnt even 
a stack frame at this point.  Please point me to a processor that does 
have a valid FP register immediately after reset, because I have never 
seen one. (I have used 80x86, PowerPC, ARM, Mips, MSP430, PIC's, Z80, 
6502, and the list goes on).  Even if its a soft reset, and the FP 
contains the FP that was valid immediately prior the reset, it is 
invalid after the reset, because the execution context has completely 
changed. And further, it might point to memory that no longer existis, 
because the Chip Select mechanisims may also have been reset.

> Also, there's nothing special about the debugger generating apparently 
> random memory fetches.  Such a fetch could equally come from the user 
> (e.g., via a typo), the target must be robust to such accesses (there 
> is the "mem" command to help with this).
This would be ideal, but not always achievable.  There is nothing 
stopping a person debugging from corrupting the registers that control 
how Chip Selects are set up, setting a chip select to be on variable 
wait state, terminated by an external device, accessing that location 
and hanging the target. (For Example)  This isnt however really the 
point.  The point is dereferencing the FP when there is no ABI in use, 
the FP being a completley ABI specific construct.

What exactly is the setting of ABI to "none" supposed to achieve, 
because I cant see any visible operation that it performs?

Steven Johnson