From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24422 invoked by alias); 2 Aug 2006 03:03:25 -0000 Received: (qmail 24414 invoked by uid 22791); 2 Aug 2006 03:03:24 -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; Wed, 02 Aug 2006 03:03:23 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1G870y-0000Gm-Ug; Tue, 01 Aug 2006 23:03:21 -0400 Date: Wed, 02 Aug 2006 03:03:00 -0000 From: 'Daniel Jacobowitz' To: Sascha Cc: gdb@sourceware.org Subject: Re: Interested in remote protocol improvements Message-ID: <20060802030320.GA981@nevyn.them.org> Mail-Followup-To: Sascha , gdb@sourceware.org References: <20060728160749.GA18728@nevyn.them.org> <20060729141300.B6A964B269@return.false.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060729141300.B6A964B269@return.false.org> 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/msg00003.txt.bz2 On Sat, Jul 29, 2006 at 04:11:59PM +0200, Sascha wrote: > I'll probably come up with some more problems when I work on the stub again. > Something I'd be really interested in is the "step-range" packet you > mentioned before. On a remote target stepping a C/C++ instruction can take > some time as GDB fires a lot of step packets. Yes, this is important. > >Where does the GDB you're using come from? I thought that I had fixed > >CodeSourcery's to use the 'g' packet for any registers which are > >available that way. This isn't documented yet, but that version of GDB > >will just decode bytes in the 'g' packet in the same order as the > >"protocol numbers" from the target XML descriptions. So one option is > >to enlarge your 'g' packet. > > It's the latest code sourcery arm-eabi-gdb. 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. You probably can't use HEAD to debug your target, but do you want to try building it and repeating the simple performance test? > Maybe a small bug: The first time I replied to the 'g' packet with all > standard arm registers (r.., f.., cpsr). But then GDB did NOT fetch the > other registers using the 'p' packet. Instead it just reported the > additional registers defined in target.xml as 0. Then I left out some > registers (like cpsr) in the 'g' packet and it worked. Things will get messed up if you put registers in your g packet that aren't in the XML description. This isn't adequately clear in the documentation yet; I'll be fixing that before the submission to mainline. > >>For memory, you can tell GDB to cache 16-byte or 32-byte "cache lines". > >>That may boost disassembly performance. See "help mem". > > I remember this caused some trouble with my stub. I will have to fix that > first. I also was not sure how this would affect "volatile" memory like the > arm memory-mapped regs. You have to manually mark them as not cached. > Platform is Windows(XP,SP2) running on Mobile Athlon XP 1700 and Code > Sourcery arm-none-eabi-GDB connected to local stub (my own stub, gdbserver > is not available for win32?). Gdbserver didn't used to be available, but it is now. You can build it from the latest FSF HEAD snapshots; I do it by running the configure script directly in the gdb/gdbserver/ subdirectory, from a Cygwin shell, with CC set to "gcc -mno-cygwin". And be sure to pass --host=i686-mingw32 to configure. > I tried to write a simple ping-pong tcp > client/server app to test the maximum performance and the best result I got > was 2 ms for a request/reply which is still way more than 0.05ms as > mentioned by you using linux. So does anyone know if this is a win32 issue? > Disabling nagle does not seem to help either. 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. -- Daniel Jacobowitz CodeSourcery