From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18434 invoked by alias); 24 Oct 2008 01:51:01 -0000 Received: (qmail 18176 invoked by uid 22791); 24 Oct 2008 01:50:59 -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; Fri, 24 Oct 2008 01:50:21 +0000 Received: (qmail 16098 invoked from network); 24 Oct 2008 01:50:19 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 24 Oct 2008 01:50:19 -0000 From: Pedro Alves To: Michael Snyder Subject: Re: [reverse/record] adjust_pc_after_break in reverse execution mode? Date: Fri, 24 Oct 2008 01:51:00 -0000 User-Agent: KMail/1.9.9 Cc: "gdb-patches@sourceware.org" , teawater References: <200810180210.16346.pedro@codesourcery.com> <200810240045.52818.pedro@codesourcery.com> <490118CB.5000500@vmware.com> In-Reply-To: <490118CB.5000500@vmware.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200810240250.20238.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/msg00599.txt.bz2 On Friday 24 October 2008 01:37:31, Michael Snyder wrote: > > In sum, it appears that decr_pc_after_break doesn't matter when you have > > continguous breakpoints, as long as you get from from B1's address to B= 2's > > address by single-stepping. =C2=A0All is good then, it appears! >=20 > I agree, at least that is the conclusion I am leaning toward. >=20 Not so fast! I knew I had to spend a little extra thinking about it, 'cause I knew something was broken, just couldn't find what. :-) *as long as you get from from B1's address to B2's address by single-stepping* was a restriction that doesn't always apply. Here's a test that will fail in forward record/replay mode, but not in normal "play" mode. volatile int global_foo =3D 0; int main (int argc, char **argv) { asm ("nop"); /* 1st insn */ asm ("nop"); /* 2nd insn */ asm ("nop"); /* 3rd insn */ asm ("nop"); /* 4th insn */ if (!global_foo) goto ahead; asm ("nop"); /* 5th insn */ asm ("nop"); /* 6th insn */ asm ("nop"); /* 7th insn */ asm ("nop"); /* 8th insn */ <<< break 1 here ahead: asm ("nop"); /* 9th insn */ <<< break 2 here end: return 0; } If you let the program reply until break 2 is hit, and assuming insn 8th and 9th are assembled as contiguous (they do on x86 -O0 for me), you'll see that adjust_pc_after_break will indeed make it appear that breakpoint 1 was hit. Now, nops are nops, but real code could have something else there... /me goes back to bed. --=20 Pedro Alves