Re: Interested in remote protocol improvements

'Daniel Jacobowitz'
2006-08-04T16:00:12Z

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