From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21223 invoked by alias); 15 Sep 2008 23:09:57 -0000 Received: (qmail 21212 invoked by uid 22791); 15 Sep 2008 23:09:56 -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; Mon, 15 Sep 2008 23:09:21 +0000 Received: from mailhost5.vmware.com (mailhost5.vmware.com [10.16.68.131]) by smtp-outbound-2.vmware.com (Postfix) with ESMTP id DACEC4E004; Mon, 15 Sep 2008 16:09:19 -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 D198EDC064; Mon, 15 Sep 2008 16:09:19 -0700 (PDT) Message-ID: <48CEEAB6.90600@vmware.com> Date: Mon, 15 Sep 2008 23:09:00 -0000 From: Michael Snyder User-Agent: Thunderbird 1.5.0.12 (X11/20080411) MIME-Version: 1.0 To: Michael Snyder , "gdb-patches@sourceware.org" , teawater Subject: Re: [reverse RFA] no singlestep-over-BP in reverse References: <48CEAA05.8050006@vmware.com> <20080915184245.GA21388@caradoc.them.org> <48CEB1F5.6080902@vmware.com> <20080915211443.GB30767@caradoc.them.org> In-Reply-To: <20080915211443.GB30767@caradoc.them.org> 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/msg00343.txt.bz2 Daniel Jacobowitz wrote: > On Mon, Sep 15, 2008 at 12:05:25PM -0700, Michael Snyder wrote: >>> If there is a breakpoint on the previous instruction, will you hit it >>> before or after de-executing that instruction? >> Well, if trap insns are in place, that's what will be >> executed (not the shadow insn). > > Presumably it'd be a hardware breakpoint. Software breakpoints in > reverse execution seem... awkward. Right. I've just been re-thinking the issue. I don't know how it might work with SW bp, but the three implementations that I know of right now all use HW bps. In that case, the target just has to guarantee to un-execute the instruction before stopping, and then everything will be OK. I posted some tests, those all work, but I will go ahead and try to port (and post) the consecutive.exp test anyway.