Frame handling

[Andrew Cagney]

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

(To clarify something, they work on the basis of ``given the next 
frame''.  They must assume that ``this frame'' does not exist - an 
attept to call get_prev_frame (next_frame) would be wrong)
(See my e-mail to daniel)

Anyway, the old code did similar to what you suggest.

Because the cache initialize was disconnected from the specific request, 
people were never sure how much to initialize and when.  As a 
consequence, it was done randomly, using random techniques.  GDB (core, 
target and architecture) is littered with calls like:

	if (!frame->extra_info)
	  INIT_FRAME_EXTRA_INFO

and

	if (!frame->saved_regs)
	  INIT_FRAME_SAVED_REGS

So while the line:
	cache = get_frame_cache (next_frame, this_cache);
might seem a pain, its far less of a pain than the old code that had 
very complicated cache initialization rules.

At least it is clear where the buck stops - the entire problem falls 
squarely on the sholders of the unwinder.

> I would like to suggest the following:
> - <port>_frame_unwind_cache functions to be registered as part of the
> frame-unwind API.

BTW, two, and not one initialize methods would need to be added: one for 
frame-unwind, and one for frame-base.  A problem from the old code was 
the plithera of unwind methods, hmm.

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

Zero benefit.

Every init frame cache method will have (not could) to store next_frame 
in the cache.  Without it, the frame code couldn't access memory or 
registers.

Burrying the frame (hiding it in a cache) would make debugging gdb a 
royal pain.  At present the applicable frame is made explicit as it is a 
parameter.

Andrew