From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22570 invoked by alias); 29 Nov 2006 07:25:35 -0000 Received: (qmail 22544 invoked by uid 22791); 29 Nov 2006 07:25:34 -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; Wed, 29 Nov 2006 07:25:28 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GpJom-00076x-2H for gdb-patches@sources.redhat.com; Wed, 29 Nov 2006 08:25:20 +0100 Received: from 73-198.umostel.ru ([82.179.73.198]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 29 Nov 2006 08:25:20 +0100 Received: from ghost by 73-198.umostel.ru with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 29 Nov 2006 08:25:20 +0100 To: gdb-patches@sources.redhat.com From: Vladimir Prus Subject: Re: Variable objects laziness Date: Wed, 29 Nov 2006 07:25:00 -0000 Message-ID: References: <17772.60058.228181.835591@kahikatea.snap.net.nz> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="nextPart4144835.DdPC6r86cQ" Content-Transfer-Encoding: 7Bit User-Agent: KNode/0.10.2 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: 2006-11/txt/msg00368.txt.bz2 --nextPart4144835.DdPC6r86cQ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8Bit Content-length: 1655 Nick Roberts wrote: > > With the new changes to varobj.c, -var-assign doesn't work for references. This is embarrassing. However, it also validates my claim that we should a single invariant-preserving function to assign new value. This crash happens, for all appearances, because varobj_set_value directly sets new value. I've checked in the attached, that fixes the crash, and causes no regressions. I did not add no testcase for this. I've run into some grave reference-related bug reported by KDevelop user (not related to my patch) and is going to fix that, and then add a new test for C++ features. > Also -var-update only reports a change when the address changes and not > the > value. Variable objects were broken before but in a different way > (-var-assign worked but -var-update always reported that the reference > value had changed). Apparently, not reporting a change is worse > > I think a further call to coerce_array is needed No, please no! Calls to coerce_array is exactly the reason for the other bug I'm fixing. This function has a nice property of silently coercing_refs, but that property is not documented, not obvious from function name and therefore should be considered a bug. Here, call to coerce_ref would work. > and the output to > -var-update should look like: > > > -var-update --all-values var1 > ^done,changelist=[{name="var1",value="4",in_scope="true",type_chan > ged="false"}] > > i.e the address shouldn't appear in the value field. Attached (references.diff) is the patch that makes gdb sense the changes in reference values, and eliminates the address from the output. Any opinions? - Volodya --nextPart4144835.DdPC6r86cQ Content-Type: text/x-diff; name="ref_assign.diff" Content-Transfer-Encoding: 8Bit Content-Disposition: attachment; filename="ref_assign.diff" Content-length: 1988 Index: ChangeLog =================================================================== RCS file: /cvs/src/src/gdb/ChangeLog,v retrieving revision 1.7995 diff -u -p -r1.7995 ChangeLog --- ChangeLog 28 Nov 2006 22:21:23 -0000 1.7995 +++ ChangeLog 29 Nov 2006 06:40:51 -0000 @@ -1,3 +1,9 @@ +2006-11-29 Vladimir Prus + + * varobj.c (varobj_set_value): Don't compare the old + and the new value here. Don't assign new value here. + Instead, call install_new_value. + 2006-11-28 Daniel Jacobowitz * regformats/reg-mips64.dat: New file. Index: varobj.c =================================================================== RCS file: /cvs/src/src/gdb/varobj.c,v retrieving revision 1.61 diff -u -p -r1.61 varobj.c --- varobj.c 28 Nov 2006 17:23:09 -0000 1.61 +++ varobj.c 29 Nov 2006 06:40:52 -0000 @@ -841,18 +841,22 @@ varobj_set_value (struct varobj *var, ch array's content. */ value = coerce_array (value); - if (!value_contents_equal (var->value, value)) - var->updated = 1; - /* The new value may be lazy. gdb_value_assign, or rather value_contents, will take care of this. If fetching of the new value will fail, gdb_value_assign with catch the exception. */ if (!gdb_value_assign (var->value, value, &val)) return 0; - value_free (var->value); + release_value (val); - var->value = val; + + /* If the value has changed, record it, so that next -var-update can + report this change. If a variable had a value of '1', we've set it + to '333' and then set again to '1', when -var-update will report this + variable as changed -- because the first assignment has set the + 'updated' flag. There's no need to optimize that, because return value + of -var-update should be considered an approximation. */ + var->updated = install_new_value (var, val, 0 /* Compare values. */); input_radix = saved_input_radix; return 1; } --nextPart4144835.DdPC6r86cQ--