Re: Current (non-) state of gdbserver

[Andrew Cagney <ac131313@cygnus.com>]

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