From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11491 invoked by alias); 30 Sep 2014 09:04:15 -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 11464 invoked by uid 89); 30 Sep 2014 09:04:14 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.2 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: cam-admin0.cambridge.arm.com Received: from cam-admin0.cambridge.arm.com (HELO cam-admin0.cambridge.arm.com) (217.140.96.50) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 30 Sep 2014 09:04:14 +0000 Received: from arm.com (edgewater-inn.cambridge.arm.com [10.1.203.204]) by cam-admin0.cambridge.arm.com (8.12.6/8.12.6) with ESMTP id s8U945wo010741; Tue, 30 Sep 2014 10:04:05 +0100 (BST) Date: Tue, 30 Sep 2014 09:04:00 -0000 From: Will Deacon To: Peter Maydell Cc: Joel Brobecker , Marcus Shawcroft , Terry Guo , Marcus Shawcroft , "lgustavo@codesourcery.com" , "yao@codesourcery.com" , "gdb-patches@sourceware.org" , "gareth@blacksphere.co.nz >> Gareth, McMullin" Subject: Re: [RFA/commit] arm-tdep.c: Do not single-step after hitting a watchpoint Message-ID: <20140930090414.GD8075@arm.com> References: <20140930085746.GC8075@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140930085746.GC8075@arm.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-SW-Source: 2014-09/txt/msg00873.txt.bz2 On Tue, Sep 30, 2014 at 09:57:46AM +0100, Will Deacon wrote: > On Mon, Sep 29, 2014 at 07:23:05PM +0100, Peter Maydell wrote: > > Joel Brobecker wrote: > > > I have been trying to understand the various contributions, and > > > I admit I am still not quite sure... > > > > > > Does it look like the patch I proposed is correct? It seems to be > > > supported by Terry Guo's experiments as well... > > > > Note that the ARMv7 architecture allows watchpoints to > > be implemented as *asynchronous*, in which case what > > you will see is that you take a watchpoint exception > > but it may not fire until after the instruction that > > triggers the watchpoint and possibly several following > > instructions have all finished execution. This may be > > what you are seeing in your hardware tests. > > No you won't; the kernel will swallow the async watchpoint and complain in > dmesg. I'm not aware of any CPU implementations that actually generate > these. D'oh, the lack of morning coffee means I missed the fall-through that Pedro pointed out. I should go find the author of that code... Will