From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6588 invoked by alias); 17 Sep 2008 18:18:24 -0000 Received: (qmail 6573 invoked by uid 22791); 17 Sep 2008 18:18:23 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-outbound-1.vmware.com (HELO smtp-outbound-1.vmware.com) (65.113.40.141) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 17 Sep 2008 18:17:48 +0000 Received: from mailhost2.vmware.com (mailhost2.vmware.com [10.16.64.160]) by smtp-outbound-1.vmware.com (Postfix) with ESMTP id EA0E26B01; Wed, 17 Sep 2008 11:17:45 -0700 (PDT) Received: from [10.20.92.218] (promb-2s-dhcp218.eng.vmware.com [10.20.92.218]) by mailhost2.vmware.com (Postfix) with ESMTP id 0C1138E606; Wed, 17 Sep 2008 11:17:46 -0700 (PDT) Message-ID: <48D1494D.4070306@vmware.com> Date: Wed, 17 Sep 2008 18:18:00 -0000 From: Michael Snyder User-Agent: Thunderbird 1.5.0.12 (X11/20080411) MIME-Version: 1.0 To: teawater CC: Joel Brobecker , 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> <48D0552E.7010200@vmware.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; 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-09/txt/msg00376.txt.bz2 Committed to branch. teawater wrote: > Looks good. Please check it in. > > And I think we have decided the how to deal with breakpoint. > > On Wed, Sep 17, 2008 at 08:54, Michael Snyder wrote: >> 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. >> >> >> 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, >> >>