From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24590 invoked by alias); 16 Sep 2008 04:13:16 -0000 Received: (qmail 24566 invoked by uid 22791); 16 Sep 2008 04:13:14 -0000 X-Spam-Check-By: sourceware.org Received: from ti-out-0910.google.com (HELO ti-out-0910.google.com) (209.85.142.187) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 16 Sep 2008 04:12:32 +0000 Received: by ti-out-0910.google.com with SMTP id d10so1605310tib.12 for ; Mon, 15 Sep 2008 21:12:29 -0700 (PDT) Received: by 10.110.2.2 with SMTP id 2mr616713tib.27.1221538349096; Mon, 15 Sep 2008 21:12:29 -0700 (PDT) Received: by 10.110.42.9 with HTTP; Mon, 15 Sep 2008 21:12:29 -0700 (PDT) Message-ID: Date: Tue, 16 Sep 2008 04:13:00 -0000 From: teawater To: "Michael Snyder" , "gdb-patches@sourceware.org" , teawater , "Daniel Jacobowitz" Subject: Re: [reverse RFA] no singlestep-over-BP in reverse In-Reply-To: <20080915184245.GA21388@caradoc.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <48CEAA05.8050006@vmware.com> <20080915184245.GA21388@caradoc.them.org> 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/msg00347.txt.bz2 I think is before exec the next instruction, the GDB will get breakpoint trap. But I found that there is a bug in inside record replay mode, I stop the GDB after exec the instruction. Michael, how do you deal with the breakpoint in gdb-freeplay and vmware record? Hui On Tue, Sep 16, 2008 at 02:42, Daniel Jacobowitz wrote: > > On Mon, Sep 15, 2008 at 11:31:33AM -0700, Michael Snyder wrote: > > When we're stopped at a breakpoint and we want to > > continue in reverse, we're not actually going to > > execute the instruction at the breakpoint -- we're > > going to de-execute the previous instruction. > > > > Therefore there's no need to singlestep before > > inserting breakpoints. In fact it would be a bad > > idea to do so, because if there is a breakpoint at > > the previous instruction, we WANT to hit it. > > > > Note that this patch is to be applied to the reverse branch. > > If there is a breakpoint on the previous instruction, will you hit it > before or after de-executing that instruction? It seems like this > logic should be somehow still necessary... but I can't put my finger > on when. > > -- > Daniel Jacobowitz > CodeSourcery