From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30649 invoked by alias); 28 Aug 2003 19:55:02 -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 30623 invoked from network); 28 Aug 2003 19:55:01 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 28 Aug 2003 19:55:01 -0000 Received: from drow by nevyn.them.org with local (Exim 4.22 #1 (Debian)) id 19sSrF-0007Fx-DP; Thu, 28 Aug 2003 15:55:01 -0400 Date: Thu, 28 Aug 2003 19:55:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: gdb-patches@sources.redhat.com Subject: Re: RFC: selected frame in read_var_value Message-ID: <20030828195501.GB27550@nevyn.them.org> Mail-Followup-To: Andrew Cagney , gdb-patches@sources.redhat.com References: <20030801192951.GA2109@nevyn.them.org> <3F329038.5040708@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F329038.5040708@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-08/txt/msg00518.txt.bz2 On Thu, Aug 07, 2003 at 01:45:28PM -0400, Andrew Cagney wrote: > >Thoughts on this? I observed one case where the selected frame hadn't been > >initialized yet: when checking watchpoint values. Oops! The condition > >matches the case in which get_current_frame () can be reasonably expected > >to > >succeed. There are a couple other places that need this same check, mostly > >functions which will work on globals as well as locals. > > I think the caller, and not this code, should be the one deciding > if/when a get_selected_frame should be called. Otherwize the dependance > on global state remains. The callers don't know any more than we do. Take a look at some of them - several callers don't take frame arguments, and work both when the program is running and when it isn't. If you want to cut down on the global state dependence, I guess you'd have to push this up through every caller, so that it could eventually be pushed even higher? Me, I was just fixing the regression caused by lazily selecting a frame. I wasn't planning on redesigning interfaces all through the block and variable layers; and fixing this really does go quite far up. For instance it works back to block_innermost_frame, which can return NULL. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer