Virtual Machine and GDB

[Cai Qian]

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.

> >> 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!
>
>