From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23600 invoked by alias); 23 Oct 2008 23:46:31 -0000 Received: (qmail 23588 invoked by uid 22791); 23 Oct 2008 23:46:30 -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; Thu, 23 Oct 2008 23:45:55 +0000 Received: (qmail 12424 invoked from network); 23 Oct 2008 23:45:53 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 23 Oct 2008 23:45:53 -0000 From: Pedro Alves To: Michael Snyder Subject: Re: [reverse/record] adjust_pc_after_break in reverse execution mode? Date: Thu, 23 Oct 2008 23:46:00 -0000 User-Agent: KMail/1.9.9 Cc: "gdb-patches@sourceware.org" , teawater References: <200810180210.16346.pedro@codesourcery.com> <200810200109.55661.pedro@codesourcery.com> <49010833.4070400@vmware.com> In-Reply-To: <49010833.4070400@vmware.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200810240045.52818.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/msg00593.txt.bz2 A Friday 24 October 2008 00:26:43, Michael Snyder wrote: > 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? I've done so a bit this morning, and came to a similar conclusion, although I noticed Hui's change to set stop_pc in TARGET_WAITKIND_NO_HISTORY, also also required. I was wanting to find time to play a little bit more, but since you're on to it... I think the issue here, is that when proceeding (continuing) from B1 below, B1: PC --> 0x80000001 INSN1 B2: 0x80000002 INSN2 GDB will always do a single-step to get over B1. Then, the record target replays INSN1, and then notices that there's a breakpoint at 0x80000002. Remember that GDB told the target to single-step (over a breakpoint), and to do so, removed all breakpoints from the inferior. Hence, the adjust_pc_after_break checks to see if there's a breakpoint inserted at `0x80000002 - 1', it will find there isn't one (no breakpoint is inserted while doing the single-step over breakpoints operation). 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! Without Hui's stop_pc change, when we'd go backwards and hit the start (end, whatever) of history, we'd get us a wrong stop_pc. Then, proceed while doing this check: if (pc == stop_pc && breakpoint_here_p (pc) && execution_direction != EXEC_REVERSE) pc == stop_pc would fail, and hence the target would not be told to single-step over the breakpoint, producing the bad effects we were seeing. (*) Hope I'm making sense. This gave me a bit of a headache this morning. :-) (*) BTW, it seemed that TARGET_WAITKIND_NO_HISTORY overrides the last event the target would report? Should'nt the last event in history be reported normally, and only *on the next* resume we'd get a TARGET_WAITKIND_NO_HISTORY? I was wondering if you'd not lose a possible interesting event, just because it happened to be on the edge of the history. > > 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 > > -- Pedro Alves