BUG: MI reporting wrong attributes for casted variables

Assume a variable like

unsigned int myValue;

It is possible to create a casted MI variable like

1096-var-create - * (int)myValue
1096^done,name="var4",numchild="0",value
="0",type="int"

GDB reports this to be an editable variable:

1097-var-show-attributes var4
1097^done,attr="editable"

But in fact, it is not. GDB does not allow assiging values
to casted
variables. So GDB should not report this to be editable.

1100-var-assign var4 1
1100^error,msg="mi_cmd_var_assign: Could not assign
expression to varible
object"

This bug is causing trouble in Eclipse CDT because casted
vars show up as
editable when they are not.

GDB Snapshot from around 26.5.2007.

Sascha

 > unsigned int myValue;
 > 
 > It is possible to create a casted MI variable like
 > 
 > 1096-var-create - * (int)myValue
 >
1096^done,name="var4",numchild="0",value
="0",type="int"
 > 
 > GDB reports this to be an editable variable:
 > 
 > 1097-var-show-attributes var4
 > 1097^done,attr="editable"
 > 
 > But in fact, it is not. GDB does not allow assiging
values to casted
 > variables. So GDB should not report this to be
editable.
 > 
 > 1100-var-assign var4 1
 > 1100^error,msg="mi_cmd_var_assign: Could not
assign expression to varible
 > object"
 > 
 > This bug is causing trouble in Eclipse CDT because
casted vars show up as
 > editable when they are not.
 > 
 > GDB Snapshot from around 26.5.2007.

Report it as a bug to the Eclipse CDT team.  They have
misinterpreted the
meaning of the "editable" attribute.

This has been reported at leasted once before, possibly by
you (or at least
another Sascha using Eclipse CDT) when I said:

  The fact that the var has the attribute
"editable" is a bit of a red herring.
  A value can't be assigned because (int)myValue isn't an
lvalue.  You get the
  same error if you do:

  -var-create - * 2*myValue
 
^done,name="var36",numchild="0",value=&q
uot;2",type="int"

  -var-assign var36 0x1234

  I think it only makes sense to watch such values.

Having said all that, I think we should add another field
"lvalue" or
"unassignable", say, to the output of
-var-show-attributes so that IDE's
like Eclipse can determine which variables can be assigned a
value.

-- 
Nick                                           http://www.inet.net.n
z/~nickrob

On Fri, Jun 22, 2007 at 08:17:39AM +1200, Nick Roberts
wrote:
> Report it as a bug to the Eclipse CDT team.  They have
misinterpreted the
> meaning of the "editable" attribute.
> 
> This has been reported at leasted once before, possibly
by you (or at least
> another Sascha using Eclipse CDT) when I said:

And also by Vladimir, two years ago.  What is the use of the
current
"editable" attribute?  I don't see anything in the
manual that would
conflict with changing it.

-- 
Daniel Jacobowitz
CodeSourcery

Daniel Jacobowitz writes:
 > On Fri, Jun 22, 2007 at 08:17:39AM +1200, Nick Roberts
wrote:
 > > Report it as a bug to the Eclipse CDT team.  They
have misinterpreted the
 > > meaning of the "editable" attribute.
 > > 
 > > This has been reported at leasted once before,
possibly by you (or at least
 > > another Sascha using Eclipse CDT) when I said:
 > 
 > And also by Vladimir, two years ago.  What is the use
of the current
 > "editable" attribute?  I don't see anything
in the manual that would
 > conflict with changing it.

Actually looking at the manual, rather than the code, it
looks like this
might have been the intended meaning:

  The `-var-assign' Command
  -------------------------

  Synopsis
  ........

        -var-assign NAME EXPRESSION

     Assigns the value of EXPRESSION to the variable object
specified by
  NAME.  The object must be `editable'.  If the variable's
value is
                             ^^^^^^^^
  altered by the assign, the variable will show up in any
subsequent
  `-var-update' list.

So if you mean add this case to the existing ones, that
seems reasonable.
It would make redisplay faster if this field was added to
the output
of -var-create and -var-list-children.  This is probably
especially
important for remote targets.

Incidentally, I find it strange that GDB can assign values
to constant types:


const i21 = 5;


-var-create - * i21
^done,name="var1",numchild="0",value=&qu
ot;5",type="const int"
(gdb) 
-var-assign var1 9
^done,value="9"
(gdb)

-- 
Nick                                           http://www.inet.net.n
z/~nickrob

>Report it as a bug to the Eclipse CDT team.  They have
misinterpreted 
>the meaning of the "editable" attribute.

>This has been reported at leasted once before, possibly
by you (or at 
>least another Sascha using Eclipse CDT) when I said:

It was me. I was busy doing other stuff and I first wanted
to have a look at
the eclipse code. It is possible to change the Eclipse CDT
code so casted
vars won't be editable. But then I thought this was more
likely a GDB bug
and it would make sense to resolve the root problem. 

>Assigns the value of EXPRESSION to the variable object
specified by
>  NAME.  The object must be `editable'.  If the
variable's value is

I think this is pretty much what the CDT guys had in mind.
They expect a var
object to be editable when it has been reported as...
"editable" .


Sascha

 > >Assigns the value of EXPRESSION to the variable
object specified by
 > >  NAME.  The object must be `editable'.  If the
variable's value is
 > 
 > I think this is pretty much what the CDT guys had in
mind. They expect a var
 > object to be editable when it has been reported as...
"editable" .

Yes, but I still don't really understand when a user would
try to change the
value of a cast of a variable.  I would have thought that if
you're making the
cast then you're intending just to watch it's value.

-- 
Nick                                           http://www.inet.net.n
z/~nickrob

>Yes, but I still don't really understand when a user
would try to change
>the value of a cast of a variable.  I would have thought
that if you're
>making the cast then you're intending just to watch it's
value.

In Eclipse CDT it is not always obvious which variables have
been casted to
a different type. So the user might assign a value and all
he gets is a
cryptic error message (cannot assign to variable object, or
something like
that).

Anyway, I just made a change to the CDT code so type casted
variables are no
longer editable. This bug has low priority. Maybe the
behavior of GDB can be
changed in the future, so that only editable vars will have
the "editable"
attribute.

Sascha