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: Marc Khouzam <marc dot khouzam at ericsson dot com>
- Cc: "'gdb at sourceware dot org'" <gdb at sourceware dot org>, "'Greg Law'" <glaw at undo-software dot com>, "'Hui Zhu'" <teawater at gmail dot com>, "'Michael Snyder'" <msnyder at vmware dot com>, "'gdb-patches ml'" <gdb-patches at sourceware dot org>
- Date: Mon, 14 Sep 2009 19:01:08 +0100
- Subject: Re: PRecord sets memory even when it says it did not
- References: <F7CE05678329534C957159168FA70DEC5153600749@EUSAACMS0703.eamcs.ericsson.se> <200909141849.57563.pedro@codesourcery.com> <F7CE05678329534C957159168FA70DEC515363D089@EUSAACMS0703.eamcs.ericsson.se>
On Monday 14 September 2009 18:53:51, Marc Khouzam wrote:
>
> > -----Original Message-----
> > From: Pedro Alves [mailto:pedro@codesourcery.com]
> > Sent: Monday, September 14, 2009 1:50 PM
> > To: gdb@sourceware.org
> > Cc: Greg Law; Hui Zhu; Marc Khouzam; Michael Snyder; gdb-patches ml
> > Subject: Re: PRecord sets memory even when it says it did not
> >
> > > 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".
> >
>
> Yes, that seems to fix everything.
Then I'd suspect either a bug dcache_xfer_memory, or a missing
target_dcache_invalidate/dcache_invalidate call somewhere.
--
Pedro Alves