From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13343 invoked by alias); 20 Oct 2008 17:44:57 -0000 Received: (qmail 13335 invoked by uid 22791); 20 Oct 2008 17:44:56 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 20 Oct 2008 17:44:21 +0000 Received: (qmail 710 invoked from network); 20 Oct 2008 17:44:18 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 20 Oct 2008 17:44:18 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: [reverse/record] adjust_pc_after_break in reverse execution mode? Date: Mon, 20 Oct 2008 17:44:00 -0000 User-Agent: KMail/1.9.9 Cc: Michael Snyder , teawater References: <200810180210.16346.pedro@codesourcery.com> <200810200109.55661.pedro@codesourcery.com> <48FBD342.5070905@vmware.com> In-Reply-To: <48FBD342.5070905@vmware.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200810201844.30954.pedro@codesourcery.com> X-IsSubscribed: yes 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 X-SW-Source: 2008-10/txt/msg00494.txt.bz2 On Monday 20 October 2008 01:39:30, Michael Snyder wrote: > See, the problem is that "adjust_pc_after_break" is assuming > memory-breakpoint semantics, but Process Record/Replay actually > implements hardware-breakpoint semantics. =C2=A0It watches the > instruction-address "bus" and stops when the PC matches the > address of a breakpoint. >=20 > I suspect this is probably a problem with other record/replay > back-ends too, but I haven't confirmed it yet. >=20 But that is wrong. If GDB is telling the target to insert software breakpoints, and the target is accepting them, then GDB assumes software breakpoints semantics for that particular architecture. That's the `target_insert_breakpoint' semantics (native/remote, doesn't matter). For remote, if the stub is accepting Z0, those breakpoint should behave as memory breakpoints. See from the manual: " `Z0,addr,length' Insert (`Z0') or remove (`z0') a memory breakpoint at address addr of size = length.=20 `Z1,addr,length' Insert (`Z1') or remove (`z1') a hardware breakpoint at address addr of= size length.=20 A hardware breakpoint is implemented using a mechanism that is not depe= ndant on being able to modify the target's memory.=20 " Notice that adjust_pc_after_break does this: /* Check whether there actually is a *software breakpoint* inserted at that location. */ if (software_breakpoint_inserted_here_p (breakpoint_pc)) ^^^^^^^^ { If the stub on a decr_pc_after_break arch lies to GDB, then, PC adjustment will be broken, even in normal forward debugging. I believe the correct thing for the target to do is to report `PC + decr_pc_after_breakpoint' on forward (replay or normal forward) breakpoint hits, if it is telling GDB that it succesfully inserted a software breakpoint. --=20 Pedro Alves