From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32019 invoked by alias); 22 Jan 2008 14:43:57 -0000 Received: (qmail 32007 invoked by uid 22791); 22 Jan 2008 14:43:56 -0000 X-Spam-Check-By: sourceware.org Received: from imr2.ericy.com (HELO imr2.ericy.com) (198.24.6.3) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 22 Jan 2008 14:43:25 +0000 Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id m0MEhMUM008365; Tue, 22 Jan 2008 08:43:23 -0600 Received: from ecamlmw720.eamcs.ericsson.se ([142.133.1.72]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Jan 2008 08:43:22 -0600 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: [Patch] Fix for -var-update to use natural format to compare Date: Tue, 22 Jan 2008 14:43:00 -0000 Message-ID: <6D19CA8D71C89C43A057926FE0D4ADAA04290E42@ecamlmw720.eamcs.ericsson.se> In-Reply-To: <20080122035325.GA28748@caradoc.them.org> From: "Marc Khouzam" To: "Daniel Jacobowitz" Cc: 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-01/txt/msg00521.txt.bz2 > > It modifies the variable object code to always uses the natural format = to compare=20 > > old and new values for the -var-update command (one line change). > > It also renames the member print_value of varobj to natural_value. >=20 > I don't think this is an appropriate change. >=20 > -var-update is supposed to tell when the displayed value has changed. > If the value in the current format hasn't changed, there's no need to > refetch.=20=20 This is assuming the frontend only displays a single value. In DSF, we (sometimes) display all values at once. Can be nice for the use= r. > why do you want to keep track of the value in > all formats? And if you're actually displaying them all > simultaneously to the user, why shouldn't they be independent varobjs? Independent varObjects would work. However every time the program stops the frontend will need to issue a var-update on five objects instead of one, and what is worse is that GDB will need to read the memory from the target five times instead of once. This is less efficient than the frontend forcing GDB to use natural format (see below.) You can refer to http://sourceware.org/ml/gdb/2008-01/msg00175.html where you had agreed with me :-) One solution is the patch I suggested. An alternative suggestion that would support both use cases, was to have an extra flag to var-update.=20=20 Something like [--content-changed | --last-display-value-changed] It would be a separate flag than the --no-values one. The front-end could then decide which behavior it wants.=20 Although, and I can understand, adding this new flag did not seem too popular. To be honest, I will have to support GDB 6.7 anyway, so I will need to work around this by myself, no matter what. What I will do is that every time I issue a var-set-format and an evaluate-expression, I will follow it by another var-set-format to natural to keep all variable objects to the natural format. This will force GDB to use the natural format for its var-update comparison. I just thought that GDB would want to support frontends that display more than one format at once. Thanks Marc