From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MUctZ-00029L-9v for qemu-devel@nongnu.org; Sat, 25 Jul 2009 04:46:21 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MUctT-00023A-Ed for qemu-devel@nongnu.org; Sat, 25 Jul 2009 04:46:19 -0400 Received: from [199.232.76.173] (port=56363 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MUctS-00022m-Sd for qemu-devel@nongnu.org; Sat, 25 Jul 2009 04:46:14 -0400 Received: from az33egw02.freescale.net ([192.88.158.103]:45219) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MUctR-0007tk-Rm for qemu-devel@nongnu.org; Sat, 25 Jul 2009 04:46:14 -0400 Received: from az33smr02.freescale.net (az33smr02.freescale.net [10.64.34.200]) by az33egw02.freescale.net (8.14.3/az33egw02) with ESMTP id n6P8iLPr013545 for ; Sat, 25 Jul 2009 01:44:34 -0700 (MST) Received: from zch01exm26.fsl.freescale.net (zch01exm26.ap.freescale.net [10.192.129.221]) by az33smr02.freescale.net (8.13.1/8.13.0) with ESMTP id n6P8iJ31024487 for ; Sat, 25 Jul 2009 03:44:20 -0500 (CDT) From: Liu Yu Date: Sat, 25 Jul 2009 16:40:12 +0800 Message-Id: <1248511217-22681-1-git-send-email-yu.liu@freescale.com> Subject: [Qemu-devel] [PATCH 0/5] List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: jan.kiszka@siemens.com, froydnj@codesourcery.com, kvm-ppc@vger.kernel.org, hollisb@us.ibm.com The whole patchset includes: patch 1: fix kvmppc build error patch 2: fix kvmppc init error patch 3~5: add kvmppc guest debug support The guest debug still have some problems I haven't solved. 1. gdb 'next' command uses software breakpoint software breakpoint is implemented via modify guest's code. In most case it works well, but when used by 'next' it's easy to make trouble on powerpc booke. For example booke has a code template for jumping to and returning from interrupt handlers: bl transfer .long handler_addr .long ret_addr when call transfer, it never return but in transfer assembly code it will read the handler_addr and ultimately call the handler. Gdb doesn't know that and treat it as a normal function call. so gdb put a software breakpoint instruction at handler_addr, in order to get trap there when return from transfer. Then guest will read software breakpoint as handler_addr and jump to there.. I'm not sure if x86 suffer this kind of issue. Is there any way to avoid this? 2. gdb 'watch' command Jan told me gdb>6.8 can issue hardware watchpoint request via command 'watch', my gdb is 6.8.50.20080821-cvs and our toolchain provider confirm that it supports hardware watch However when I use 'watch', I can only see single step from gdbstub side. Did I miss anything?