From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26491 invoked by alias); 10 Jul 2007 17:14:53 -0000 Received: (qmail 26479 invoked by uid 22791); 10 Jul 2007 17:14:52 -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; Tue, 10 Jul 2007 17:14:48 +0000 Received: from Debian-exim by zigzag.lvk.cs.msu.su with spam-scanned (Exim 4.50) id 1I8JIR-0003F4-2T for gdb-patches@sources.redhat.com; Tue, 10 Jul 2007 21:14:43 +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 1I8JIJ-0003Eq-6C; Tue, 10 Jul 2007 21:14:35 +0400 From: Vladimir Prus To: Nick Roberts Subject: Re: [MI] lvalues and variable_editable Date: Tue, 10 Jul 2007 17:14:00 -0000 User-Agent: KMail/1.9.5 Cc: gdb-patches@sources.redhat.com References: <18048.64048.398970.186217@kahikatea.snap.net.nz> <18066.55213.92057.292881@kahikatea.snap.net.nz> In-Reply-To: <18066.55213.92057.292881@kahikatea.snap.net.nz> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200707102114.31334.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/msg00163.txt.bz2 On Tuesday 10 July 2007 04:49, Nick Roberts wrote: > > > + static int > > > + variable_editable_pv (struct varobj *var) > >=20 > > Can we probably use "varobj_editable_pv". Using > > varobj in some places, and "variable" in others > > makes for confusing code. >=20 > (I meant variable_editable_p.) >=20 > It looks like you renamed type_changeable to varobj_value_is_changeable_p > following Apple's version. I agree that there should be some consistency >=20 > variable_editable_p, variable_changeable_p? >=20 > var_editable_p, var_changeable_p? >=20 > or, probably better >=20 > 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. > > Also, why is_root_p check? It is possible to create varobj for > > an expression the creates rvalue of structure type. The children of=20 > > such varobj won't be lvalues, and won't be editable, but this code > > won't catch this case. >=20 > 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. > > > *************** 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: Assertio= n `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_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. >=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. We should not have any problems, because we never try to get varobj->value for object of struct, union or array type. - Volodya >=20