From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15964 invoked by alias); 22 Jan 2008 15:03:09 -0000 Received: (qmail 15951 invoked by uid 22791); 22 Jan 2008 15:03:07 -0000 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 22 Jan 2008 15:02:36 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 2B0AD98375; Tue, 22 Jan 2008 15:02:34 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id CBEB798216; Tue, 22 Jan 2008 15:02:33 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.68) (envelope-from ) id 1JHKe0-0000CG-Su; Tue, 22 Jan 2008 10:02:32 -0500 Date: Tue, 22 Jan 2008 15:03:00 -0000 From: Daniel Jacobowitz To: Marc Khouzam Cc: gdb-patches@sources.redhat.com Subject: Re: [Patch] Fix for -var-update to use natural format to compare Message-ID: <20080122150232.GA32509@caradoc.them.org> Mail-Followup-To: Marc Khouzam , gdb-patches@sources.redhat.com References: <20080122035325.GA28748@caradoc.them.org> <6D19CA8D71C89C43A057926FE0D4ADAA04290E42@ecamlmw720.eamcs.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6D19CA8D71C89C43A057926FE0D4ADAA04290E42@ecamlmw720.eamcs.ericsson.se> User-Agent: Mutt/1.5.17 (2007-12-11) 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/msg00522.txt.bz2 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? -- Daniel Jacobowitz CodeSourcery