This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On 12/08/2013 07:59 AM, Yao Qi wrote:

> After some discussions, it becomes clear to me that we should flush
> target cache before handling events, in the place of the callers of
> handle_inferior_event.  I am wondering why don't we flush cache inside
> handle_inferior_event?  Although flushing cache is not much relevant
> to handle_inferior_event, this can avoid doing cache flush in every
> caller of handle_inferior_event.

The concern is that target_wait implementations may read memory.

wait_for_inferior & friends used to have a registers_changed call
and this comment:

      /* We have to invalidate the registers BEFORE calling target_wait
	 because they can be loaded from the target while in target_wait.
	 This makes remote debugging a bit more efficient for those
	 targets that provide critical registers as part of their normal
	 status mechanism. */

      overlay_cache_invalid = 1;
      registers_changed ();

      if (deprecated_target_wait_hook)
	ecs->ptid = deprecated_target_wait_hook (waiton_ptid, &ecs->ws, 0);
      else
	ecs->ptid = target_wait (waiton_ptid, &ecs->ws, 0);


Removed here:

 https://sourceware.org/ml/gdb-patches/2011-09/msg00122.html

That was easy to do given we can't read registers of running
threads, so we're sure a new regcache will be created for
the just stopped thread, but for memory it looks simpler and
safer to me to flush before target_wait instead of going
through all possible target_wait paths that could read
memory and be sure to flush there.

-- 
Pedro Alves


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]