[PATCH 2/3] skip_prolgoue (amd64)

Yao Qi yao@codesourcery.com
Thu Dec 5 01:21:00 GMT 2013


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 (齐尧)



More information about the Gdb-patches mailing list