Re: Frame handling

["Jafa" <jafa@silicondust.com>]

Hi Andrew

>>> I'm not sure I understand the question.

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

>Um, this is still dangling.  Can you please express your question using
>terminology consistent with the frame unwind code.

Sorry, it was a bit of a ramble :-)

Avr and d10v ports both have function avr/d10v_frame_unwind_cache which
figure out everything about a frame but are internal functions.

The frame-base and frame-unwind APIs provides a machanism to register
functions -

struct frame_base
{
  ...
  frame_this_base_ftype *this_base;
  frame_this_locals_ftype *this_locals;
  frame_this_args_ftype *this_args;
};

struct frame_unwind
{
  ...
  frame_this_id_ftype *this_id;
  frame_prev_register_ftype *prev_register;
};

All five of these functions work on the principle of "given this frame,
figure out xxx information of the caller's frame" and are passed a pointer
to the next_frame (child frame). For example, "given this frame, figure out
where the arguments start of the caller's frame."

I would like to suggest the following:
- <port>_frame_unwind_cache functions to be registered as part of the
frame-unwind API.
- GDB to call <port>_frame_unwind_cache once each time it wants to go back
one frame.
- next_frame parameter removed from all five functions above.
- remove call to <port>_frame_unwind_cache function from the port-specific
implementations of the five functions above.

At a minimum the <port>_frame_unwind_cache function could store the
next_frame parameter and the five functions above could get next_frame from
this_base_cache parameter.

In practice many (most?) ports will do a <port>_frame_unwind_cache function
that figures out everything about the frame in one step and the five
fucntions above will simply read out of the this_base_cache.

Advantages:
- Eliminates some common code from all ports. (call to
<port>_frame_unwind_cache inside each function).
- Eliminates next_frame parameter to these functions.
- Easier to explain/understand the API because you only have to think about
one frame level.
- If a particular port wants the next_frame parameter to search within each
of the five functions then they can save the next_frame parameter themselves
(1 line of code) and it is exactly the same.

I would be happy to provide a patch to look at if that would help explain
and fuel the discussion.

Thanks

Nick