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

[Pedro Alves <pedro@codesourcery.com>]

On Monday 14 September 2009 20:04:12, Doug Evans wrote:

> It seems like what's needed is to move
> 
>   /* Make sure the cache gets updated no matter what - if we are
> writing
>      to the stack, even if this write is not tagged as such, we still
> need
>      to update the cache. */
> 
>   if (inf != NULL
>       && readbuf == NULL
>       && !region->attrib.cache
>       && stack_cache_enabled_p
>       && object != TARGET_OBJECT_STACK_MEMORY)
>     {
>       dcache_update (target_dcache, memaddr, (void *) writebuf, reg_len);
>     }
> 
> to after the call
> 
>       res = ops->to_xfer_partial (ops, TARGET_OBJECT_MEMORY, NULL,
>                                   readbuf, writebuf, memaddr, reg_len);
> 
> predicated on res > 0.
> 
> [dcache.c does the write first, and then updates the cache if it
> succeeded, we just need to do that here too, methinks]

That's fine with me as well.


There's one wrinkly corner case not being handled.  If the to_xfer_partial
routine throws an error, say a ptrace error of some kind (usually
perror_with_name), the ops target may still have succeeded in writing a
part of that partial transfer, but, the matching caches lines aren't
being invalidated/committed.  This is fine if we assume that errors
are only thrown before attempting any transfer at all, but that is not
reality.  E.g., when xfering [1000, 2000) in a single go, that may
fail half way, say, at 1500 with a hard thrown error.  Only thing 100%
safe to in these cases is to just flush the whole cache area that was
attempted to be written, or perhaps simpler, the whole cache.  Not
something you'd see hapenning every day, but still something
to consider at some point.

-- 
Pedro Alves