Problem with MI -var-evaluate-expression command

Problem with MI -var-evaluate-expression command

[Mo DeJong]

Hello gdbers.

I have been looking at the GDB/MI recently and have run into a problem
with the -var-evaluate-expression method that really seems like a bug.
It seems one is unable to access children of a variable object unless
the -var-list-children command has been run for that object. Here
is a quick example to demonstrate what I mean.

% cat S.c
struct S {
    int v1;
    int v2;
};

int main() {
    struct S* s = (struct S*) malloc(sizeof(struct S));
    s->v1 = 0;
    s->v2 = 1;
    return 0;
}

(compile, then invoke with mi1)

-file-exec-and-symbols S
^done
(gdb)

-break-insert S.c:9
^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x080483ee",func="main",file="S.c",line="9",times="0"}
(gdb)

-var-create svar * "(struct S *) 0x8049560"
^done,name="svar",numchild="2",type="struct S *"
(gdb) 

# I can access the variable

-var-evaluate-expression svar
^done,value="0x8049560"
(gdb) 

# But not the a child variable

-var-evaluate-expression svar.v1
&"Variable object not found\n"
^error,msg="Variable object not found"
(gdb) 

# I need to call -var-list-children first

-var-list-children svar
^done,numchild="2",children={child={name="svar.v1",exp="v1",numchild="0",type="int"},child={name="svar.v2",exp="v2",numchild="0",type="int"}}
(gdb) 

# Now it works

-var-evaluate-expression svar.v1
^done,value="0"
(gdb) 


Is this a bug in the MI? It sure seems like one to me, but I thought
I would ask to make sure. The docs don't mention anything about
having to invoke the -var-evaluate-expression method before accessing
children of a variable.

cheers
Mo DeJong

Re: Problem with MI -var-evaluate-expression command

[Keith Seitz]

On Wed, 10 Jul 2002, Mo DeJong wrote:

> % cat S.c
> struct S {
>     int v1;
>     int v2;
> };
>
> -var-create svar * "(struct S *) 0x8049560"
> ^done,name="svar",numchild="2",type="struct S *"
> (gdb)
> -var-evaluate-expression svar
> ^done,value="0x8049560"
> (gdb)
> -var-evaluate-expression svar.v1
> &"Variable object not found\n"
> ^error,msg="Variable object not found"

How is a UI to know what the children of svar are? You do, because you're
a human, but a UI reacting programmatically could not automatically know
that svar has a child named "v1" _until_ it asks svar for its children
(thus creating the varobjs).

Remember, we're dealing with VARiable OBJects here. You cannot do anything
without a varobj.

Insight is the major client for this code right now. (In fact varobj was
originally written for Insight, but it appeared to be useful to someone
else, and it was added to MI.) Here's what Insight does:

Given the expression "svar" which is perhaps supplied by "info
locals", "-stack-list-locals", or from the user inputting it as a watch, a
UI would:

1) Create varobj for (the expression) "svar"
2) Ask the varobj for a display name and stuff this into a column of the
   display
3) Ask the varobj for its type and stuff that into a column
4) Ask the varobj for its value and stuff that into a column
5) Ask the varobj if it has any children. If it does, it puts a little "+"
   next to the name, so that the user can expand it.

Now, when the user hits the "+", Insight will ask the varobj for its
children. It gets back a list of varobjs. It then repeats steps 2-5 for
each of these new varobjs.

In practice, I think it works quite well, but I may be a little biased,
since I originally wrote varobj for Insight. ;-)

Keith

Re: Problem with MI -var-evaluate-expression command

[Mo DeJong]

On Wed, 10 Jul 2002 17:31:11 -0700 (PDT)
Keith Seitz <keiths@redhat.com> wrote:

> How is a UI to know what the children of svar are? You do, because you're
> a human, but a UI reacting programmatically could not automatically know
> that svar has a child named "v1" _until_ it asks svar for its children
> (thus creating the varobjs).

...
 
> Now, when the user hits the "+", Insight will ask the varobj for its
> children. It gets back a list of varobjs. It then repeats steps 2-5 for
> each of these new varobjs.

It sounds like that works just fine for a watch window where each
child will be displayed. I just wonder if that is the only valid use case.
I am looking at building a scripting interface to the gdb/mi, so I don't need
watch window semantics just now.

My reading of the docs seems to indicate that the variable objects
interface is an improvement over just evaluating plain expressions
since the same "syntax" would be used to access C, C++, or Java
objects with children. I also liked the fact that you could set the
format of the returned value and then pass the whole "var object"
around from one function to another. That said, this -var-evaluate-expression
children thing has got me thinking that I should just stick with
-data-evaluate-expression and skip the -var-* methods. Here is why.

