From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17805 invoked by alias); 3 Apr 2008 19:10:13 -0000 Received: (qmail 17797 invoked by uid 22791); 3 Apr 2008 19:10:12 -0000 X-Spam-Check-By: sourceware.org Received: from bluesmobile.specifix.com (HELO bluesmobile.specifix.com) (216.129.118.140) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 03 Apr 2008 19:09:55 +0000 Received: from [127.0.0.1] (bluesmobile.specifix.com [216.129.118.140]) by bluesmobile.specifix.com (Postfix) with ESMTP id 332ED3BE61; Thu, 3 Apr 2008 12:09:53 -0700 (PDT) Subject: Re: -var-update @ From: Michael Snyder To: Daniel Jacobowitz Cc: Nick Roberts , Marc Khouzam , Vladimir Prus , gdb-patches@sources.redhat.com In-Reply-To: <20080403185832.GB9403@caradoc.them.org> References: <200803271338.24328.vladimir@codesourcery.com> <6D19CA8D71C89C43A057926FE0D4ADAA04290FD3@ecamlmw720.eamcs.ericsson.se> <18412.2657.401216.698985@kahikatea.snap.net.nz> <20080403185832.GB9403@caradoc.them.org> Content-Type: text/plain Date: Thu, 03 Apr 2008 20:05:00 -0000 Message-Id: <1207249792.31772.186.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 (2.10.3-7.fc7) Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-04/txt/msg00077.txt.bz2 On Thu, 2008-04-03 at 14:58 -0400, Daniel Jacobowitz wrote: > On Fri, Mar 28, 2008 at 08:58:09AM +1200, Nick Roberts wrote: > > > DSF only updates varObj that are visible on screen. So currently, it always > > > uses -var-update with a single varObj name (never use *). > > > > Which must mean that there is a round trip to the target for each variable > > object that needs to be updated. > > > > This is sounds similar to the previous discussion about using > > "-var-list-children --all-values". There Daniel stated that "for a lot of > > embedded targets [...] reading memory becomes the dominant time delay". > > > > Can someone give some typical numbers for "round trip time" vs "reading memory" > > time. In my naive understanding of embedded targets, I would have thought the > > "round trip time" might be large due to a slow serial link, while "reading > > memory" wouldn't change much as all RAM is pretty much the same. Or is the > > latter slow because of the time taken to transfer any unneeded extra data back > > to the host? > > Reading memory from the target is usually, in my experience, dominated > by round trip time. There's at least three different round trips > involved: MI frontend to GDB, GDB to debug server, debug server over > hardware probe to the target. Because GDB and the remote protocol > are synchronous, only one memory read can happen at a time, so the > first two always have to wait at least the length of the last one. > A typical USB probe takes between 3ms and 10ms to read memory; that's > just how USB works. I've seen reports that on Windows's USB stack > it's more like 50ms but I haven't confirmed that myself yet. > > For typical use this delay is independent of the amount of memory > you're reading, until it gets very large. Four bytes and four hundred > take about the same time. Only if gdb requests it all in one go. Sometimes it reads it a word at a time... in that case all those round trips can really add up!