Re: infrun.c:restore_selected_frame???

[Andrew Cagney <ac131313 at cygnus dot com>]

> 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 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.

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?

> 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.

Andrew