This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: infrun.c:restore_selected_frame???
- From: Andrew Cagney <ac131313 at cygnus dot com>
- To: Jim Ingham <jingham at apple dot com>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Mon, 08 Apr 2002 19:26:50 -0400
- Subject: Re: infrun.c:restore_selected_frame???
- References: <9637D4C6-475D-11D6-A9CC-000393540DDC@apple.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