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: Checking if addess is on stack?

> From: Vladimir Prus <>
> Date: Thu, 20 Apr 2006 15:48:35 +0400
> Cc:
> > (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.)

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