Re: MI: Another -var-update bug? [PATCH]

[Nick Roberts <nickrob@snap.net.nz>]

 > Yeah.  My only concern about this is a variable going out of scope
 > which might then come back into scope.  That can't happen if the frame
 > is gone (unless something has changed), 

Currently variable objects consider a variable to be back in scope if a
frame is re-entered.

 >                                         but it can happen with blocks
 > once we support optimized blocks better (I posted a patch for this
 > once).
 > 
 > Here's an example.  Suppose we have this code:
 > 
 >   int func()
 >   {
 >     int i = foo();
 >     {
 >        int j = bar();
 >        j = j * j;
 >        i += j;
 >     }
 >     baz();
 >     return i;
 >   }
 > 
 > Since baz can't see i or j, it's legitimate for the compiler to move
 > the call to baz up to right after the call to bar.

That sounds like some kind of optimisation.  Does this happen with -O0?

 >                                                     Then we'll appear
 > to "leave" the block and "re-enter" it after another step.

Entering another function doesn't take existing variables out of scope
does it?  Block addresses are measured against the PC of the frame that
the variable is defined in.

 > Will the front end delete the varobj if it sees in_scope="false"?

I can't speak for others but in Emacs I just use a grey font for variables that
go out of scope and leave it to the user to explicily delete them.  The worst
scenario, if there is a problem at all, is that the watch expression would be
inexplicably greyed for one step.


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