From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5968 invoked by alias); 9 Jan 2003 03:23:39 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 5956 invoked from network); 9 Jan 2003 03:23:36 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by 209.249.29.67 with SMTP; 9 Jan 2003 03:23:36 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18WVAh-00015u-00; Wed, 08 Jan 2003 23:24:03 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18WTII-0002kk-00; Wed, 08 Jan 2003 22:23:46 -0500 Date: Thu, 09 Jan 2003 03:23:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: gdb@sources.redhat.com Subject: Re: Failures in store.exp caused by regcache Message-ID: <20030109032346.GA10532@nevyn.them.org> Mail-Followup-To: Andrew Cagney , gdb@sources.redhat.com References: <20030108190506.GA558@nevyn.them.org> <3E1C77B4.8070401@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E1C77B4.8070401@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-01/txt/msg00111.txt.bz2 On Wed, Jan 08, 2003 at 02:10:44PM -0500, Andrew Cagney wrote: > >(Or rather, by the value code's interaction with the regcache) > > > >Andrew, this is more your area; I'd like your advice before I dig any > >further. Here's what's going wrong. Consider the command sequence: > >"up; print u; set u = s_1; print u". > > - u has class LOC_REGISTER > > - The register's home is memory > > - read_var_value therefore returns an lval_memory > > - the value of the register is in the register unwind cache at this point > > - we modify the memory backing the store > > - we have no way to tell that we've just modified the value of a saved > > register on the stack > > - the second print returns the cached value > > > >So, what do we do? > > Flush the frame cache. Ugg. Well, if we have to, then we have to. I suppose we do. We obviously want to preserve things like the selected frame, however. Andrew, should I do this the way I do for "set backtrace-below-main", and should there be a general function for that? I.E.: void do_flush_frames_sfunc (char *args, int from_tty, struct cmd_list_element *c) { int saved_level; struct frame_info *cur_frame; if (! target_has_stack) return; saved_level = frame_relative_level (get_selected_frame ()); flush_cached_frames (); cur_frame = find_relative_frame (get_current_frame (), &saved_level); select_frame (cur_frame); /* If we were below main and backtrace-below-main was turned off, SAVED_LEVEL will be non-zero. CUR_FRAME will point to main. Accept this but print the new frame. */ if (saved_level != 0) print_stack_frame (get_selected_frame (), -1, 0); } -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer