From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12605 invoked by alias); 30 Nov 2013 10:11:41 -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 12594 invoked by uid 89); 30 Nov 2013 10:11:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.1 required=5.0 tests=AWL,BAYES_40,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; Sat, 30 Nov 2013 10:11:39 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id rAUABU1N016968 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 30 Nov 2013 05:11:30 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id rAUABS6f027708; Sat, 30 Nov 2013 05:11:29 -0500 Message-ID: <5299B9D0.2020304@redhat.com> Date: Sat, 30 Nov 2013 12:01: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> In-Reply-To: <52994E79.4000004@codesourcery.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-11/txt/msg00959.txt.bz2 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