From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31688 invoked by alias); 8 Apr 2002 23:26:51 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 31675 invoked from network); 8 Apr 2002 23:26:50 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 8 Apr 2002 23:26:50 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 204F53EF8; Mon, 8 Apr 2002 19:26:51 -0400 (EDT) Message-ID: <3CB2273A.7080302@cygnus.com> Date: Mon, 08 Apr 2002 16:26:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:0.9.9) Gecko/20020328 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Ingham Cc: gdb-patches@sources.redhat.com Subject: Re: infrun.c:restore_selected_frame??? References: <9637D4C6-475D-11D6-A9CC-000393540DDC@apple.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-04/txt/msg00329.txt.bz2 > 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