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: Pedro Alves <palves at redhat dot com>
- To: Joel Brobecker <brobecker at adacore 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 15:10:43 +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> <542AA806 dot 10804 at redhat dot com> <20140930135031 dot GD6927 at adacore dot com>
On 09/30/2014 02:50 PM, Joel Brobecker wrote:
>> 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.
I assume that WFAR/DSCR are privileged registers though.
On Linux, for example, they're not exported to userspace.
> 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.
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).
Thanks,
Pedro Alves