[PATCH 2/3] skip_prolgoue (amd64)

[Pedro Alves]

On 12/05/2013 01:19 AM, Yao Qi wrote:
> On 12/04/2013 08:07 PM, Pedro Alves wrote:
>> It can still help for the duration of the command, or for the
>> duration of the event handling.  GDB might end up reading the
>> same locations more than once while doing either.  Also, the
>> overfetching can still help anyway.  E.g., in the prologue
>> analyzers while handling each event.
> 
> While handling an event, if another thread is still running, we still
> can't use cache.

I think we can.  My view here is that handling an event
is a quick and short lived operation.  GDB bursts a few reads
in sequence, and then moves on to the next event.  In that
scenario, you get as much stale results with or without a cache.
IOW, even without the cache, running threads can change memory as
GDB reads it, and so the chances of hitting stale data with or
without a cache are practically the same.  OTOH, distinct target
events (and commands, etc.) can trigger quite apart (time-wise),
and that break the odd balance -- not flushing the cache
between events increases the changes of hitting stale data,
compared to not having a cache.

> Beside the predicate "is any thread running", another is "no thread is
> resumed since last flushing".  Cache should be flushed when either is
> true.

Not sure I understood that.

-- 
Pedro Alves