From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19012 invoked by alias); 4 Dec 2013 12:08:11 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 19000 invoked by uid 89); 4 Dec 2013 12:08:10 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.3 required=5.0 tests=AWL,BAYES_50,RDNS_NONE,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.3.2 X-HELO: mx1.redhat.com Received: from Unknown (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 04 Dec 2013 12:08:09 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id rB4C81aj008270 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 4 Dec 2013 07:08:01 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id rB4C7xFf006075; Wed, 4 Dec 2013 07:08:00 -0500 Message-ID: <529F1B1F.2040606@redhat.com> Date: Wed, 04 Dec 2013 12:08:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: Yao Qi CC: Mark Kettenis , gdb-patches@sourceware.org Subject: Re: [PATCH 2/3] skip_prolgoue (amd64) References: <1385735051-27558-1-git-send-email-yao@codesourcery.com> <1385735051-27558-3-git-send-email-yao@codesourcery.com> <201311291436.rATEaZ5Z030292@glazunov.sibelius.xs4all.nl> <201311291605.rATG5XVb030184@glazunov.sibelius.xs4all.nl> <52994E79.4000004@codesourcery.com> <5299B9D0.2020304@redhat.com> <529C37A2.9000207@codesourcery.com> <529E9462.9010001@codesourcery.com> In-Reply-To: <529E9462.9010001@codesourcery.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-12/txt/msg00122.txt.bz2 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