From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58807) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XasvG-0006Vn-L6 for qemu-devel@nongnu.org; Sun, 05 Oct 2014 17:01:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XasvA-0003sl-ON for qemu-devel@nongnu.org; Sun, 05 Oct 2014 17:00:54 -0400 Received: from ssl.serverraum.org ([88.198.40.39]:34358) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XasvA-0003rV-Hy for qemu-devel@nongnu.org; Sun, 05 Oct 2014 17:00:48 -0400 From: Michael Walle Date: Sun, 05 Oct 2014 23:00:43 +0200 Message-ID: <5047300.VcNyaJIrmA@thanatos> In-Reply-To: <1410545057-14014-1-git-send-email-peter.maydell@linaro.org> References: <1410545057-14014-1-git-send-email-peter.maydell@linaro.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [Qemu-devel] [PATCH] gdbstub: Allow target CPUs to specify watchpoint STOP_BEFORE_ACCESS flag List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: patches@linaro.org, qemu-devel@nongnu.org, Max Filippov , "Edgar E. Iglesias" , Aurelien Jarno , Richard Henderson Am Freitag, 12. September 2014, 19:04:17 schrieb Peter Maydell: > GDB assumes that watchpoint set via the gdbstub remote protocol will > behave in the same way as hardware watchpoints for the target. In > particular, whether the CPU stops with the PC before or after the insn > which triggers the watchpoint is target dependent. Allow guest CPU > code to specify which behaviour to use. This fixes a bug where with > guest CPUs which stop before the accessing insn GDB would manually > step forward over what it thought was the insn and end up one insn > further forward than it should be. > > We set this flag for the CPU architectures which set > gdbarch_have_nonsteppable_watchpoint in gdb 7.7: > ARM, CRIS, LM32, MIPS and Xtensa. > > Signed-off-by: Peter Maydell Hi Peter, i've tested your patch on the lm32 target. My test program was like the following: mvhi r1, hi(0x10000000) ori r1, r1, lo(0x10000000) nop nop nop nop sw (r1+0), r0 ; (1) store some value to 0x10000000 nop ; (2) nop ; (3) nop nop 1: bi 1b ; loop forever I can confirm that your patch makes qemu stop one instruction earlier. Without your patch the program is stopped at (3). With your patch applied the program is stopped at (2). But I guess the correct point to stop is (1), right? I think there is still some mistake in the lm32 target code in qemu. I'll look into it soon. -- -michael