-var-update and address changes

-var-update and address changes

[Vladimir Prus]

Hi,
I'm running into what looks like a bug in -var-update. Basically, I create a
varobj with "&variable", then I enter a function that has a variable with
the same name, and -var-update does not report anything.

Here's the code, and the gdb session. 

    int foo()
    {
        int i = 10;
        ++i;
        return i;
    }
    
    int main()
    {
        int i = 10;
        i = foo();
        return i;
    }

And here's the session

    -break-insert a.cpp:12
    ^done,....
    (gdb)
    -break-insert a.cpp:5
    ^done,....
    (gdb)
    -exec-run
    ^running
    (gdb)
    *stopped,reason="breakpoint-hit",.....
    (gdb)
    -var-create TEST * &i
    ^done,name="TEST",numchild="1",type="int *"
    (gdb)
    -exec-continue
    ^running
    (gdb)
    *stopped,reason="breakpoint-hit",.......
    (gdb)
    -var-update *
    ^done,changelist=[]
    (gdb)

The value of "&i" changes, but -var-update does not report this. This can be
explained by the fact that varobjs are "bound" to the stack frame where
they were created, but that "binding" is not mentioned in documentation.

The problem I'm trying to solve is this:
1. In some frame, I create varobj for 'i'.
2. After continue, I see that there's local variable 'i', and I want to find
out if previously-created varobj can be used to show this local 'i', or if
I should create new 'i'.

   - I can't use frame ids because gdb only prints code address, and two    
     different stack frames can have the same code address.
   - I can't use -var-update, because it does not seem to report anything
   - I can't use -var-update on variable addresses, because of the above
     report

So, the only solution is to remove all varobjs, and create them afresh,
which is contrary to the very purpose of varobjs.

