This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Virtual Machine and GDB


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!




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]