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: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.

> 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. 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...

> In Linux's sources I see this:
> 
> /* Determine number of usable WRPs available. */
> static int get_num_wrps(void)
> {
> 	/*
> 	 * On debug architectures prior to 7.1, when a watchpoint fires, the
> 	 * only way to work out which watchpoint it was is by disassembling
> 	 * the faulting instruction and working out the address of the memory
> 	 * access.
> 	 *
> 	 * Furthermore, we can only do this if the watchpoint was precise
> 	 * since imprecise watchpoints prevent us from calculating register
> 	 * based addresses.
> 	 *
> 	 * Providing we have more than 1 breakpoint register, we only report
> 	 * a single watchpoint register for the time being. This way, we always
> 	 * know which watchpoint fired. In the future we can either add a
> 	 * disassembler and address generation emulator, or we can insert a
> 	 * check to see if the DFAR is set on watchpoint exception entry
> 	 * [the ARM ARM states that the DFAR is UNKNOWN, but experience shows
> 	 * that it is set on some implementations].
> 	 */
> 	if (get_debug_arch() < ARM_DEBUG_ARCH_V7_1)
> 		return 1;
> 
> So, even on Linux, on v6, etc. (< v7.1), it seems to me that we're
> indeed very likely to get _asynchronous_ watchpoints reported to GDB,
> and so this in GDB:

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).

Will