Re: [PATCH] MI: lvalues and variable_editable

[Vladimir Prus <ghost@cs.msu.su>]

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