From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-patches-return-58647-listarch-gdb-patches=sources.redhat.com@sourceware.org>
Received: (qmail 14921 invoked by alias); 16 Sep 2008 18:40:02 -0000
Received: (qmail 14892 invoked by uid 22791); 16 Sep 2008 18:40:01 -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; Tue, 16 Sep 2008 18:39:26 +0000
Received: from mailhost2.vmware.com (mailhost2.vmware.com [10.16.64.160]) 	by smtp-outbound-2.vmware.com (Postfix) with ESMTP id 94728D00C; 	Tue, 16 Sep 2008 11:39:24 -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 8B0BF8E54B; 	Tue, 16 Sep 2008 11:39:24 -0700 (PDT)
Message-ID: <48CFFCEA.7000002@vmware.com>
Date: Tue, 16 Sep 2008 18:40:00 -0000
From: Michael Snyder <msnyder@vmware.com>
User-Agent: Thunderbird 1.5.0.12 (X11/20080411)
MIME-Version: 1.0
To: teawater <teawater@gmail.com>
CC: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Subject: Re: [reverse RFA] no singlestep-over-BP in reverse
References: <48CEAA05.8050006@vmware.com>	 <20080915184245.GA21388@caradoc.them.org> <daef60380809152110u663350abx76b283d519c5a09d@mail.gmail.com>
In-Reply-To: <daef60380809152110u663350abx76b283d519c5a09d@mail.gmail.com>
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: <gdb-patches.sourceware.org>
List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb-patches/>
List-Post: <mailto:gdb-patches@sourceware.org>
List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-patches-owner@sourceware.org
X-SW-Source: 2008-09/txt/msg00358.txt.bz2

teawater wrote:
> 
> 
> On Tue, Sep 16, 2008 at 02:42, Daniel Jacobowitz <drow@false.org 
> <mailto:drow@false.org>> wrote:
> 
> 
>     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.
> 
> 
> 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.

Aha, let's figure out a test for this question.
It's rather important.   ;-)

> Michael, how do you deal with the breakpoint in gdb-freeplay and vmware 
> record?

Both use simulated hardware breakpoints.  That is, they both
accept the Z0 message and emulate hardware breakpoint semantics
by watching the address of execution (one instruction at a time).