GDB interface with simulator

GDB interface with simulator

[Rama Singh]

Hi,
I am working on a cycle accurate simulator and for the
purpose of debugging application, I wish to use gdb.
Now gdb has in build support for about a dozen most
popular simulators. It interacts with the simulator as
a library. I wish to use my simulator as an
independent process running on the same machine or on
other machine. 
Is it posible to have gdb interact with a simulator
over a socket? Also where can I find more information
on this? I believe that implementing this will involve
writing a gdb stub that will compile with the
application and thus interact with the host gdb. Am I
getting things correctly or is there some other
possible way too?

Thanks in advance for any help

Regards
Rama Singh
Department of Electrical Engg.
MMM Engg College (MMMEC)
Gorakhpur

________________________________________________________________________
Yahoo! India Mobile: Download the latest polyphonic ringtones.
Go to http://in.mobile.yahoo.com

Re: GDB interface with simulator

[John Williams]

Hi Rama,

Rama Singh wrote:
> I am working on a cycle accurate simulator and for the
> purpose of debugging application, I wish to use gdb.
> Now gdb has in build support for about a dozen most
> popular simulators. It interacts with the simulator as
> a library. I wish to use my simulator as an
> independent process running on the same machine or on
> other machine. 
> Is it posible to have gdb interact with a simulator
> over a socket? Also where can I find more information
> on this? I believe that implementing this will involve
> writing a gdb stub that will compile with the
> application and thus interact with the host gdb. Am I
> getting things correctly or is there some other
> possible way too?

Take a look at the gdbserver application, distributed with GDB. 
Speifically, the remote-utils.c file will show you the socket interface, 
and provide some tips on how to implement it.

You basically just implement stubs to read/write memory, query 
registers, set breakpoints, that sort of thing.

Then, read

http://sources.redhat.com/gdb/current/onlinedocs/gdb_33.html

to see the format of the remote debugging packets.

You might just be able to integrate the gdbserver application into your 
simulator.

Good luck,

John

Re: GDB interface with simulator

[Rama Singh]

 --- John Williams <jwilliams@itee.uq.edu.au> wrote: >
Hi Rama,
> 
> Rama Singh wrote:
> > I am working on a cycle accurate simulator and for
> the
> > purpose of debugging application, I wish to use
> gdb.
> > Now gdb has in build support for about a dozen
> most
> > popular simulators. It interacts with the
> simulator as
> > a library. I wish to use my simulator as an
> > independent process running on the same machine or
> on
> > other machine. 
> > Is it posible to have gdb interact with a
> simulator
> > over a socket? Also where can I find more
> information
> > on this? I believe that implementing this will
> involve
> > writing a gdb stub that will compile with the
> > application and thus interact with the host gdb.
> Am I
> > getting things correctly or is there some other
> > possible way too?
> 
> Take a look at the gdbserver application,
> distributed with GDB. 
> Speifically, the remote-utils.c file will show you
> the socket interface, 
> and provide some tips on how to implement it.
Well I tried some hand on the gdbserver. I have it
running on a P4 RH-8 box. But it basically exec the
object file. Is there a way to tell gdbserver to exec
on my simulator.

> 
> You basically just implement stubs to read/write
> memory, query 
> registers, set breakpoints, that sort of thing.
> 
> Then, read
> 
>
http://sources.redhat.com/gdb/current/onlinedocs/gdb_33.html
> 
> to see the format of the remote debugging packets.
> 
> You might just be able to integrate the gdbserver
> application into your 
> simulator.
Does this mean that gdbserver is a target dependent
application? or should I compile it with my
target-dependent compiler?
> 
> Good luck,
> 
> John
>  

________________________________________________________________________
Yahoo! India Mobile: Download the latest polyphonic ringtones.
Go to http://in.mobile.yahoo.com

GDB interface with simulator

[Doug Evans]

