infrun.c:restore_selected_frame???
Jim Ingham
jingham@apple.com
Tue Apr 9 13:18:00 GMT 2002
Andrew,
On Monday, April 8, 2002, at 04:26 PM, Andrew Cagney wrote:
>> Hi, all...
>
> (Have you been sending me subliminal messages telling me to look at
> selected_frame_level? I'd not looked at this e-mail when I posted the
> patch http://sources.redhat.com/ml/gdb-patches/2002-04/msg00241.html to
> add a frame->level.
>
I saw that and wondered if YOU had been reading MY mind...
>> I am totally confused by restore_selected_frame. Why is it calling
>> find_relative_frame, passing in the current frame and level?
>> Remember, level comes from a stored value of selected_frame_level.
>> selected_frame_level is set in select_frame, and is either an absolute
>> frame level, or -1 if the caller of select_frame was just selecting by
>> frame_info and doesn't care about the level (which is done in a number
>> of places). So it is NOT a relative level at all, certainly not
>> relative to whatever the current frame happens to be except by
>> accident...
>
> Selected_frame_level is relative (0 is inner most) not absolute. The
> above patch demonstrates this.
>
If this is right, the way it is set (and the comment) at the beginning
of select_frame is confusing:
/* Select frame FI, and note that its stack level is LEVEL.
LEVEL may be -1 if an actual level number is not known. */
void
select_frame (struct frame_info *fi, int level)
{
register struct symtab *s;
selected_frame = fi;
selected_frame_level = level;
Sounds like if I have a hold of the frame_info, it is sufficient to pass
this and -1 in, but that is not right...
> The code appears to be assuming that, after an inferior function call,
> current frame has been restored to its pre-inferior-call and hence that
> current_frame+level gives the saved frame.
>
> Robert Elz's comment suggests this isn't always the case and you can
> end up selecting a frame that doesn't match the expected (the commented
> out test). I think there are two cases when this occures:
>
> - the inferior function didn't exit and you've ended up with more than
> the expected number of frames to the saved frame. The level test won't
> detect this and you'll just select the wrong frame
>
> - the inferior function did exit along with a few other things and
> you've ended up with less frames then you expected. The level test
> might detect this (if the number of levels takes you off the bottom of
> the stack).
>
>> Since you also have the frame address sitting around in the
>> restore_selected_frame_args, why not use it to find the frame
>> instead? The patch below works for me, and eliminates a bunch of
>> errant kvetching about "Unable to restore selected frame"...
>
> What are the exact circumstances under which this occures? You're not
> N levels down from the current/inner-most stack frame?
This is a collision with the varobj code. varobj_create stashes away
the current frame - in case the varobj that you are creating is in
another frame, and then restores it by calling:
select_frame (fi, -1);
According to the header comment for select frame, this is reasonable,
because -1 is supposed to mean "I don't care about the level, but of
course this doesn't work when you try to do restore_selected_frame with
-1 from frame 0...
>
>> Does this seem right?
>
> I'm fairly sure it is.
>
> --
>
> Looking at find_frame_addr_in_frame_chain(), I think it needs to be
> made more robust - check that the loop hasn't gone past the specified
> frame. The level code would have been covering this problem up.
>
> --
>
> Hmm, to more robustly identify a frame, should we save both the
> frame->frame and frame->pc (or containing function)? This is
> separate / independant - I've always wondered if frame->frame was
> sufficient.
We do this in Project Builder, but there we do it because a GUI has to
present the WHOLE stack frame every time you step, which is slow, so we
optimize this by sending frame+pc duples to PB using a special purpose
command that just gets these and doesn't reconstruct the whole stack.
Don't know if you need this in gdb though. When did you think this
might be a problem?
Jim
--
Jim Ingham jingham@apple.com
Developer Tools - gdb
Apple Computer
More information about the Gdb-patches
mailing list