Re: [MI] lvalues and variable_editable

[Nick Roberts <nickrob at snap dot net dot nz>]

 > > varobj_editable_p,  varobj_changeable_p?
 > 
 > This last seems best to me. I think that the "varobj_value_changeable"
 > is more accurate than varobj_changeable, because it specifically means
 > that var->value never changes, but that's probably not important.

OK I'll do this for the patch in question.

 > >  > Also, why is_root_p check? It is possible to create varobj for
 > >  > an expression the creates rvalue of structure type. The children of 
 > >  > such varobj won't be lvalues, and won't be editable, but this code
 > >  > won't catch this case.
 > > 
 > > I'm not sure what you mean by "won't catch this case" but this is in
 > > variable_editable_p which is called by varobj_set_value.  If the user
 > > tries to assign a value to a child this check means GDB won't need to
 > > test if it's not an lvalue.
 > 
 > Well, ideally if I have a varobj for rvalue structure, I want the children
 > of such varobj to be reported as non-editable. It does not seem to happen,
 > IIUC.

Remember that an rvalue may be an lvalue also.  I think you are saying a varobj
with children which aren't lvalues.  How would you create such a varobj?  Note:

int m[10];

(gdb) 
-var-create - * m
^done,name="var1",numchild="10",type="int [10]"
(gdb) 
-var-create - * (float)m
^done,name="var2",numchild="0",type="float"
(gdb) 
-var-create - * 2*m
&"Argument to arithmetic operation not a number or boolean.\n"
^error,msg="Argument to arithmetic operation not a number or boolean."


 > >  > > *************** varobj_value_is_changeable_p (struct var
 > >  > > *** 1819,1837 ****
 > >  > > --- 1822,1842 ----
 > >  > > 
 > >  > > type = get_value_type (var);
 > >  > > 
 > >  > > +
 > >  > > switch (TYPE_CODE (type))
 > >  > > {
 > >  > > case TYPE_CODE_STRUCT:
 > >  > > case TYPE_CODE_UNION:
 > >  > > case TYPE_CODE_ARRAY:
 > >  > > ! ? ? case TYPE_CODE_FUNC:
 > >  > > ! ? ? case TYPE_CODE_METHOD:
 > >  > > ! ? ? ? return 0;
 > >  > 
 > >  > In current gdb, assuming this declaration:
 > >  > 
 > >  >         void (*fp)();
 > >  > 
 > >  > I can create varobj for *fp:
 > >  > 
 > >  >         -var-create V * *fp
 > >  > 
 > >  > and V will be updated if fp changes. With your patch,
 > >  > I get this:
 > >  > 
 > >  >         -var-create V * *fp
 > >  >         ~"varobj.c:2180: internal-error: c_value_of_variable: Assertion `varobj_value_is_changeable_p (var)' failed.\n"
 > >  >         ~"A problem internal to GDB has been detected,\n"
 > >  >         ~"further debugging may prove unreliable.\n"
 > >  >         ~"Quit this debugging session? (y or n) "
 > > 
 > > OK.  I had just thought about fp being TYPE_CODE_PTR.
 > > 
 > >  > So, probably TYPE_CODE_FUNC should be handled in variable_editable_p.
 > >  > I'm not sure about TYPE_CODE_METHOD -- I don't know how to construct
 > >  > an object of that type using any possible expression.
 > > 
 > > That's where they came from.  OK, I'll investigate.  It occurs to me that you
 > > might be create problems with pointers to structs, unions and arrays too.
 > 
 > We should not have any problems, because we never try to get varobj->value
 > for object of struct, union or array type.

Actually now I've looked at it, I think the problem is in c_value_of_variable.
I think there should be an extra clause, something like:


  switch (TYPE_CODE (type))
    {
+    case TYPE_CODE_FUNCTION:
+      return xstrdup ("<function>");
+      /* break; */

and a similar one for TYPE_CODE_METHOD, either here or in
cplus_value_of_variable.  Functions and methods are surely not changeable.

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