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: Joel Brobecker <brobecker at adacore dot com>
- To: Pedro Alves <palves at redhat dot com>
- Cc: Peter Maydell <peter dot maydell at linaro dot org>, 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 06:50:31 -0700
- 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> <542AA806 dot 10804 at redhat dot 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