This is the mail archive of the
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: Michael Snyder <msnyder at vmware dot com>
- Cc: Marc Khouzam <marc dot khouzam at ericsson dot com>, "'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>, "'gdb-patches ml'" <gdb-patches at sourceware dot org>
- Date: Mon, 14 Sep 2009 19:15:07 +0100
- Subject: Re: PRecord sets memory even when it says it did not
- References: <F7CE05678329534C957159168FA70DEC5153600749@EUSAACMS0703.eamcs.ericsson.se> <firstname.lastname@example.org> <4AAE8492.email@example.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:firstname.lastname@example.org]
> >>> Sent: Monday, September 14, 2009 1:50 PM
> >>> To: email@example.com
> >>> 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