Re: GDB and ARM Frame Pointer strangeness

Steven Johnson
2004-06-10T00:06:58Z

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