From mboxrd@z Thu Jan  1 00:00:00 1970
From: Andrew Cagney <ac131313@cygnus.com>
To: Daniel Jacobowitz <dmj+@andrew.cmu.edu>
Cc: gdb@sources.redhat.com
Subject: Re: Current (non-) state of gdbserver
Date: Thu, 12 Jul 2001 13:04:00 -0000
Message-id: <3B4E02BA.6070805@cygnus.com>
References: <20010710234505.A5814@nevyn.them.org>
X-SW-Source: 2001-07/msg00123.html

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