From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4692 invoked by alias); 11 Jul 2007 06:46:06 -0000 Received: (qmail 4680 invoked by uid 22791); 11 Jul 2007 06:46:05 -0000 X-Spam-Check-By: sourceware.org Received: from zigzag.lvk.cs.msu.su (HELO zigzag.lvk.cs.msu.su) (158.250.17.23) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 11 Jul 2007 06:46:01 +0000 Received: from Debian-exim by zigzag.lvk.cs.msu.su with spam-scanned (Exim 4.50) id 1I8VxV-0006Gj-Dv for gdb-patches@sources.redhat.com; Wed, 11 Jul 2007 10:45:58 +0400 Received: from localhost ([127.0.0.1] helo=ip6-localhost) by zigzag.lvk.cs.msu.su with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1I8VxM-0006GT-WD; Wed, 11 Jul 2007 10:45:49 +0400 From: Vladimir Prus To: Nick Roberts Subject: Re: [MI] lvalues and variable_editable Date: Wed, 11 Jul 2007 06:46:00 -0000 User-Agent: KMail/1.9.5 Cc: gdb-patches@sources.redhat.com References: <18048.64048.398970.186217@kahikatea.snap.net.nz> <200707102114.31334.ghost@cs.msu.su> <18068.12759.961280.457617@kahikatea.snap.net.nz> In-Reply-To: <18068.12759.961280.457617@kahikatea.snap.net.nz> MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_byHlGdH1zrXtOMf" Message-Id: <200707111045.47111.ghost@cs.msu.su> 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: 2007-07/txt/msg00169.txt.bz2 --Boundary-00=_byHlGdH1zrXtOMf Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-length: 5663 On Wednesday 11 July 2007 05:26, Nick Roberts wrote: > > Well, ideally if I have a varobj for rvalue structure, I want the chil= dren > > of such varobj to be reported as non-editable. It does not seem to hap= pen, > > IIUC. >=20 > Remember that an rvalue may be an lvalue also.=20=20 I'm not sure what you mean. Technically, lvalue can be converted to rvalue (per section 4.1 of the C++ standard). As a practical matter, however, each expression is either assignable-to, or non-assignable > I think you are saying a varobj=20 > with children which aren't lvalues. How would you create such a varobj? = Note: Consider the attached program. Then consider this session: (gdb) b main ........ (gdb) r .........=09 (gdb) -var-create F * return_foo() ^done,name=3D"F",numchild=3D"1",type=3D"foo" (gdb) -var-list-children F ^done,numchild=3D"1",children=3D[child=3D{name=3D"F.public",exp=3D"public"= ,numchild=3D"2"}] (gdb) -var-list-children F.public ^done,numchild=3D"2",children=3D[child=3D{name=3D"F.public.i",exp=3D"i",nu= mchild=3D"0",type=3D"int"},child=3D{name=3D"F.public.j",exp=3D"j",numchild= =3D"0",type=3D"int"}] (gdb) -var-assign F.public.i 10 &"mi_cmd_var_assign: Could not assign expression to varible object\n" ^error,msg=3D"mi_cmd_var_assign: Could not assign expression to varible ob= ject" (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.p= ublic.i marked as non-editable, so that frontend won't even let the user to assign a value. I don't think y= our patch will do that. It should be noted that update of F, above, is broken, but it's broken in a= n unrelated way. > > > > > *************** varobj_value_is_changeable_p (struct var > > > > > *** 1819,1837 **** > > > > > --- 1822,1842 ---- > > > > >=20 > > > > > type =3D get_value_type (var); > > > > >=20 > > > > > + > > > > > switch (TYPE_CODE (type)) > > > > > { > > > > > case TYPE_CODE_STRUCT: > > > > > case TYPE_CODE_UNION: > > > > > case TYPE_CODE_ARRAY: > > > > > ! =A0 =A0 case TYPE_CODE_FUNC: > > > > > ! =A0 =A0 case TYPE_CODE_METHOD: > > > > > ! =A0 =A0 =A0 return 0; > > > >=20 > > > > In current gdb, assuming this declaration: > > > >=20 > > > > void (*fp)(); > > > >=20 > > > > I can create varobj for *fp: > > > >=20 > > > > -var-create V * *fp > > > >=20 > > > > and V will be updated if fp changes. With your patch, > > > > I get this: > > > >=20 > > > > -var-create V * *fp > > > > ~"varobj.c:2180: internal-error: c_value_of_variable: Ass= ertion `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) " > > >=20 > > > OK. I had just thought about fp being TYPE_CODE_PTR. > > >=20 > > > > So, probably TYPE_CODE_FUNC should be handled in variable_editabl= e_p. > > > > I'm not sure about TYPE_CODE_METHOD -- I don't know how to constr= uct > > > > an object of that type using any possible expression. > > >=20 > > > 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. > >=20 > > We should not have any problems, because we never try to get varobj->v= alue > > for object of struct, union or array type. >=20 > Actually now I've looked at it, I think the problem is in c_value_of_vari= able. > I think there should be an extra clause, something like: >=20 >=20 > switch (TYPE_CODE (type)) > { > + case TYPE_CODE_FUNCTION: > + return xstrdup (""); > + /* break; */ >=20 > and a similar one for TYPE_CODE_METHOD, either here or in > cplus_value_of_variable.=20=20 Such a change will be regression from the current behaviour. Consider the a= ttached program and the following session: (gdb) b main ..... (gdb) r .... (gdb) n &"n\n" ~"8\t fp =3D bar;\n" ^done (gdb) -var-create F * *fp ^done,name=3D"F",numchild=3D"0",type=3D"void (void)" (gdb) -var-evaluate-expression F ^done,value=3D"{void (void)} 0x80483c4 " (gdb) next &"next\n" ~"9\t return 0;\n" ^done (gdb) -var-update F ^done,changelist=3D[{name=3D"F",in_scope=3D"true",type_changed=3D"false"}] (gdb) -var-evaluate-expression F ^done,value=3D"{void (void)} 0x80483ca " (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_valu= e_of_variable as outlined above, you'll only see "" as output. > Functions and methods are surely not changeable.=20 I think you misunderstand the meaning of varobj_value_is_changeable_p. It d= oes not indicate if the object itself may be changed, by the programming language o= r 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. If you make gdb print "" for objects of function type, then clear= ly the value cannot change, and varobj_value_is_changrable_p can return true for functions. However, I don't see any reason why printing "" for object of function type would be better than the current situation. I furth= er suspect that "*f" above will be rvalue, so it will be reported as non-editable by y= our patch anyway. - Volodya --Boundary-00=_byHlGdH1zrXtOMf Content-Type: text/x-c++src; charset="iso-8859-1"; name="rvalue.cpp" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="rvalue.cpp" Content-length: 184 int i = 0; struct foo { int i; int j; }; foo return_foo () { struct foo f = { i, i+1}; return f; } int main() { i = 1; i = 2; i = 3; i = 4; return 0; } --Boundary-00=_byHlGdH1zrXtOMf Content-Type: text/x-c++src; charset="iso-8859-1"; name="fp.cpp" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="fp.cpp" Content-length: 96 void foo() {} void bar() {} int main() { void (*fp)() = foo; fp = bar; return 0; } --Boundary-00=_byHlGdH1zrXtOMf--