From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-patches-return-59379-listarch-gdb-patches=sources.redhat.com@sourceware.org>
Received: (qmail 16105 invoked by alias); 20 Oct 2008 17:51:56 -0000
Received: (qmail 16096 invoked by uid 22791); 20 Oct 2008 17:51:55 -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, 20 Oct 2008 17:51:20 +0000
Received: from mailhost3.vmware.com (mailhost3.vmware.com [10.16.27.45]) 	by smtp-outbound-2.vmware.com (Postfix) with ESMTP id 2DE8C3D005; 	Mon, 20 Oct 2008 10:51:19 -0700 (PDT)
Received: from [10.20.92.59] (promb-2s-dhcp59.eng.vmware.com [10.20.92.59]) 	by mailhost3.vmware.com (Postfix) with ESMTP id 1B602C9A29; 	Mon, 20 Oct 2008 10:51:19 -0700 (PDT)
Message-ID: <48FCC413.3040506@vmware.com>
Date: Mon, 20 Oct 2008 17:51:00 -0000
From: Michael Snyder <msnyder@vmware.com>
User-Agent: Thunderbird 1.5.0.12 (X11/20080411)
MIME-Version: 1.0
To: Pedro Alves <pedro@codesourcery.com>
CC: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>,   teawater <teawater@gmail.com>
Subject: Re: [reverse/record] adjust_pc_after_break in reverse execution mode?
References: <200810180210.16346.pedro@codesourcery.com> <200810200109.55661.pedro@codesourcery.com> <48FBD342.5070905@vmware.com> <200810201844.30954.pedro@codesourcery.com>
In-Reply-To: <200810201844.30954.pedro@codesourcery.com>
Content-Type: text/plain; charset=UTF-8; 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-10/txt/msg00495.txt.bz2

Pedro Alves wrote:

> I believe the correct thing for the target to do is to
> report `PC + decr_pc_after_breakpoint' on forward (replay or normal forward)
> breakpoint hits, if it is telling GDB that it succesfully
> inserted a software breakpoint.

Yeah, you and Daniel have both said essentially the same.
And I think you're right.

Hui, can you do this?

Unfortunately, right now I think you are handling the
breakpoints in record.c (which is architecture-agnostic).
Maybe you'll have to check the decr_pc_after_break value.