From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1268 invoked by alias); 4 Aug 2006 16:00:12 -0000 Received: (qmail 1248 invoked by uid 22791); 4 Aug 2006 16:00:10 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Fri, 04 Aug 2006 16:00:07 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1G925l-0008NJ-Dd; Fri, 04 Aug 2006 12:00:05 -0400 Date: Fri, 04 Aug 2006 16:00:00 -0000 From: 'Daniel Jacobowitz' To: Sascha Cc: gdb@sourceware.org Subject: Re: Interested in remote protocol improvements Message-ID: <20060804160005.GA31681@nevyn.them.org> Mail-Followup-To: Sascha , gdb@sourceware.org References: <20060728160749.GA18728@nevyn.them.org> <20060729141300.B6A964B269@return.false.org> <20060802030320.GA981@nevyn.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11+cvs20060403 X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-08/txt/msg00026.txt.bz2 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