From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 998 invoked by alias); 27 Dec 2011 19:58:29 -0000 Received: (qmail 982 invoked by uid 22791); 27 Dec 2011 19:58:27 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 27 Dec 2011 19:58:10 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 7AB442BB24D for ; Tue, 27 Dec 2011 14:58:09 -0500 (EST) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id LmnEHGV+4UKW for ; Tue, 27 Dec 2011 14:58:09 -0500 (EST) Received: from kwai.gnat.com (kwai.gnat.com [205.232.38.4]) by rock.gnat.com (Postfix) with ESMTP id 6AC432BB240 for ; Tue, 27 Dec 2011 14:58:09 -0500 (EST) Received: by kwai.gnat.com (Postfix, from userid 1345) id 672D892BF6; Tue, 27 Dec 2011 14:58:09 -0500 (EST) From: Paul Hilfinger To: gdb-patches@sourceware.org Subject: [RFA] Have block_innermost_frame start from selected frame Reply-to: Hilfinger@adacore.com Message-Id: <20111227195809.672D892BF6@kwai.gnat.com> Date: Tue, 27 Dec 2011 19:59:00 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2011-12/txt/msg00847.txt.bz2 The GDB documentation suggests that the notation FOO::x is intended for static variables, but in fact it also "works" for local variables as well. For various reasons, we tend to do this quite a bit in Ada, but the issue raised here comes up in C as well (the message following this one contains a proposed test case in C). The change proposed here causes no regressions, but the obvious question is why things currently work as they do (FOO::x ignores the selected frame). Is this because (as we hope) nobody else uses FOO:: for referencing local variables? Previously, GDB would search for the frame containing variables in a particular lexical block starting from the current (top) frame, ignoring any currently selected frame. It is not clear why this is desirable for variables that require a frame; why would a user deliberately select one frame and then expect to see the value of a variable in a more recent frame? This change causes block_innermost_frame to start looking from the selected frame, if there is one. This change is perhaps unnecessarily conservative. It uses get_selected_frame_if_set rather than get_selected_frame in order to avoid the side effect of calling select_frame, which would probably be harmless. Paul N. Hilfinger 2011-12-27 Paul Hilfinger * gdb/blockframe.c (block_innermost_frame): Start search from selected from, if present, or otherwise the current frame. --- gdb/ChangeLog | 5 +++++ gdb/blockframe.c | 4 +++- 2 files changed, 8 insertions(+), 1 deletions(-) diff --git a/gdb/ChangeLog b/gdb/ChangeLog index 87031a6..39bc63a 100644 --- a/gdb/ChangeLog +++ b/gdb/ChangeLog @@ -1,3 +1,8 @@ +2011-12-27 Paul Hilfinger + + * blockframe.c (block_innermost_frame): Start search from + selected from,if present, or otherwise the current frame. + 2011-12-27 Joel Brobecker * ada-lang.c (should_use_wild_match): New function. diff --git a/gdb/blockframe.c b/gdb/blockframe.c index ef53a3d..92271ff 100644 --- a/gdb/blockframe.c +++ b/gdb/blockframe.c @@ -370,7 +370,9 @@ block_innermost_frame (const struct block *block) start = BLOCK_START (block); end = BLOCK_END (block); - frame = get_current_frame (); + frame = get_selected_frame_if_set (); + if (frame == NULL) + frame = get_current_frame (); while (frame != NULL) { struct block *frame_block = get_frame_block (frame, NULL); -- 1.7.0.4