Re: PRecord sets memory even when it says it did not

[Michael Snyder <msnyder at vmware dot com>]

Pedro Alves wrote:
> A Monday 14 September 2009 18:59:46, Michael Snyder escreveu:
> > Pedro Alves wrote:
> > > 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.
> > I'm not too familiar with this dcache.
> > Is it up to the target to_xfer_memory method
> > to invalidate it before erroring out?
>
> No.  dcache_xfer_memory tries to handle it itself already, with
> dcache_invalidate_line, but there's probably a bug over there, which
> should be easy to catch stepping through dcache_xfer_memory in the
> offending case.  Note that it is dcache_xfer_memory
> that calls the target to_xfer_memory routine, not
> memory_xfer_partial.

Umm, that last sentence does not seem to be true.
1) I can see the call to ops->to_xfer_partial in memory_xfer_partial src
2) I've got a backtrace right here showing record_xfer_partial
called by memory_xfer_partial.