From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3620 invoked by alias); 22 Jan 2008 15:35:26 -0000 Received: (qmail 3609 invoked by uid 22791); 22 Jan 2008 15:35:26 -0000 X-Spam-Check-By: sourceware.org Received: from main.gmane.org (HELO ciao.gmane.org) (80.91.229.2) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 22 Jan 2008 15:34:55 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JHL9E-0005fI-LD for gdb-patches@sources.redhat.com; Tue, 22 Jan 2008 15:34:48 +0000 Received: from 77.246.241.246 ([77.246.241.246]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 22 Jan 2008 15:34:48 +0000 Received: from vladimir by 77.246.241.246 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 22 Jan 2008 15:34:48 +0000 To: gdb-patches@sources.redhat.com From: Vladimir Prus Subject: Re: [Patch] Fix for -var-update to use natural format to compare Date: Tue, 22 Jan 2008 15:35:00 -0000 Message-ID: References: <20080122035325.GA28748@caradoc.them.org> <6D19CA8D71C89C43A057926FE0D4ADAA04290E42@ecamlmw720.eamcs.ericsson.se> <20080122150232.GA32509@caradoc.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit User-Agent: KNode/0.10.5 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-01/txt/msg00524.txt.bz2 Daniel Jacobowitz wrote: > On Tue, Jan 22, 2008 at 09:43:21AM -0500, Marc Khouzam wrote: >> You can refer to http://sourceware.org/ml/gdb/2008-01/msg00175.html >> where you had agreed with me :-) > > That's what happens when the thread goes on too long :-) > > Here's the problem, as I see it. There are two different reasonable > definitions of "varobj has changed". One is that the textual > representation has changed. The other is that the underlying bytes > have changed. > > We used to check the underlying bytes. This was a problem because the > textual representation for a "char *" includes more bytes than the > value, for C-like languages. So, as Nick mentioned last week, we > would not detect a change from "GNU" to "GDB" in a "char *", but we > would display the "GNU" string in -var-evaluate-expression. > > We switched to checking the string representation. But if you're > looking in lots of formats, then this is not enough. > > We could check in all supported formats; check in the natural format; > or go back to checking the underlying bytes. Checking in the natural > format is appealing because it's efficient. But does the natural > format always capture changes in any of the other formats? We don't know. In particular, because we haven't yet fully implemented Python-based custom formatting of things, so we're not sure how that work and interact with traditional formats. Specifically, suppose there a command that specifies Python function used to compute string representation of a value. In that case, 'natural' format in the current meaning might not change while string representation return by the Python code changes. I think there are actually two different problems: 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. 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: (a) Always keep varobj (from frontnend) in natural format, and assume 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. (b) Allow a varobj to have a *list* formats to show. Make -var-update check all formats, make -var-evaluate-expression return all formats. Now (a) can be done either on frontend side, or on gdb side (by making comparisons use naturally formatted string). I suspect that the frontend side is better here, since very few frontends regularly show same value in several formats. - Volodya - Volodya