=?iso-8859-1?q?Rama=20Singh?= writes:
 > I wish to use my simulator as an
 > independent process running on the same machine or on
 > other machine. 

Old versions of gdb had a file in gdb/gdbserver called low-sim.c.
IIRC, one would use this file in gdbserver and would link gdbserver
with libsim.a.  You would then run this program on the host
you want to run your simulator on and use "target remote <simhost>:<port>"
in gdb to talk to gdbserver+sim.

Maybe you could grab that file from an old version of gdb (e.g. 5.3)
and try to make it work with the version of gdb you have.
[or maybe even just build gdbserver from 5.3 sources]

I don't recall why support for gdbserver+sim has been removed.
Maybe I'm mistaken and it's still there and I just can't see it.

 > Is it posible to have gdb interact with a simulator
 > over a socket? Also where can I find more information
 > on this? I believe that implementing this will involve
 > writing a gdb stub that will compile with the
 > application and thus interact with the host gdb. Am I
 > getting things correctly or is there some other
 > possible way too?

The other way to go is to write a gdb stub and compile that
into the application.  You will need the stub's i/o routines
to use the socket.  sim/common/dv-sockser.c provides one
implementation of low level socket support that you need.
Some of the provided sims use this, so that should give you
enough examples to work from.

It does require having a working stub though.
One way to debug your stub would be to do both,
but now we're getting fancy, and you might want to
try just one of them for now.

Re: GDB interface with simulator

[Daniel Jacobowitz]

On Fri, Nov 14, 2003 at 09:07:17AM -0800, Doug Evans wrote:
> =?iso-8859-1?q?Rama=20Singh?= writes:
>  > I wish to use my simulator as an
>  > independent process running on the same machine or on
>  > other machine. 
> 
> Old versions of gdb had a file in gdb/gdbserver called low-sim.c.
> IIRC, one would use this file in gdbserver and would link gdbserver
> with libsim.a.  You would then run this program on the host
> you want to run your simulator on and use "target remote <simhost>:<port>"
> in gdb to talk to gdbserver+sim.
> 
> Maybe you could grab that file from an old version of gdb (e.g. 5.3)
> and try to make it work with the version of gdb you have.
> [or maybe even just build gdbserver from 5.3 sources]
> 
> I don't recall why support for gdbserver+sim has been removed.
> Maybe I'm mistaken and it's still there and I just can't see it.

Because there was no point.  The current simulators link directly into
GDB, and the simulator interface has changed since anyone tried to use
gdbserver that way.  The correct thing is to write a layer in your
simulator that serves the same purpose (speaks the remote protocol). 
It's not too hard.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: GDB interface with simulator

[Theodore A. Roth]

On Fri, 14 Nov 2003, Daniel Jacobowitz wrote:

> On Fri, Nov 14, 2003 at 09:07:17AM -0800, Doug Evans wrote:
> > =?iso-8859-1?q?Rama=20Singh?= writes:
> >  > I wish to use my simulator as an
> >  > independent process running on the same machine or on
> >  > other machine.
> >
> > Old versions of gdb had a file in gdb/gdbserver called low-sim.c.
> > IIRC, one would use this file in gdbserver and would link gdbserver
> > with libsim.a.  You would then run this program on the host
> > you want to run your simulator on and use "target remote <simhost>:<port>"
> > in gdb to talk to gdbserver+sim.
> >
> > Maybe you could grab that file from an old version of gdb (e.g. 5.3)
> > and try to make it work with the version of gdb you have.
> > [or maybe even just build gdbserver from 5.3 sources]
> >
> > I don't recall why support for gdbserver+sim has been removed.
> > Maybe I'm mistaken and it's still there and I just can't see it.
>
> Because there was no point.  The current simulators link directly into
> GDB, and the simulator interface has changed since anyone tried to use
> gdbserver that way.  The correct thing is to write a layer in your
> simulator that serves the same purpose (speaks the remote protocol).
> It's not too hard.

