Virtual Machine and GDB

Virtual Machine and GDB

[Cai Qian]

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.

Qian

Re: Virtual Machine and GDB

[Daniel Jacobowitz]

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.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Virtual Machine and GDB

[Cai Qian]

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
>

Re: Virtual Machine and GDB

[Daniel Jacobowitz]

On Mon, Aug 21, 2006 at 01:24:01AM +0100, Cai Qian wrote:
> 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?

Yes, that's usually how it's done.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Virtual Machine and GDB

[Cai Qian]

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

Re: Virtual Machine and GDB

[teawater]

Does GDB support the ARCH of you VM?

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

Re: Virtual Machine and GDB

[Cai Qian]

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

Re: Virtual Machine and GDB

[Daniel Jacobowitz]

On Mon, Aug 21, 2006 at 01:22:34PM +0100, 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,

No no no.  This is almost certainly not what you want to do.  This bit
of the documentation is not actually relevant.

You want to debug the bare code running inside the virtual machine,
right?  Then what you probably want to do is a stub integrated directly
with the source code of the virtual machine.  Then that stub can
respond to a single step packet by requesting the virtual machine
execute one instruction, and so forth.  The stub runs outside the VM.

> 2) Can't find information on what kind of debug features I can have
> when after implementing the remote stub. Breakpoint, watchpoint,
> single step?

See the remote protocol appendix in the GDB manual.  All of those are
supported.

> 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

You don't need one; you can either use "load", or you can load directly
from the virtual machine and just have GDB connect.


-- 
Daniel Jacobowitz
CodeSourcery

Re: Virtual Machine and GDB

[teawater]

Sorry, I told about ARCH because I think you were the people that ask
the same question in CLF.
He told that his VM has a new instruction set. So I think the ARCH of
his VM is not support by GDB.
If the ARCH of your VM is supported by GDB, you will not need to porting it.

>>2) Can't find information on what kind of debug features I can have
>>when after implementing the remote stub. Breakpoint, watchpoint,
>>single step?
http://sources.redhat.com/gdb/onlinedocs/gdb_33.html
This doc is very clear.

>>3) Not sure how to write a download program to download executable
>>from target to host in a debug session.
I think if your stub on VM support GDBRSP write memory command M, you
can use GDB command load do it.

Re: Virtual Machine and GDB

[Neo]

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.

For JVM 1.4.2 and 1.5, I have successfully debugged it with the latest 
gdb locally.

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!

Re: Virtual Machine and GDB

[Cai Qian]

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.

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

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

Re: Virtual Machine and GDB

[Michael Snyder]

On Mon, 2006-08-21 at 18:59 +0100, 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.

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.

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).

Re: Virtual Machine and GDB

[Neo]

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

Re: Virtual Machine and GDB

[Daniel Jacobowitz]

On Mon, Aug 21, 2006 at 11:28:12AM -0700, Michael Snyder wrote:
> 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.

What sort of VM are we talking about here?  I think a lot of the
responses have been assuming different meanings for that term.

If it's a bytecode language, like a Java Virtual Machine, then
you don't want this at all.  You would have to have multiple processes
in the VM, plus an internal debug interface allowing one process to
debug another.  Instead, think of it more like a simulator; the
virtual machine monitor can talk directly to GDB.

If it's a whole system simulator, more like qemu or vmware, then
maybe you want to have a stub running on the inside.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Virtual Machine and GDB

[Cai Qian]

Hi,

On 8/21/06, Michael Snyder <Michael.Snyder@palmsource.com> wrote:
> On Mon, 2006-08-21 at 18:59 +0100, 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.
>
> 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.

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

Qian

>
>
>
>
>

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

Re: Virtual Machine and GDB

[Michael Snyder]

On Mon, 2006-08-21 at 19:49 +0100, Cai Qian wrote:
> Hi,
> 
> On 8/21/06, Michael Snyder <Michael.Snyder@palmsource.com> wrote:
> > On Mon, 2006-08-21 at 18:59 +0100, 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.
> >
> > 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.

Re: Virtual Machine and GDB

[Michael Snyder]

On Mon, 2006-08-21 at 19:57 +0100, Cai Qian wrote:

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

Right -- so once you get your gdbserver to talk to gdb, 
the next thing you have to do is teach gdb to understand
your new architecture.

If you look at some of the base architecture ports that you
mentioned, for instance sh-tdep.c or h8300-tdep.c, these
are examples of what I mean.  They tell gdb how to interpret
the register set etc. of the given target architecture.

You need to write one of these for your target.

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

Re: Virtual Machine and GDB

[Anupama Chandwani]

Hi..

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

>>Qian


