Re: Checking if addess is on stack?

[Daniel Jacobowitz <drow at false dot org>]

On Thu, Apr 20, 2006 at 09:26:04PM +0300, Eli Zaretskii wrote:
> > We're at HERE.  I believe that what Vladimir wants is:
> >   (A) a watchpoint on the value referenced by ptr->i, at the moment,
> >       regardless of future changes to ptr.  I do this all the time
> >       and wouldn't mind an easier way, but it's just:
> >          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.

> >   (B) For that watchpoint to go out of scope when kin.i, the underlying
> >       object, dies.
> 
> 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.

> >       Put this way, it's apparent that there is really no way to do
> >       this.
> 
> 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.

> >       -> Would that actually be neat and useful for the CLI?
> > 
> > (gdb) print $31
> > $32 = (int *) 0x44444444 <kin.i in frame #3>
> 
> Doesn't "info symbol $31" do this already?

I believe only for global variables, not for locals on the stack.

-- 
Daniel Jacobowitz
CodeSourcery