From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8317 invoked by alias); 28 Mar 2008 14:32:21 -0000 Received: (qmail 8305 invoked by uid 22791); 28 Mar 2008 14:32:20 -0000 X-Spam-Check-By: sourceware.org Received: from imr1.ericy.com (HELO imr1.ericy.com) (198.24.6.9) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 28 Mar 2008 14:31:42 +0000 Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id m2SEVQ1R025655; Fri, 28 Mar 2008 09:31:34 -0500 Received: from ecamlmw720.eamcs.ericsson.se ([142.133.1.72]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Mar 2008 09:31:34 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: -var-update @ Date: Fri, 28 Mar 2008 14:32:00 -0000 Message-ID: <6D19CA8D71C89C43A057926FE0D4ADAA04290FD9@ecamlmw720.eamcs.ericsson.se> In-Reply-To: <18412.2657.401216.698985@kahikatea.snap.net.nz> From: "Marc Khouzam" To: "Nick Roberts" Cc: "Vladimir Prus" , 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/msg00460.txt.bz2 > > DSF only updates varObj that are visible on screen. So currently, it a= lways > > uses -var-update with a single varObj name (never use *). >=20 > Which must mean that there is a round trip to the target for each variable > object that needs to be updated. >=20 > 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". >=20 > Can someone give some typical numbers for "round trip time" vs "reading m= emory" > time. In my naive understanding of embedded targets, I would have though= t 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 t= he > latter slow because of the time taken to transfer any unneeded extra data= back > to the host? I'm not familiar with such numbers myself, although I would be interested in finding out. However, I wanted to point out that there are currently two possible options for var-update -var-update -var-update * (we'll ignore the new -var-update @, which does not affect the discussion) For DSF, which tries to minimize the amount of work done, we can: 1- use multiple var-update , which typically results in=20 about 5 or 6 var-updates being sent (only 5 or 6 variables are visible on-s= creen). Then GDB on the target reads the memory for those 5 or 6 varObjs. 2- use var-update *, which results in a single -var-update, but which makes GDB on the target read the memory of all varObjects, which can be anywhere from, say, 5 to 5000, or even more. As you can see, option 2 does not scale, irrespective of which is=20 the true bottleneck, the round-trip time, or the target memory access. That is why DSF does not use var-update *. But you are right that less round-trips would be even better. So, to improve option 1, Vladimir's suggestion of a batch -var-update -var-update ... would be better (although DSF is not currently setup for it.) BTW, is there a limit (enforced or recommended) on the number of varObj that can be created? BR, Marc