I've written an avr simulator that speaks the remote protocol directly.
If you are looking for an example, it's available on savannah:

  http://savannah.nongnu.org/projects/simulavr

Another example of the same thing with a different implementation is the
avarice project. It speaks the remote protocol, but instead of talking
to a simulator, it talks to a jtage ice box.

  http://sourceforge.net/projects/avarice

Look at the source in cvs for each.

Hope that helps.

Ted Roth

Re: GDB interface with simulator

[Doug Evans]

Daniel Jacobowitz writes:
 > > I don't recall why support for gdbserver+sim has been removed.
 > > Maybe I'm mistaken and it's still there and I just can't see it.
 > 
 > Because there was no point.  The current simulators link directly into
 > GDB, and the simulator interface has changed since anyone tried to use
 > gdbserver that way.  The correct thing is to write a layer in your
 > simulator that serves the same purpose (speaks the remote protocol). 
 > It's not too hard.

How about instead of adding it to every simulator,
just add it as a common piece of code that gets linked in with
<target>-run and turned on when some argument is passed.

OTOH, is all one would end up doing is copying a bunch of code
from gdb/gdbserver to sim/common?

[That's an honest question.  Just trying to learn how you require it.]

Re: GDB interface with simulator

[Rama Singh]

Hi,
Thanks for the answers. I have certain newbiew
querries for gdb-stubs.
I do not hve any OS running on my target board and
hence there is no point in porting of gdbserver. I
need to write the gdb-stub for my architecture.
Now there is a conept of threads which may share data
and insns. Going though some of the discussions
previously about thread support in gdb, i realise that
gdb does support threads. Have some querries regarding
this.
Is it possible, under a gdb-stub implementation, that
once a thread has hit breakpoint and all the others
are stop, we can selectevely resume some of the
threads and step on the rest?

Also looking into gdb-stub implementation, I have
found that there is no way of specifying the thread
id? a search on the net provided a protocol document
as
http://world.std.com/~qqi/download/protocol.txt
Is this a document for the gdb remote protocol for
stubs?

I do not see any support for seting and removing
breakpoints in sparc-stub.c. Does that mean that for
setting breakpoint, we need to put in breakpoint() and
recompile the whole application again?

How do I specify gdb to which thread it has to hook
to?
I do a 'target remote COMM' How to read specific info
about a thread?

Just to make things simple, where can I find a
gdb-stub implementation for MIPS architecture.

Thanks and Regards
Rama Singh

--- Daniel Jacobowitz <drow@mvista.com> wrote:
> On Fri, Nov 14, 2003 at 09:07:17AM -0800, Doug Evans
> wrote:
> > =?iso-8859-1?q?Rama=20Singh?= writes:
> >  > I wish to use my simulator as an
> >  > independent process running on the same machine
> or on
> >  > other machine. 
> > 
> > Old versions of gdb had a file in gdb/gdbserver
> called low-sim.c.
> > IIRC, one would use this file in gdbserver and
> would link gdbserver
> > with libsim.a.  You would then run this program on
> the host
> > you want to run your simulator on and use "target
> remote <simhost>:<port>"
> > in gdb to talk to gdbserver+sim.
> > 
> > Maybe you could grab that file from an old version
> of gdb (e.g. 5.3)
> > and try to make it work with the version of gdb
> you have.
> > [or maybe even just build gdbserver from 5.3
> sources]
> > 
> > I don't recall why support for gdbserver+sim has
> been removed.
> > Maybe I'm mistaken and it's still there and I just
> can't see it.
> 
> Because there was no point.  The current simulators
> link directly into
> GDB, and the simulator interface has changed since
> anyone tried to use
> gdbserver that way.  The correct thing is to write a
> layer in your
> simulator that serves the same purpose (speaks the
> remote protocol). 
> It's not too hard.
> 
> -- 
> Daniel Jacobowitz
> MontaVista Software                         Debian
> GNU/Linux Developer


__________________________________
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/