From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2774 invoked by alias); 17 Dec 2013 20:41:16 -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 2671 invoked by uid 89); 17 Dec 2013 20:41:15 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 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; Tue, 17 Dec 2013 20:41:14 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id rBHKfCdT009239 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 17 Dec 2013 15:41:12 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id rBHKfA4k021720; Tue, 17 Dec 2013 15:41:10 -0500 Message-ID: <52B0B6E5.3030903@redhat.com> Date: Tue, 17 Dec 2013 20:41: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 v8 24/24] record-btrace: add (reverse-)stepping support References: <1386839747-8860-1-git-send-email-markus.t.metzger@intel.com> <1386839747-8860-25-git-send-email-markus.t.metzger@intel.com> <52AB5E6A.1010105@redhat.com> <52AF62CB.7010805@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-12/txt/msg00663.txt.bz2 On 12/17/2013 03:47 PM, Metzger, Markus T wrote: >> -----Original Message----- >> From: Metzger, Markus T >> Sent: Tuesday, December 17, 2013 4:06 PM >> To: Pedro Alves > > >> I'm beginning to wonder if we should actually adjust the PC for >> btrace replay. The way I interpret the function, we got a SIGTRAP >> for executing the breakpoint instruction. The PC is after the breakpoint >> instruction, so it is one byte after the actual breakpoint location. We're >> now trying to undo the execution of the breakpoint instruction. >> Is this correct? >> >> In that case, we shouldn't adjust the PC since we did not execute >> the breakpoint instruction in the trace. We just asked whether there >> is a breakpoint at the current location. >> >> This seems to be different for s/w record. This is the first time, I need >> to distinguish between the different record targets. > > The s/w record target also does not execute the breakpoint instruction. > It increments the PC by gdbarch_decr_pc_after_break () when it finds a > s/w breakpoint at the current location. > > I wonder why they are doing that. Is this a workaround that was considered > less intrusive than what I am proposing below? It just seemed better at the time. When it was originally submitted the precord target was a lot more invasive in the core side, and I pushed for redoing it as a target (new stratum), and make it as transparent as possible. The current decr_pc_after_break handling was a result of that mindset. I'm not seeing a reason your suggested direction couldn't work for the s/w record target too. -- Pedro Alves