This is the mail archive of the
mailing list for the GDB project.
Re: [RFA/commit] arm-tdep.c: Do not single-step after hitting a watchpoint
- From: Pedro Alves <palves at redhat dot com>
- To: Peter Maydell <peter dot maydell at linaro dot org>
- 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: Tue, 30 Sep 2014 13:54:30 +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> <CAFEAcA9Dx5GE6QCktvbQF8sL1MsRxE5BmPNruSw4FsW9VyD_2w at mail dot gmail dot com> <542A72F9 dot 5090203 at redhat dot com> <CAFEAcA9CFb+NbpMc_O1e2VQHngG0t481STay7c9-p1DQFR8jTA at mail dot gmail dot com> <542A872B dot 9050203 at redhat dot com>
On 09/30/2014 11:34 AM, Pedro Alves wrote:
>> 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.