This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 2/3] skip_prolgoue (amd64)
- From: Yao Qi <yao at codesourcery dot com>
- To: Pedro Alves <palves at redhat dot com>
- Cc: Mark Kettenis <mark dot kettenis at xs4all dot nl>, <gdb-patches at sourceware dot org>
- Date: Thu, 5 Dec 2013 22:07:07 +0800
- Subject: Re: [PATCH 2/3] skip_prolgoue (amd64)
- Authentication-results: sourceware.org; auth=none
- References: <1385735051-27558-1-git-send-email-yao at codesourcery dot com> <1385735051-27558-3-git-send-email-yao at codesourcery dot com> <201311291436 dot rATEaZ5Z030292 at glazunov dot sibelius dot xs4all dot nl> <201311291605 dot rATG5XVb030184 at glazunov dot sibelius dot xs4all dot nl> <52994E79 dot 4000004 at codesourcery dot com> <5299B9D0 dot 2020304 at redhat dot com> <529C37A2 dot 9000207 at codesourcery dot com> <529E9462 dot 9010001 at codesourcery dot com> <529F1B1F dot 2040606 at redhat dot com> <529FD4B9 dot 10008 at codesourcery dot com> <52A06AC1 dot 1030209 at redhat dot com>
On 12/05/2013 08:00 PM, Pedro Alves wrote:
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.
I disagree. Results may be staled with cache, but results may be
different, not staled, without cache. They are different because they
are red on different times, but all of them are valid. It is a snapshot
of a piece of memory on a certain moment.
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,
I suspect you meant "chances" instead of "changes".
compared to not having a cache.
Flushing the cache decreases likelihood of getting staled data, but
can't completely remove it. I am fine to use cache in non-stop mode, as
it helps performance, so we have to compromise.
>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.
I meant, even "none of threads is running now", we may have to flush
cache if "they were resumed" (and all stopped now).
--
Yao (éå)