From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13476 invoked by alias); 20 Dec 2013 16:31:03 -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 13465 invoked by uid 89); 20 Dec 2013 16:31:02 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 20 Dec 2013 16:31:02 +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 rBKGUxX1000340 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 20 Dec 2013 11:30:59 -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 rBKGUuPi028832; Fri, 20 Dec 2013 11:30:57 -0500 Message-ID: <52B470C0.30307@redhat.com> Date: Fri, 20 Dec 2013 16:31: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: "Metzger, Markus T" CC: "jan.kratochvil@redhat.com" , "gdb-patches@sourceware.org" , Eli Zaretskii Subject: Re: [PATCH v9 29/29] record-btrace: add (reverse-)stepping support References: <1387471499-29444-1-git-send-email-markus.t.metzger@intel.com> <1387471499-29444-30-git-send-email-markus.t.metzger@intel.com> <52B3529E.70407@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-12/txt/msg00844.txt.bz2 On 12/20/2013 02:47 PM, Metzger, Markus T wrote: >> -----Original Message----- >> From: Metzger, Markus T >> Sent: Friday, December 20, 2013 3:37 PM >> To: Pedro Alves > > >>> This really shouldn't be necessary, given target_resume does >>> it for you. If you still needed, you're papering over some >>> problem. >> >> If we start replaying in to_wait, we'll call get_current_frame >> to fix up some stepping related frames. This will be done on >> the current PC. >> >> When we step later on in record_btrace_step_thread, we change >> the replay position but not the PC. >> >> I guess it will be more clear when I move this into >> record_btrace_step_thread and change the comment. > > I moved it to record_btrace_start_replaying: Hmm. > > @@ -1406,15 +1405,15 @@ record_btrace_start_replaying (struct thread_info *tp) > /* Restore the previous execution state. */ > set_executing (tp->ptid, executing); > > + /* Invalidate registers again. If this is called on the to_wait path, > + we expect registers still invalid from to_resume. */ > + registers_changed_ptid (tp->ptid); > + The registers haven't really changed at this point. It seems like it that may help because it just happens that today, nothing is currently reading registers before you move the thread to the next position. If something does that, you'll get stale results again. It'd be safer to do this right after moving the thread to the next trace position. So with that in mind, either indeed put it in record_btrace_step_thread or just leave it at the place the original code had it already, but update the comment to sound more determined, something like: /* We just moved the thread to a different trace position. If anything fetched the thread's registers before, its regcache is stale now. */ registers_changed_ptid (tp->ptid); Thanks, -- Pedro Alves