From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 353 invoked by alias); 16 Sep 2014 11:12:47 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 340 invoked by uid 89); 16 Sep 2014 11:12:45 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 16 Sep 2014 11:12:43 +0000 Received: from svr-orw-fem-04.mgc.mentorg.com ([147.34.97.41]) by relay1.mentorg.com with esmtp id 1XTqga-0007UV-5J from Yao_Qi@mentor.com ; Tue, 16 Sep 2014 04:12:40 -0700 Received: from GreenOnly (147.34.91.1) by svr-orw-fem-04.mgc.mentorg.com (147.34.97.41) with Microsoft SMTP Server id 14.3.181.6; Tue, 16 Sep 2014 04:12:39 -0700 From: Yao Qi To: Joel Brobecker CC: Subject: Re: [RFA/commit] arm-tdep.c: Do not single-step after hitting a watchpoint. References: <1410786062-19274-1-git-send-email-brobecker@adacore.com> Date: Tue, 16 Sep 2014 11:12:00 -0000 In-Reply-To: <1410786062-19274-1-git-send-email-brobecker@adacore.com> (Joel Brobecker's message of "Mon, 15 Sep 2014 06:01:02 -0700") Message-ID: <87bnqf2578.fsf@codesourcery.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2014-09/txt/msg00523.txt.bz2 Joel Brobecker 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 STO= P_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] =3D> 0x000001b2 <+14>: cmp r3, #1 0x000001b4 <+16>: bne.n 0x1ba 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 =3D 1283 New value =3D 0 recurse (a=3D10) at ../../../../git/gdb/testsuite/gdb.base/recurse.c:15 15 if (a =3D=3D 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] =3D> 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. --=20 Yao (=E9=BD=90=E5=B0=A7)