From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18873 invoked by alias); 23 Oct 2008 23:32:23 -0000 Received: (qmail 18862 invoked by uid 22791); 23 Oct 2008 23:32:23 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-outbound-2.vmware.com (HELO smtp-outbound-2.vmware.com) (65.115.85.73) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 23 Oct 2008 23:31:41 +0000 Received: from mailhost3.vmware.com (mailhost3.vmware.com [10.16.27.45]) by smtp-outbound-2.vmware.com (Postfix) with ESMTP id 08A384A011; Thu, 23 Oct 2008 16:31:39 -0700 (PDT) Received: from [10.20.92.59] (promb-2s-dhcp59.eng.vmware.com [10.20.92.59]) by mailhost3.vmware.com (Postfix) with ESMTP id F3142C9A20; Thu, 23 Oct 2008 16:31:38 -0700 (PDT) Message-ID: <49010833.4070400@vmware.com> Date: Thu, 23 Oct 2008 23:32:00 -0000 From: Michael Snyder User-Agent: Thunderbird 1.5.0.12 (X11/20080411) MIME-Version: 1.0 To: Pedro Alves CC: "gdb-patches@sourceware.org" , teawater Subject: Re: [reverse/record] adjust_pc_after_break in reverse execution mode? References: <200810180210.16346.pedro@codesourcery.com> <48FBB718.4040706@vmware.com> <200810200109.55661.pedro@codesourcery.com> In-Reply-To: <200810200109.55661.pedro@codesourcery.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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/msg00592.txt.bz2 Hi Pedro, I duplicated your test case, and found that I could reproduce the behavior that you show below, but only so long as the branch did not contain your "adjust_pc_after_break" patch. Once I added that patch to the branch, this behavior seemed to go away. If I look carefully at what you did below, it seems like the forward-replay problem only shows up immediately after the reverse-replay problem manifests. And my experiments reflect the same thing. The branch is now patched. Could you spare a moment to play with it, and see if you can make it break again? Thanks! Pedro Alves wrote: > On Sunday 19 October 2008 23:39:20, Michael Snyder wrote: >> After codgitating for a bit (that's "thinking" when you're over 50), >> I've decided that you're right. >> >> However, I have a new concern -- I'm worried about what it will do >> when it's replaying but going forward. >> >> Could you possibly revisit your test and see what it does >> if you record all the way to line 9 or 10, then back up >> to line 6, then continue with breakpoints at 6 and 7? > > Eh, you're right. It's broken. > > (gdb) record > (gdb) b 6 > Breakpoint 2 at 0x8048352: file nop.c, line 6. > (gdb) b 7 > Breakpoint 3 at 0x8048353: file nop.c, line 7. > (gdb) n > > Breakpoint 3, main () at nop.c:7 > 7 asm ("nop"); > (gdb) n > 8 asm ("nop"); > (gdb) > 9 asm ("nop"); > (gdb) n > 10 } > (gdb) rc > Continuing. > > Breakpoint 3, main () at nop.c:7 > 7 asm ("nop"); > (gdb) rn > > No more reverse-execution history. > main () at nop.c:6 > 6 asm ("nop"); > (gdb) n > > Breakpoint 2, main () at nop.c:6 > 6 asm ("nop"); > (gdb) > 8 asm ("nop"); > (gdb) > 9 asm ("nop"); > (gdb) > > > > -- > Pedro Alves