Re: Lazy get_frame_id()

[Daniel Jacobowitz <drow@mvista.com>]

On Sun, Mar 16, 2003 at 06:27:19PM -0500, Andrew Cagney wrote:
> Hello,
> 
> At present a frame's ID is computed when the prev frame is created.  I'd 
> like to propose that, instead, for code relying on the new frame 
> mechanisms, the computation of a frame's ID be delayed until it is 
> needed - an explicit call to get_frame_id().
> 
> This will mean that get_prev_frame() is reduced to something like:
> 
> 	... perform refuse to unwind checks ...
> 	- this->pc isn't valid? return NULL
> 	- this->id isn't valid? return NULL
> 	... create the new frame ...
> 	prev = allocate()
> 	prev->pc = frame_pc_unwind (this);
> 	(prev->type, prev->unwind =
> 		(frame_type_from_pc (prev->pc),
> 		 find_unwind_find_by_pc (prev->pc));
> 	... link it in ...
> 	this->prev = prev;
> 	prev->next = this;
> 	... return it ...
> 	return prev;
> 
> 
> Where:
> 
> - frame_pc_unwind(), when applied to the sentinel frame, does not need 
> to do any prologue analysis and hence shouldn't be a load on the target.
> 
> - frame_type_from_pc(), frame_unwind_find_by_pc() can/should be merged 
> since they are both using the same PC based tests.
> 
> - the frame ID sanity checks are removed (or only applied when trying to 
> do the next chain).

This I really like.  It seems like the right time...

> This has two immediatly effects:
> 
> - get_current_frame() is cheap
> 
> - when a back-trace dies with an invalid frame (due to frame ID), it is 
> possible to examine that invalid frame (previously it wasn't possible).

This is a definite improvement.  You mean if (for instance) there is a
call to error() trying to build the next frame?  I've run into this in
practice.

> It opens up the possibility of, in WFI (infrun.c, et.al.), replacing the 
> calls:
> - PC_IN_SIGTRAMP()
> - PC_IN_CALL_DUMMY()
> with the equivalent: get_frame_type (get_current_frame ()) == 
> SIGTRAMP_FRAME et.al.  In fact, since the computation would be done 
> once, this would be less load on the target.
> 
> 
> What's the fine print?
> 
> It will have the effect of making it very difficult to predict which of 
> this_id() or prev_register() is called first.  The call sequence can 
> always be forced (if that makes peoples life easier).

IMVHO, we should probably force the frame ID before general register
unwinding.

> ``for code relying on the new frame mechanisms''.  The WFI change, for 
> old architectures, could potentially make them run slower (for old 
> architectures get_current_frame() forces a prologue analysis).  I'm 
> going to go out on a limb and argue that this is OK.  It doesn't break 
> the old architectures (just degrades them a little :-).  On the other 
> hand, it makes it possible to ratinalize WFI a little.

And I agree here too.  Mark's making great strides on converting i386
already.  I don't have time this month to follow the frame stuff as it
evolves, so I've been mostly ignoring it, but I'm willing to try my
hand at converting the other architectures I need once it seems to have
stabilized.

If your port wants performance benefits it has to move forwards!

> Anyway, ignoring WFI, any comments on the principle behind this change?

I like it.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer