gdbserver implementation

gdbserver implementation

[Kris Warkentin]

I'm thinking about doing some work on making gdbserver work on QNX Neutrino.
I'd love to RTFM on how to do that but so far I'm not finding it.  Is there
an FM or do I have to RTFC?

I already have gdb running on Neutrino using our procfs interface so I
suspect that a large part of the work has been done for me there.  I had
this fantasy that gdbserver would just use the native files for a target and
take what functionality it needed from there but that doesn't seem to be the
case.  I guess the dependencies would make it too big that way.

Perhaps someone can share some advice, point to a link or at least suggest
which header to look at first?

TIA

Kris

Re: gdbserver implementation

[Daniel Jacobowitz]

On Thu, Apr 10, 2003 at 03:17:20PM -0400, Kris Warkentin wrote:
> I'm thinking about doing some work on making gdbserver work on QNX Neutrino.
> I'd love to RTFM on how to do that but so far I'm not finding it.  Is there
> an FM or do I have to RTFC?

Nope, no FM to speak of.

> I already have gdb running on Neutrino using our procfs interface so I
> suspect that a large part of the work has been done for me there.  I had
> this fantasy that gdbserver would just use the native files for a target and
> take what functionality it needed from there but that doesn't seem to be the
> case.  I guess the dependencies would make it too big that way.
> 
> Perhaps someone can share some advice, point to a link or at least suggest
> which header to look at first?

I tried to make it use the native files.  It would have required
breaking the native files into more pieces, and turned out to be a bit
too fragile; so instead it was separated out.

The first thing to be careful of is the dead code in the gdbserver
directory.  I'll whack it as soon as I get a chance, I've been meaning
to for a while.  Right now all the low-* files are dead.

After that, well, there's the beginnings of a target abstraction layer
but it suffers from a lack of targets.  Feel free to change anything
you want outside of the platform-specific code if you think it's an
improvement, or drop me a line if there's something you want it to do.

I haven't had a lot of time for gdbserver recently, but I still have
hopes of making it do things like support limited file transfer/daemon
mode....  Not enough round tuits.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: gdbserver implementation

[Kris Warkentin]

> After that, well, there's the beginnings of a target abstraction layer
> but it suffers from a lack of targets.  Feel free to change anything
> you want outside of the platform-specific code if you think it's an
> improvement, or drop me a line if there's something you want it to do.
>
> I haven't had a lot of time for gdbserver recently, but I still have
> hopes of making it do things like support limited file transfer/daemon
> mode....  Not enough round tuits.

Thanks Daniel.  We have a pretty full featured remote debug agent in our
pdebug.  It runs as a daemon on a com or network port plus it runs from
inetd.  It supports upload/download and spawning of processes on the remote,
listing of remote pids, attaching, etc.  It also supports threads and
everything else you would expect such as memory/register reads, solib
loading, etc.  Multiple gdbs SHOULD be able to talk to a single pdebug.  You
can set the targets environment to inherit from either the host or target.
We support a console so you can interact with the remote processes
stdin/stdout, etc.  We also can print meminfo on the process that shows how
the process and its libs are mapped into the address space.

There are a few problems with it though.  On an unreliable connection with a
very fast host and slow target, there are occasionally issues with
syncronization that can cause lockups (extremely rare).  The protocol is not
full duplex which exacerbates this problem.  The console channels are only
two way so stdout and stderr are merged.

I've never used gdbserver before.  How does its feature set compare to this?
We wanted to see how well gdbserver worked for us and were considering
migrating to get away from the pdebug protocol issues.

cheers,

Kris

Re: gdbserver implementation

[Kris Warkentin]

> I've never used gdbserver before.  How does its feature set compare to
this?
> We wanted to see how well gdbserver worked for us and were considering
> migrating to get away from the pdebug protocol issues.

I should say that one of the reasons for this is that we now have an IDE
with it's own remote agent that does a great deal of the fancy stuff so it's
not required at the pdebug/gdbserver level.  The remote agent sets
everything up and then just spawns pdebug to talk to gdb.  One of the big
pains in our pdebug protocol is the extents that it goes to in ensuring
reliable communication.  It's a good feature but it's also where things
occasionally fall down due to the complexity.  If the IDE's agent is
ensuring reliable communication, then none of that code is required and
gdbserver might be just the thing.

cheers,

Kris