From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10734 invoked by alias); 17 Sep 2008 00:56:41 -0000 Received: (qmail 10725 invoked by uid 22791); 17 Sep 2008 00:56:40 -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; Wed, 17 Sep 2008 00:56:05 +0000 Received: from mailhost5.vmware.com (mailhost5.vmware.com [10.16.68.131]) by smtp-outbound-2.vmware.com (Postfix) with ESMTP id 8F47946103; Tue, 16 Sep 2008 17:56:03 -0700 (PDT) Received: from [10.20.92.218] (promb-2s-dhcp218.eng.vmware.com [10.20.92.218]) by mailhost5.vmware.com (Postfix) with ESMTP id 8348CDC090; Tue, 16 Sep 2008 17:56:03 -0700 (PDT) Message-ID: <48D0552E.7010200@vmware.com> Date: Wed, 17 Sep 2008 00:56:00 -0000 From: Michael Snyder User-Agent: Thunderbird 1.5.0.12 (X11/20080411) MIME-Version: 1.0 To: Joel Brobecker CC: teawater , Daniel Jacobowitz , "gdb-patches@sourceware.org" Subject: Re: [reverse RFA] no singlestep-over-BP in reverse References: <48CEAA05.8050006@vmware.com> <48CFFE21.8030709@vmware.com> <20080916201029.GB3935@adacore.com> In-Reply-To: <20080916201029.GB3935@adacore.com> Content-Type: multipart/mixed; boundary="------------040600030609050403030306" 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-09/txt/msg00367.txt.bz2 This is a multi-part message in MIME format. --------------040600030609050403030306 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-length: 699 Joel Brobecker wrote: >> And I believe that consistent behavior / semantics should be: >> >> If you tell me that you are stopped at instruction 1000, >> regardless of whether you were going forward or backward >> when you got there, then I will expect that if I tell you >> to execute forward, you will execute the instruction at >> 1000. > > This makes total sense to me. I think I would be very confused > by the debugger if I started going back and forth with a debugger > that didn't follow the semantics above. Thanks. By the way I've revised this patch slightly, as shown below. Use "== reverse" instead of "!= forward". Makes it do the right thing in the "unknown" case. --------------040600030609050403030306 Content-Type: text/plain; name="bpstep.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="bpstep.txt" Content-length: 1217 2008-09-15 Michael Snyder * infrun.c (proceed): No need to singlestep over a breakpoint when resuming in reverse. Index: infrun.c =================================================================== RCS file: /cvs/src/src/gdb/infrun.c,v retrieving revision 1.300.2.5 diff -u -p -r1.300.2.5 infrun.c --- infrun.c 5 Sep 2008 03:37:10 -0000 1.300.2.5 +++ infrun.c 17 Sep 2008 00:54:00 -0000 @@ -1226,11 +1226,17 @@ proceed (CORE_ADDR addr, enum target_sig if (addr == (CORE_ADDR) -1) { - if (pc == stop_pc && breakpoint_here_p (pc)) + if (pc == stop_pc && breakpoint_here_p (pc) + && target_get_execution_direction () != EXEC_REVERSE) /* There is a breakpoint at the address we will resume at, step one instruction before inserting breakpoints so that we do not stop right away (and report a second hit at this - breakpoint). */ + breakpoint). + + Note, we don't do this in reverse, because we won't + actually be executing the breakpoint insn anyway. + We'll be (un-)executing the previous instruction. */ + oneproc = 1; else if (gdbarch_single_step_through_delay_p (gdbarch) && gdbarch_single_step_through_delay (gdbarch, --------------040600030609050403030306--