Checking if addess is on stack?

Checking if addess is on stack?

[Vladimir Prus]

Hi,
in order to improve watchpoints handling in KDevelop, I need to figure out
if a given address is part of current frame's stack. Is there any command
to produce that information? I guess I can look at frame base address and
check if my address is "close" to that, but it's a bit unreliable.

For reference, the watchpoint changes for KDevelop are outlined at:

  http://lists.kde.org/?l=kdevelop-devel&m=114552206721831&w=2

TIA,
Volodya

Re: Checking if addess is on stack?

[Eli Zaretskii]

> From:  Vladimir Prus <ghost@cs.msu.su>
> Date:  Thu, 20 Apr 2006 12:49:53 +0400
> 
> in order to improve watchpoints handling in KDevelop, I need to figure out
> if a given address is part of current frame's stack. Is there any command
> to produce that information? I guess I can look at frame base address and
> check if my address is "close" to that, but it's a bit unreliable.
> 
> For reference, the watchpoint changes for KDevelop are outlined at:
> 
>   http://lists.kde.org/?l=kdevelop-devel&m=114552206721831&w=2

I think one way to solve the problems you describe in that URL is to
set a temporary breakpoint whose commands set the watchpoint:

   tb do_that
   commands
   > watch ptr->i
   > continue
   > end

