From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17066 invoked by alias); 17 Sep 2008 15:44:25 -0000 Received: (qmail 17057 invoked by uid 22791); 17 Sep 2008 15:44:24 -0000 X-Spam-Check-By: sourceware.org Received: from ti-out-0910.google.com (HELO ti-out-0910.google.com) (209.85.142.185) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 17 Sep 2008 15:43:47 +0000 Received: by ti-out-0910.google.com with SMTP id d10so2190928tib.12 for ; Wed, 17 Sep 2008 08:43:44 -0700 (PDT) Received: by 10.110.49.2 with SMTP id w2mr3466164tiw.28.1221666224051; Wed, 17 Sep 2008 08:43:44 -0700 (PDT) Received: by 10.110.42.9 with HTTP; Wed, 17 Sep 2008 08:43:43 -0700 (PDT) Message-ID: Date: Wed, 17 Sep 2008 15:44:00 -0000 From: teawater To: "Michael Snyder" Subject: Re: [reverse RFA] no singlestep-over-BP in reverse Cc: "Joel Brobecker" , "Daniel Jacobowitz" , "gdb-patches@sourceware.org" In-Reply-To: <48D0552E.7010200@vmware.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <48CEAA05.8050006@vmware.com> <48CFFE21.8030709@vmware.com> <20080916201029.GB3935@adacore.com> <48D0552E.7010200@vmware.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-09/txt/msg00370.txt.bz2 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, > >