From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4597 invoked by alias); 3 Apr 2008 18:58:55 -0000 Received: (qmail 4589 invoked by uid 22791); 3 Apr 2008 18:58:54 -0000 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 03 Apr 2008 18:58:35 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id D94D2983BE; Thu, 3 Apr 2008 18:58:33 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id 8E25098278; Thu, 3 Apr 2008 18:58:33 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1JhUds-0002mA-Q0; Thu, 03 Apr 2008 14:58:32 -0400 Date: Thu, 03 Apr 2008 19:31:00 -0000 From: Daniel Jacobowitz To: Nick Roberts Cc: Marc Khouzam , Vladimir Prus , gdb-patches@sources.redhat.com Subject: Re: -var-update @ Message-ID: <20080403185832.GB9403@caradoc.them.org> Mail-Followup-To: Nick Roberts , Marc Khouzam , Vladimir Prus , gdb-patches@sources.redhat.com References: <200803271338.24328.vladimir@codesourcery.com> <6D19CA8D71C89C43A057926FE0D4ADAA04290FD3@ecamlmw720.eamcs.ericsson.se> <18412.2657.401216.698985@kahikatea.snap.net.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <18412.2657.401216.698985@kahikatea.snap.net.nz> User-Agent: Mutt/1.5.17 (2007-12-11) 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/msg00076.txt.bz2 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. -- Daniel Jacobowitz CodeSourcery