Re: [RFA/commit] arm-tdep.c: Do not single-step after hitting a watchpoint

[Will Deacon <will.deacon@arm.com>]

On Tue, Sep 30, 2014 at 10:14:20AM +0100, Pedro Alves wrote:
> On 09/30/2014 09:57 AM, 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. 
> 
> It doesn't seem to swallow it; only warn.  In hw_breakpoint_pending:
> 
> 
> 	/* 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;
> 
> Note the fallthrough.
> 
> In any case, GDB has to care about halt mode, jtag, system, etc.
> debugging, not just Linux.
> 
> > I'm not aware of any CPU implementations that actually generate these.
> 
> Thanks.  Until we hear a clearer report otherwise, that's what I'll
> assume going forward.

Now that I've realised you were also talking about ARMv6, I should clarify
that I was only referring to v7-A (and v8, since that's architected) CPUs.

For v6, all watchpoint exceptions are reported via the asynchronous method.
You can use the WFAR register to determine the instruction responsible for
the fault.

Will