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: Pedro Alves <palves at redhat dot com>
- To: Yao Qi <yao at codesourcery dot com>
- Cc: Mark Kettenis <mark dot kettenis at xs4all dot nl>, gdb-patches at sourceware dot org
- Date: Sat, 30 Nov 2013 10:11:28 +0000
- 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>
On 11/30/2013 02:33 AM, Yao Qi wrote:
> On 11/30/2013 12:05 AM, Mark Kettenis wrote:
>> But only if the cache is properly invalidated when control when
>> running/stepping. Is it?
>
> Yes, cache is invalidated when the inferior is to be resumed. See
> target.c:target_resume.
>
> void
> target_resume (ptid_t ptid, int step, enum gdb_signal signal)
> {
> struct target_ops *t;
>
> target_dcache_invalidate ();
> ....
>
We also invalidate the cache just before running a command, threads
may be running, in prepare_execute_command:
struct cleanup *
prepare_execute_command (void)
{
...
/* With multiple threads running while the one we're examining is
stopped, the dcache can get stale without us being able to detect
it. For the duration of the command, though, use the dcache to
help things like backtrace. */
if (non_stop)
target_dcache_invalidate ();
It seems like we can "dangerously" hit stale cache (probably most
visible with non-stop mode) between target events:
#1 - all threads set running, dcache is invalidated
#2 - thread 1 stops. As we handle the event, we read code, and cache it.
#3 - others threads continue running. some thread jits something, or
changes code that was cached.
#4 - thread 2 stops. As we handle the event, we read code, hitting
stale cache.
I'm thinking we might need to flush the dcache before handling each
event, like we already invalidate the overlay cache (see
"overlay_cache_invalid = 1" in infrun.c) ?
--
Pedro Alves