Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Vladimir Prus <ghost@cs.msu.su>
Cc: gdb@sources.redhat.com
Subject: Re: Checking if addess is on stack?
Date: Thu, 20 Apr 2006 14:27:00 -0000	[thread overview]
Message-ID: <u8xq0wi8g.fsf@gnu.org> (raw)
In-Reply-To: <200604201548.36899.ghost@cs.msu.su> (message from Vladimir Prus 	on Thu, 20 Apr 2006 15:48:35 +0400)

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


  reply	other threads:[~2006-04-20 12:21 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-04-20 10:27 Vladimir Prus
2006-04-20 11:42 ` Eli Zaretskii
2006-04-20 11:48   ` Vladimir Prus
2006-04-20 12:21     ` Eli Zaretskii
2006-04-20 12:49       ` Vladimir Prus
2006-04-20 14:27         ` Eli Zaretskii [this message]
2006-04-20 14:39           ` Daniel Jacobowitz
2006-04-20 15:24             ` Eli Zaretskii
2006-04-20 15:32               ` Daniel Jacobowitz
2006-04-20 18:41                 ` Eli Zaretskii
2006-04-20 19:12                   ` Daniel Jacobowitz
2006-04-21 11:45                     ` Eli Zaretskii
2006-04-22  8:06                       ` Daniel Jacobowitz
2006-04-20 16:29           ` Vladimir Prus
2006-04-20 19:03             ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=u8xq0wi8g.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=gdb@sources.redhat.com \
    --cc=ghost@cs.msu.su \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox