From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27699 invoked by alias); 28 Dec 2011 15:30:48 -0000 Received: (qmail 27449 invoked by uid 22791); 28 Dec 2011 15:30:43 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00 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; Wed, 28 Dec 2011 15:30:25 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 7949F2BAE55; Wed, 28 Dec 2011 10:30:24 -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 9r+I6IqK58-K; Wed, 28 Dec 2011 10:30:24 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id E26A82BADC6; Wed, 28 Dec 2011 10:30:23 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id DA47E145615; Wed, 28 Dec 2011 07:30:08 -0800 (PST) Date: Wed, 28 Dec 2011 15:41:00 -0000 From: Joel Brobecker To: Jan Kratochvil Cc: Paul Hilfinger , gdb-patches@sourceware.org Subject: Re: [RFA] Have block_innermost_frame start from selected frame Message-ID: <20111228153008.GN23376@adacore.com> References: <20111227195809.672D892BF6@kwai.gnat.com> <20111228130130.GA1855@host2.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111228130130.GA1855@host2.jankratochvil.net> User-Agent: Mutt/1.5.20 (2009-06-14) 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/msg00870.txt.bz2 > 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. Good idea. (and thanks for catching the need to update the funtion description comment). > > 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? What do you mean by ambiguous? Is it the case described here, where we have multiple frames for the given FUNCTION? I don't think we should query(). Users often respond negatively to query, particularly in a case like this where we can make the behavior unambiguous and easily describable. I think one reason why I like Paul's choice is the fact that his suggestion opens the expression to something that is more useful than the original behavior. With the new behavior, you can get the old behavior by simply switching back to frame 0, and then querying FUNCTION::VARIABLE. But the new behavior introduces the possibility of getting the value of a FUNCTION::VARIABLE inside another frame by simply selecting that frame. It's the only way to get the value of "var" in our testcase, and you cannot currently do it with the old behavior. > 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. I think simple is good enough, in this particular case. -- Joel