From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23533 invoked by alias); 28 Jul 2006 16:07:58 -0000 Received: (qmail 23370 invoked by uid 22791); 28 Jul 2006 16:07:54 -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, 28 Jul 2006 16:07:52 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1G6UsQ-0004x0-0M; Fri, 28 Jul 2006 12:07:50 -0400 Date: Sat, 29 Jul 2006 14:13:00 -0000 From: Daniel Jacobowitz To: Sascha Cc: gdb@sourceware.org Subject: Re: Interested in remote protocol improvements Message-ID: <20060728160749.GA18728@nevyn.them.org> Mail-Followup-To: Sascha , gdb@sourceware.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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-07/txt/msg00199.txt.bz2 On Fri, Jul 28, 2006 at 05:36:38PM +0200, Sascha wrote: > Hi, > > I read some posts from Daniel Jacobowitz and his plans about improving the > remote protocol. Are there any further informations available? Pretty much all of the projects I've got in progress I've been discussing on the mailing lists. What I need is for people with additional problems to tell us more about them, so that we can cooperate on improving it. > I already tested the "Self-describing targets" target.xml idea and it works > pretty well (using the codesourcery gdb for arm). I used the target > description to add new registers - this way I could avoid hacking GDB. That's great news! I'm glad to hear that it was useful. The protocol as implemented on that branch is never going to be merged. However, something will be, and I hope it won't be too different. I've been waiting on this because it overlaps with the flash memory patches that my coworked Vladimir has been submitting. I hope we'll be done merging those in another week or two; after that, I'll be focusing on this project again. > Since my current project depends on the remote protocol performance I'm > interested in any progress. > The biggest problem is the speed. Even on my localhost tcp connection a > request + reply packet takes about 5-10 ms. So if GDB is driven by some > external IDE which fetches all registers and maybe some disassembly after > each step/break you can easily reach 1 second delay for every step. > Unfortunately GDB tries to fetch every additional register one by one using > the P packet. The same thing happens for the disassembly (word by word). 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. I know this doesn't work in FSF GDB. If 'p' is present it will be used exclusively for all registers. That's one of the bits I need to submit. Another possible improvement would be to add a "fetch list of registers" packet. But this is very hard to integrate with the way GDB works now; we don't know early enough which registers will be necessary. I'm not sure how to approach this but it would be a lot of work. For memory, you can tell GDB to cache 16-byte or 32-byte "cache lines". That may boost disassembly performance. See "help mem". As for localhost communications, 5-10ms seems high. What platform is this? How long does this test take? (gdb) maint time 1 (gdb) set $i = 0 (gdb) while $i++ < 10000 >set $b = *(char *)$pc >end Command execution time: 0.422936 That's about 0.05 ms per packet + response. This is GNU/Linux, connected to a gdbserver running on localhost. -- Daniel Jacobowitz CodeSourcery