This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Lazy get_frame_id()
- From: Andrew Cagney <ac131313 at redhat dot com>
- To: gdb at sources dot redhat dot com
- Date: Sun, 16 Mar 2003 18:27:19 -0500
- Subject: Lazy get_frame_id()
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