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: Tue, 10 Dec 2013 08:55:59 +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> <52A426E8 dot 2030808 at codesourcery dot com> <52A5AF41 dot 6080207 at redhat dot com> <52A5BF2F dot 9060708 at codesourcery dot com> <52A5C202 dot 8010109 at redhat dot com> <52A5CC0D dot 4080004 at codesourcery dot com> <52A5E2EE dot 5040501 at redhat dot com>
On 12/09/2013 11:34 PM, Pedro Alves wrote:
>> "wait -> handle event -> wait" is like a loop or circle to me, and we
>> >can flush at any point(s) of this circle, depending on what heuristic
>> >we are using.
> Again, the point is making it so that the cache does not enlarge
> the race window with the inferior itself. IOW, make the cache
> transparent WRT to chances of seeing a teared value, prologue, or
> whatever. Between starting to handle an event and finishing
> it, a very short time passes. Between finishing handling an
> event and the next event, an unbound amount of time passes.
> If we don't flush the cache just before handling the event,
> having the cache active has a much much wider race window width
> than without the cache active.
OK, I am convinced. Here is the patch to flush cache in every
"overlay_cache_invalid = 1" place. Beside this, I also invalidate
both target cache and overlay cache in infrun_thread_stop_requested_callback,
because handle_inferior_event is called in it.
--
Yao (éå)
gdb:
2013-12-10 Yao Qi <yao@codesourcery.com>
* infrun.c: Include "target-dcache.h".
(prepare_for_detach): Call target_dcache_invalidate.
(wait_for_inferior): Likewise.
(fetch_inferior_event): Likewise.
(infrun_thread_stop_requested_callback): Likewise. Set
overlay_cache_invalid to 1.
---
gdb/infrun.c | 24 ++++++++++++++++++++++++
1 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/gdb/infrun.c b/gdb/infrun.c
index 3b55583..d8f9787 100644
--- a/gdb/infrun.c
+++ b/gdb/infrun.c
@@ -60,6 +60,7 @@
#include "objfiles.h"
#include "completer.h"
#include "target-descriptions.h"
+#include "target-dcache.h"
/* Prototypes for local functions */
@@ -2475,6 +2476,13 @@ infrun_thread_stop_requested_callback (struct thread_info *info, void *arg)
old_chain = make_cleanup_restore_current_thread ();
+ overlay_cache_invalid = 1;
+ /* Flush target cache before starting to handle each event.
+ Target was running and cache could be stale. This is just a
+ heuristic. Running threads may modify target memory, but we
+ don't get any event. */
+ target_dcache_invalidate ();
+
/* Go through handle_inferior_event/normal_stop, so we always
have consistent output as if the stop event had been
reported. */
@@ -2677,6 +2685,11 @@ prepare_for_detach (void)
memset (ecs, 0, sizeof (*ecs));
overlay_cache_invalid = 1;
+ /* Flush target cache before starting to handle each event.
+ Target was running and cache could be stale. This is just a
+ heuristic. Running threads may modify target memory, but we
+ don't get any event. */
+ target_dcache_invalidate ();
if (deprecated_target_wait_hook)
ecs->ptid = deprecated_target_wait_hook (pid_ptid, &ecs->ws, 0);
@@ -2740,6 +2753,12 @@ wait_for_inferior (void)
overlay_cache_invalid = 1;
+ /* Flush target cache before starting to handle each event.
+ Target was running and cache could be stale. This is just a
+ heuristic. Running threads may modify target memory, but we
+ don't get any event. */
+ target_dcache_invalidate ();
+
if (deprecated_target_wait_hook)
ecs->ptid = deprecated_target_wait_hook (waiton_ptid, &ecs->ws, 0);
else
@@ -2805,6 +2824,11 @@ fetch_inferior_event (void *client_data)
make_cleanup_restore_current_thread ();
overlay_cache_invalid = 1;
+ /* Flush target cache before starting to handle each event. Target
+ was running and cache could be stale. This is just a heuristic.
+ Running threads may modify target memory, but we don't get any
+ event. */
+ target_dcache_invalidate ();
make_cleanup_restore_integer (&execution_direction);
execution_direction = target_execution_direction ();
--
1.7.7.6