From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41418) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xatxm-0000SQ-SU for qemu-devel@nongnu.org; Sun, 05 Oct 2014 18:07:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xatxh-0002G2-Jx for qemu-devel@nongnu.org; Sun, 05 Oct 2014 18:07:34 -0400 Received: from ssl.serverraum.org ([88.198.40.39]:35051) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xatxh-0002Fu-Cs for qemu-devel@nongnu.org; Sun, 05 Oct 2014 18:07:29 -0400 From: Michael Walle Date: Mon, 06 Oct 2014 00:07:25 +0200 Message-ID: <2269835.dOncxI2WOO@thanatos> In-Reply-To: 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: Patch Tracking , QEMU Developers , Max Filippov , "Edgar E. Iglesias" , Aurelien Jarno , Richard Henderson Am Sonntag, 5. Oktober 2014, 22:48:05 schrieb Peter Maydell: > On 5 October 2014 22:36, Peter Maydell wrote: > > On 5 October 2014 22:00, Michael Walle wrote: > >> 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?> > > No, gdb wants execution to stop with the PC just after the > > instruction which issued the memory access, with whatever > > effects the instruction had having already taken place. > > So (2) is correct. (I think nicer UI would indeed be to > > stop at (1) but you can't get that effect on CPUs like > > x86 which only stop after the wp insn has executed, and > > they'd rather be consistent.) > > ...and incidentally the way it achieves this for "stop before > wp insn" CPU targets is that it unsets the watchpoint > and automatically steps one instruction before returning > control to the gdb user. (You can see this if you turn > gdb's remote-protocol debug on.) Ah, now it makes sense :) Tested-by: Michael Walle (for lm32) -- -michael