From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19780 invoked by alias); 9 Jul 2007 13:13:17 -0000 Received: (qmail 19771 invoked by uid 22791); 9 Jul 2007 13:13:16 -0000 X-Spam-Check-By: sourceware.org Received: from main.gmane.org (HELO ciao.gmane.org) (80.91.229.2) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 09 Jul 2007 13:13:14 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1I7t32-00056o-EN for gdb-patches@sources.redhat.com; Mon, 09 Jul 2007 15:13:04 +0200 Received: from 241-246.umostel.ru ([77.246.241.246]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 09 Jul 2007 15:13:04 +0200 Received: from ghost by 241-246.umostel.ru with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 09 Jul 2007 15:13:04 +0200 To: gdb-patches@sources.redhat.com From: Vladimir Prus Subject: Re: [MI] lvalues and variable_editable Date: Mon, 09 Jul 2007 13:13:00 -0000 Message-ID: References: <18048.64048.398970.186217@kahikatea.snap.net.nz> <18065.52462.459675.416595@kahikatea.snap.net.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8Bit User-Agent: KNode/0.10.2 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/msg00147.txt.bz2 Nick Roberts wrote: > --- 1747,1752 ---- > *************** value_get_print_value (struct value *val > *** 1799,1804 **** > --- 1778,1808 ---- > return thevalue; > } > > + > + static int > + variable_editable_pv (struct varobj *var) Can we probably use "varobj_editable_pv". Using varobj in some places, and "variable" in others makes for confusing code. > + { > +   struct expression *exp; > +   struct value *value; > + > +   if (CPLUS_FAKE_CHILD (var)) > +     return 0; > + > +   if (is_root_p (var)) > +     { > +       if (!gdb_evaluate_expression (var->root->exp, &value)) > +       { > +         /* We cannot proceed without a valid expression. */ > +         xfree (exp); > +         return 0; > +       } Why do you evaluate this? The expression should already be evaluated when creating varobj. So, using var->value should be sufficient. 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. > *************** 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) " 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. - Volodya