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

[Peter Maydell <peter.maydell@linaro.org>]

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

For ARMv8 (so including all AArch64 CPUs) watchpoints must
be synchronous.

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

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

thanks
-- PMM