Re: Frame handling

[Andrew Cagney <ac131313@redhat.com>]

>> this_id - Given a frame, return a unique identifier for the caller's frame
>> based on the caller's frame base address and the calling functions entry
>> point.
>> prev_register - Given a frame, return the value of a specified register as
>> it was on entry to this function (registers that are known to be saved on
>> the stack)
>> 
>> Question - what registers is gdb expecting prev_register to give reasonable
>> results for? Just PC? Or SP and FP as well?
> 
> 
> As many as possible.  This _completely_ replaces all other unwinding,
> for instance frame_chain and the extra_info/saved_registers data. 
> Might want to take a look at the ARM conversion I just posted; I don't
> promise it's right...

Yes.  GDB now relies on the prev_register method when popping a frame so 
unless it works well, things fail pretty quick.

>> Question - reading through this again I think the goal of call these
>> functions is to work with the current frame and the function get passed the
>> child frame so they can do a backtrace if it hasn't already been done... why
>> not call a function to do a 1 level backtrace and then eliminate the
>> next_frame parameter? It would recduce confusion and most ports will have an
>> internal unwind function anyway.


> Because it doesn't make much difference, I think.  The key is that the
> info generated when doing the backtrace is target specific, and opaque.

I'm not sure I understand the question.

Andrew