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 07:26:12 -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> <20140930135031 dot GD6927 at adacore dot com> <542AB9E3 dot 5090100 at redhat dot com>
> I assume that WFAR/DSCR are privileged registers though.
> On Linux, for example, they're not exported to userspace.
Indeed, I was expecting as much...
> > 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.
Sure! That's what I meant, and was thinking of our gdbserver
implementation. But now that I think this through, of course
GDBserver is mostly implemented... on top of an OS! Duh...
> 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).
That's very interesting. When I talked to one of our QEMU developers
in house about this, he wasn't even sure if it was possible for
QEMU to stop at the instruction triggering the watchpoint. Now,
we know it is, but it could be simpler for QEMU to implement the
same policy on all targets.
--
Joel