From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13860 invoked by alias); 28 Mar 2008 16:33:45 -0000 Received: (qmail 13850 invoked by uid 22791); 28 Mar 2008 16:33:44 -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 16:33:23 +0000 Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id m2SGXHo8029724; Fri, 28 Mar 2008 11:33:17 -0500 Received: from ecamlmw720.eamcs.ericsson.se ([142.133.1.72]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Mar 2008 11:33:17 -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 16:33:00 -0000 Message-ID: <6D19CA8D71C89C43A057926FE0D4ADAA04290FE2@ecamlmw720.eamcs.ericsson.se> In-Reply-To: <200803281921.55277.vladimir@codesourcery.com> From: "Marc Khouzam" To: "Vladimir Prus" Cc: "Nick Roberts" , 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/msg00475.txt.bz2 > > For DSF, which tries to minimize the amount of work done, we can: > >=20 > > 1- use multiple var-update , which typically results in=20 > > about 5 or 6 var-updates being sent (only 5 or 6 variables are=20 > > visible on-screen). Then GDB on the target reads the memory for=20 > > those 5 or 6 varObjs. > >=20 > > 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. > >=20 > > 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. >=20 > 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. I handn't thought of that. Although, this also comes with its own drawback= s. If the user scrolls the variable view, new varObjects will need to be updat= ed, but they will need to be unfrozen first, and the newly hidden ones will need to be frozen. In the end, I think it will end up being more commands than using var-update . With DSF updating only visible varObjs, I think var-update is=20 sufficiently efficient. Marc