This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: PRecord sets memory even when it says it did not
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