BUG: MI reporting wrong attributes for casted variables

BUG: MI reporting wrong attributes for casted variables

[Srrr]

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

Re: BUG: MI reporting wrong attributes for casted variables

[Nick Roberts]

 > 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="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.nz/~nickrob

Re: BUG: MI reporting wrong attributes for casted variables

[Daniel Jacobowitz]

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

Re: BUG: MI reporting wrong attributes for casted variables

[Nick Roberts]

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="5",type="const int"
(gdb) 
-var-assign var1 9
^done,value="9"
(gdb)

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: BUG: MI reporting wrong attributes for casted variables

[Vladimir Prus]

Nick Roberts wrote:

> 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
>                              ^^^^^^^^

I agree that currently, 'editable' is not particularly useful, and if 'editable'
means '-var-assign most likely will succeeed', it would be better.

>   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.

I'm not sure. Getting the 'editable' attribute does not require
talking to inferiour, so what target you use does not matter.

- Volodya

Re: BUG: MI reporting wrong attributes for casted variables

[Sascha Radike]

>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

Re: BUG: MI reporting wrong attributes for casted variables

[Nick Roberts]

 > >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.nz/~nickrob

Re: BUG: MI reporting wrong attributes for casted variables

[Sascha Radike]

>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