From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hollis Blanchard Date: Wed, 14 May 2008 18:25:32 +0000 Subject: Re: [kvm-ppc-devel] [kvm-devel] [RFC] Reworking KVM_DEBUG_GUEST Message-Id: <200805141325.32231.hollisb@us.ibm.com> List-Id: References: <48282B63.6000204@web.de> <1210777972.6580.15.camel@thinkpadL> <482B0533.2060603@web.de> In-Reply-To: <482B0533.2060603@web.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: kvm-devel@lists.sourceforge.net Cc: kvm-ppc-devel@lists.sourceforge.net, jyoung5@us.ibm.com, Jan Kiszka On Wednesday 14 May 2008 10:28:51 Jan Kiszka wrote: > So gdb on power relies only on those few hw-breakpoints? With x86 you > can perfectly run gdb (with soft BPs) in parallel with the gdbstub > (currently based on hw-BPs, but the same would be true for soft-BPs > inserted by the gdbstub). GDB on Power inserts trap instructions, i.e. standard "soft" breakpoints. It does not rely on the hardware breakpoints. It gets a little more complicated when you involve a GDB stub. IIRC, GDB will ask the stub to set the breakpoint, and if the stub doesn't support it, GDB will fall back to overwriting the instructions in memory. Does the Qemu GDB stub advertise breakpoint support? If not, the only support needed in KVM would be to send all debug interrupts to qemu, and allow qemu to send them back down for in-guest breakpoints. -- Hollis Blanchard IBM Linux Technology Center ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ kvm-ppc-devel mailing list kvm-ppc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-ppc-devel From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hollis Blanchard Subject: Re: [RFC] Reworking KVM_DEBUG_GUEST Date: Wed, 14 May 2008 13:25:32 -0500 Message-ID: <200805141325.32231.hollisb@us.ibm.com> References: <48282B63.6000204@web.de> <1210777972.6580.15.camel@thinkpadL> <482B0533.2060603@web.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-ppc-devel@lists.sourceforge.net, jyoung5@us.ibm.com, Jan Kiszka To: kvm-devel@lists.sourceforge.net Return-path: In-Reply-To: <482B0533.2060603@web.de> Content-Disposition: inline List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces@lists.sourceforge.net Errors-To: kvm-devel-bounces@lists.sourceforge.net List-Id: kvm.vger.kernel.org On Wednesday 14 May 2008 10:28:51 Jan Kiszka wrote: > So gdb on power relies only on those few hw-breakpoints? With x86 you > can perfectly run gdb (with soft BPs) in parallel with the gdbstub > (currently based on hw-BPs, but the same would be true for soft-BPs > inserted by the gdbstub). GDB on Power inserts trap instructions, i.e. standard "soft" breakpoints. It does not rely on the hardware breakpoints. It gets a little more complicated when you involve a GDB stub. IIRC, GDB will ask the stub to set the breakpoint, and if the stub doesn't support it, GDB will fall back to overwriting the instructions in memory. Does the Qemu GDB stub advertise breakpoint support? If not, the only support needed in KVM would be to send all debug interrupts to qemu, and allow qemu to send them back down for in-guest breakpoints. -- Hollis Blanchard IBM Linux Technology Center ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/