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: Will Deacon <will dot deacon at arm dot com>
- To: Pedro Alves <palves at redhat dot com>
- Cc: Peter Maydell <peter dot maydell at linaro dot org>, Joel Brobecker <brobecker at adacore dot com>, Marcus Shawcroft <marcus dot shawcroft at gmail dot com>, Terry Guo <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" <yao at codesourcery dot com>, "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>, "Gareth, McMullin" <gareth at blacksphere dot co dot nz>
- Date: Tue, 30 Sep 2014 10:18:24 +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>
On Tue, Sep 30, 2014 at 10:08:09AM +0100, Pedro Alves wrote:
> The report that confuses me is Gareth's:
>
> https://sourceware.org/ml/gdb/2014-09/msg00013.html
>
> As it sounds like he has v7-m hardware that has asynchronous
> behavior. Gareth, can you confirm this, please?
Running Linux or bare-metal? The hw_breakpoint code in the kernel certainly
wasn't written with v7-m in mind and I'd be surprised if it even probed
successfully at boot.
> Still, in any case, from that LKML post:
>
> "v6 cores are the opposite; they only generate asynchronous
> watchpoint exceptions".
>
> So, eh!? Does your qemu patch take this into account? Seems
> like it should.
Hmm, I didn't realise v6 was on the table here. In that case, you need to
signal an async exception and set the WFAR register to indicate the
watchpointed instruction. Not that Linux uses this...
> In Linux's sources I see this:
>
> /* Determine number of usable WRPs available. */
> static int get_num_wrps(void)
> {
> /*
> * On debug architectures prior to 7.1, when a watchpoint fires, the
> * only way to work out which watchpoint it was is by disassembling
> * the faulting instruction and working out the address of the memory
> * access.
> *
> * Furthermore, we can only do this if the watchpoint was precise
> * since imprecise watchpoints prevent us from calculating register
> * based addresses.
> *
> * Providing we have more than 1 breakpoint register, we only report
> * a single watchpoint register for the time being. This way, we always
> * know which watchpoint fired. In the future we can either add a
> * disassembler and address generation emulator, or we can insert a
> * check to see if the DFAR is set on watchpoint exception entry
> * [the ARM ARM states that the DFAR is UNKNOWN, but experience shows
> * that it is set on some implementations].
> */
> if (get_debug_arch() < ARM_DEBUG_ARCH_V7_1)
> return 1;
>
> So, even on Linux, on v6, etc. (< v7.1), it seems to me that we're
> indeed very likely to get _asynchronous_ watchpoints reported to GDB,
> and so this in GDB:
The comment/code above is about finding the address of the memory access
that triggered the watchpoint, as opposed to the address of the instruction.
(e.g. if I load from address FOO, then I only get told about FOO in v7.1).
Will