This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: PRecord sets memory even when it says it did not
- From: Pedro Alves <pedro at codesourcery dot com>
- To: gdb at sourceware dot org
- Cc: Greg Law <glaw at undo-software dot com>, Hui Zhu <teawater at gmail dot com>, Marc Khouzam <marc dot khouzam at ericsson dot com>, Michael Snyder <msnyder at vmware dot com>, "gdb-patches ml" <gdb-patches at sourceware dot org>
- Date: Mon, 14 Sep 2009 18:49:57 +0100
- Subject: Re: PRecord sets memory even when it says it did not
- References: <F7CE05678329534C957159168FA70DEC5153600749@EUSAACMS0703.eamcs.ericsson.se> <daef60380909132139k46f577aet63f4089a97138368@mail.gmail.com> <4AAE7910.5040907@undo-software.com>
On Monday 14 September 2009 18:10:40, Greg Law wrote:
> Hui Zhu wrote:
> > On Mon, Sep 14, 2009 at 09:54, Marc Khouzam <marc.khouzam@ericsson.com> 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