From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27578 invoked by alias); 30 Sep 2014 10:07:41 -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 27533 invoked by uid 89); 30 Sep 2014 10:07:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 30 Sep 2014 10:07:39 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s8UA7PiU010010 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 30 Sep 2014 06:07:25 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s8UA7LcP003678; Tue, 30 Sep 2014 06:07:22 -0400 Message-ID: <542A80D9.20104@redhat.com> Date: Tue, 30 Sep 2014 10:07:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Will Deacon CC: Peter Maydell , Joel Brobecker , Marcus Shawcroft , Terry Guo , Marcus Shawcroft , "lgustavo@codesourcery.com" , "yao@codesourcery.com" , "gdb-patches@sourceware.org" , "Gareth, McMullin" Subject: Re: [RFA/commit] arm-tdep.c: Do not single-step after hitting a watchpoint References: <5429D9FC.6000509@redhat.com> <542A72F9.5090203@redhat.com> <20140930091824.GE8075@arm.com> In-Reply-To: <20140930091824.GE8075@arm.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-SW-Source: 2014-09/txt/msg00879.txt.bz2 On 09/30/2014 10:18 AM, Will Deacon wrote: > On Tue, Sep 30, 2014 at 10:08:09AM +0100, Pedro Alves wrote: >> The report that confuses me is Gareth's: >> >> https://sourceware.org/ml/gdb/2014-09/msg00013.html >> >> As it sounds like he has v7-m hardware that has asynchronous >> behavior. Gareth, can you confirm this, please? > > Running Linux or bare-metal? The hw_breakpoint code in the kernel certainly > wasn't written with v7-m in mind and I'd be surprised if it even probed > successfully at boot. Judging from the black magic probes' description at: http://www.blacksphere.co.nz/main/blackmagic, definitely bare-metal. > >> Still, in any case, from that LKML post: >> >> "v6 cores are the opposite; they only generate asynchronous >> watchpoint exceptions". >> >> So, eh!? Does your qemu patch take this into account? Seems >> like it should. > > Hmm, I didn't realise v6 was on the table here. GDB supports that, and older. Doesn't qemu do v6? > In that case, you need to signal an async exception and set the WFAR > register to indicate the watchpointed instruction. Not that Linux uses this... Yeah, even though Linux doesn't use this, this then must be what bare metal probes and other OSs will necessarily be using to support watchpoints on < v7. OK, then on v6 (and earlier), the WFAR will be (as Luis pointed out elsewhere), from: (ARM1156T2F-S, IIUC, that's a v6) http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0290g/Bhcdjdcg.html 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® 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. I may be missing something, but that page leaves me wondering what happens if the instruction after the instruction that caused the watchpoint is a branch. Will the WFAR point still point at "address + 8" ? Or will it point at the branch destination? In any case, it sounds like _nothing_ should be unwinding the PC back -8 nor -4 to help the debugger, as that would make the program re-execute instructions that had already executed. For further confirmation, I looked at the v6-m manual I have handy (DDI 0419C). There, I see: C1.5.2: The following are asynchronous debug events: - Watchpoint debug events, including PC match watchpoints And then on C1.6.4 The DebugReturnAddress value DebugReturnAddress is the address of the first instruction to be executed on exit from Debug state. This address indicates the point in the execution stream where the debug event was invoked. For a hardware or a software breakpoint, this is the address of the breakpointed instruction. For all other debug events, including PC match watchpoints, DebugReturnAddress is the address of the first instruction that both: - in a simple sequential execution of the program, executes after the instruction that caused the debug event - has not been executed. And in C1.7.1 A watchpoint event is asynchronous to the instruction that caused it. The DebugReturnAddress value for a watchpoint event must be that of an instruction to be executed after the instruction responsible for generating the watchpoint. This seems to confirm my current understanding that indeed that +8/+4 offset in WFAR should _never_ be adjusted, as the instructions at +0 and +4/+2 have already been executed. So, my current understanding is that when debugging a < v7 target, GDB should always treat watchpoints as continuable (asynchronous), as that's all the hardware supports/supported. And when debugging a >= v7 target, GDB should treat watchpoints as synchronous as that's all real hardware supports (even though the architecture permits both sync and async, in theory). And if we do this in GDB, then it's be better that qemu likewise treats watchpoints as asynchronous on < v7, so that GDB doesn't need to know whether it's talking to real bare-metal and against qemu. Does that make sense? > The comment/code above is about finding the address of the memory access > that triggered the watchpoint, as opposed to the address of the instruction. > (e.g. if I load from address FOO, then I only get told about FOO in v7.1). Understood. Thanks, Pedro Alves