From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3897 invoked by alias); 30 Sep 2014 10:18:07 -0000 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 Received: (qmail 3882 invoked by uid 89); 30 Sep 2014 10:18:06 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-lb0-f176.google.com Received: from mail-lb0-f176.google.com (HELO mail-lb0-f176.google.com) (209.85.217.176) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Tue, 30 Sep 2014 10:18:05 +0000 Received: by mail-lb0-f176.google.com with SMTP id p9so4128179lbv.35 for ; Tue, 30 Sep 2014 03:18:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=1pyPbgsB6VEPsjJL7GcP4KkLW5oz1aOqDB0BuwVuvOU=; b=IioRFndSjldzd7KdQBAvq0Qyvp05fpgA3RNZWCKffNym2ix51FMgtvT0nrheaRlOOR EYIgP8otMHVbdcxvPMtcUBrOMv+K2Kox48Qxp+z+gbFkUcNmd0EUqJOjFXt3+r0xzZZT aJ7MgF1TyLlFHVeA6AgkCt0WuUedoZkqj+avy6SKztoKvyUawKlEpbsfgrv7CSKpNhgZ gfs3jf/Ia86n5S8VPBxzkruk7h57fyV3utnT8SxPMhPg+BhHN8NF1u1fdLE+quiVg179 PJaaLDTCAj3FyCxWAmE6FABG7VeknVtiQKkDeYej7QEaNS62okHIBWl6uitGVhJ3SKM4 H51Q== X-Gm-Message-State: ALoCoQnaWpXM8Ngmy64rCh3BM7HmoJ2ffXXXC7ivJFk2HH16i7TAd2Lyq6Gig8r0Oa/rYtMoIP0I X-Received: by 10.112.72.10 with SMTP id z10mr14914649lbu.87.1412072282140; Tue, 30 Sep 2014 03:18:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.130.161 with HTTP; Tue, 30 Sep 2014 03:17:42 -0700 (PDT) In-Reply-To: <542A80D9.20104@redhat.com> References: <5429D9FC.6000509@redhat.com> <542A72F9.5090203@redhat.com> <20140930091824.GE8075@arm.com> <542A80D9.20104@redhat.com> From: Peter Maydell Date: Tue, 30 Sep 2014 10:18:00 -0000 Message-ID: Subject: Re: [RFA/commit] arm-tdep.c: Do not single-step after hitting a watchpoint To: Pedro Alves Cc: Will Deacon , Joel Brobecker , Marcus Shawcroft , Terry Guo , Marcus Shawcroft , "lgustavo@codesourcery.com" , "yao@codesourcery.com" , "gdb-patches@sourceware.org" , "Gareth, McMullin" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2014-09/txt/msg00880.txt.bz2 On 30 September 2014 11:07, Pedro Alves wrote: > WFAR - Watchpoint Fault Address Register > > The WFAR is updated to indicate the address of the instruction that > accessed the watchpointed address: > > - the address of the instruction + 8 in ARM state > - the address of the instruction + 4 in Thumb=C2=AE state > > What wasn't clear to me was whether this meant that the > instruction at the address of the instruction, and > at the the address of the instruction +4/+2 (ARM/Thumb) had > executed completely or not. It's my understanding now that, > yes, both the instruction that caused the watchpoint and the > instruction after that one have already been executed. No, you are misinterpreting this. The WFAR records the address of the offending instruction + an offset which you have to correct for. The offset does *not* have any relation to how many further instructions the CPU has executed after the offending instruction, which could be none, one, two or ten. Asynchronous watchpoints are *asynchronous*, which means there is no timing guarantee about how soon the CPU will notice that one has fired and stop executing insns. The only guarantee you get in v7 is that you'll get the watchpoint before any exception that might be caused by a following instruction. -- PMM