From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4003 invoked by alias); 30 Sep 2014 08:54:10 -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 3992 invoked by uid 89); 30 Sep 2014 08:54:09 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.3 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 08:54:08 +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 s8U8rnwo009195; Tue, 30 Sep 2014 09:53:50 +0100 (BST) Date: Tue, 30 Sep 2014 08:54:00 -0000 From: Will Deacon To: Pedro Alves Cc: Joel Brobecker , Marcus Shawcroft , Terry Guo , Marcus Shawcroft , "lgustavo@codesourcery.com" , Yao Qi , "gdb-patches@sourceware.org" , Peter Maydell , "gareth@blacksphere.co.nz >> Gareth McMullin" Subject: Re: [RFA/commit] arm-tdep.c: Do not single-step after hitting a watchpoint. Message-ID: <20140930085359.GB8075@arm.com> References: <87bnqf2578.fsf@codesourcery.com> <20140916115936.GM4871@adacore.com> <5418279A.1040604@codesourcery.com> <20140916124814.GO4871@adacore.com> <54183681.3010504@codesourcery.com> <5418556E.7010502@redhat.com> <541C6860.9070907@redhat.com> <20140929175151.GC6927@adacore.com> <5429C94B.20209@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5429C94B.20209@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-SW-Source: 2014-09/txt/msg00871.txt.bz2 On Mon, Sep 29, 2014 at 10:04:11PM +0100, Pedro Alves wrote: > On 09/29/2014 06:51 PM, Joel Brobecker wrote: > > Hello all, > > > >> Hmm. So when the data abort triggers at fault+8, the instruction > >> that triggered the abort hasn't actually completed, right? No memory > >> has changed yet. > >> > >> So if nothing does the adjustment, like Gareth found out happens with > >> the Black Magic Probe, then we'll resume execution from the > >> wrong address/instruction (with the effects of the skipped instructions > >> missing, including the memory write...). Did I understand that > >> right? (Gareth, is that what you see?) > > > > 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... > > Nope, Terry's experiments supported the current code. > > The experiments (which were on Linux) showed that the watchpoint was > reported to GDB first with the PC pointing at the instruction that > accessed memory, and then GDB single-stepped once, and the PC ends up > pointing at one instruction after the instruction that changed memory. FWIW, that also matches the intention of the kernel-side code. The same logic applies to arm64, despite the availability of hardware single-step there (the PTRACE_SINGLESTEP request can be used to access that feature). Furthermore, this also matches the ARMv7/8 debug architectures; a watchpoint data abort will be taken before the faulting instruction has executed. Will