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

[Pedro Alves <pedro@codesourcery.com>]

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.

-- 
Pedro Alves