MI: type prefixes for values

On Tuesday 21 February 2006 21:13, Jim Ingham wrote:

> > Say, I've created a bunch of variable objects for
for local
> > variables. When I
> > leave the function, those variables become
invalid. How do you
> > detect this
> > case? Do you have a command
'-list-var-objects-that-are-dead', or
> > some other
> > mechanism.
>
> We don't do this in gdb.  Xcode keeps track of which
varobj's go with
> which stack frames, and deletes them when appropriate. 
You want to
> be a little clever about this, 'cause there's no need
to delete the
> varobj's till the function is actually popped off the
stack.  You
> might descend into another function then come back to
this one, in
> which case the varobj's are still good.

I was thinking about this more, and still not 100% sure how
Xcode can do this. 
Do you mean that Xcode takes a stack trace when the varobj
was created, and 
deletes varobj whenever it sees that stack became shorter?

The case I'm not sure about is this:

1. main calls 'a' which calls 'b' which bits breakpoint.
2  varobj is created for local var of 'b'
3. Users says 'continue'.
4. 'b' exists and then 'a' calls 'b' again and
breakpoint is
   hit again.

However, this second time it's not guaranteed that stack
frame of 'b' is at 
the same address as it was the last time -- maybe 'a' has
pushed something on 
stack. How do you detect this case?

> Note, however, that the varobj's do remember their
frames, so if you
> tried to evaluate one that was no longer on the stack,
the varobj
> would report "out of scope".

Would be great to add this in FSF version.

- Volodya

On Thu, Apr 06, 2006 at 05:03:25PM +0400, Vladimir Prus
wrote:
> I was thinking about this more, and still not 100% sure
how Xcode can do this. 
> Do you mean that Xcode takes a stack trace when the
varobj was created, and 
> deletes varobj whenever it sees that stack became
shorter?
> 
> The case I'm not sure about is this:
> 
> 1. main calls 'a' which calls 'b' which bits
breakpoint.
> 2  varobj is created for local var of 'b'
> 3. Users says 'continue'.
> 4. 'b' exists and then 'a' calls 'b' again and
breakpoint is
>    hit again.
> 
> However, this second time it's not guaranteed that
stack frame of 'b' is at 
> the same address as it was the last time -- maybe 'a'
has pushed something on 
> stack. How do you detect this case?

Either b's stack frame is at the same address - in which
case the
varobj is still valid - or else it isn't, in which case the
frame id
has changed.

> > Note, however, that the varobj's do remember
their frames, so if you
> > tried to evaluate one that was no longer on the
stack, the varobj
> > would report "out of scope".
> 
> Would be great to add this in FSF version.

It's already there:

  /* The frame for this expression */
  struct frame_id frame;

c_value_of_root will always fail if the frame is gone.

-- 
Daniel Jacobowitz
CodeSourcery

On Thursday 06 April 2006 17:35, Daniel Jacobowitz wrote:
> On Thu, Apr 06, 2006 at 05:03:25PM +0400, Vladimir Prus
wrote:
> > I was thinking about this more, and still not 100%
sure how Xcode can do
> > this. Do you mean that Xcode takes a stack trace
when the varobj was
> > created, and deletes varobj whenever it sees that
stack became shorter?
> >
> > The case I'm not sure about is this:
> >
> > 1. main calls 'a' which calls 'b' which bits
breakpoint.
> > 2  varobj is created for local var of 'b'
> > 3. Users says 'continue'.
> > 4. 'b' exists and then 'a' calls 'b' again
and breakpoint is
> >    hit again.
> >
> > However, this second time it's not guaranteed
that stack frame of 'b' is
> > at the same address as it was the last time --
maybe 'a' has pushed
> > something on stack. How do you detect this case?
>
> Either b's stack frame is at the same address - in
which case the
> varobj is still valid - or else it isn't, in which
case the frame id
> has changed.

I did not know that GDB exposes frame ID in any way, and Jim
has mentioned 
that it's XCode that does the magic, not gdb. Is there some
command to print 
frame id that I've missed?

> > > Note, however, that the varobj's do remember
their frames, so if you
> > > tried to evaluate one that was no longer on
the stack, the varobj
> > > would report "out of scope".
> >
> > Would be great to add this in FSF version.
>
> It's already there:
>
>   /* The frame for this expression */
>   struct frame_id frame;
>
> c_value_of_root will always fail if the frame is gone.

Sorry, does not seems to work this way here. For the
following program: 

  void foo()
  {
      int i = 10;
      ++i;
  }

  int main()
  {
      foo();
  }

