From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-patches-return-59399-listarch-gdb-patches=sources.redhat.com@sourceware.org>
Received: (qmail 4380 invoked by alias); 21 Oct 2008 18:36:33 -0000
Received: (qmail 4372 invoked by uid 22791); 21 Oct 2008 18:36:33 -0000
X-Spam-Check-By: sourceware.org
Received: from smtp-outbound-1.vmware.com (HELO smtp-outbound-1.vmware.com) (65.115.85.69)     by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 21 Oct 2008 18:35:31 +0000
Received: from mailhost2.vmware.com (mailhost2.vmware.com [10.16.67.167]) 	by smtp-outbound-1.vmware.com (Postfix) with ESMTP id 805D31344E; 	Tue, 21 Oct 2008 11:35:27 -0700 (PDT)
Received: from [10.20.92.59] (promb-2s-dhcp59.eng.vmware.com [10.20.92.59]) 	by mailhost2.vmware.com (Postfix) with ESMTP id 63E748E5F6; 	Tue, 21 Oct 2008 11:35:27 -0700 (PDT)
Message-ID: <48FE1FE0.7040803@vmware.com>
Date: Tue, 21 Oct 2008 18:36: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: Pedro Alves <pedro@codesourcery.com>,   "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Subject: Re: [reverse/record] adjust_pc_after_break in reverse execution mode?
References: <200810180210.16346.pedro@codesourcery.com>	 <48FCC413.3040506@vmware.com>	 <daef60380810201636g3aa0e935r55eedbac1457e9a1@mail.gmail.com>	 <200810210121.07914.pedro@codesourcery.com> <daef60380810210003v3a1b366o8d9b142c46f19c69@mail.gmail.com>
In-Reply-To: <daef60380810210003v3a1b366o8d9b142c46f19c69@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-10/txt/msg00515.txt.bz2

teawater wrote:
> Sorry I send too much Email. I found that:
> 
>       if (singlestep_breakpoints_inserted_p
>           || !ptid_equal (ecs->ptid, inferior_ptid)
>           || !currently_stepping (ecs->event_thread)
>           || ecs->event_thread->prev_pc == breakpoint_pc)
>         regcache_write_pc (regcache, breakpoint_pc);
> 
> Before write_pc, there are a lot of thing to check. Do we  need to
> check it in record_wait?
> If so, it actually useless cause it will be set back in adjust_pc_after_break?
> Maybe we can let adjust_pc_after_break disable in replay mode.
> 
> How do you think?

I think we should leave adjust_pc_after_break alone,
and change record_wait so that it adjusts the pc by
adding decr_pc_after_break(gdbarch) when appropriate.

Whenever possible, gdb should not need to know the difference
between replay and live debugging.  This keeps things simple,
and preserves modularity.

Of course, you don't have access to the "ecs" object, which
is local to infrun.  But you do know whether or not gdb is
stepping.  And (for now) you know that there is only one
thread, so you can (for now) ignore the thread id (ptid).

The value of "step" that was passed to record_resume
came from "currently_stepping", so you should be able
to use that.

Something close to the patch that Pedro posted should work...