This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] MI: lvalues and variable_editable
On Tuesday 30 October 2007 14:04:53 Nick Roberts wrote:
> > I believe that var->value will be NULL.
>
> Yes, that looks good. I'll use:
>
> if (!var->value || !VALUE_LVAL(var->value))
> return 0;
>
> and that should keep us both happy.
As long there which code *replaces* gdb_evaluate_expression, I'm
perfectly happy. Thanks!
> > GDB,
> > as it stands, allows you to create a variable object in any frame, and your
> > patch does not work with that. So, either creating variable objects in any
> > frame should be disallowed,
>
> Actually I think that would be a good idea. Generally a user would create a
> watch expression in the frame he's examining. If not, the frontend would have
> to prompt for the frame. Does KDevelop do this?
At the moment, KDevelop does not have any command that would create varobj
in non-current frame (although it's possible to create varobj in one frame,
and then assign to it while the current frame is different).
Daniel Jacobowitz later wrote:
> > Actually I think that would be a good idea. Generally a user would
> > create a watch expression in the frame he's examining. If not, the
> > frontend would have to prompt for the frame. Does KDevelop do this?
>
> If you have a GUI with a stack pane, it may be showing a lot of frames
> at once. Why force the front end to select a frmae before creating
> the varobj?
Yeah. For example, if stack widgets shows variables it would be quite
reasonable to allow expanding a variable, and creating varobj for
some nested field, and there's no need to switch frames.
(The problem with switching frames is that GUI and gdb will be temporary
out-of-sync, and generally all cases where GUI and gdb are out of sync
lead to bugs).
- Volodya