From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31428 invoked by alias); 22 Aug 2006 01:21:03 -0000 Received: (qmail 31414 invoked by uid 22791); 22 Aug 2006 01:21:02 -0000 X-Spam-Check-By: sourceware.org Received: from ug-out-1314.google.com (HELO ug-out-1314.google.com) (66.249.92.173) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 22 Aug 2006 01:20:59 +0000 Received: by ug-out-1314.google.com with SMTP id u2so1952270uge for ; Mon, 21 Aug 2006 18:20:56 -0700 (PDT) Received: by 10.67.24.13 with SMTP id b13mr4047551ugj; Mon, 21 Aug 2006 18:20:56 -0700 (PDT) Received: by 10.66.238.1 with HTTP; Mon, 21 Aug 2006 18:20:56 -0700 (PDT) Message-ID: Date: Tue, 22 Aug 2006 01:21:00 -0000 From: teawater To: "Cai Qian" Subject: Re: Virtual Machine and GDB Cc: gdb@sourceware.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <44E9E787.9010202@cse.unl.edu> <44E9FBC3.4000201@cse.unl.edu> 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/msg00177.txt.bz2 On 8/22/06, Cai Qian wrote: > Hi, > > On 8/21/06, Neo wrote: > > Cai, > > > > Please see my comments following. > > > > Neo > > > > 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. > > > > > I think the gdb will not help for this case. What you need is a debugger > > provided by the VM. For JVM, you need to use the jdb to debug your > > "executable" code on the top of VM. And what do > > you mean "new instruction set"? Are they new instructions for the VM or > > the target arch? > > OK. The VM does not have a debugger at the moment. That is why I try > to debug remotely. "New instruction set" means it is not i386, SPARC, > SuperH etc, and GDB does not support the arch yet. > So I think you need to make GDB support your ARCH first. I did something that is same with you are doing in before. I made GDB support my ARCH first.After that, Add GDBRSP server function to my VM. Then I can debug the program that running on my VM. > > >> For JVM 1.4.2 and 1.5, I have successfully debugged it with the latest > > >> gdb locally. > > >> > > > > > > Sounds interesting. Any information about how you achieve that? > > > > > I think this would be quite straight forward just like debugging other > > binaries running on Linux host, since the latest gdb includes the > > patches to handle execve. > > >> Thanks, > > >> Neo > > >> > > >> Cai Qian wrote: > > >> > Hi, > > >> > > > >> > On 8/21/06, teawater wrote: > > >> >> Does GDB support the ARCH of you VM? > > >> >> > > >> > > > >> > Sorry, what do you mean by GDB support the ARCH of VM? Do you mean > > >> > port GDB? Does it really necessary to port GDB to the VM? At the > > >> > moment, GDB can't run natively on my VM, nor gdbserver. I am wondering > > >> > if I can still do remote debugging. According to the document [1], it > > >> > seems I can create a remote stub for the target, and then link it to > > >> > the program I am going to run on the target, ie, to implement at least > > >> > the following functions, > > >> > > > >> > getDebugChar, putDebugChar, flush_i_cache, memset, exceptionHandler > > >> > > > >> > Although there are lots of things unclear, > > >> > > > >> > 1) The doc said "int getDebugChar() > > >> > Write this subroutine to read a single character from the serial > > >> > port. It may be identical to getchar for your target system; a > > >> > different name is used to allow you to distinguish the two if you > > >> > wish". However, the serial port is not possible for me, so I assume > > >> > here it should be "read a single character from the socket", and I > > >> > also work for stub. At the moment, I am not sure how to write this > > >> > function, because there is no read syscall in VM. Not sure if it will > > >> > be better to port Glibc or newlib first. > > >> > > > >> > 2) Can't find information on what kind of debug features I can have > > >> > when after implementing the remote stub. Breakpoint, watchpoint, > > >> > single step? > > >> > > > >> > 3) Not sure how to write a download program to download executable > > >> > from target to host in a debug session. > > >> > > > >> > [1] > > >> http://sources.redhat.com/gdb/current/onlinedocs/gdb_18.html#SEC160 > > >> > > > >> > Qian > > >> > > > >> >> On 8/21/06, Cai Qian wrote: > > >> >> > Hi, > > >> >> > > > >> >> > On 8/21/06, teawater wrote: > > >> >> > > I think you need add a GDBRSP server function to your VM. GDBRSP > > >> >> > > support TCP/IP. Read > > >> >> > > http://sources.redhat.com/gdb/onlinedocs/gdb_33.html. > > >> >> > > But I think you need make GDB support your ARCH first. Maybe > > >> my doc > > >> >> > > "Porting GDB(1)" (http://teawater.googlepages.com/epgdb1.pdf) is > > >> >> > > helpful. > > >> >> > > > > >> >> > > > >> >> > There probably no need to port the whole GDB to my VM (which it is > > >> >> > quite difficult at the moment). I just want to have an ability > > >> to do > > >> >> > remote debugging. If GDB RSP can support TCP/IP, a remote stub and > > >> >> > server functionality seem enough? > > >> >> > > > >> >> > Qian > > >> >> > > > >> >> > > On 8/21/06, Cai Qian wrote: > > >> >> > > > Hi, > > >> >> > > > > > >> >> > > > On 8/21/06, Daniel Jacobowitz wrote: > > >> >> > > > > On Sun, Aug 20, 2006 at 10:10:45PM +0100, Cai Qian wrote: > > >> >> > > > > > Hi, > > >> >> > > > > > > > >> >> > > > > > How can I communicate a virtual machine (like Java virtual > > >> >> machine) > > >> >> > > > > > with the host, If I want to use GDB serial protocol? The > > >> >> target > > >> >> > > > > > backend has been developed for the virtual machine, so > > >> >> simple C code > > >> >> > > > > > can be complied and run. In addition, I have written a > > >> >> remote stub for > > >> >> > > > > > the target. > > >> >> > > > > > > >> >> > > > > I'm sorry, I don't understand the question. What are you > > >> >> trying to do > > >> >> > > > > that you don't know how to? Normally the stub and debugger > > >> >> would use > > >> >> > > > > TCP to communicate, or a pipe. > > >> >> > > > > > > >> >> > > > > > >> >> > > > I tried to use GDB to remote debug code run on virtual machine, > > >> >> but I > > >> >> > > > don't know how to commnunicate target and host. Does it mean I > > >> >> need to > > >> >> > > > insert some code to virtual machine, so it will wait a socket > > >> >> Then, > > >> >> > > > GDB is going to connect this port? > > >> >> > > > > > >> >> > > > Qian > > >> >> > > > > > >> >> > > > > -- > > >> >> > > > > Daniel Jacobowitz > > >> >> > > > > CodeSourcery > > >> >> > > > > > > >> >> > > > > > >> >> > > > > >> >> > > > >> >> > > >> > > > >> > > >> -- > > >> I would remember that if researchers were not ambitious > > >> probably today we haven't the technology we are using! > > >> > > >> > > > > > > > -- > > I would remember that if researchers were not ambitious > > probably today we haven't the technology we are using! > > > > >