From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6263 invoked by alias); 29 Jul 2006 14:13:09 -0000 Received: (qmail 6253 invoked by uid 22791); 29 Jul 2006 14:13:08 -0000 X-Spam-Check-By: sourceware.org Received: from d102.x-mailer.de (HELO d102.x-mailer.de) (212.162.13.80) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 29 Jul 2006 14:13:00 +0000 Received: from [84.131.170.184] (helo=insanenotebook) by d102.x-mailer.de with esmtp (Exim 4.61) (envelope-from ) id 1G6pYi-0006Jk-Ri; Sat, 29 Jul 2006 16:12:56 +0200 From: "Sascha" To: "'Daniel Jacobowitz'" Cc: Subject: AW: Interested in remote protocol improvements Date: Sun, 30 Jul 2006 10:05:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <20060728160749.GA18728@nevyn.them.org> X-Info: valid message X-Info: original Date 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-07/txt/msg00200.txt.bz2 Message-ID: <20060730100500.e7PafWDV4Z-E3bDhB0CjlqZI8R6GiXwwqqcJ2eHzlWQ@z> Thanks for your reply. >What I need is for people with >additional problems to tell us more about them, so that we can >cooperate on improving it. 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. >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. Maybe the 'g' packet will fetch all registers. I haven't tried that yet as I didn't want all registers to be transmitted. Some registers need special processing (and are not required for gdb's stack processing, etc.) so it takes a bit more time which slows down the step process (mentioned above). But I'm going to try to respond with signal packet which includes all base registers. All additional (+ base) registers could be received by 'g' then. 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. >>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. >>As for localhost communications, 5-10ms seems high. What platform is >>this? How long does this test take? >>Command execution time: 0.422936 This is quite scary: about 60 seconds ! So this would be about 6ms for request+reply. It's a bit less if both processes have high priority. 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?). 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. Thanks Sascha