From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6305 invoked by alias); 5 Sep 2003 17:18:00 -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 6288 invoked from network); 5 Sep 2003 17:17:55 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 5 Sep 2003 17:17:55 -0000 Received: from drow by nevyn.them.org with local (Exim 4.22 #1 (Debian)) id 19vKDT-0000dh-Gx for ; Fri, 05 Sep 2003 13:17:47 -0400 Date: Fri, 05 Sep 2003 17:18:00 -0000 From: Daniel Jacobowitz To: gdb-patches@sources.redhat.com Subject: Re: RFC: selected frame in read_var_value Message-ID: <20030905171747.GA2385@nevyn.them.org> Mail-Followup-To: gdb-patches@sources.redhat.com References: <20030801192951.GA2109@nevyn.them.org> <3F329038.5040708@redhat.com> <20030828195501.GB27550@nevyn.them.org> <3F58C35A.3060908@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F58C35A.3060908@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-09/txt/msg00078.txt.bz2 On Fri, Sep 05, 2003 at 01:09:46PM -0400, Andrew Cagney wrote: > >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? > > Yep, welcome to my world :-) Your world is a very strange place :) > >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. > > What about something like this as a step sideways: > > >if (frame == NULL) > > frame = deprecated_safe_get_selected_frame (); > > where deprecated_safe_get_selected_frame() would contain those sanity > checks? Do you think this would interfere with fixing it later? If not, I'll put together a patch. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer