This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA/commit] arm-tdep.c: Do not single-step after hitting a watchpoint
- From: Peter Maydell <peter dot maydell at linaro dot org>
- To: Pedro Alves <palves at redhat dot com>
- Cc: Joel Brobecker <brobecker at adacore dot com>, Marcus Shawcroft <marcus dot shawcroft at gmail dot com>, Terry dot Guo at arm dot com, Marcus Shawcroft <Marcus dot Shawcroft at arm dot com>, "lgustavo at codesourcery dot com" <lgustavo at codesourcery dot com>, yao at codesourcery dot com, gdb-patches at sourceware dot org, Will Deacon <Will dot Deacon at arm dot com>, "Gareth, McMullin" <gareth at blacksphere dot co dot nz>
- Date: Mon, 29 Sep 2014 23:53:51 +0100
- Subject: Re: [RFA/commit] arm-tdep.c: Do not single-step after hitting a watchpoint
- Authentication-results: sourceware.org; auth=none
- References: <CAFEAcA_0C+UqGwM39A4EQCQLg59fNbJ2du8rhrt++Q-pdE9rgQ at mail dot gmail dot com> <5429D9FC dot 6000509 at redhat dot com>
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