Re: Frame handling

[Daniel Jacobowitz <drow at mvista dot com>]

On Mon, Jun 30, 2003 at 06:18:33PM -0700, Jafa wrote:
> Hi all,
> 
> I am bringing the ip2k port back in sync with the trunk and I need to check
> my (limited) understanding of the new scheme...
> 
> This email is mostly a ramble about my understanding of the new frame
> handling that I would like a sanity check on.
> 
> frame_base_set_default (gdbarch, &avr_frame_base) registers a set of
> function handlers:
> this_base - given a frame, figure out the base address of the caller frame
> (caller's FP)... usually this means doing some analysis to figure everything
> out about the frame and populating the port-specific cache for this new
> frame.
> this_locals - given a frame, figure out the address of the local variables
> of the callers frame (usually caller's FP as debug info already allows for
> the offset).
> this_args - given a frame, figure out the address of the args passed to the
> callers frame (usually caller's FP as debug info already allows for the
> offset).
> 
> Port specific implementation... The first time one of these functions is
> called the port-specific cache will be a NULL pointer... the code should
> allocate memory to hold the useful frame variables and figure out the frame
> information. Subsequent calls will receive the cache back and can return the
> values from the cache.

You're good so far.

> frame_base_set_default also sets the unwind options...

No, it doesn't.  That unwind member is used for comparison purposes
only.  See the "Sneaky" comment in get_frame_base_address, and all of
"frame-unwind.h".  Esp. frame_unwind_append_predicate.

> type - always NORMAL_FRAME?

For a target's unwinders, probably.

> 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...

> 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.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer