[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