This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [MI] lvalues and variable_editable
> (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