Can somebody suggest the right fix? So far, I think that the simplest
approach is to make gdb print stack address of current frame, like is done
on the Apple branch:

     553^done,stack=[frame= 
     {level="0",addr="0x00003db0",fp="0xbffff2c0",......

That way, frontend can deal with the issue of frame stacks themself, and
-var-update will be only used when single-stepping inside a given frame.
Will patches to implement this be welcome?

And I still don't know what to do about variable shadowing inside a single
function.

- Volodya

Re: -var-update and address changes

[Jim Ingham]

On Apr 12, 2006, at 5:04 AM, Vladimir Prus wrote:

>
> Hi,
> I'm running into what looks like a bug in -var-update. Basically, I  
> create a
> varobj with "&variable", then I enter a function that has a  
> variable with
> the same name, and -var-update does not report anything.
>
> Here's the code, and the gdb session.
>
>     int foo()
>     {
>         int i = 10;
>         ++i;
>         return i;
>     }
>
>     int main()
>     {
>         int i = 10;
>         i = foo();
>         return i;
>     }
>
> And here's the session
>
>     -break-insert a.cpp:12
>     ^done,....
>     (gdb)
>     -break-insert a.cpp:5
>     ^done,....
>     (gdb)
>     -exec-run
>     ^running
>     (gdb)
>     *stopped,reason="breakpoint-hit",.....
>     (gdb)
>     -var-create TEST * &i
>     ^done,name="TEST",numchild="1",type="int *"
>     (gdb)
>     -exec-continue
>     ^running
>     (gdb)
>     *stopped,reason="breakpoint-hit",.......
>     (gdb)
>     -var-update *
>     ^done,changelist=[]
>     (gdb)
>
> The value of "&i" changes, but -var-update does not report this.  
> This can be
> explained by the fact that varobjs are "bound" to the stack frame  
> where
> they were created, but that "binding" is not mentioned in  
> documentation.
>
> The problem I'm trying to solve is this:
> 1. In some frame, I create varobj for 'i'.
> 2. After continue, I see that there's local variable 'i', and I  
> want to find
> out if previously-created varobj can be used to show this local  
> 'i', or if
> I should create new 'i'.
>
>    - I can't use frame ids because gdb only prints code address,  
> and two
>      different stack frames can have the same code address.
>    - I can't use -var-update, because it does not seem to report  
> anything
>    - I can't use -var-update on variable addresses, because of the  
> above
>      report
>
> So, the only solution is to remove all varobjs, and create them  
> afresh,
> which is contrary to the very purpose of varobjs.
>
> Can somebody suggest the right fix? So far, I think that the simplest
> approach is to make gdb print stack address of current frame, like  
> is done
> on the Apple branch:
>
>      553^done,stack=[frame=
>      {level="0",addr="0x00003db0",fp="0xbffff2c0",......
>
> That way, frontend can deal with the issue of frame stacks  
> themself, and
> -var-update will be only used when single-stepping inside a given  
> frame.
> Will patches to implement this be welcome?

That's what I would suggest.  It seemed the simplest way to handle  
this when we were first thinking about it.

>
> And I still don't know what to do about variable shadowing inside a  
> single
> function.

I added another option to -stack-list-locals to print all the blocks  
in a given function.  Using this plus the option to have -stack-list- 
locals return variable object, you will get all the shadowed  
variables in the function as varobj's when you enter the function.   
Then the varobj system will tell you which of these are in and out of  
scope at any given PC.  We also tell what the valid block is, but  
Xcode doesn't use this info at present.

This all works in our branch if you want to see one example of how to  
do it.

Jim

Re: -var-update and address changes

[Vladimir Prus]

Jim Ingham wrote:


>> So, the only solution is to remove all varobjs, and create them
>> afresh,
>> which is contrary to the very purpose of varobjs.
>>
>> Can somebody suggest the right fix? So far, I think that the simplest
>> approach is to make gdb print stack address of current frame, like
>> is done
>> on the Apple branch:
>>
>>      553^done,stack=[frame=
>>      {level="0",addr="0x00003db0",fp="0xbffff2c0",......
>>
>> That way, frontend can deal with the issue of frame stacks
>> themself, and
>> -var-update will be only used when single-stepping inside a given
>> frame.
>> Will patches to implement this be welcome?
> 
> That's what I would suggest.  It seemed the simplest way to handle
> this when we were first thinking about it.

FWIW, I've imp^H^H^Hkluged this by parsing the output of "info frame"
command. This gets me full frame id, but this should really be inside MI.

>> And I still don't know what to do about variable shadowing inside a
>> single
>> function.
> 
> I added another option to -stack-list-locals to print all the blocks
> in a given function.  Using this plus the option to have -stack-list-
> locals return variable object, you will get all the shadowed
> variables in the function as varobj's when you enter the function.
> Then the varobj system will tell you which of these are in and out of
> scope at any given PC.  

You mean, using -var-update and the "in_scope" attribute?

> This all works in our branch if you want to see one example of how to
> do it.

Unfortunately, last time I tried it did not build on Linux.

- Volodya

Re: -var-update and address changes

[Jim Ingham]

On Apr 13, 2006, at 1:26 AM, Vladimir Prus wrote:

> Jim Ingham wrote:
>
>
>>> So, the only solution is to remove all varobjs, and create them
>>> afresh,
>>> which is contrary to the very purpose of varobjs.
>>>
>>> Can somebody suggest the right fix? So far, I think that the  
>>> simplest
>>> approach is to make gdb print stack address of current frame, like
>>> is done
>>> on the Apple branch:
>>>
>>>      553^done,stack=[frame=
>>>      {level="0",addr="0x00003db0",fp="0xbffff2c0",......
>>>
>>> That way, frontend can deal with the issue of frame stacks
>>> themself, and
>>> -var-update will be only used when single-stepping inside a given
>>> frame.
>>> Will patches to implement this be welcome?
>>
>> That's what I would suggest.  It seemed the simplest way to handle
>> this when we were first thinking about it.
>
> FWIW, I've imp^H^H^Hkluged this by parsing the output of "info frame"
> command. This gets me full frame id, but this should really be  
> inside MI.
>
>>> And I still don't know what to do about variable shadowing inside a
>>> single
>>> function.
>>
>> I added another option to -stack-list-locals to print all the blocks
>> in a given function.  Using this plus the option to have -stack-list-
>> locals return variable object, you will get all the shadowed
>> variables in the function as varobj's when you enter the function.
>> Then the varobj system will tell you which of these are in and out of
>> scope at any given PC.
>
> You mean, using -var-update and the "in_scope" attribute?

Yes, -var-update will list as changed any varobj that has come into  
or out of scope since the last -var-update.

>
>> This all works in our branch if you want to see one example of how to
>> do it.
>
> Unfortunately, last time I tried it did not build on Linux.

Sorry 'bout that.  We only ever build it on Mac OS X.

Jim

Re: -var-update and address changes

[Daniel Jacobowitz]

On Wed, Apr 12, 2006 at 04:04:36PM +0400, Vladimir Prus wrote:
> I'm running into what looks like a bug in -var-update. Basically, I create a
> varobj with "&variable", then I enter a function that has a variable with
> the same name, and -var-update does not report anything.

I think we've concluded that this is a feature, not a bug...

> The value of "&i" changes, but -var-update does not report this. This can be
> explained by the fact that varobjs are "bound" to the stack frame where
> they were created, but that "binding" is not mentioned in documentation.

... and adding this to the manual would be welcome.

> The problem I'm trying to solve is this:
> 1. In some frame, I create varobj for 'i'.
> 2. After continue, I see that there's local variable 'i', and I want to find
> out if previously-created varobj can be used to show this local 'i', or if
> I should create new 'i'.

OK, so, you need to map this to a frame.  Apple outputs the frame
address.  I think this is pretty nasty; frame IDs ought to be opaque in
the interface (e.g. in case we change their contents again)... Jim,
what does your front end do with the frame IDs?  Is there anything
besides testing for equality?  If there is, we can use unique opaque
identifiers instead; personally I'm much happier with that.  The
best unique identifier might in fact be the contents of the frame
ID; I'm just trying to define how clients are allowed to interpret
it, hopefully not at all.

> Can somebody suggest the right fix? So far, I think that the simplest
> approach is to make gdb print stack address of current frame, like is done
> on the Apple branch:
> 
>      553^done,stack=[frame= 
>      {level="0",addr="0x00003db0",fp="0xbffff2c0",......
> 
> That way, frontend can deal with the issue of frame stacks themself, and
> -var-update will be only used when single-stepping inside a given frame.
> Will patches to implement this be welcome?

I guess.  It seems reasonable.

The MI working group list is now open; should we move this sort of
conversation there?

-- 
Daniel Jacobowitz
CodeSourcery

Re: -var-update and address changes

[Jim Ingham]

On Apr 14, 2006, at 6:15 AM, Daniel Jacobowitz wrote:

> On Wed, Apr 12, 2006 at 04:04:36PM +0400, Vladimir Prus wrote:
>> I'm running into what looks like a bug in -var-update. Basically,  
>> I create a
>> varobj with "&variable", then I enter a function that has a  
>> variable with
>> the same name, and -var-update does not report anything.
>
> I think we've concluded that this is a feature, not a bug...
>
>> The value of "&i" changes, but -var-update does not report this.  
>> This can be
>> explained by the fact that varobjs are "bound" to the stack frame  
>> where
>> they were created, but that "binding" is not mentioned in  
>> documentation.
>
> ... and adding this to the manual would be welcome.

The docs are there, just not altogether clear.  They say:

The frame under which the expression should be evaluated can be
specified by @var{frame-addr}.  A @samp{*} indicates that the current
frame should be used.

The last sentence means that the varobj will be bound to whatever the  
current frame is.  It can be read to mean "it's re-evaluated in  
whatever the current frame happens to be when you update it" - maybe  
that's how Vlad understood it.  So you just need to make this a  
little clearer.

Note as an aside, that we had to add another varobj type which is  
evaluated in the selected frame, whatever that happens to be.  That  
was useful for a general "variable inspector" window.  People wanted  
to put some expression there, and have it re-evaluated in the topmost  
frame whenever they stopped.  So we added that functionality.  But  
that is clearly distinct from what the "*" varobj type is supposed to  
mean.

>
>> The problem I'm trying to solve is this:
>> 1. In some frame, I create varobj for 'i'.
>> 2. After continue, I see that there's local variable 'i', and I  
>> want to find
>> out if previously-created varobj can be used to show this local  
>> 'i', or if
>> I should create new 'i'.
>
> OK, so, you need to map this to a frame.  Apple outputs the frame
> address.  I think this is pretty nasty; frame IDs ought to be  
> opaque in
> the interface (e.g. in case we change their contents again)... Jim,
> what does your front end do with the frame IDs?  Is there anything
> besides testing for equality?  If there is, we can use unique opaque
> identifiers instead; personally I'm much happier with that.  The
> best unique identifier might in fact be the contents of the frame
> ID; I'm just trying to define how clients are allowed to interpret
> it, hopefully not at all.

The fp part is just used as part of the frame fingerprint.  The pc is  
used for other purposes of course (for instance if the disassembly  
window is open), but the fp part is just used to check whether the  
frame needs to be refreshed.  I have no problem with it being opaque.

>
>> Can somebody suggest the right fix? So far, I think that the simplest
>> approach is to make gdb print stack address of current frame, like  
>> is done
>> on the Apple branch:
>>
>>      553^done,stack=[frame=
>>      {level="0",addr="0x00003db0",fp="0xbffff2c0",......
>>
>> That way, frontend can deal with the issue of frame stacks  
>> themself, and
>> -var-update will be only used when single-stepping inside a given  
>> frame.
>> Will patches to implement this be welcome?
>
> I guess.  It seems reasonable.
>
> The MI working group list is now open; should we move this sort of
> conversation there?

That seems appropriate.

Jim

Re: -var-update and address changes

[Daniel Jacobowitz]

On Fri, Apr 14, 2006 at 12:49:05PM -0700, Jim Ingham wrote:
> Note as an aside, that we had to add another varobj type which is  
> evaluated in the selected frame, whatever that happens to be.  That  
> was useful for a general "variable inspector" window.  People wanted  
> to put some expression there, and have it re-evaluated in the topmost  
> frame whenever they stopped.  So we added that functionality.  But  
> that is clearly distinct from what the "*" varobj type is supposed to  
> mean.

Well, I interpreted it the other way around, so I'll dispute your
"clearly" :-)

> The fp part is just used as part of the frame fingerprint.  The pc is  
> used for other purposes of course (for instance if the disassembly  
> window is open), but the fp part is just used to check whether the  
> frame needs to be refreshed.  I have no problem with it being opaque.

It's the PC of the frame, not the current PC; I'm not sure why you'd
want to use it.  In any case, you can always fetch it for the frame,
or report it separately.  So, let's plan on using frame IDs in MI,
and defining them opaquely.  I'd even go so far as to make them strings
rather than numbers.

-- 
Daniel Jacobowitz
CodeSourcery

Re: -var-update and address changes

[Jim Ingham]

On Apr 14, 2006, at 12:53 PM, Daniel Jacobowitz wrote:

> On Fri, Apr 14, 2006 at 12:49:05PM -0700, Jim Ingham wrote:
>> Note as an aside, that we had to add another varobj type which is
>> evaluated in the selected frame, whatever that happens to be.  That
>> was useful for a general "variable inspector" window.  People wanted
>> to put some expression there, and have it re-evaluated in the topmost
>> frame whenever they stopped.  So we added that functionality.  But
>> that is clearly distinct from what the "*" varobj type is supposed to
>> mean.
>
> Well, I interpreted it the other way around, so I'll dispute your
> "clearly" :-)

Yeah, every time I have to fix this code, I have to figure out the  
difference between "current frame" and "selected frame".  Once I've  
thought about it a bit, I'm convinced that it's clear.  But then I  
forget it almost immediately...

>
>> The fp part is just used as part of the frame fingerprint.  The pc is
>> used for other purposes of course (for instance if the disassembly
>> window is open), but the fp part is just used to check whether the
>> frame needs to be refreshed.  I have no problem with it being opaque.
>
> It's the PC of the frame, not the current PC; I'm not sure why you'd
> want to use it.  In any case, you can always fetch it for the frame,
> or report it separately.  So, let's plan on using frame IDs in MI,
> and defining them opaquely.  I'd even go so far as to make them  
> strings
> rather than numbers.

If you have a disassembly view showing, and you are clicking around  
on the stack, Xcode fetches enough code to fill the disassembly  
window around the pc of the frame you've selected on the stack.   
Having the pc returned with the stack frame eliminates one round  
trip.  People tend to nervously click around on the stack for no  
apparent reason while they are thinking about the problem they are  
working on.  So this needs to be somewhat quick, though this one  
round trip is probably negligible.  OTOH the fewer things you have to  
do by "send a request, wait for the reply, do the next request" the  
easier it is to program on the client side.  I wouldn't lean too hard  
on this one way or another.

Jim

Re: -var-update and address changes

[Daniel Jacobowitz]

On Fri, Apr 14, 2006 at 01:04:22PM -0700, Jim Ingham wrote:
> If you have a disassembly view showing, and you are clicking around  
> on the stack, Xcode fetches enough code to fill the disassembly  
> window around the pc of the frame you've selected on the stack.   
> Having the pc returned with the stack frame eliminates one round  
> trip.  People tend to nervously click around on the stack for no  
> apparent reason while they are thinking about the problem they are  
> working on.  So this needs to be somewhat quick, though this one  
> round trip is probably negligible.  OTOH the fewer things you have to  
> do by "send a request, wait for the reply, do the next request" the  
> easier it is to program on the client side.  I wouldn't lean too hard  
> on this one way or another.

Let me rephrase.

This is the PC associated with the frame, right now.  It's not the PC
in the frame ID at all.  That PC is the start of the function
containing the frame.

-- 
Daniel Jacobowitz
CodeSourcery

Re: -var-update and address changes

[Nick Roberts]

 > > Can somebody suggest the right fix? So far, I think that the simplest
 > > approach is to make gdb print stack address of current frame, like is done
 > > on the Apple branch:
 > > 
 > >      553^done,stack=[frame= 
 > >      {level="0",addr="0x00003db0",fp="0xbffff2c0",......
 > > 
 > > That way, frontend can deal with the issue of frame stacks themself, and
 > > -var-update will be only used when single-stepping inside a given frame.
 > > Will patches to implement this be welcome?
 > 
 > I guess.  It seems reasonable.

ISTR that Totalview displays the fp address of each frame in the call stack.
This seems natural and I wonder why "info stack" chooses to display the pc
addresses.

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

Re: -var-update and address changes

[Vladimir Prus]

On Saturday 15 April 2006 00:09, Daniel Jacobowitz wrote:
> On Fri, Apr 14, 2006 at 01:04:22PM -0700, Jim Ingham wrote:
> > If you have a disassembly view showing, and you are clicking around
> > on the stack, Xcode fetches enough code to fill the disassembly
> > window around the pc of the frame you've selected on the stack.
> > Having the pc returned with the stack frame eliminates one round
> > trip.  People tend to nervously click around on the stack for no
> > apparent reason while they are thinking about the problem they are
> > working on.  So this needs to be somewhat quick, though this one
> > round trip is probably negligible.  OTOH the fewer things you have to
> > do by "send a request, wait for the reply, do the next request" the
> > easier it is to program on the client side.  I wouldn't lean too hard
> > on this one way or another.
>
> Let me rephrase.
>
> This is the PC associated with the frame, right now.  It's not the PC
> in the frame ID at all.  That PC is the start of the function
> containing the frame.

And that PC is of some use too. I some distant future, I want to make KDevelop 
remember the state of variables tree for a specific frame. Say, you've 
entered function 'foo' and switched display format for variable 'mask' from 
'natural' to 'binary'. You probably want binary format to be used whenever 
you enter 'foo' next time. Using frame PC is one way to capture the current 
frame. It's not ideal, since frame address can change on recompilation, but 
on the other hand, the worst thing that will happen is that you'll use wrong 
format for a variable, which is not big problems.

So, I think frame PC is useful on it's own.

- Volodya

Re: -var-update and address changes

[Mark Kettenis]

> From: Vladimir Prus <ghost@cs.msu.su>
> Date: Mon, 17 Apr 2006 09:53:56 +0400
> 
> On Saturday 15 April 2006 00:09, Daniel Jacobowitz wrote:
> > On Fri, Apr 14, 2006 at 01:04:22PM -0700, Jim Ingham wrote:
> > > If you have a disassembly view showing, and you are clicking around
> > > on the stack, Xcode fetches enough code to fill the disassembly
> > > window around the pc of the frame you've selected on the stack.
> > > Having the pc returned with the stack frame eliminates one round
> > > trip.  People tend to nervously click around on the stack for no
> > > apparent reason while they are thinking about the problem they are
> > > working on.  So this needs to be somewhat quick, though this one
> > > round trip is probably negligible.  OTOH the fewer things you have to
> > > do by "send a request, wait for the reply, do the next request" the
> > > easier it is to program on the client side.  I wouldn't lean too hard
> > > on this one way or another.
> >
> > Let me rephrase.
> >
> > This is the PC associated with the frame, right now.  It's not the PC
> > in the frame ID at all.  That PC is the start of the function
> > containing the frame.
> 
> And that PC is of some use too. I some distant future, I want to make KDevelop 
> remember the state of variables tree for a specific frame. Say, you've 
> entered function 'foo' and switched display format for variable 'mask' from 
> 'natural' to 'binary'. You probably want binary format to be used whenever 
> you enter 'foo' next time. Using frame PC is one way to capture the current 
> frame. It's not ideal, since frame address can change on recompilation, but 
> on the other hand, the worst thing that will happen is that you'll use wrong 
> format for a variable, which is not big problems.
> 
> So, I think frame PC is useful on it's own.

Address space randomization (used by OpenBSD and any halfway decent
Linux distribution) will kill this idea completely.  The frame ID will
vary from run to run on those systems.

Mark

Re: -var-update and address changes

[Vladimir Prus]

On Monday 17 April 2006 12:40, Mark Kettenis wrote:

> > And that PC is of some use too. I some distant future, I want to make
> > KDevelop remember the state of variables tree for a specific frame. Say,
> > you've entered function 'foo' and switched display format for variable
> > 'mask' from 'natural' to 'binary'. You probably want binary format to be
> > used whenever you enter 'foo' next time. Using frame PC is one way to
> > capture the current frame. It's not ideal, since frame address can change
> > on recompilation, but on the other hand, the worst thing that will happen
> > is that you'll use wrong format for a variable, which is not big
> > problems.
> >
> > So, I think frame PC is useful on it's own.
>
> Address space randomization (used by OpenBSD and any halfway decent
> Linux distribution) will kill this idea completely.  The frame ID will
> vary from run to run on those systems.

I know and would appreciate a more reliable mechanism (say, opaque "scope 
id"). Even with address randomization things will work if you enter the same 
function several times without restarting application.

- Volodya

Re: -var-update and address changes

[Vladimir Prus]

On Friday 14 April 2006 23:49, Jim Ingham wrote:

> Note as an aside, that we had to add another varobj type which is
> evaluated in the selected frame, whatever that happens to be.  That
> was useful for a general "variable inspector" window.  People wanted
> to put some expression there, and have it re-evaluated in the topmost
> frame whenever they stopped.  So we added that functionality.  But
> that is clearly distinct from what the "*" varobj type is supposed to
> mean.

Hi Jim,
is this "variable inspector" the same thing that's called "watches" in other 
IDEs? Well, I really wish that gdb did support variable objects that are 
reevaluated in the current frame. As it stands now, I have to re-create 
variable objects on each step.

Alternatively, it might be good if gdb provided some way to identify specific 
scope. Then, "watches" can be bound to that scope and be automatically 
disabled when out of scope.

In other words, suppose that while inside some function I'm interested in 
value of "i + 10". Then, there are two choices:

  - Somehow record the scope where I'm interested in that expression,
    and show expression as disabled elsewhere.
  - Try to recompute the expression on each stop.

While the second approach at least guarantees that the expression will be 
re-evaluated each time I enter the "interesting" scope, it also involves a 
bit of extra work for re-evaluating it in other "uninteresting" scopes.

- Volodya

Re: -var-update and address changes

[Nick Roberts]

Vladimir Prus writes:
 > On Friday 14 April 2006 23:49, Jim Ingham wrote:
 > 
 > > Note as an aside, that we had to add another varobj type which is
 > > evaluated in the selected frame, whatever that happens to be.  That
 > > was useful for a general "variable inspector" window.  People wanted
 > > to put some expression there, and have it re-evaluated in the topmost
 > > frame whenever they stopped.  So we added that functionality.  But
 > > that is clearly distinct from what the "*" varobj type is supposed to
 > > mean.
 > 
 > Hi Jim,
 > is this "variable inspector" the same thing that's called "watches" in other 
 > IDEs? Well, I really wish that gdb did support variable objects that are 
 > reevaluated in the current frame. As it stands now, I have to re-create 
 > variable objects on each step.

Assuming some ambiguity with current/selected, have you tried (not documented):

"-var-create - @ NAME" 

which behaves a bit differently to "-var-create - * NAME".

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

Re: -var-update and address changes

[Vladimir Prus]

On Tuesday 02 May 2006 17:14, Nick Roberts wrote:
> Vladimir Prus writes:
>  > On Friday 14 April 2006 23:49, Jim Ingham wrote:
>  > > Note as an aside, that we had to add another varobj type which is
>  > > evaluated in the selected frame, whatever that happens to be.  That
>  > > was useful for a general "variable inspector" window.  People wanted
>  > > to put some expression there, and have it re-evaluated in the topmost
>  > > frame whenever they stopped.  So we added that functionality.  But
>  > > that is clearly distinct from what the "*" varobj type is supposed to
>  > > mean.
>  >
>  > Hi Jim,
>  > is this "variable inspector" the same thing that's called "watches" in
>  > other IDEs? Well, I really wish that gdb did support variable objects
>  > that are reevaluated in the current frame. As it stands now, I have to
>  > re-create variable objects on each step.
>
> Assuming some ambiguity with current/selected, have you tried (not
> documented):
>
> "-var-create - @ NAME"
>
> which behaves a bit differently to "-var-create - * NAME".

Wow, that's exactly what I'm looking for. Except that it's buggy :-(
When I have code like this:

  int foo()
  {
      long i = 15;
      printf("foo\n");
  }

  int main()
  {
    int i = 5;
    printf("hi 1\n");
    foo();
  }

and I use

  -var-create I @ i

right before call to 'foo()', then when I enter 'foo', -var-update correctly 
notices the change in value and in type. However, when I have:

  int foo()
  {
      long i = 15;
      printf("foo\n");
  }

  int main()
  {
    int i = 5;
    printf("hi 1\n");
    foo();
  }

then -var-update inside 'foo' does not report anything and 
-var-evaluate-expression still reports the value of 'i' from 'main'. Here's 
the faulty code (varobj.c: value_of_root):

    tmp_var = varobj_create (NULL, var->name, (CORE_ADDR) 0,
			       USE_SELECTED_FRAME);
     if (tmp_var == NULL)
	{
	  return NULL;
	}
     new_type = varobj_get_type (tmp_var);
     if (strcmp (old_type, new_type) == 0)
	{
	  varobj_delete (tmp_var, NULL, 0);
	  *type_changed = 0;
	}
     else

In other words, if the type of 'i' in the current frame happens to be the 
same, the newly created varobj is immediately deleted. What about patch along 
the following lines, that will create new varobj even if type is the same?

@@ -1641,28 +1741,14 @@
 	  return NULL;
 	}
       new_type = varobj_get_type (tmp_var);
-      if (strcmp (old_type, new_type) == 0)
-	{
-	  varobj_delete (tmp_var, NULL, 0);
-	  *type_changed = 0;
-	}
-      else
-	{
-	  if (*type_changed)
-	    {
-	      tmp_var->obj_name =
-		savestring (var->obj_name, strlen (var->obj_name));
-	      varobj_delete (var, NULL, 0);
-	    }
-	  else
-	    {
-	      tmp_var->obj_name = varobj_gen_name ();
-	    }
-	  install_variable (tmp_var);
-	  *var_handle = tmp_var;
-	  var = *var_handle;
-	  *type_changed = 1;
-	}
+      *type_changed = (strcmp (old_type, new_type) != 0);
+
+      tmp_var->obj_name =
+          savestring (var->obj_name, strlen (var->obj_name));
+      varobj_delete (var, NULL, 0);
+      install_variable (tmp_var);
+      *var_handle = tmp_var;
+      var = *var_handle;
     }

- Volodya

Re: -var-update and address changes

[Jim Ingham]

Shouldn't the call to var->root->lang->value_of_root down at the  
bottom of value_of_root take care of fetching the new value?  You  
don't want to discard the old varobj unless you have to, because if  
the varobj represents a structure or pointer to a structure and the  
user has fetched any children, or changed the format, or whatever,  
you will lose that state.

Also, I must be missing something this morning, but I can't see any  
difference between your two examples.

Jim

On May 2, 2006, at 6:40 AM, Vladimir Prus wrote:

> On Tuesday 02 May 2006 17:14, Nick Roberts wrote:
>> Vladimir Prus writes:
>>> On Friday 14 April 2006 23:49, Jim Ingham wrote:
>>>> Note as an aside, that we had to add another varobj type which is
>>>> evaluated in the selected frame, whatever that happens to be.  That
>>>> was useful for a general "variable inspector" window.  People  
>>>> wanted
>>>> to put some expression there, and have it re-evaluated in the  
>>>> topmost
>>>> frame whenever they stopped.  So we added that functionality.  But
>>>> that is clearly distinct from what the "*" varobj type is  
>>>> supposed to
>>>> mean.
>>>
>>> Hi Jim,
>>> is this "variable inspector" the same thing that's called  
>>> "watches" in
>>> other IDEs? Well, I really wish that gdb did support variable  
>>> objects
>>> that are reevaluated in the current frame. As it stands now, I  
>>> have to
>>> re-create variable objects on each step.
>>
>> Assuming some ambiguity with current/selected, have you tried (not
>> documented):
>>
>> "-var-create - @ NAME"
>>
>> which behaves a bit differently to "-var-create - * NAME".
>
> Wow, that's exactly what I'm looking for. Except that it's buggy :-(
> When I have code like this:
>
>   int foo()
>   {
>       long i = 15;
>       printf("foo\n");
>   }
>
>   int main()
>   {
>     int i = 5;
>     printf("hi 1\n");
>     foo();
>   }
>
> and I use
>
>   -var-create I @ i
>
> right before call to 'foo()', then when I enter 'foo', -var-update  
> correctly
> notices the change in value and in type. However, when I have:
>
>   int foo()
>   {
>       long i = 15;
>       printf("foo\n");
>   }
>
>   int main()
>   {
>     int i = 5;
>     printf("hi 1\n");
>     foo();
>   }
>
> then -var-update inside 'foo' does not report anything and
> -var-evaluate-expression still reports the value of 'i' from  
> 'main'. Here's
> the faulty code (varobj.c: value_of_root):
>
>     tmp_var = varobj_create (NULL, var->name, (CORE_ADDR) 0,
> 			       USE_SELECTED_FRAME);
>      if (tmp_var == NULL)
> 	{
> 	  return NULL;
> 	}
>      new_type = varobj_get_type (tmp_var);
>      if (strcmp (old_type, new_type) == 0)
> 	{
> 	  varobj_delete (tmp_var, NULL, 0);
> 	  *type_changed = 0;
> 	}
>      else
>
> In other words, if the type of 'i' in the current frame happens to  
> be the
> same, the newly created varobj is immediately deleted. What about  
> patch along
> the following lines, that will create new varobj even if type is  
> the same?
>
> @@ -1641,28 +1741,14 @@
>  	  return NULL;
>  	}
>        new_type = varobj_get_type (tmp_var);
> -      if (strcmp (old_type, new_type) == 0)
> -	{
> -	  varobj_delete (tmp_var, NULL, 0);
> -	  *type_changed = 0;
> -	}
> -      else
> -	{
> -	  if (*type_changed)
> -	    {
> -	      tmp_var->obj_name =
> -		savestring (var->obj_name, strlen (var->obj_name));
> -	      varobj_delete (var, NULL, 0);
> -	    }
> -	  else
> -	    {
> -	      tmp_var->obj_name = varobj_gen_name ();
> -	    }
> -	  install_variable (tmp_var);
> -	  *var_handle = tmp_var;
> -	  var = *var_handle;
> -	  *type_changed = 1;
> -	}
> +      *type_changed = (strcmp (old_type, new_type) != 0);
> +
> +      tmp_var->obj_name =
> +          savestring (var->obj_name, strlen (var->obj_name));
> +      varobj_delete (var, NULL, 0);
> +      install_variable (tmp_var);
> +      *var_handle = tmp_var;
> +      var = *var_handle;
>      }
>
> - Volodya
>

Re: -var-update and address changes

[Vladimir Prus]

On Tuesday 02 May 2006 21:22, Jim Ingham wrote:
> Shouldn't the call to var->root->lang->value_of_root down at the
> bottom of value_of_root take care of fetching the new value?  

Well, it fetches the new value, I believe.

> You 
> don't want to discard the old varobj unless you have to, because if
> the varobj represents a structure or pointer to a structure and the
> user has fetched any children, or changed the format, or whatever,
> you will lose that state.

Ah, that's right. In fact much of complexity in current KDevelop code is 
maintaining open/close state of items, so would be nice if gdb handled this.
Do you suggest that we don't create new varobj unless value change, or that we 
carry over all settings from the old one to the new?

>
> Also, I must be missing something this morning, but I can't see any
> difference between your two examples.

Ah, sorry, they are the same indeed. In the second example, the type of 'i' 
inside 'foo' function should be 'int'. In that case, gdb does not notice that 
name 'i' now refers to different variable.

- Volodya

Re: -var-update and address changes

[Vladimir Prus]

On Thursday 04 May 2006 18:50, Daniel Jacobowitz wrote:
> On Wed, May 03, 2006 at 10:02:21AM +0400, Vladimir Prus wrote:
> > On Tuesday 02 May 2006 21:22, Jim Ingham wrote:
> > > Shouldn't the call to var->root->lang->value_of_root down at the
> > > bottom of value_of_root take care of fetching the new value?
> >
> > Well, it fetches the new value, I believe.
>
> For the wrong frame.
>
> I've only lightly tested this; could you give it a try?  If it works, I
> think we should really get the "@" syntax added to the manual and
> testsuite.

This appears to work for a simple case of variable 'i' defined both in 'main' 
and in 'foo' called from main.

For the case where I'm stepping into 'bar' that has no 'i', -var-update 
correctly says that 'i' has gone out of scope. However, after -exec-finish, 
-var-update does not say that 'i' is not back in scope -- which would be nice 
if "@-varobjs" are to be used for watches.

Here's example I've used for testing:

include <stdio.h>

int foo()
{
    int i = 15;
    printf("foo\n");
}

int bar()
{
}

int main()
{
    int i = 5;
    printf("hi 1\n");
    foo();
    bar();
}

and example session:

b 19
&"b 19\n"
~"Breakpoint 1 at 0x804849e: file s.cpp, line 19.\n"
^done
(gdb)
r
&"r\n"
~"Starting program: /space/p2/ghost/build/mi-tests/a.out \n"
hi 1
foo
~"\n"
~"Breakpoint 1, main () at s.cpp:19\n"
~"19\t    bar();\n"
^done
(gdb)
-var-create I @ i
^done,name="I",numchild="0",type="int"
(gdb)
-exec-step
^running
(gdb)
*stopped,reason="end-stepping-range",thread-id="0",frame={addr="0x08048473",func="bar",args=[],file="s.cpp",fullname="/space/p2/ghost/build/mi-tests/s.cpp",line="12"}
(gdb)
-var-update *
^done,changelist=[{name="I",in_scope="false"}]
(gdb)
-exec-finish
^running
(gdb)
*stopped,reason="function-finished",thread-id="0",frame={addr="0x080484a3",func="main",args=[],file="s.cpp",fullname="/space/p2/ghost/build/mi-tests/s.cpp",line="20"},gdb-result-var="$1",return-value="4"
(gdb)
-var-update *
^done,changelist=[]
(gdb)
p i
&"p i\n"
~"$2 = 5"
~"\n"
^done
(gdb)

- Volodya

Re: -var-update and address changes

[Daniel Jacobowitz]

On Thu, May 04, 2006 at 07:11:46PM +0400, Vladimir Prus wrote:
> This appears to work for a simple case of variable 'i' defined both in 'main' 
> and in 'foo' called from main.
> 
> For the case where I'm stepping into 'bar' that has no 'i', -var-update 
> correctly says that 'i' has gone out of scope. However, after -exec-finish, 
> -var-update does not say that 'i' is not back in scope -- which would be nice 
> if "@-varobjs" are to be used for watches.

I'm not terribly surprised by this.  While I was fiddling with it I got
the feeling that the in-and-out-of-scope code was not very robust.  I'm
not going to try to debug this any further now, though - do you want to?


-- 
Daniel Jacobowitz
CodeSourcery

Re: -var-update and address changes

[Vladimir Prus]

On Thursday 04 May 2006 18:50, Daniel Jacobowitz wrote:
> On Wed, May 03, 2006 at 10:02:21AM +0400, Vladimir Prus wrote:
> > On Tuesday 02 May 2006 21:22, Jim Ingham wrote:
> > > Shouldn't the call to var->root->lang->value_of_root down at the
> > > bottom of value_of_root take care of fetching the new value?
> >
> > Well, it fetches the new value, I believe.
>
> For the wrong frame.
>
> I've only lightly tested this; could you give it a try?  If it works, I
> think we should really get the "@" syntax added to the manual and
> testsuite.
>
> The removed reinit_frame_cache is undoubtedly a performance suck.  I
> see no reason it should be necessary.  This code is still dubious;
> the select_frame call clobbers the selected frame and nothing ever
> restores it.

I believe that it's saved/restored in varobj_update.

- Volodya

Re: -var-update and address changes

[Daniel Jacobowitz]

On Fri, May 05, 2006 at 10:25:32AM +0400, Vladimir Prus wrote:
> On Thursday 04 May 2006 18:50, Daniel Jacobowitz wrote:
> > The removed reinit_frame_cache is undoubtedly a performance suck.  I
> > see no reason it should be necessary.  This code is still dubious;
> > the select_frame call clobbers the selected frame and nothing ever
> > restores it.
> 
> I believe that it's saved/restored in varobj_update.

Ah, you are correct.  Thanks.

-- 
Daniel Jacobowitz
CodeSourcery