Re: Interested in remote protocol improvements

['Daniel Jacobowitz' <drow at false dot org>]

On Fri, Aug 04, 2006 at 05:39:16PM +0200, Sascha wrote:
> > I rewrote a bunch of the native Windows support code after our last
> release.
> > I bet that would help you with your networking performance problems. 
> > None of that code is on the branch; it's only available on the FSF
> > HEAD, which doesn't have the XML description stuff yet.
> 
> > It might be a general Windows issue... but that would be pretty
> > disappointing.  If it is, there's not much we can do about it :-(
> > You might want to try communicating with the stub over a pipe instead
> > of a TCP socket; that's what we've been doing recently here at
> > CodeSourcery.
> 
> Somehow I feel that this is a Win32 issue, but I haven't found any
> information about this (Maybe you (or someone else) can run the "while++ <
> 10000" test on windows using mingw gdb and gdbserver to verify this? )

First I tried using mingw gdbserver and a stock Cygwin GDB:

(gdb) maint time 1
Command execution time: 0.000000
(gdb) set $i = 0
Command execution time: 0.000000
(gdb) while $i++ < 10000
 >set $b = *(char *)$pc
 >end
Command execution time: 5.006000

So, that's about 0.5ms.  It's ten times worse than the 0.05ms I could
generate on GNU/Linux, but much better than you were seeing.  This is a
Dell laptop from last year; it's got a 1.6GHz Pentium M (though I think
it's power-managed down to something slower right now).

I also tried a native mingw32 GDB built from HEAD and got 5.788000
seconds; about the same really.

> I already noticed that there is a pipe support implemented for gdb/mingw -
> is that what you are using ? Unfortunately there is no documentation. I had

Sure there is:

`target remote | COMMAND'
     Run COMMAND in the background and communicate with it using a
     pipe.  The COMMAND is a shell command, to be parsed and expanded
     by the system's command shell, `/bin/sh'; it should expect remote
     protocol packets on its standard input, and send replies on its
     standard output.  You could use this to run a stand-alone simulator
     that speaks the remote debugging protocol, to make net connections
     using programs like `ssh', or for other similar tricks.

     If COMMAND closes its standard output (perhaps by exiting), GDB
     will try to send it a `SIGTERM' signal.  (If the program has
     already exited, this will have no effect.)
   
("Remote Debugging" chapter, under "Connecting").

> a look at the source and did a test but GDB wants to launch another
> application if I specify the "|" to use a pipe (target remote | something).
> My stub is already running and it would use the named pipe api. Does gdb
> support named pipes ?

GDB does not yet have any support for named pipes on Windows.  This
could be added, I suppose; I don't need it myself, though.

> Alright. Good to know.
> 
> Another question about the remote protocol... the error code numbers don't
> have any effect, do they ? If my stub responds with "E99" for example,  how
> do I notice this (number) in GDB ? And even more important, how do I notice
> this using GDB/MI ?

In general, there is no way to do this today.  I've spent some time
thinking about the general issue of communicating errors, but I
haven't got any plans on how to improve the situation.  Someone
needs to come up with a solid design for this.

-- 
Daniel Jacobowitz
CodeSourcery