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