Re: Frame handling

[Andrew Cagney <ac131313 at redhat dot 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