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

[Joel Brobecker <brobecker@adacore.com>]

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

I was thinking about something along the same lines; a little
less sophisticated perhaps: check WFAR, and if far enough,
then cancel the single-step. Informing the user about how
far would certainly be a useful info for the user. The only
part I'm unclear about is whether it's OK to check WFAR when
in synchronous mode, and whether it'll have a WFAR=0 in case
of a synchronous breakpoint...

-- 
Joel