From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29424 invoked by alias); 28 Oct 2008 02:04:20 -0000 Received: (qmail 29415 invoked by uid 22791); 28 Oct 2008 02:04:18 -0000 X-Spam-Check-By: sourceware.org Received: from ti-out-0910.google.com (HELO ti-out-0910.google.com) (209.85.142.191) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 28 Oct 2008 02:03:24 +0000 Received: by ti-out-0910.google.com with SMTP id d10so1308668tib.12 for ; Mon, 27 Oct 2008 19:03:21 -0700 (PDT) Received: by 10.110.109.12 with SMTP id h12mr4025914tic.52.1225159401156; Mon, 27 Oct 2008 19:03:21 -0700 (PDT) Received: by 10.110.42.9 with HTTP; Mon, 27 Oct 2008 19:03:21 -0700 (PDT) Message-ID: Date: Tue, 28 Oct 2008 03:21: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: 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/msg00671.txt.bz2 Hi Pedro and Michael, How do you think about the patch in http://sourceware.org/ml/gdb-patches/2008-10/msg00634.html Thanks, Hui On Sat, Oct 25, 2008 at 15:07, teawater wrote: > The old patch make my_waitpid_record set pc even if this is not a breakpoint. > So I make a new patch that my_waitpid_record just set pc when this is > a breakpoint. > > > 2008-10-24 Hui Zhu > > * record.c (record_wait): Check breakpint before forward > execute in replay mode. > Check breakpoint use function "breakpoint_inserted_here_p" > in replay mode. > Set pc if forward execute, gdbarch_decr_pc_after_break is not > 0 and this is not single step in replay mode. > > * linux-nat.c (my_waitpid_record): Add > gdbarch_decr_pc_after_break to pc if need. > > > > On Fri, Oct 24, 2008 at 17:57, teawater wrote: >> Hi buddies, >> >> This is the new patch that fix the break bug. >> >> But I think I still need to add some code to deal with signal. >> >> 2008-10-24 Hui Zhu >> >> * record.c (record_wait): Check breakpint before forward >> execute in replay mode. >> Check breakpoint use function "breakpoint_inserted_here_p" >> in replay mode. >> Set pc if forward execute, gdbarch_decr_pc_after_break is not >> 0 and this is not single step in replay mode. >> >> * linux-nat.c (my_waitpid_record): Add >> gdbarch_decr_pc_after_break to pc if need. >> >> Thanks, >> Hui >> >> On Fri, Oct 24, 2008 at 16:10, teawater wrote: >>> 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 >>>> >>> >> >