Re: [MI] lvalues and variable_editable

[Nick Roberts <nickrob@snap.net.nz>]

 > 	(gdb)
 > 	-var-assign F.public.i 10
 > 	&"mi_cmd_var_assign: Could not assign expression to varible object\n"
 > 	^error,msg="mi_cmd_var_assign: Could not assign expression to varible object"
 > 	(gdb)
 > 
 > Clearly, gdb does not like assigning to F.public.i, and I'm pretty sure it's
 > because VALUE_LVAL for that varobj returns false. Naturally, it's reasonable
 > to expect to have F.public.i marked as non-editable, so that frontend won't
 > even let the user to assign a value. I don't think your patch will do that.

OK.  It would be strange to try to edit such variable objects, but I take
your point and will change it (back to it's original set of conditions).

 > 	-var-update F
 > 	^done,changelist=[{name="F",in_scope="true",type_changed="false"}]
 > 	(gdb)
 > 	-var-evaluate-expression F
 > 	^done,value="{void (void)} 0x80483ca <bar()>"
 > 	(gdb)
 > 
 > Note that the current gdb has no problem whatsoever with printing the value
 > of function, and it also notices when a value changes. If you change c_value_of_variable
 > as outlined above, you'll only see "<function>" as output.
 > 
 > > Functions and methods are surely not changeable. 
 > 
 > I think you misunderstand the meaning of varobj_value_is_changeable_p. It
 > does not indicate if the object itself may be changed, by the programming
 > language or by gdb user. It indicates if the value of varobj, as printed by
 > -var-evaluate-expression, may change. As shown above, in current gdb, the
 > value of varobj having type 'function' can change just fine, in a meaningful
 > way.

It shows I misunderstood the concept of the value of a function.  I'll
change that also, which means varobj_editable_p can't be easily derived
from varobj_changeable_p.


-- 
Nick                                           http://www.inet.net.nz/~nickrob