One can evaluate an expression like so quite easily:

-data-evaluate-expression "objPtr->member1->dataPtr->bytes"

But to do this same thing with a variable object I would need to
send these commands.

-var-create objPtr * "objPtr"
-var-list-children objPtr
-var-list-children objPtr.member1
-var-list-children objPtr.member1.dataPtr
-var-evaluate-expression objPtr.member1.dataPtr.bytes

Now, I could keep my own record of the variables that "know" what
their children are and check this record every time a variable is
accessed from my API. But, that just strikes me as really ugly and
it seems to waste a lot of bandwidth. I don't have a problem with
leaving support for the -var-* methods out of my wrapper
because of this issue, I just thought I would bring it up.

In any event, the docs for the -var-evaluate-expression should be
updated to explicitly state that the user needs to call -var-list-children
for a variable object before accessing any children.

Mo

Re: Problem with MI -var-evaluate-expression command

[Keith Seitz]

On Thu, 11 Jul 2002, Mo DeJong wrote:

> It sounds like that works just fine for a watch window where each
> child will be displayed. I just wonder if that is the only valid use case.
> I am looking at building a scripting interface to the gdb/mi, so I don't need
> watch window semantics just now.

If your input is coming from an automated UI, then it sh/would use -var-*.
On the other hand, if the input were coming from a user, then you would
definately want to use -data-*, e.g., Insight's variable windows use
-var-*, but GDB's console would use -data-* (if it implemented its
commands that way).

Keith

Re: Problem with MI -var-evaluate-expression command

[Jim Ingham]

Mo,

On Friday, July 12, 2002, at 08:23  AM, 
gdb-digest-help@sources.redhat.com wrote:

> From: Mo DeJong <supermo@bayarea.net>
> Date: Thu Jul 11, 2002  12:18:39  PM US/Pacific
> To: gdb@sources.redhat.com
> Subject: Re: Problem with MI -var-evaluate-expression command
>
>
> On Wed, 10 Jul 2002 17:31:11 -0700 (PDT)
> Keith Seitz <keiths@redhat.com> wrote:
>
>> How is a UI to know what the children of svar are? You do, because 
>> you're
>> a human, but a UI reacting programmatically could not automatically 
>> know
>> that svar has a child named "v1" _until_ it asks svar for its children
>> (thus creating the varobjs).
>
> ...
>
>> Now, when the user hits the "+", Insight will ask the varobj for its
>> children. It gets back a list of varobjs. It then repeats steps 2-5 
>> for
>> each of these new varobjs.
>
> It sounds like that works just fine for a watch window where each
> child will be displayed. I just wonder if that is the only valid use 
> case.
> I am looking at building a scripting interface to the gdb/mi, so I 
> don't need
> watch window semantics just now.
>
> My reading of the docs seems to indicate that the variable objects
> interface is an improvement over just evaluating plain expressions
> since the same "syntax" would be used to access C, C++, or Java
> objects with children. I also liked the fact that you could set the
> format of the returned value and then pass the whole "var object"
> around from one function to another. That said, this 
> -var-evaluate-expression
> children thing has got me thinking that I should just stick with
> -data-evaluate-expression and skip the -var-* methods. Here is why.
>
> One can evaluate an expression like so quite easily:
>
> -data-evaluate-expression "objPtr->member1->dataPtr->bytes"
>
> But to do this same thing with a variable object I would need to
> send these commands.
>
> -var-create objPtr * "objPtr"
> -var-list-children objPtr
> -var-list-children objPtr.member1
> -var-list-children objPtr.member1.dataPtr
> -var-evaluate-expression objPtr.member1.dataPtr.bytes
>
> Now, I could keep my own record of the variables that "know" what
> their children are and check this record every time a variable is
> accessed from my API. But, that just strikes me as really ugly and
> it seems to waste a lot of bandwidth. I don't have a problem with
> leaving support for the -var-* methods out of my wrapper
> because of this issue, I just thought I would bring it up.
>
> In any event, the docs for the -var-evaluate-expression should be
> updated to explicitly state that the user needs to call 
> -var-list-children
> for a variable object before accessing any children.

One thing here.  The fact that the name of the children is parent.child 
is an implementation detail, not a public interface.  For instance, in 
C++ classes, the name of the public instance variable foo of object 
objPtr is objPtr.public.foo.  I don't really think it is a good idea to 
change this, because as some point I would kind of like to shorten 
these, they get really cumbersome for deep trees...  So assuming that 
you know the varobj name of member1 of objPtr is objPtr.member1 isn't 
really safe.

Jim
--
Jim Ingham                                   jingham@apple.com
Developer Tools - gdb
Apple Computer