Since you already have a communicating mechanism up, its good, u wont take much
time for including ur target in gdb. Your on right track, but after parsing wat
the packet wants just call the callback functions in gdb. Instead of setting a
flag in VM to indicate the next command, just call the function of "next" in gdb.
It will take care of the required.
       Read how targets are supported by gdb, ull get a gud view of exactly wat u
have to implement.

Re: Virtual Machine and GDB

[Anupama Chandwani]

Hi..

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

>>Qian


Since you already have a communicating mechanism up, its good, u wont take much
time for including ur target in gdb. Your on right track, but after parsing wat
the packet wants just call the callback functions in gdb. Instead of setting a
flag in VM to indicate the next command, just call the function of "next" in gdb.
It will take care of the required.
       Read how targets are supported by gdb, ull get a gud view of exactly wat u
have to implement.

Re: Virtual Machine and GDB

[Anupama Chandwani]

Hi..

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

>>Qian


Since you already have a communicating mechanism up, its good, u wont take much
time for including ur target in gdb. Your on right track, but after parsing wat
the packet wants just call the callback functions in gdb. Instead of setting a
flag in VM to indicate the next command, just call the function of "next" in gdb.
It will take care of the required.
       Read how targets are supported by gdb, ull get a gud view of exactly wat u
have to implement.

Re: Virtual Machine and GDB

[Anupama Chandwani]

Hi..

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

>>Qian


Since you already have a communicating mechanism up, its good, u wont take much
time for including ur target in gdb. Your on right track, but after parsing wat
the packet wants just call the callback functions in gdb. Instead of setting a
flag in VM to indicate the next command, just call the function of "next" in gdb.
It will take care of the required.
       Read how targets are supported by gdb, ull get a gud view of exactly wat u
have to implement.

Re: Virtual Machine and GDB

[Anupama Chandwani]

Hi..

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

>>Qian


Since you already have a communicating mechanism up, its good, u wont take much
time for including ur target in gdb. Your on right track, but after parsing wat
the packet wants just call the callback functions in gdb. Instead of setting a
flag in VM to indicate the next command, just call the function of "next" in gdb.
It will take care of the required.
       Read how targets are supported by gdb, ull get a gud view of exactly wat u
have to implement.

Re: Virtual Machine and GDB

[Anupama Chandwani]

Hi..

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

>>Qian


Since you already have a communicating mechanism up, its good, u wont take much
time for including ur target in gdb. Your on right track, but after parsing wat
the packet wants just call the callback functions in gdb. Instead of setting a
flag in VM to indicate the next command, just call the function of "next" in gdb.
It will take care of the required.
       Read how targets are supported by gdb, ull get a gud view of exactly wat u
have to implement.

Re: Virtual Machine and GDB

[Anupama Chandwani]

Hi..

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

>>Qian


Since you already have a communicating mechanism up, its good, u wont take much
time for including ur target in gdb. Your on right track, but after parsing wat
the packet wants just call the callback functions in gdb. Instead of setting a
flag in VM to indicate the next command, just call the function of "next" in gdb.
It will take care of the required.
       Read how targets are supported by gdb, ull get a gud view of exactly wat u
have to implement.

Re: Virtual Machine and GDB

[Anupama Chandwani]

Hi..

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

>>Qian


Since you already have a communicating mechanism up, its good, u wont take much
time for including ur target in gdb. Your on right track, but after parsing wat
the packet wants just call the callback functions in gdb. Instead of setting a
flag in VM to indicate the next command, just call the function of "next" in gdb.
It will take care of the required.
       Read how targets are supported by gdb, ull get a gud view of exactly wat u
have to implement.

Re: Virtual Machine and GDB

[Anupama Chandwani]

Hi..

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

>>Qian


Since you already have a communicating mechanism up, its good, u wont take much
time for including ur target in gdb. Your on right track, but after parsing wat
the packet wants just call the callback functions in gdb. Instead of setting a
flag in VM to indicate the next command, just call the function of "next" in gdb.
It will take care of the required.
       Read how targets are supported by gdb, ull get a gud view of exactly wat u
have to implement.

Re: Virtual Machine and GDB

[Anupama Chandwani]

Hi..

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

>>Qian


Since you already have a communicating mechanism up, its good, u wont take much
time for including ur target in gdb. Your on right track, but after parsing wat
the packet wants just call the callback functions in gdb. Instead of setting a
flag in VM to indicate the next command, just call the function of "next" in gdb.
It will take care of the required.
       Read how targets are supported by gdb, ull get a gud view of exactly wat u
have to implement.

Re: Virtual Machine and GDB

[Anupama Chandwani]

Hi..

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

>>Qian


Since you already have a communicating mechanism up, its good, u wont take much
time for including ur target in gdb. Your on right track, but after parsing wat
the packet wants just call the callback functions in gdb. Instead of setting a
flag in VM to indicate the next command, just call the function of "next" in gdb.
It will take care of the required.
       Read how targets are supported by gdb, ull get a gud view of exactly wat u