I get this session:

    (gdb)
    -break-insert a.cpp:5
    ^done,bkpt={......
    (gdb)
    -exec-run
    ^running
    (gdb)
   
*stopped,reason="breakpoint-hit",frame={addr=&q
uot;0x080483a1",func="foo"
    (gdb)
    -var-create TMP * i
   
^done,name="TMP",numchild="0",type=
"int"
    (gdb)
    -var-evaluate-expression TMP
    ^done,value="10"
    (gdb)
    -exec-finish
    ^running
    (gdb)
   
*stopped,reason="function-finished",frame={addr=
"0x080483bd",func="main",
    (gdb)
    -var-evaluate-expression TMP
    ^done,value="10"
    (gdb)

There's no indication that 'TMP' varobj belongs to the
stack frame we've 
already left. This is with vanilla 6.4.

- Volodya

On Thu, Apr 06, 2006 at 05:45:16PM +0400, Vladimir Prus
wrote:
> > Either b's stack frame is at the same address -
in which case the
> > varobj is still valid - or else it isn't, in
which case the frame id
> > has changed.
> 
> I did not know that GDB exposes frame ID in any way,
and Jim has mentioned 
> that it's XCode that does the magic, not gdb. Is there
some command to print 
> frame id that I've missed?

There shouldn't be, but GDB will notice if the varobj has
gone invalid.

>     -exec-finish
>     ^running
>     (gdb)
>    
*stopped,reason="function-finished",frame={addr=
"0x080483bd",func="main",
>     (gdb)
>     -var-evaluate-expression TMP
>     ^done,value="10"
>     (gdb)
> 
> There's no indication that 'TMP' varobj belongs to
the stack frame we've 
> already left. This is with vanilla 6.4.

Interesting, the check isn't on this path.  I wonder if we
really need
both different ways to get at the value of a variable. 
varobj_update
uses value_of_root, but -var-evaluate-expression uses
value_of_variable.  I bet we have some redundant code here. 
Maybe not,
value_of_variable is only used for strings, the others work
on struct
value.

Anyway:

-var-update *
^done,changelist=[{name="TMP",in_scope="fa
lse"}]

There's your out of scope marker.

-- 
Daniel Jacobowitz
CodeSourcery

On Thursday 06 April 2006 18:01, Daniel Jacobowitz wrote:

> >     -exec-finish
> >     ^running
> >     (gdb)
> >    
> >
*stopped,reason="function-finished",frame={addr=
"0x080483bd",func="main",
> > (gdb)
> >     -var-evaluate-expression TMP
> >     ^done,value="10"
> >     (gdb)
> >
> > There's no indication that 'TMP' varobj belongs
to the stack frame we've
> > already left. This is with vanilla 6.4.
>
> Interesting, the check isn't on this path.  I wonder
if we really need
> both different ways to get at the value of a variable. 
varobj_update
> uses value_of_root, but -var-evaluate-expression uses
> value_of_variable.  I bet we have some redundant code
here.  Maybe not,
> value_of_variable is only used for strings, the others
work on struct
> value.

I don't quite understand if you're saying that the current
behaviour is a bug, 
or not. Can you clarify?

> Anyway:
>
> -var-update *
>
^done,changelist=[{name="TMP",in_scope="fa
lse"}]
>
> There's your out of scope marker.

Yes, this is indeed what I'm after. However, now there's
reverse problem. Say 
I create variable object for variable 'i'. Then during
stepping I enter 
function that also has variable 'i'. I need to detect,
somehow, that 'i' 
varobj created earlier relates to the parent stack frame,
not the current, 
and that I have to create new variable object.

How do I do that? Using -var-update does not seem to produce
this information? 
Am I supposed to manually keep track of frame-id where
variable object was 
created? And if so, how do I get frame-id?

- Volodya

On Thu, Apr 06, 2006 at 06:31:24PM +0400, Vladimir Prus
wrote:
> > > There's no indication that 'TMP' varobj
belongs to the stack frame we've
> > > already left. This is with vanilla 6.4.
> >
> > Interesting, the check isn't on this path.  I
wonder if we really need
> > both different ways to get at the value of a
variable.  varobj_update
> > uses value_of_root, but -var-evaluate-expression
uses
> > value_of_variable.  I bet we have some redundant
code here.  Maybe not,
> > value_of_variable is only used for strings, the
others work on struct
> > value.
> 
> I don't quite understand if you're saying that the
current behaviour is a bug, 
> or not. Can you clarify?

I don't know.  It's an interface.

Maybe it is an error for you to try to evaluate something
after
-var-update says it has gone out of scope.

Maybe -var-evaluate-expression should report not in scope.

Someone with more MI experience would have to decide.

> Yes, this is indeed what I'm after. However, now
there's reverse problem. Say 
> I create variable object for variable 'i'. Then
during stepping I enter 
> function that also has variable 'i'. I need to
detect, somehow, that 'i' 
> varobj created earlier relates to the parent stack
frame, not the current, 
> and that I have to create new variable object.
> 
> How do I do that? Using -var-update does not seem to
produce this information? 
> Am I supposed to manually keep track of frame-id where
variable object was 
> created? And if so, how do I get frame-id?

I don't know.  Maybe Jim will comment.

-- 
Daniel Jacobowitz
CodeSourcery

On Apr 6, 2006, at 6:45 AM, Vladimir Prus wrote:

> On Thursday 06 April 2006 17:35, Daniel Jacobowitz
wrote:
>> On Thu, Apr 06, 2006 at 05:03:25PM +0400, Vladimir
Prus wrote:
>>> I was thinking about this more, and still not
100% sure how Xcode  
>>> can do
>>> this. Do you mean that Xcode takes a stack
trace when the varobj was
>>> created, and deletes varobj whenever it sees
that stack became  
>>> shorter?
>>>
>>> The case I'm not sure about is this:
>>>
>>> 1. main calls 'a' which calls 'b' which
bits breakpoint.
>>> 2  varobj is created for local var of 'b'
>>> 3. Users says 'continue'.
>>> 4. 'b' exists and then 'a' calls 'b'
again and breakpoint is
>>>    hit again.
>>>
>>> However, this second time it's not guaranteed
that stack frame of  
>>> 'b' is
>>> at the same address as it was the last time --
maybe 'a' has pushed
>>> something on stack. How do you detect this
case?
>>
>> Either b's stack frame is at the same address - in
which case the
>> varobj is still valid - or else it isn't, in which
case the frame id
>> has changed.
>
> I did not know that GDB exposes frame ID in any way,
and Jim has  
> mentioned
> that it's XCode that does the magic, not gdb. Is there
some command  
> to print
> frame id that I've missed?

gdb does know what stack frame a variable is bound to.  But
gdb  
doesn't do any cleanup of variable objects on it's own. 
That's up to  
the MI client.  I am pretty sure that is what I was
referring to.

>
>>>> Note, however, that the varobj's do
remember their frames, so if  
>>>> you
>>>> tried to evaluate one that was no longer on
the stack, the varobj
>>>> would report "out of scope".
>>>
>>> Would be great to add this in FSF version.
>>
>> It's already there:
>>
>>   /* The frame for this expression */
>>   struct frame_id frame;
>>
>> c_value_of_root will always fail if the frame is
gone.
>
> Sorry, does not seems to work this way here. For the
following  
> program:
>
>   void foo()
>   {
>       int i = 10;
>       ++i;
>   }
>
>   int main()
>   {
>       foo();
>   }
>
> I get this session:
>
>     (gdb)
>     -break-insert a.cpp:5
>     ^done,bkpt={......
>     (gdb)
>     -exec-run
>     ^running
>     (gdb)
>     *stopped,reason="breakpoint-hit",frame=

> {addr="0x080483a1",func="foo"
>     (gdb)
>     -var-create TMP * i
>    
^done,name="TMP",numchild="0",type=
"int"
>     (gdb)
>     -var-evaluate-expression TMP
>     ^done,value="10"
>     (gdb)
>     -exec-finish
>     ^running
>     (gdb)
>    
*stopped,reason="function-finished",frame= 
> {addr="0x080483bd",func="main",
>     (gdb)
>     -var-evaluate-expression TMP
>     ^done,value="10"
>     (gdb)
>
> There's no indication that 'TMP' varobj belongs to
the stack frame  
> we've
> already left. This is with vanilla 6.4.
>

-var-evaluate-expression just fetches the data for the
expression as  
it was last computed.  As such, it doesn't know in or out
of scope.   
It's -var-update, which recomputes the variable's value. 
So if you  
add on to your example:

-var-update TMP
^done,changelist=[varobj={name="TMP",in_scope=&
quot;false"}]

This is for the Apple gdb, BTW, I don't have a Linux box
handy so I'm  
not sure what the FSF gdb would print out, but the logic
would be the  
same.

Jim

On Thu, Apr 06, 2006 at 09:06:14AM -0700, Jim Ingham wrote:
> -var-evaluate-expression just fetches the data for the
expression as  
> it was last computed.  As such, it doesn't know in or
out of scope.   

I can see, from careful inspection, that this is true.  It
surprised
the heck out of me.  I'd have expected it to evaluate it
now, not to
return the last evaluated value.

Should it do this?  If so, we should fix the manual.

Eek!  Every call to c_value_of_root for a local changes the
selected
frame and reinitializes the frame cache, discarding previous
unwindings.  That's awful.  I sure hope it isn't
necessary.

-- 
Daniel Jacobowitz
CodeSourcery

On Apr 6, 2006, at 9:19 AM, Daniel Jacobowitz wrote:

> On Thu, Apr 06, 2006 at 09:06:14AM -0700, Jim Ingham
wrote:
>> -var-evaluate-expression just fetches the data for
the expression as
>> it was last computed.  As such, it doesn't know in
or out of scope.
>
> I can see, from careful inspection, that this is true. 
It surprised
> the heck out of me.  I'd have expected it to evaluate
it now, not to
> return the last evaluated value.
>
> Should it do this?  If so, we should fix the manual.

I think the idea here was that if you wanted you could use
varobj's  
as "history" if you wanted to.  It is also might
be convenient that  
if you are using one varobj to display a value in a number
of places  
in the UI you don't have to re-evaluate it every time.  But
to tell  
the truth, I don't think either of these features is used
in Xcode or  
in Insight either, IIRC.

>
> Eek!  Every call to c_value_of_root for a local changes
the selected
> frame and reinitializes the frame cache, discarding
previous
> unwindings.  That's awful.  I sure hope it isn't
necessary.

That looks like that's been there for a long time.  I am
not sure why  
it is necessary.  It doesn't cause as much problem as you
would  
expect, since in common practice, you get the stack, and
display  
that, then just noodle around in the variables on the bottom
of the  
stack.  But you're right, it would be good not to do this. 
I'll try  
taking it out, and see what happens under Xcode.

Jim


>
> -- 
> Daniel Jacobowitz
> CodeSourcery

On Apr 6, 2006, at 7:41 AM, Daniel Jacobowitz wrote:

> On Thu, Apr 06, 2006 at 06:31:24PM +0400, Vladimir Prus
wrote:
>>>> There's no indication that 'TMP' varobj
belongs to the stack  
>>>> frame we've
>>>> already left. This is with vanilla 6.4.
>>>
>>> Interesting, the check isn't on this path.  I
wonder if we really  
>>> need
>>> both different ways to get at the value of a
variable.   
>>> varobj_update
>>> uses value_of_root, but
-var-evaluate-expression uses
>>> value_of_variable.  I bet we have some
redundant code here.   
>>> Maybe not,
>>> value_of_variable is only used for strings, the
others work on  
>>> struct
>>> value.
>>
>> I don't quite understand if you're saying that
the current  
>> behaviour is a bug,
>> or not. Can you clarify?
>
> I don't know.  It's an interface.
>
> Maybe it is an error for you to try to evaluate
something after
> -var-update says it has gone out of scope.
>
> Maybe -var-evaluate-expression should report not in
scope.
>
> Someone with more MI experience would have to decide.

I don't know why it was originally done this way.  But in
practice it  
doesn't much matter.  The separation between
"update" and "evaluate"  
is useful, since "what's changed" and
"give me a value" are questions  
you want to ask separately.  Since the UI generally knows
what it  
wants to fetch, having -var-evaluate-expression error if the
varobj  
was out of scope hasn't been a big deal in practice.

>
>> Yes, this is indeed what I'm after. However, now
there's reverse  
>> problem. Say
>> I create variable object for variable 'i'. Then
during stepping I  
>> enter
>> function that also has variable 'i'. I need to
detect, somehow,  
>> that 'i'
>> varobj created earlier relates to the parent stack
frame, not the  
>> current,
>> and that I have to create new variable object.

>>
>> How do I do that? Using -var-update does not seem
to produce this  
>> information?
>> Am I supposed to manually keep track of frame-id
where variable  
>> object was
>> created? And if so, how do I get frame-id?
>
> I don't know.  Maybe Jim will comment.

One of the changes that I made early on when we started
using the MI  
seriously for Xcode was to add an option to
-stack-list-locals and - 
stack-list-args to make varobj's for all the locals/args. 
We always  
use these commands to get the varobj's that correspond to
the stack  
frame.  Then it is a simple matter in the UI to tie these
variable  
objects to their frames, and update, evaluate, whatever,
them as  
appropriate for the frame the user is currently looking at.

I think it's a lot easier doing it this way than having an
option in  
the MI to report the varobj's frame, and then having to
check that  
against the stack each time.

The other bit involved here is that Xcode does keep track of
the last  
stack and compares it against the current stack every time
you stop.   
That way it knows which frames it does or doesn't have to
create new  
variable objects for.

Jim



>
> -- 
> Daniel Jacobowitz
> CodeSourcery