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

[Pedro Alves <palves@redhat.com>]

On 09/30/2014 11:34 AM, Pedro Alves wrote:

>> (Similarly,
>> we provide watchpoint support in our stub even if
>> the CPU we're emulating has no watchpoint support
>> of its own at all. Think of us as like a JTAG probe.)
> 
> Well, it seems to me that GDB, on v6-and-lower is
> doing the wrong thing for real halt-mode/jtag probes.
> If we fix that in GDB, then your qemu patch breaks
> things on v6.

BTW, given v7-m behaves like this as well, it sounds
like this may not be the last we hear about asynchronous
watchpoints (thinking bare-metal here).

But, I've given this further thought while cooking lunch.  :-)

Given that with asynchronous watchpoints, any number
of instructions could have been executed, which isn't
exactly the same as always triggering the exception just
after the instruction completes, and, since the instruction
that triggered the watchpoint can be discovered (in WFAR), I
think we should indeed assume synchronous watchpoints by
default, and then handle asynchronous watchpoints by
augmenting the watchpoint event (packet) reported to GDB
by indicating the asyncness and the instruction
that triggered the exception (if known).  On such targets,
GDB could be a bit more helpful and if execution stops far
from where the watchpoint triggered, it could tell that to
the user.  On Linux, if we wanted to expose this to the
ptracer, we'd stuff it somewhere in the SIGTRAP's siginfo.

How does that sound?

In a nutshell, less guesswork for GDB, by making the
target be more precise in its event reporting.

Thanks,
Pedro Alves