This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On Sun, Dec 31, 2006 at 11:38:46AM +1300, Nick Roberts wrote:
> Currently variable objects consider a variable to be back in scope if a
> frame is re-entered.

Hmm.  Interesting... not sure if that's the most useful behavior -
frame re-entrance is a matter of a great deal of luck.

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

Probably not, but it would be up to the compiler.

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

That's not what I meant by leaving the block.  We'll appear to execute
a line inside the block, a line outside the block (from the same
function), and then a line inside the block again.  But I guess this is
not much different from calling a function, right?

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

Good, that's not bad at all.  If Vlad doesn't think this is likely to
break kdevelop or Eclipse, the patch is OK.

-- 
Daniel Jacobowitz
CodeSourcery


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]