This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [MI] lvalues and variable_editable
- From: Vladimir Prus <ghost at cs dot msu dot su>
- To: Nick Roberts <nickrob at snap dot net dot nz>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Tue, 10 Jul 2007 21:14:30 +0400
- Subject: Re: [MI] lvalues and variable_editable
- References: <18048.64048.398970.186217@kahikatea.snap.net.nz> <f6tc8l$ccc$1@sea.gmane.org> <18066.55213.92057.292881@kahikatea.snap.net.nz>
On Tuesday 10 July 2007 04:49, Nick Roberts wrote:
> > > + 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.
>
> (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?
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
> > 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.
> > > *************** 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.
- Volodya
>