This is the mail archive of the 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

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