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