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

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

On 29 September 2014 23:15, Pedro Alves <palves@redhat.com> wrote:
> On 09/29/2014 07:23 PM, Peter Maydell wrote:
>> Note that the ARMv7 architecture allows watchpoints to
>> be implemented as *asynchronous*

> I only have DDI 0406C.b handy, which says:
>
>  ARMv7 permits watchpoints to be either synchronous or asynchronous. An implementation can implement
>  synchronous watchpoints, asynchronous watchpoints, or both. It is IMPLEMENTATION DEFINED under what
>  circumstances a watchpoint is synchronous or asynchronous.
>
> Ouch.  So this IMPLEMENTATION DEFINED note means this isn't really
> in control of the software/debugger, i.e., nothing a stub/probe
> could tweak, but instead baked into the specific ARM chip?

Correct. IMPDEF means that it is the choice of the
CPU implementation which behaviour to take.

>> 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).
>
> "Incorrect" may be too strong then, but understood.

I wrote the QEMU patch; I'm happy to call our old
behaviour incorrect :-)

> So even on Linux, iiuc, it's possible to see a watchpoint
> trigger after the write has already happened; it'll depend on
> hardware implementation.

Yes.

> I think the most flexible would be if the watchpoint
> event reported to GDB indicated which type it got, so
> that'd support the case an arch ever supports mixing both
> kinds of watchpoints.

Ha, I hadn't noticed that the architecture permits an
implementation to provide both kinds (or indeed to
have one watchpoint that might fire in either way), but
you're right that it's theoretically allowed.

> The next option would be something in the xml target description.
> It's be a global per-target, so no mixing types of watchpoints.
> (That is either sent to gdb by the stub, or loaded manually
> with "set tdesc filename".)
>
> Failing all that, we may want a "set arm ..." knob to
> override the default...
>
> Or we just forget all this, assuming that ARM chips that
> have async watchpoints will disappear into obsolescence
> forever soon enough.  :-)

There's an assertion in this LKML post from 2010:
https://lkml.org/lkml/2010/4/14/127
that v7 cores do actually all generate synchronous
watchpoint exceptions (even though architecturally
they're permitted not to). Was your test h/w a v6?

If this is a v6-and-earlier thing I'd certainly be tempted
to sweep the issue under the carpet...

thanks
-- PMM