From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16749 invoked by alias); 9 Apr 2002 20:18:18 -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 16731 invoked from network); 9 Apr 2002 20:18:16 -0000 Received: from unknown (HELO mail-out2.apple.com) (17.254.0.51) by sources.redhat.com with SMTP; 9 Apr 2002 20:18:16 -0000 Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out2.apple.com (8.11.3/8.11.3) with ESMTP id g39KIHs29540 for ; Tue, 9 Apr 2002 13:18:17 -0700 (PDT) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Tue, 9 Apr 2002 13:18:16 -0700 Received: from inghji (inghji.apple.com [17.202.40.220]) by scv2.apple.com (8.11.3/8.11.3) with ESMTP id g39KIFi19554; Tue, 9 Apr 2002 13:18:15 -0700 (PDT) Date: Tue, 09 Apr 2002 13:18:00 -0000 Subject: Re: infrun.c:restore_selected_frame??? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: gdb-patches@sources.redhat.com To: Andrew Cagney From: Jim Ingham In-Reply-To: <3CB2273A.7080302@cygnus.com> Message-Id: Content-Transfer-Encoding: 7bit X-SW-Source: 2002-04/txt/msg00369.txt.bz2 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