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

[Yao Qi <yao at codesourcery dot com>]

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 (éå)