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

[Pedro Alves <palves@redhat.com>]

On 09/30/2014 02:50 PM, Joel Brobecker wrote:
>> 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. 

I assume that WFAR/DSCR are privileged registers though.
On Linux, for example, they're not exported to userspace.

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

I think it'd be better leave those details to the
remote stub / OS though.  E.g., this way, qemu's gdbserver
stub may support watchpoint variants that the hardware
qemu is emulating doesn't support.

For instance, as a natural extension of this, we could
make it possible for qemu to have non-continuable watchpoints
(trap before the instruction that changes memory executes) on all
targets, even x86.  Or have it trap after the instruction
that changes memory, but tell GDB the address of the instruction
that triggered the watchpoint (there's no magic number to subtract
on x86, due to variable-length instructions).

Thanks,
Pedro Alves