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!