Re: Checking if addess is on stack?

[Eli Zaretskii <eliz at gnu dot org>]

> Date: Thu, 20 Apr 2006 14:41:53 -0400
> From: Daniel Jacobowitz <drow@false.org>
> 
> > >          print &ptr->i
> > >          watch *$31
> > >       (Where $31 is the right number.
> > 
> > But "watch ptr->i" already does that for you.  Except that it _also_
> > watches &ptr, and that latter address is what goes out of scope when
> > we leave func2.
> 
> These two are not at all the same.  Suppose ptr is being walked along a
> linked list.  The user might be interested in the expression "ptr->i",
> but in my experience that's almost never what I want if ptr is moving;
> instead, I am interested in (for example) something scribbling over
> this particular element of the linked list.  I don't care when ptr goes
> out of scope, or when ptr is changed.  I'm interested in the memory.

That's one possible situation, sure.  But there are others: someone
could be scribbling over ptr->i by inadvertently changing ptr itself.

If you think this latter situation is unlikely or uninteresting, you
in effect say that our whole concept of watching expression values is
wrong.

> > So perhaps we need to modify the watchpoint machinery so that when
> > func2 returns, we stop watching the parts of the expression that are
> > popped from the stack, but continue watching those which are still
> > valid and in scope.  Would that make sense?
> 
> I don't understand.  How could we continue watching anything, if we can
> no longer evaluate the expression?  None of the expression is still in
> scope.

But this particular expression's result is just an address, and that
address can be watched without recomputing the expression.

> > I think it can be achieved with setting 2 watchpoints: one on
> > "ptr->i", the other on the address it points to.
> 
> That will catch when ptr goes out of scope, but we don't care about
> that.  In my example, ptr goes out of scope in one function, but the
> thing it points to doesn't go "out of scope" until much later.

In your example, you (the user) knew what you were after.  I was
arguing that doing this always in a front end, like what Vladimir was
suggesting, might not be what users expect in each particular case.