From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15582 invoked by alias); 24 Oct 2008 08:11:31 -0000 Received: (qmail 15570 invoked by uid 22791); 24 Oct 2008 08:11:30 -0000 X-Spam-Check-By: sourceware.org Received: from ti-out-0910.google.com (HELO ti-out-0910.google.com) (209.85.142.190) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 24 Oct 2008 08:10:55 +0000 Received: by ti-out-0910.google.com with SMTP id d10so436685tib.12 for ; Fri, 24 Oct 2008 01:10:52 -0700 (PDT) Received: by 10.110.5.14 with SMTP id 14mr1109803tie.58.1224835852146; Fri, 24 Oct 2008 01:10:52 -0700 (PDT) Received: by 10.110.42.9 with HTTP; Fri, 24 Oct 2008 01:10:52 -0700 (PDT) Message-ID: Date: Fri, 24 Oct 2008 08:11:00 -0000 From: teawater To: "Pedro Alves" , "Michael Snyder" Subject: Re: [reverse/record] adjust_pc_after_break in reverse execution mode? Cc: "gdb-patches@sourceware.org" In-Reply-To: <200810240250.20238.pedro@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200810180210.16346.pedro@codesourcery.com> <200810240045.52818.pedro@codesourcery.com> <490118CB.5000500@vmware.com> <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/msg00602.txt.bz2 Thanks Pedro and Michael, I think the reason is P record let inferior step recycle in the linux-nat target. So when it break by breakpint, it will not let (pc+gdbarch_decr_pc_after_break (gdbarch)). Then after adjust_pc_after_break, The PC is error. I will try to deal with it. Hui On Fri, Oct 24, 2008 at 09:50, Pedro Alves wrote: > 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 B2's >> > address by single-stepping. All is good then, it appears! >> >> I agree, at least that is the conclusion I am leaning toward. >> > > 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 = 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. > > -- > Pedro Alves >