This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Current (non-) state of gdbserver
- To: Daniel Jacobowitz <dmj+ at andrew dot cmu dot edu>
- Subject: Re: Current (non-) state of gdbserver
- From: Andrew Cagney <ac131313 at cygnus dot com>
- Date: Thu, 12 Jul 2001 16:04:10 -0400
- Cc: gdb at sources dot redhat dot com
- References: <20010710234505.A5814@nevyn.them.org>
Since people are posting wishlists on GDBserver, I'll post mine. It
contains one item:
o get it to talk to its self
That is, a GDBserver talking to a GDBserver talking to a GDBserver. The
foundation for each layer being a target object/stack-entry/...
As John Kallal has rightly pointed out, this is hard, really hard. It
means GDBserver gets an event-loop. It means GDBserver has to do
non-blocking reads and writes, it means ....
However, it also offers a glimmer of hope on one of GDB's problems - its
very blocking centric behavour. GDBserver could be small enough, yet
applicable enough, to allow the development of a proper target stack.
Using sufficient glue, gaffer tape and spac-filler, (and a re-entrant
event-loop) it could even be bolted onto GDB's current target interface.
Maybe.
----
With regard to modifying the remote protocol, to be honest, for all its
warts, beginning to think it isn't that bad. If you think about it,
consider a memory read:
-> $M<addr>#CC
<- +$<hex-data>#CC
-> +
then, apart from assuming a reliable channel (and remove the ``+'')
there isn't much more you can extract out of this. Bigger gains can be
made by making better use of that channel (combining reads/writes, ...)
all of which are changes to GDB.
This isn't to say that a replacement protocol wouldn't be more welcome
though.
Andrew