From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24663 invoked by alias); 10 Jul 2007 00:49:59 -0000 Received: (qmail 24654 invoked by uid 22791); 10 Jul 2007 00:49:58 -0000 X-Spam-Check-By: sourceware.org Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.8) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 10 Jul 2007 00:49:56 +0000 Received: from kahikatea.snap.net.nz (216.61.255.123.dynamic.snap.net.nz [123.255.61.216]) by viper.snap.net.nz (Postfix) with ESMTP id 171B33D9B1A; Tue, 10 Jul 2007 12:49:52 +1200 (NZST) Received: by kahikatea.snap.net.nz (Postfix, from userid 1000) id C9C0F8FBF6; Tue, 10 Jul 2007 12:49:49 +1200 (NZST) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <18066.55213.92057.292881@kahikatea.snap.net.nz> Date: Tue, 10 Jul 2007 00:49:00 -0000 To: Vladimir Prus Cc: gdb-patches@sources.redhat.com Subject: Re: [MI] lvalues and variable_editable In-Reply-To: References: <18048.64048.398970.186217@kahikatea.snap.net.nz> <18065.52462.459675.416595@kahikatea.snap.net.nz> X-Mailer: VM 7.19 under Emacs 22.1.50.12 X-IsSubscribed: yes 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/msg00158.txt.bz2 > > + 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. (I meant variable_editable_p.) 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 variable_editable_p, variable_changeable_p? var_editable_p, var_changeable_p? or, probably better varobj_editable_p, varobj_changeable_p? > > + { > > + =A0 struct expression *exp; > > + =A0 struct value *value; > > + > > + =A0 if (CPLUS_FAKE_CHILD (var)) > > + =A0 =A0 return 0; > > + > > + =A0 if (is_root_p (var)) > > + =A0 =A0 { > > + =A0 =A0 =A0 if (!gdb_evaluate_expression (var->root->exp, &value)) > > + =A0=A0=A0=A0=A0=A0{ > > + =A0=A0=A0=A0=A0=A0 =A0/* We cannot proceed without a valid expressio= n. */ > > + =A0=A0=A0=A0=A0=A0 =A0xfree (exp); > > + =A0=A0=A0=A0=A0=A0 =A0return 0; > > + =A0=A0=A0=A0=A0=A0} >=20 > Why do you evaluate this? The expression should already be > evaluated when creating varobj. So, using var->value should > be sufficient. I've already replied to Daniel on this 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=20 > 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. >=20 > > *************** 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: 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 y= ou might be create problems with pointers to structs, unions and arrays too. --=20 Nick http://www.inet.net.nz/~nick= rob