This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Frame handling
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