(and similarly for block-local variables: put a breakpoint on the
block's first line).  If you want to keep the watchpoints between
sessions, record the temporary breakpoints and reinsert them when the
session starts.

Would this do what you want?

Re: Checking if addess is on stack?

[Vladimir Prus]

On Thursday 20 April 2006 14:22, Eli Zaretskii wrote:
> > From:  Vladimir Prus <ghost@cs.msu.su>
> > Date:  Thu, 20 Apr 2006 12:49:53 +0400
> >
> > in order to improve watchpoints handling in KDevelop, I need to figure
> > out if a given address is part of current frame's stack. Is there any
> > command to produce that information? I guess I can look at frame base
> > address and check if my address is "close" to that, but it's a bit
> > unreliable.
> >
> > For reference, the watchpoint changes for KDevelop are outlined at:
> >
> >   http://lists.kde.org/?l=kdevelop-devel&m=114552206721831&w=2
>
> I think one way to solve the problems you describe in that URL is to
> set a temporary breakpoint whose commands set the watchpoint:
>
>    tb do_that
>    commands
>
>    > watch ptr->i
>    > continue
>    > end
>
> (and similarly for block-local variables: put a breakpoint on the
> block's first line).  If you want to keep the watchpoints between
> sessions, record the temporary breakpoints and reinsert them when the
> session starts.
>
> Would this do what you want?

I'm not sure that's exactly what I need. This way, watchpoint will be 
automatically inserted when I enter 'do_that', but as soon as I leave 
'do_that', gdb will remove wathchpoint because 'ptr' has gone out of scope. 
This will prevent me from catching accesses to ptr->i made outside of the 
function where 'ptr' is valid. Am I missing something?

Thanks,
Volodya

Re: Checking if addess is on stack?

[Eli Zaretskii]

> From: Vladimir Prus <ghost@cs.msu.su>
> Date: Thu, 20 Apr 2006 14:26:58 +0400
> Cc: gdb@sources.redhat.com
> 
> I'm not sure that's exactly what I need. This way, watchpoint will be 
> automatically inserted when I enter 'do_that', but as soon as I leave 
> 'do_that', gdb will remove wathchpoint because 'ptr' has gone out of scope. 
> This will prevent me from catching accesses to ptr->i made outside of the 
> function where 'ptr' is valid. Am I missing something?

Perhaps _I_ am missing something.  Isn't `ptr' a variable that is
local to the function `do_that'?  I thought it was; if so, then it
couldn't possibly be accessed after `do_that' returns, because all
locals are popped off the stack when `do_that' returns.  These locals
will get entirely new values when `do_that' is entered the next time.

(If you want to catch accesses to the address where `ptr' _was_ on the
stack, then you really need to set the wathchpoint on an absolute
address.  But watching addresses on the stack beyond the stack top is
a very unusual thing to do, so I don't think this is what your users
would need.)

OTOH, if by ``leave `do_that''' you mean that `do_that' calls some
other function, then `ptr' does not go off the scope, and GDB should
not delete the watchpoint.

Does this make sense?

Re: Checking if addess is on stack?

[Vladimir Prus]

On Thursday 20 April 2006 15:42, Eli Zaretskii wrote:
> > From: Vladimir Prus <ghost@cs.msu.su>
> > Date: Thu, 20 Apr 2006 14:26:58 +0400
> > Cc: gdb@sources.redhat.com
> >
> > I'm not sure that's exactly what I need. This way, watchpoint will be
> > automatically inserted when I enter 'do_that', but as soon as I leave
> > 'do_that', gdb will remove wathchpoint because 'ptr' has gone out of
> > scope. This will prevent me from catching accesses to ptr->i made outside
> > of the function where 'ptr' is valid. Am I missing something?
>
> Perhaps _I_ am missing something.  Isn't `ptr' a variable that is
> local to the function `do_that'?  I thought it was; if so, then it
> couldn't possibly be accessed after `do_that' returns, because all
> locals are popped off the stack when `do_that' returns.  These locals
> will get entirely new values when `do_that' is entered the next time.
>
> (If you want to catch accesses to the address where `ptr' _was_ on the
> stack, then you really need to set the wathchpoint on an absolute
> address.  

Precisely, I want to catch accesses to a specific address, and I want that to 
be the only (or at least default) behaviour in KDevelop. That is, if user 
types in any expression, KDevelop will compute the address of that expression 
and set watchpoint on address.

The rationale is that in the case I've given:

  void do_that(My_class* ptr)
  {     
                ptr->i = .....;
                ........
  }

user most likely wants to catch all future accesses to variable 'i', and does 
not care if those accesses go via 'ptr' in 'do_that', or via some other 
pointer variable in some other function.

> But watching addresses on the stack beyond the stack top is 
> a very unusual thing to do, so I don't think this is what your users
> would need.)

Exactly, so I want to detect the case where address in on the stack, and in 
that case disable the watchpoint when function exists. But there's no easy 
way to detect if address is on stack, and that's the problem.

- Volodya

Re: Checking if addess is on stack?

[Eli Zaretskii]

> From: Vladimir Prus <ghost@cs.msu.su>
> Date: Thu, 20 Apr 2006 15:48:35 +0400
> Cc: gdb@sources.redhat.com
> 
> > (If you want to catch accesses to the address where `ptr' _was_ on the
> > stack, then you really need to set the wathchpoint on an absolute
> > address.  
> 
> Precisely, I want to catch accesses to a specific address, and I want that to 
> be the only (or at least default) behaviour in KDevelop. That is, if user 
> types in any expression, KDevelop will compute the address of that expression 
> and set watchpoint on address.

I think if this will be the only behavior, users might not like it.

The reason is that users will sometimes wish to be notified when the
value of `ptr' changes as well, (it depends on what problem they are
debugging), since changing the value of `ptr' in most cases changes
`ptr->i' also.  GDB already does the necessary footwork, i.e. when
you say "watch ptr->i", it sets watchpoints on both `ptr' and `ptr->i'
(and in general on all the addresses of variables that participate in
a watched expression).  But if you replace `ptr->i' with its address,
you will not be notified when the value of `ptr' changes, and will
continue to watch the (now stale) address.  Sometimes, that is what
the user wants, but sometimes it isn't, and you will never know which
case you are facing.

Anyway, please note that this issue has nothing to do with leaving the
scope of the block where `ptr->i' was defined: when program leaves
that scope, there's no interesting accesses to &ptr->i that you want
to show your users; in particular, that address may be occupied by a
totally different local variable from a different function, in which
case accesses to that address are valid and don't affect future
invocations of `do_that' in any way (unless it uses local variables
without initializing them first).

> The rationale is that in the case I've given:
> 
>   void do_that(My_class* ptr)
>   {     
>                 ptr->i = .....;
>                 ........
>   }
> 
> user most likely wants to catch all future accesses to variable 'i', and does 
> not care if those accesses go via 'ptr' in 'do_that', or via some other 
> pointer variable in some other function.

I think setting a watchpoint on `ptr->i' will do what you want here:
it will watch _any_ accesses to that address, because GDB actually
computes the address and places a watchpoint there.  So no matter how
was the address accessed, the watchpoint will trigger.

Do you have any specific examples where this logic does not work?  If
so, please show those examples.

> Exactly, so I want to detect the case where address in on the stack, and in 
> that case disable the watchpoint when function exists. But there's no easy 
> way to detect if address is on stack, and that's the problem.

Well, I thought the trick with tb does the equivalent of what you
wanted.  It automatically inserts the watchpoint when the scope is
entered, while its deletion is handled by GDB itself.  Next time the
function is entered, GDB will insert the watchpoint again.  Isn't that
what you want, as far as the variable-out-of-scope issue is
considered?  (Whether to watch the address or the expression is a
different matter, as mentioned above.)

Re: Checking if addess is on stack?

[Daniel Jacobowitz]

On Thu, Apr 20, 2006 at 03:21:03PM +0300, Eli Zaretskii wrote:
> Well, I thought the trick with tb does the equivalent of what you
> wanted.  It automatically inserts the watchpoint when the scope is
> entered, while its deletion is handled by GDB itself.  Next time the
> function is entered, GDB will insert the watchpoint again.  Isn't that
> what you want, as far as the variable-out-of-scope issue is
> considered?  (Whether to watch the address or the expression is a
> different matter, as mentioned above.)

What he wants is not to stop the watchpoint when ptr goes out of scope,
but when ptr->i goes out of scope - if ptr points to a stack allocated
variable, in this function or another one.

Sorry, Vladimir, there's no way to do this.  You'd have to keep an eye
on the value of $sp manually, and know whether the stack grew up or
down.  Even that wouldn't help enough, since you might miss a stack pop
and push.  There's no way to keep track of register values in the way
we can watchpoint memory.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Checking if addess is on stack?

[Eli Zaretskii]

> Date: Thu, 20 Apr 2006 08:49:04 -0400
> From: Daniel Jacobowitz <drow@false.org>
> 
> What he wants is not to stop the watchpoint when ptr goes out of scope,
> but when ptr->i goes out of scope - if ptr points to a stack allocated
> variable, in this function or another one.

Sorry, I'm probably too dumb and so am still in the woods--could you
provide an example of such a situation?

Specifically, where is ptr allocated--is it itself on the stack or
somewhere else?

Re: Checking if addess is on stack?

[Daniel Jacobowitz]

On Thu, Apr 20, 2006 at 05:27:51PM +0300, Eli Zaretskii wrote:
> > Date: Thu, 20 Apr 2006 08:49:04 -0400
> > From: Daniel Jacobowitz <drow@false.org>
> > 
> > What he wants is not to stop the watchpoint when ptr goes out of scope,
> > but when ptr->i goes out of scope - if ptr points to a stack allocated
> > variable, in this function or another one.
> 
> Sorry, I'm probably too dumb and so am still in the woods--could you
> provide an example of such a situation?
> 
> Specifically, where is ptr allocated--is it itself on the stack or
> somewhere else?

Everything's clearer with code!  Let's try this.

struct kind {
  int i;
};

void func1 (void)
{
  struct kind kin;

  func2 (&kin);
}

void func2 (struct kind *my_kin)
{
  struct kind *ptr = my_kin;
  /* HERE */
}

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.  DON'T try "watch *$"!  It will
      re-evaluate the expression when you next stop and get a different
      value for $ !)

  (B) For that watchpoint to go out of scope when kin.i, the underlying
      object, dies.

      Put this way, it's apparent that there is really no way to do
      this.  We could approximate it; we could figure out that it
      belonged to a frame, but not its scope within that frame.
      Well, I suppose we could... we could calculate the addresses
      of all locals of that frame within the current block and
      work out inside which one it was.

      -> Would that actually be neat and useful for the CLI?

(gdb) print $31
$32 = (int *) 0x44444444 <kin.i in frame #3>

-- 
Daniel Jacobowitz
CodeSourcery

Re: Checking if addess is on stack?

[Eli Zaretskii]

> Date: Thu, 20 Apr 2006 10:39:44 -0400
> From: Daniel Jacobowitz <drow@false.org>
> 
> Everything's clearer with code!

It is, thanks.

> struct kind {
>   int i;
> };
> 
> void func1 (void)
> {
>   struct kind kin;
> 
>   func2 (&kin);
> }
> 
> void func2 (struct kind *my_kin)
> {
>   struct kind *ptr = my_kin;
>   /* HERE */
> }
> 
> 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.

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

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

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

Re: Checking if addess is on stack?

[Daniel Jacobowitz]

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

Re: Checking if addess is on stack?

[Eli Zaretskii]

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

Re: Checking if addess is on stack?

[Daniel Jacobowitz]

On Thu, Apr 20, 2006 at 10:03:11PM +0300, Eli Zaretskii wrote:
> 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.

It depends what you're debugging, of course.  I'm generally debugging
"something in the list is wrong, later, in another function";
"something in this function clobbered the loop pointer" is much rarer.
That's likely to be in a register, for instance.

I think that the idea of watching expression values is useful as an
option, but if there's more than one memory location involved I can't
think when the last time I wanted the current behavior was.  And I find
it very unintuitive that "print &foo->bar; watch *$31" is not the same
as "watch foo->bar" (and that the former is so cumbersome).

But I'm not suggesting changing our behavior at this late date.

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

I would believe that it is more often correct, especially if the GUI is
used to set the watchpoint - if I clicked on a member of a structure and
said "watch this", I'd mean the member, not whatever expression I followed
to get that window to pop up.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Checking if addess is on stack?

[Vladimir Prus]

On Thursday 20 April 2006 16:21, Eli Zaretskii wrote:

> > The rationale is that in the case I've given:
> >
> >   void do_that(My_class* ptr)
> >   {
> >                 ptr->i = .....;
> >                 ........
> >   }
> >
> > user most likely wants to catch all future accesses to variable 'i', and
> > does not care if those accesses go via 'ptr' in 'do_that', or via some
> > other pointer variable in some other function.
>
> I think setting a watchpoint on `ptr->i' will do what you want here:
> it will watch _any_ accesses to that address, because GDB actually
> computes the address and places a watchpoint there.  So no matter how
> was the address accessed, the watchpoint will trigger.
>
> Do you have any specific examples where this logic does not work?  If
> so, please show those examples.

void set(int* ptr)
{
    *ptr = 10;
}

void modify(int* ptr)
{
    *ptr = 15;
}

int main()
{
    int i;
    set(&i);
    modify(&i);
    return 0;
}

I get this debug session with gdb 6.4:

(gdb) b set
Breakpoint 1 at 0x8048397: file main.cpp, line 4.
(gdb) r
Starting program: /tmp/mi/a.out

Breakpoint 1, set (ptr=0xbf967374) at main.cpp:4
4           *ptr = 10;
(gdb) n
5       }
(gdb) watch *ptr
Hardware watchpoint 2: *ptr
(gdb) c
Continuing.
Hardware watchpoint 2 deleted because the program has left the block
in which its expression is valid.

Program exited normally.
(gdb)

I don't watch watchpoint 2 to be deleted in this case.

> > Exactly, so I want to detect the case where address in on the stack, and
> > in that case disable the watchpoint when function exists. But there's no
> > easy way to detect if address is on stack, and that's the problem.
>
> Well, I thought the trick with tb does the equivalent of what you
> wanted.  It automatically inserts the watchpoint when the scope is
> entered, while its deletion is handled by GDB itself.  Next time the
> function is entered, GDB will insert the watchpoint again.  Isn't that
> what you want, as far as the variable-out-of-scope issue is
> considered?  (Whether to watch the address or the expression is a 
> different matter, as mentioned above.)

I want to set breakpoint at address, and be it automatically removed when 
leaving function, if and only if the address is on function stack.

In current gdb, I can either:
1. Set watchpoint on expression, and it will be always deleted, like in above 
case.
2. Set watchpoint on address, and it won't be ever deleted.

- Volodya

Re: Checking if addess is on stack?

[Eli Zaretskii]

> From: Vladimir Prus <ghost@cs.msu.su>
> Date: Thu, 20 Apr 2006 19:31:37 +0400
> Cc: gdb@sources.redhat.com
> 
> (gdb) watch *ptr
> Hardware watchpoint 2: *ptr
> (gdb) c
> Continuing.
> Hardware watchpoint 2 deleted because the program has left the block
> in which its expression is valid.
> 
> Program exited normally.
> (gdb)
> 
> I don't watch watchpoint 2 to be deleted in this case.

You could put 2 watchpoints instead of one, as in the session attached
at the end of this message.  (Yes, I know that it triggers outside
`main', but that's what we have now.)

> I want to set breakpoint at address, and be it automatically removed when 
> leaving function, if and only if the address is on function stack.

Doing this in all cases would be a misfeature, for the reasons I tried
to explain: users normally expect us to stop the program when any one
of the variables which contribute to an expression's value are
modified.

> In current gdb, I can either:
> 1. Set watchpoint on expression, and it will be always deleted, like in above 
> case.
> 2. Set watchpoint on address, and it won't be ever deleted.

I suggested a possible enhancement to watchpoints to do better, but
someone will have to code it (assuming that people agree with my
suggestion).


D:\usr\eli\data>gdb ./dbw.exe
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-mingw32"...
(gdb) b set
Breakpoint 1 at 0x401293: file dbw.c, line 3.
(gdb) r
Starting program: D:\usr\eli\data/./dbw.exe

Breakpoint 1, set (ptr=0x22ff74) at dbw.c:3
3           *ptr = 10;
(gdb) watch *ptr
Hardware watchpoint 2: *ptr
(gdb) p/x ptr
$1 = 0x22ff74
(gdb) watch *(int *)$1
Hardware watchpoint 3: *(int *) $1
(gdb) c
Continuing.
Hardware watchpoint 2: *ptr

Old value = 2
New value = 10
Hardware watchpoint 4: *(int *) $1

Old value = 2
New value = 10
set (ptr=0x22ff74) at dbw.c:4
4       }
(gdb) c
Continuing.

Watchpoint 2 deleted because the program has left the block in
which its expression is valid.
main () at dbw.c:15
15          modify(&i);
(gdb) c
Continuing.
Hardware watchpoint 4: *(int *) $1

Old value = 10
New value = 15
modify (ptr=0x22ff74) at dbw.c:9
9       }
(gdb) c
Continuing.
Hardware watchpoint 4: *(int *) $1

Old value = 15
New value = 0
0x77c39ebb in msvcrt!_cexit ()
(gdb) c
Continuing.
Hardware watchpoint 4: *(int *) $1

Old value = 0
New value = -1
0x7c81caa9 in KERNEL32!ExitProcess () from C:\WINDOWS\system32\kernel32.dll
(gdb) c
Continuing.

Program exited normally.
(gdb)