From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10089 invoked by alias); 18 Oct 2008 03:26:39 -0000 Received: (qmail 10080 invoked by uid 22791); 18 Oct 2008 03:26:39 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 18 Oct 2008 03:26:04 +0000 Received: (qmail 27003 invoked from network); 18 Oct 2008 03:26:02 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 18 Oct 2008 03:26:02 -0000 From: Pedro Alves To: teawater Subject: Re: [reverse/record] adjust_pc_after_break in reverse execution mode? Date: Sat, 18 Oct 2008 03:26:00 -0000 User-Agent: KMail/1.9.9 Cc: gdb-patches@sourceware.org, "Michael Snyder" References: <200810180210.16346.pedro@codesourcery.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_KdV+I8l5/1cSx6X" Message-Id: <200810180426.02411.pedro@codesourcery.com> 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-10/txt/msg00461.txt.bz2 --Boundary-00=_KdV+I8l5/1cSx6X Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-length: 163 On Saturday 18 October 2008 04:06:29, teawater wrote: > Great! Please check it in maintree. Done. I've revised the text a tiny bit, like below. -- Pedro Alves --Boundary-00=_KdV+I8l5/1cSx6X Content-Type: text/x-diff; charset="iso-8859-1"; name="adjust_pc_reverse.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="adjust_pc_reverse.diff" Content-length: 1885 2008-10-18 Pedro Alves * infrun.c (adjust_pc_after_break): Do nothing if executing in reverse. --- gdb/infrun.c | 29 +++++++++++++++++++++++++++++ 1 file changed, 29 insertions(+) Index: src/gdb/infrun.c =================================================================== --- src.orig/gdb/infrun.c 2008-10-18 00:43:46.000000000 +0100 +++ src/gdb/infrun.c 2008-10-18 04:18:55.000000000 +0100 @@ -1826,6 +1826,35 @@ adjust_pc_after_break (struct execution_ if (ecs->ws.value.sig != TARGET_SIGNAL_TRAP) return; + /* In reverse execution, when a breakpoint is hit, the instruction + under it has already been de-executed. The reported PC always + points at the breakpoint address, so adjusting it further would + be wrong. E.g., consider this case on a decr_pc_after_break == 1 + architecture: + + B1 0x08000000 : INSN1 + B2 0x08000001 : INSN2 + 0x08000002 : INSN3 + PC -> 0x08000003 : INSN4 + + Say you're stopped at 0x08000003 as above. Reverse continuing + from that point should hit B2 as below. Reading the PC when the + SIGTRAP is reported should read 0x08000001 and INSN2 should have + been de-executed already. + + B1 0x08000000 : INSN1 + B2 PC -> 0x08000001 : INSN2 + 0x08000002 : INSN3 + 0x08000003 : INSN4 + + We can't apply the same logic as for forward execution, because + we would wrongly adjust the PC to 0x08000000, since there's a + breakpoint at PC - 1. We'd then report a hit on B1, although + INSN1 hadn't been de-executed yet. Doing nothing is the correct + behaviour. */ + if (execution_direction == EXEC_REVERSE) + return; + /* If this target does not decrement the PC after breakpoints, then we have nothing to do. */ regcache = get_thread_regcache (ecs->ptid); --Boundary-00=_KdV+I8l5/1cSx6X--