From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8164 invoked by alias); 28 Mar 2008 16:22:59 -0000 Received: (qmail 7912 invoked by uid 22791); 28 Mar 2008 16:22:58 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 28 Mar 2008 16:22:32 +0000 Received: (qmail 12371 invoked from network); 28 Mar 2008 16:22:30 -0000 Received: from unknown (HELO localhost) (vladimir@127.0.0.2) by mail.codesourcery.com with ESMTPA; 28 Mar 2008 16:22:30 -0000 From: Vladimir Prus To: "Marc Khouzam" Subject: Re: -var-update @ Date: Fri, 28 Mar 2008 16:22:00 -0000 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) Cc: "Nick Roberts" , gdb-patches@sources.redhat.com References: <6D19CA8D71C89C43A057926FE0D4ADAA04290FD9@ecamlmw720.eamcs.ericsson.se> In-Reply-To: <6D19CA8D71C89C43A057926FE0D4ADAA04290FD9@ecamlmw720.eamcs.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200803281921.55277.vladimir@codesourcery.com> 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/msg00472.txt.bz2 On Friday 28 March 2008 17:31:33 Marc Khouzam 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? > > 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 > about 5 or 6 var-updates being sent (only 5 or 6 variables are visible on-screen). > 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 > the true bottleneck, the round-trip time, or the target memory access. You can freeze variable objects that are not visible to the user, and -var-update * won't fetch those. Please see the -var-set-frozen command. > 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? There's no hard limit. The practical limit depends on target and can only be found empirically. - Volodya