This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Lazy get_frame_id()
- From: Andrew Cagney <ac131313 at redhat dot com>
- To: Andrew Cagney <ac131313 at redhat dot com>
- Cc: gdb at sources dot redhat dot com
- Date: Wed, 19 Mar 2003 20:25:19 -0500
- Subject: Re: Lazy get_frame_id()
- References: <3E750857.50601@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.