From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1566 invoked by alias); 20 Oct 2008 00:44:33 -0000 Received: (qmail 1558 invoked by uid 22791); 20 Oct 2008 00:44:32 -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; Mon, 20 Oct 2008 00:43:44 +0000 Received: from mailhost2.vmware.com (mailhost2.vmware.com [10.16.67.167]) by smtp-outbound-2.vmware.com (Postfix) with ESMTP id AE59630000; Sun, 19 Oct 2008 17:43:42 -0700 (PDT) Received: from [10.20.92.59] (promb-2s-dhcp59.eng.vmware.com [10.20.92.59]) by mailhost2.vmware.com (Postfix) with ESMTP id 6636B8E568; Sun, 19 Oct 2008 17:43:42 -0700 (PDT) Message-ID: <48FBD342.5070905@vmware.com> Date: Mon, 20 Oct 2008 00:44: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/msg00481.txt.bz2 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. Thought so. See, the problem is that "adjust_pc_after_break" is assuming memory-breakpoint semantics, but Process Record/Replay actually implements hardware-breakpoint semantics. It watches the instruction-address "bus" and stops when the PC matches the address of a breakpoint. I suspect this is probably a problem with other record/replay back-ends too, but I haven't confirmed it yet. Still, I think that the patch you committed was correct for the reverse case. This is a corner case that reveals that "reverse" and "replay" are not synonymous. > (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