From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14241 invoked by alias); 27 Mar 2008 20:58:41 -0000 Received: (qmail 14229 invoked by uid 22791); 27 Mar 2008 20:58:40 -0000 X-Spam-Check-By: sourceware.org Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.8) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 27 Mar 2008 20:58:15 +0000 Received: from kahikatea.snap.net.nz (100.31.255.123.static.snap.net.nz [123.255.31.100]) by viper.snap.net.nz (Postfix) with ESMTP id BBF863DA55B; Fri, 28 Mar 2008 09:58:11 +1300 (NZDT) Received: by kahikatea.snap.net.nz (Postfix, from userid 1000) id 3014D8FC6D; Fri, 28 Mar 2008 08:58:10 +1200 (NZST) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18412.2657.401216.698985@kahikatea.snap.net.nz> Date: Thu, 27 Mar 2008 20:58:00 -0000 To: "Marc Khouzam" Cc: "Vladimir Prus" , Subject: RE: -var-update @ In-Reply-To: <6D19CA8D71C89C43A057926FE0D4ADAA04290FD3@ecamlmw720.eamcs.ericsson.se> References: <200803271338.24328.vladimir@codesourcery.com> <6D19CA8D71C89C43A057926FE0D4ADAA04290FD3@ecamlmw720.eamcs.ericsson.se> X-Mailer: VM 7.19 under Emacs 22.1.92.3 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-03/txt/msg00455.txt.bz2 > 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? -- Nick http://www.inet.net.nz/~nickrob