Re: Lazy get_frame_id()

[Andrew Cagney <ac131313@redhat.com>]

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

So, I've got some raw GCOV data vis:

	new	lazy	main	func

         4092	4587	4587	gdbarch_pc_in_sigtramp
	9456	9246	9385	gdbarch_deprecated_pc_in_call_dummy
	3047	2837	2837	create_sentinel_frame
	3739	3739	3882	d10v_frame_this_id
	4296	4296	4331	d10v_frame_prev_register
	35754	35754	36281	gdbsim_xfer_inferior_memory
	24434	24434	24581	gdbsim_fetch_register

main=mainline
lazy=lazy id evaluation
new=lazy id evaluation + infrun using get_frame_type()

but am wondering how to interpret it.  Here's an attempt:

The create sentinel frame's went up slightly as it is creating more 
frames.  This would also cause the slight rise in pc_in_call_dummy calls 
(since that is always checked first).  The minor this_id, prev_register, 
and the gdbsim_XXX call reduction can be attributed entirely to the lazy 
id evaluation (the d10v sigtramp function doesn't do anything to the 
target).

The important one is pc-in-sigtramp and that was reduced by 10%.

So I guess this data indicates that all is ok ...  Any suggestions for 
what else to look at?  Mainline with infrun using get_prev_frame()?

Andrew

PS: There is also calls like:
PC_IN_SIGTRAMP (prev_pc, prev_func_name)
but I left them them be.