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

[Michael Snyder <msnyder@vmware.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.