Re: [PATCH 2/3] skip_prolgoue (amd64)

Yao Qi
2013-12-05T01:21:43Z

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.

>
> Actually "non-stop", vs "all-stop" here isn't the ideal
> predicate. The real predicate is "is any thread running".
> "non-stop" is just being currently used in
> prepare_execute_command as proxy for that, just because
> that was the easiest.
>

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

> On 12/04/2013 02:33 AM, Yao Qi wrote:
>
>> >@@ -2806,6 +2807,16 @@ fetch_inferior_event (void *client_data)
>> >
>> > overlay_cache_invalid = 1;
>> >
>> >+ if (non_stop)
>> >+ {
>> >+ /* In non-stop mode, one thread stops and caches the contents of
>> >+ stack or code, while other running threads may change the
>> >+ code (through JIT) or stack. The target cache can get stale
>> >+ without us being able to detect it. Flush target cache
>> >+ before handling each event. */
>> >+ target_dcache_invalidate ();
>> >+ }
> I don't actually think this should be gated on non-stop. It

Right, "non-stop" is not a proper condition here.

> should be unconditional. I mentioned before that it'd be most
> visible with non-stop, but that doesn't imply it's not
> visible with all-stop. If we're seeing or going to wait for
> a target event, it's because the target was running,
> irrespective of all-stop/non-stop. I really think we

That is true, but once we got a target event, target(or thread in the
target) may not stop. It is still unsafe to use cache.

--
Yao (é½å°§)