From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12939 invoked by alias); 21 Aug 2006 19:13:36 -0000 Received: (qmail 12929 invoked by uid 22791); 21 Aug 2006 19:13:35 -0000 X-Spam-Check-By: sourceware.org Received: from mx2.palmsource.com (HELO mx2.palmsource.com) (12.7.175.14) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 21 Aug 2006 19:13:29 +0000 Received: from localhost (localhost [127.0.0.1]) by localhost.domain.tld (Postfix) with ESMTP id 9449425F3F; Mon, 21 Aug 2006 12:13:27 -0700 (PDT) Received: from mx2.palmsource.com ([127.0.0.1]) by localhost (mx2.palmsource.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 02379-01-2; Mon, 21 Aug 2006 12:13:24 -0700 (PDT) Received: from ussunex01.palmsource.com (unknown [192.168.101.9]) by mx2.palmsource.com (Postfix) with ESMTP id 588D825EFB; Mon, 21 Aug 2006 12:13:24 -0700 (PDT) Received: from 192.168.92.59 ([192.168.92.59]) by ussunex01.palmsource.com ([192.168.101.9]) via Exchange Front-End Server owa.palmsource.com ([10.0.20.17]) with Microsoft Exchange Server HTTP-DAV ; Mon, 21 Aug 2006 19:13:23 +0000 Received: from svmsnyderlnx by owa.palmsource.com; 21 Aug 2006 12:13:24 -0700 Subject: Re: Virtual Machine and GDB From: Michael Snyder To: Cai Qian Cc: gdb@sourceware.org In-Reply-To: References: <20060821000736.GA2596@nevyn.them.org> <44E9E787.9010202@cse.unl.edu> <1156184892.8438.18.camel@localhost.localdomain> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Mon, 21 Aug 2006 19:13:00 -0000 Message-Id: <1156187604.9010.5.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-08/txt/msg00173.txt.bz2 On Mon, 2006-08-21 at 19:49 +0100, Cai Qian wrote: > Hi, > > On 8/21/06, Michael Snyder wrote: > > On Mon, 2006-08-21 at 18:59 +0100, Cai Qian wrote: > > > Hi, > > > > > > On 8/21/06, Neo wrote: > > > > Cai, > > > > > > > > I am wondering why you need to debug the VM remotely. Maybe you have > > > > your own requirements, such as for embedded systems. But I think you > > > > need to first make sure you can debug any binary running on your target > > > > board remotely. Then, you can treat the VM as the rest ordinary binary. > > > > > > > > > > I don't want to debug VM itself here, but executable running on the > > > VM. As my VM has a new instruction set, and GDB is quite unlikely to > > > run locally. > > > > OK, so you have two issues: > > 1) You need to get gdbserver running in your VM, and provide > > some means for gdbserver to talk to a gdb that is running in the > > outside world. Unles you have access to a serial port, the > > obvious way to do this is to get a IP stack running in the VM, > > assign it an IP address, and let gdbserver open up a socket. > > Then gdb (running somewhere outside of the VM) can attach to > > the socket. > > > > I have implemented a debug server in VM. At the moment, it can read > the RSP messages from remote GDB through socket. So, I think I have > done this part. Great... > > 2) You need to teach gdb to understand the architecture of > > your virtual machine -- the word size, the instruction language, > > the register set, and so forth. That doesn't mean porting gdb > > to RUN on the VM -- it just means teaching gdb how to DEBUG > > the VM (meaning, debug something that is running in the VM). > > > > How can I achieve this part? At the moment, after received a packet > from remote GDB, I am trying to parse the packet first, and then send > the right response to GDB. For example, if VM received a "info > registers" command at the debug socket, it will try to collect > register information, and then generate a right RSP message back. Or, > if it received "next", I can set a flag in VM to indicate to only > execute one instruction. Is that a right way to do? Well, what's the register set of your VM? Is it a virtual pentium? In that case, you have nothing to do except make sure that the gdb was configured and built with --target=i386-xxx. Similarly if the virtual machine is (or pretends to be) any other known architecture. If it's emulating some new, previously unknown architecture with a unique register set and instruction set, then you need to do what we call a target base port of gdb -- that is, teach gdb how to interpret this new machine architecture.