From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26904 invoked by alias); 4 May 2006 12:10:37 -0000 Received: (qmail 26887 invoked by uid 22791); 4 May 2006 12:10:35 -0000 X-Spam-Check-By: sourceware.org Received: from zigzag.lvk.cs.msu.su (HELO zigzag.lvk.cs.msu.su) (158.250.17.23) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 04 May 2006 12:10:33 +0000 Received: from Debian-exim by zigzag.lvk.cs.msu.su with spam-scanned (Exim 4.50) id 1Fbcf6-0003yd-El for gdb-patches@sources.redhat.com; Thu, 04 May 2006 16:10:30 +0400 Received: from zigzag.lvk.cs.msu.su ([158.250.17.23]) by zigzag.lvk.cs.msu.su with esmtp (Exim 4.50) id 1Fbcev-0003nE-1z; Thu, 04 May 2006 16:10:17 +0400 From: Vladimir Prus To: Nick Roberts Subject: Re: Variable objects: references formatting Date: Thu, 04 May 2006 12:10:00 -0000 User-Agent: KMail/1.7.2 Cc: gdb-patches@sources.redhat.com References: <17497.14121.225320.477428@farnswood.snap.net.nz> <200605041100.09748.ghost@cs.msu.su> <17497.43822.261192.673547@farnswood.snap.net.nz> In-Reply-To: <17497.43822.261192.673547@farnswood.snap.net.nz> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200605041610.16153.ghost@cs.msu.su> Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-05/txt/msg00041.txt.bz2 On Thursday 04 May 2006 11:20, Nick Roberts wrote: > > Again, maybe you can provide specific case where this error is produced? > > If it affect real-world cases we'd better fix it soon. > > It happens when I debug Emacs but I can't provide a simple case yet. > However, do you see the problem with references that I mentioned earlier > (that they don't seem to disappear from the changelist with -var-update)? > This seems to be the case for any variable object made from a reference. Yes, I see that for variable object created from reference, -var-update * always mentions that. Looking at this under debugger, it seems that the call to my_value_equal in varobj_update compares the value of *reference* to the value of new *referenced-to* object. This happens in my_value_equal (varobj.c): static int my_value_equal (struct value *val1, struct value *volatile val2, int *error2) { /* Make sure we also know the contents of VAL2. */ val2 = coerce_array (val2); Before this call, val2 is the value of reference itself. After this call, it has value of referenced-to object. val1, on the other hand, is still the value of reference. I'm not sure what's the point of that call is, and importantly, I'm not sure what would be the right behaviour. Variable object corresponding to reference can be reported as updated either when: (1) The referenced-to value changes (2) The value of reference changes itself (3) Both I think that (1) is the right solution since in C++ reference can't change value, and change of reference value in gdb can be only when reference goes into scope or goes out of scope, so we're never interested in the value of reference itself. In fact, both Eclipse and KDevelop hide the reference value in its displays. If (1) is what we need, there should be extra call to 'coerce_array' for 'val1'. In fact, that call should probably be done when varobj is first created. Alas, quick attempt to do that results in segfault, and I'm out of time for today. Feel free to beat me to it ;-) - Volodya