Re: gdbserver implementation

["Kris Warkentin" <kewarken@qnx.com>]

> 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