From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 884 invoked by alias); 28 Dec 2011 13:02:25 -0000 Received: (qmail 875 invoked by uid 22791); 28 Dec 2011 13:02:24 -0000 X-SWARE-Spam-Status: No, hits=-7.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 28 Dec 2011 13:01:57 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pBSD1Yc9008174 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 28 Dec 2011 08:01:34 -0500 Received: from host2.jankratochvil.net (ovpn-116-32.ams2.redhat.com [10.36.116.32]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id pBSD1Ub7021364 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 28 Dec 2011 08:01:33 -0500 Date: Wed, 28 Dec 2011 13:10:00 -0000 From: Jan Kratochvil To: Paul Hilfinger Cc: gdb-patches@sourceware.org Subject: Re: [RFA] Have block_innermost_frame start from selected frame Message-ID: <20111228130130.GA1855@host2.jankratochvil.net> References: <20111227195809.672D892BF6@kwai.gnat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111227195809.672D892BF6@kwai.gnat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes 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/msg00867.txt.bz2 On Tue, 27 Dec 2011 20:58:09 +0100, Paul Hilfinger wrote: > 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. refrenced doc: If you wish, you can specify a static variable in a particular function or file, using the colon-colon (`::') notation: FILE::VARIABLE FUNCTION::VARIABLE In such case the doc should be updated, particularly that it has became now related to the currently selected frame. > This change causes block_innermost_frame to start looking from the selected > frame, if there is one. It may be all even more tricky than it was before. What about using query() if such reference is ambiguous? It may not be so easy determining the ambiguity. Something like checking symbol_read_needs_frame() and then also checking if there exist >= 2 different frames containing the block. Thanks, Jan