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: Yao Qi <yao at codesourcery dot com>
- To: Joel Brobecker <brobecker at adacore dot com>
- Cc: <gdb-patches at sourceware dot org>
- Date: Tue, 16 Sep 2014 19:08:27 +0800
- Subject: Re: [RFA/commit] arm-tdep.c: Do not single-step after hitting a watchpoint.
- Authentication-results: sourceware.org; auth=none
- References: <1410786062-19274-1-git-send-email-brobecker at adacore dot com>
Joel Brobecker <brobecker@adacore.com> writes:
> Hello!
>
> Re: question about ARM watchpoints
> https://www.sourceware.org/ml/gdb/2014-09/msg00000.html
>
> This patch fixes an issue with watchpoints on ARM targets, where
> the debugger stops 2 instructions after the instruction causing
> the watchpoint. GDB is expected to stop at the next instruction.
>
> The problem is caused by the fact that GDB does an extra single-step
> after receiving the watchpoint notification, because the
> have_nonsteppable_watchpoint gdbarch attribute is set for ARM
> targets. Our experiments indicate that this is incorrect, at
> least for the versions of ARM that we tested on (ARMv7). We tried
Joel,
Can you elaborate your experiments? Do you do experiments on qemu, arm
bare metal targets or arm linux targets?
I find Peter tries to fix the same problem we encounter in qemu side,
[Qemu-devel] [PATCH] gdbstub: Allow target CPUs to specify watchpoint STOP_BEFORE_ACCESS flag
http://lists.nongnu.org/archive/html/qemu-devel/2014-09/msg02665.html
and this patch isn't accepted yet.
Without this patch, program stops two instructions after the variable is
updated on qemu trunk,
0x000001ae <+10>: str r3, [r7, #12]
0x000001b0 <+12>: ldr r3, [r7, #4]
=> 0x000001b2 <+14>: cmp r3, #1
0x000001b4 <+16>: bne.n 0x1ba <recurse+22>
however, with Peter's patch applied, program stops one instruction after
the variable is updated,
(gdb) watch b
Hardware watchpoint 3: b
(gdb) c
Continuing.
Hardware watchpoint 3: b
Old value = 1283
New value = 0
recurse (a=10) at ../../../../git/gdb/testsuite/gdb.base/recurse.c:15
15 if (a == 1)
(gdb) disassemble recurse
Dump of assembler code for function recurse:
0x000001a4 <+0>: push {r7, lr}
0x000001a6 <+2>: sub sp, #16
0x000001a8 <+4>: add r7, sp, #0
0x000001aa <+6>: str r0, [r7, #4]
0x000001ac <+8>: movs r3, #0
0x000001ae <+10>: str r3, [r7, #12]
=> 0x000001b0 <+12>: ldr r3, [r7, #4]
0x000001b2 <+14>: cmp r3, #1
Note that with patched qemu, two fails in gdb.base/recurse.exp are
fixed. At least, gdb and qemu should be in sync on this.
--
Yao (éå)