Frame handling

["Jafa" <jafa at silicondust dot com>]

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.

frame_base_set_default also sets the unwind options...
type - always NORMAL_FRAME?
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?

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.

frame_unwind_append_predicate (gdbarch, d10v_frame_p) - this seams to
register the same unwind options as above?

I think this makes sense but I would appreciate a sanity check :-)

Thanks

Nick

Nick Kelsey
Senior Software Engineer
Ubicom