This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Lazy get_frame_id()
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: gdb at sources dot redhat dot com
- Date: Sun, 16 Mar 2003 19:36:20 -0500
- Subject: Re: Lazy get_frame_id()
- References: <3E750857.50601@redhat.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