From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13751 invoked by alias); 22 Jan 2008 16:38:49 -0000 Received: (qmail 13741 invoked by uid 22791); 22 Jan 2008 16:38:49 -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; Tue, 22 Jan 2008 16:38:20 +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 m0MGcI40026796 for ; Tue, 22 Jan 2008 10:38:18 -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 10:38:18 -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 16:38:00 -0000 Message-ID: <6D19CA8D71C89C43A057926FE0D4ADAA04290E4A@ecamlmw720.eamcs.ericsson.se> In-Reply-To: <20080122150232.GA32509@caradoc.them.org> From: "Marc Khouzam" To: 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/msg00525.txt.bz2 > I think there are actually two different problems: >=20 > 1. Given single varobj that is displayed in one format, how does one > one if the value is "really changed". The answer here is that you don't > get to find that -- -var-update reports only changes in displayed > value, and since changing format is fast, nothing else is needed here. Ok. > 2. If UI wishes to show varobj in several formats, how does it > figure out of *any* of formats has changed. There are two possible > solutions: >=20 > (a) Always keep varobj (from frontnend) in natural format, and assume= =20 > that if natural format changes, all values possibly change. In this > case, getting a value in different format will involve switching > to that format and then switching back. That is what I will do. If it is the best thing for GDB to make this a requirement for a frontend t= hat wants to show mutliple formats, may I suggest that it be added to the documentation of var-update? A short mention that "if a frontend wants to be notified of a change in any format, it should keep the variable object in the natural format". Also, if GDB requires this of frontends showing mutliple formats, it would be nice to have -var-evaluate-expression take a format as an optional parameter. Then, the frontend would not need to use -var-set-format to get a different formatted value, and could keep the variable object in the natural format at all times. I can provide a patch if this is a supported idea. > (b) Allow a varobj to have a *list* formats to show. Make > -var-update check all formats, make -var-evaluate-expression > return all formats. >=20 This seems cumbersome to me and will provide superfluous information for case 1 above.