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: Wed, 04 Dec 2013 12:07:59 +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> <5299B9D0 dot 2020304 at redhat dot com> <529C37A2 dot 9000207 at codesourcery dot com> <529E9462 dot 9010001 at codesourcery dot com>
On 12/04/2013 02:33 AM, Yao Qi wrote:
> On 12/02/2013 03:32 PM, Yao Qi wrote:
>> > GDB target cache contains both code cache and stack cache. GDB can
>> > know the JIT event by means of jit event breakpoint, but GDB can't know
>> > whether a thread's stack is modified (by other threads). So we have
>> > to flush target cache before handling*every* event :-/ I'll send a
>> > follow-up patch.
> When I finished the patch below, I wondered whether this is the right
> way to go.
>
> Nowadays, in non-stop mode, GDB flushes target cache between
> each command. With the patch applied, GDB flushes target cache between
> each event. Then, I realize that GDB flushes cache at any changes (GDB
> commands from user and events from inferior) in non-stop mode, so I
> can't figure out a case that cache can be used. Do we still need target
> cache in non-stop mode?
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.
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.
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
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
should invalidate the cache at all places we invalidate the
overlay cache (wait_for_inferior, etc.), not just fetch_inferior_event.
For all-stop, it shouldn't really make a difference to
performance, as we invalidate the cache on resumes anyway,
and in all-stop, there must always be a resume prior to
any stop...
--
Pedro Alves