have to implement.

Re: Virtual Machine and GDB

[Anupama Chandwani]

Hi..

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

>>Qian


Since you already have a communicating mechanism up, its good, u wont take much
time for including ur target in gdb. Your on right track, but after parsing wat
the packet wants just call the callback functions in gdb. Instead of setting a
flag in VM to indicate the next command, just call the function of "next" in gdb.
It will take care of the required.
       Read how targets are supported by gdb, ull get a gud view of exactly wat u
have to implement.

Re: Virtual Machine and GDB

[Anupama Chandwani]

Hi..

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

>>Qian


Since you already have a communicating mechanism up, its good, u wont take much
time for including ur target in gdb. Your on right track, but after parsing wat
the packet wants just call the callback functions in gdb. Instead of setting a
flag in VM to indicate the next command, just call the function of "next" in gdb.
It will take care of the required.
       Read how targets are supported by gdb, ull get a gud view of exactly wat u
have to implement.

Re: Virtual Machine and GDB

[Anupama Chandwani]

Hi..

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

>>Qian


Since you already have a communicating mechanism up, its good, u wont take much
time for including ur target in gdb. Your on right track, but after parsing wat
the packet wants just call the callback functions in gdb. Instead of setting a
flag in VM to indicate the next command, just call the function of "next" in gdb.
It will take care of the required.
       Read how targets are supported by gdb, ull get a gud view of exactly wat u
have to implement.

Re: Virtual Machine and GDB

[Anupama Chandwani]

Hi..

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

>>Qian


Since you already have a communicating mechanism up, its good, u wont take much
time for including ur target in gdb. Your on right track, but after parsing wat
the packet wants just call the callback functions in gdb. Instead of setting a
flag in VM to indicate the next command, just call the function of "next" in gdb.
It will take care of the required.
       Read how targets are supported by gdb, ull get a gud view of exactly wat u
have to implement.

Re: Virtual Machine and GDB

[Anupama Chandwani]

Hi..

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

>>Qian


Since you already have a communicating mechanism up, its good, u wont take much
time for including ur target in gdb. Your on right track, but after parsing wat
the packet wants just call the callback functions in gdb. Instead of setting a
flag in VM to indicate the next command, just call the function of "next" in gdb.
It will take care of the required.
       Read how targets are supported by gdb, ull get a gud view of exactly wat u
have to implement.

Re: Virtual Machine and GDB

[Anupama Chandwani]

Hi..

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

>>Qian


Since you already have a communicating mechanism up, its good, u wont take much
time for including ur target in gdb. Your on right track, but after parsing wat
the packet wants just call the callback functions in gdb. Instead of setting a
flag in VM to indicate the next command, just call the function of "next" in gdb.
It will take care of the required.
       Read how targets are supported by gdb, ull get a gud view of exactly wat u
have to implement.

Re: Virtual Machine and GDB

[Anupama Chandwani]

Hi..

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

>>Qian


Since you already have a communicating mechanism up, its good, u wont take much
time for including ur target in gdb. Your on right track, but after parsing wat
the packet wants just call the callback functions in gdb. Instead of setting a
flag in VM to indicate the next command, just call the function of "next" in gdb.
It will take care of the required.
       Read how targets are supported by gdb, ull get a gud view of exactly wat u
have to implement.

Re: Virtual Machine and GDB

[Anupama Chandwani]

Hi..

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

>>Qian


Since you already have a communicating mechanism up, its good, u wont take much
time for including ur target in gdb. Your on right track, but after parsing wat
the packet wants just call the callback functions in gdb. Instead of setting a
flag in VM to indicate the next command, just call the function of "next" in gdb.
It will take care of the required.
       Read how targets are supported by gdb, ull get a gud view of exactly wat u
have to implement.

Re: Virtual Machine and GDB

[Anupama Chandwani]

Hi..

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

>>Qian


Since you already have a communicating mechanism up, its good, u wont take much
time for including ur target in gdb. Your on right track, but after parsing wat
the packet wants just call the callback functions in gdb. Instead of setting a
flag in VM to indicate the next command, just call the function of "next" in gdb.
It will take care of the required.
       Read how targets are supported by gdb, ull get a gud view of exactly wat u
have to implement.

Re: Virtual Machine and GDB

[Anupama Chandwani]

Hi..

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

>>Qian


Since you already have a communicating mechanism up, its good, u wont take much
time for including ur target in gdb. Your on right track, but after parsing wat
the packet wants just call the callback functions in gdb. Instead of setting a
flag in VM to indicate the next command, just call the function of "next" in gdb.
It will take care of the required.
       Read how targets are supported by gdb, ull get a gud view of exactly wat u
have to implement.