From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58684) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZtFJp-00008T-HQ for qemu-devel@nongnu.org; Mon, 02 Nov 2015 08:38:42 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZtFJh-0006Gr-Km for qemu-devel@nongnu.org; Mon, 02 Nov 2015 08:38:41 -0500 Received: from mail-lf0-x22c.google.com ([2a00:1450:4010:c07::22c]:35680) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZtFJh-0006GW-DG for qemu-devel@nongnu.org; Mon, 02 Nov 2015 08:38:33 -0500 Received: by lfbn126 with SMTP id n126so61475193lfb.2 for ; Mon, 02 Nov 2015 05:38:32 -0800 (PST) References: <1445003887-14475-1-git-send-email-peter.maydell@linaro.org> <1445003887-14475-14-git-send-email-peter.maydell@linaro.org> <5627D63E.5080404@gmail.com> From: Sergey Fedorov Message-ID: <56376755.1070702@gmail.com> Date: Mon, 2 Nov 2015 16:38:29 +0300 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PULL 13/13] target-arm: Fix CPU breakpoint handling List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: QEMU Developers On 02.11.2015 14:09, Peter Maydell wrote: > On 21 October 2015 at 19:15, Sergey Fedorov wrote: >> On 16.10.2015 16:58, Peter Maydell wrote: >>> From: Sergey Fedorov >>> >>> A QEMU breakpoint match is not definitely an architectural breakpoint >>> match. If an exception is generated unconditionally during translation, >>> it is hardly possible to ignore it in the debug exception handler. >>> >>> Generate a call to a helper to check CPU breakpoints and raise an >>> exception only if any breakpoint matches architecturally. >>> >>> Signed-off-by: Sergey Fedorov >>> Reviewed-by: Peter Maydell >>> Signed-off-by: Peter Maydell >>> --- >> It turns out that this change introduced an issue which can be >> illustrated by the following test: >> I think we could fix this problem by cleaning up DISAS_UPDATE usage in >> target-arm/translate.c and implementing PC update as in >> target-arm/translate-a64.c. I could prepare a patch for that. >> >> Another problem, I think, is that we should somehow restore the CPU >> state before raising an exception from check_breakpoints() helper. But >> so far I have no idea how to fix this... > Hi, Sergey -- how are you doing with the fix for this? It would > be good to get it in and tested soon, because hardfreeze is next > week. > > I've also had a report that this patch broke gdbstub single-stepping, > which might be the same underlying cause. Hi Peter, The patch for DISAS_UPDATE is almost ready. Basically, all I need is to prepare a commit message. But I'm not sure how to deal with CPU state restoring issue. Also it's a strange thing about gdbstub single-stepping I'm going to look at it. Best, Sergey