Lazy get_frame_id()

[Andrew Cagney <ac131313@redhat.com>]

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


So?

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

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

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


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


Thoughts?
Andrew