Virtual Machine and GDB

[teawater]

On 8/22/06, Cai Qian <caiqian@gmail.com> wrote:
> Hi,
>
> On 8/21/06, Neo <cjia@cse.unl.edu> wrote:
> > Cai,
> >
> > Please see my comments following.
> >
> > Neo
> >
> > Cai Qian wrote:
> > > Hi,
> > >
> > > On 8/21/06, Neo <cjia@cse.unl.edu> 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 <teawater@gmail.com> 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 <caiqian@gmail.com> wrote:
> > >> >> > Hi,
> > >> >> >
> > >> >> > On 8/21/06, teawater <teawater@gmail.com> 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 <caiqian@gmail.com> wrote:
> > >> >> > > > Hi,
> > >> >> > > >
> > >> >> > > > On 8/21/06, Daniel Jacobowitz <drow@false.org> 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!
> >
> >
>