From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7082 invoked by alias); 14 Sep 2009 17:50:02 -0000 Received: (qmail 7039 invoked by uid 22791); 14 Sep 2009 17:50:00 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 14 Sep 2009 17:49:55 +0000 Received: (qmail 12960 invoked from network); 14 Sep 2009 17:49:54 -0000 Received: from unknown (HELO orlando) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 14 Sep 2009 17:49:54 -0000 From: Pedro Alves To: gdb@sourceware.org Subject: Re: PRecord sets memory even when it says it did not Date: Mon, 14 Sep 2009 17:50:00 -0000 User-Agent: KMail/1.9.10 Cc: Greg Law , Hui Zhu , Marc Khouzam , Michael Snyder , "gdb-patches ml" References: <4AAE7910.5040907@undo-software.com> In-Reply-To: <4AAE7910.5040907@undo-software.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200909141849.57563.pedro@codesourcery.com> 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: 2009-09/txt/msg00423.txt.bz2 On Monday 14 September 2009 18:10:40, Greg Law wrote: > Hui Zhu wrote: > > On Mon, Sep 14, 2009 at 09:54, Marc Khouzam wrote: > > I just tried change it with "p a=99". I think it must have something > > different with "set var a = 8". > > I've noticed something similar with UndoDB. Until very recently, if we > failed a 'poke' operation (which we do when in replay mode) the data > would not be changed. But with a recent gdb built from cvs (as of about > two weeks ago), despite UndoDB failing the poke, the value still appears > to the user to have been written. > > Could this be related to the caching changes that have happened > recently? i.e. does the cache get updated even though the underlying > poke operation failed? If so, this issue would seem to be wider than > just prec (and wider than reverse, too). If so, then there's an easy way to find out: try again with "set stack-cache off". -- Pedro Alves