From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18055 invoked by alias); 29 Sep 2014 22:15:43 -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 18045 invoked by uid 89); 29 Sep 2014 22:15:42 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 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; Mon, 29 Sep 2014 22:15:41 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s8TMFTvD022618 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 29 Sep 2014 18:15:29 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s8TMFOXf004116; Mon, 29 Sep 2014 18:15:25 -0400 Message-ID: <5429D9FC.6000509@redhat.com> Date: Mon, 29 Sep 2014 22:15: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: Peter Maydell , Joel Brobecker CC: Marcus Shawcroft , Terry.Guo@arm.com, Marcus Shawcroft , "lgustavo@codesourcery.com" , yao@codesourcery.com, gdb-patches@sourceware.org, Will Deacon , "Gareth, McMullin" Subject: Re: [RFA/commit] arm-tdep.c: Do not single-step after hitting a watchpoint References: In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-09/txt/msg00858.txt.bz2 On 09/29/2014 07:23 PM, 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. > > For *synchronous* watchpoints, the behaviour is that the > CPU stops *before* execution of the instruction which > triggers the fault, and the memory access does not take > place. This is pretty clearly described in the ARM ARM > (see DDI0406C.c section C3.4.4 "Synchronous and asynchronous > Watchpoint debug events" and the referenced "Effects of > data-aborted instructions" section). I only have DDI 0406C.b handy, which says: ARMv7 permits watchpoints to be either synchronous or asynchronous. An implementation can implement synchronous watchpoints, asynchronous watchpoints, or both. It is IMPLEMENTATION DEFINED under what circumstances a watchpoint is synchronous or asynchronous. Ouch. So this IMPLEMENTATION DEFINED note means this isn't really in control of the software/debugger, i.e., nothing a stub/probe could tweak, but instead baked into the specific ARM chip? Or is there some register the probe could tweak to change the this behavior? Now I'm confused on the mention of the Linux kernel subtracting 8 from the PC to help GDB. I can't find that anywhere in the kernel's sources. > For ARMv8 (so including all AArch64 CPUs) watchpoints must > be synchronous. Ah, so this issue will eventually go away on its own. :-) > > QEMU's built in gdbstub was incorrectly not implementing > synchronous watchpoints (ie it was halting after the > execution of the offending insn, not before). This is fixed > by the QEMU patch referenced earlier, and with that patch > QEMU and GDB interoperate correctly (on ARM and also on > other architectures which have the "stop before insn" > watchpoint semantics). "Incorrect" may be too strong then, but understood. > > GDB should continue to set have_nonsteppable_watchpoint > for ARM architectures, indicating: > * watchpoints fire before the insn executes > * you need to disable the watchpoint to successfully > singlestep the insn > as this is correct for synchronous watchpoints. > > If you have h/w with asynchronous watchpoints then there > really isn't much you can do about stopping in the > right place. Ideally I guess gdb would not do a step > in that case, but I don't think it has access to > enough info about the target CPU to know this (the > kernel does get this info in the DBGDSCR.MOE register > field, which is different for synchronous and > asynchronous watchpoint events). Ah. In the kernel I have handy, I see: /* * Called from either the Data Abort Handler [watchpoint] or the * Prefetch Abort Handler [breakpoint] with interrupts disabled. */ static int hw_breakpoint_pending(unsigned long addr, unsigned int fsr, struct pt_regs *regs) { int ret = 0; u32 dscr; preempt_disable(); if (interrupts_enabled(regs)) local_irq_enable(); /* We only handle watchpoints and hardware breakpoints. */ ARM_DBG_READ(c0, c1, 0, dscr); /* Perform perf callbacks. */ switch (ARM_DSCR_MOE(dscr)) { case ARM_ENTRY_BREAKPOINT: breakpoint_handler(addr, regs); break; case ARM_ENTRY_ASYNC_WATCHPOINT: WARN(1, "Asynchronous watchpoint exception taken. Debugging results may be unreliable\n"); case ARM_ENTRY_SYNC_WATCHPOINT: watchpoint_handler(addr, fsr, regs); break; default: ret = 1; /* Unhandled fault. */ } preempt_enable(); return ret; } (note the ARM_ENTRY_ASYNC_WATCHPOINT case falls-through.) So even on Linux, iiuc, it's possible to see a watchpoint trigger after the write has already happened; it'll depend on hardware implementation. I think the most flexible would be if the watchpoint event reported to GDB indicated which type it got, so that'd support the case an arch ever supports mixing both kinds of watchpoints. The next option would be something in the xml target description. It's be a global per-target, so no mixing types of watchpoints. (That is either sent to gdb by the stub, or loaded manually with "set tdesc filename".) Failing all that, we may want a "set arm ..." knob to override the default... Or we just forget all this, assuming that ARM chips that have async watchpoints will disappear into obsolescence forever soon enough. :-) Thanks, Pedro Alves