Re: Frame handling

Jafa
2003-07-01T05:00:56Z

Hi Daniel,

Thanks for the sanity check - I like the way this APi is heading btw.

>> 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 agree, and I don't think it will make much difference eitehr way, however
I was just thinking that it would be a whole lot easier to explain these
functions...

unwind - Given this frame, go analyize its caller and populate a
port-specific info block/cache, return unique id.

this_base - Given your port-specific frame block/cache data back, what is
the frame's base address?

this_locals - Given your port-specific frame block/cache data back, where do
the frame's locals start?

this_args - Given your port-specific frame block/cache data back, where do
the frame's args start?

this_id - Superceeded by unwind fucntion?

It took a day to 'click' about the logic bhind the cache because I was
looking at it the wrong way... If an API is easier to explain then it is
easier for people to get it right.

Out of interest, what is the theory behind the frame id being made up of
address + func?

I should have the ip2k port frame handling working tomorrow so I will post
the tdep if you would like to take a look. It would probably be good to
check it into the FSF trunk.

Thanks

Nick

----- Original Message -----
From: "Daniel Jacobowitz" <drow@mvista.com>
To: <jafa@silicondust.com>
Sent: Monday, June 30, 2003 8:43 PM
Subject: Re: Frame handling

*This message was transferred with a trial version of CommuniGate(tm) Pro*
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