Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: "Rodney M. Bates" <rodney.bates@wichita.edu>
To: Eli Zaretskii <eliz@gnu.org>
Cc: gdb@sourceware.org
Subject: Re: breakpoint for accessing memory location
Date: Sun, 22 Oct 2006 15:20:00 -0000	[thread overview]
Message-ID: <453B8C22.3010206@wichita.edu> (raw)
In-Reply-To: <ubqo5pc7y.fsf@gnu.org>



Eli Zaretskii wrote:
>>Date: Sat, 21 Oct 2006 13:55:25 -0500
>>From: "Rodney M. Bates" <rodney.bates@wichita.edu>
>>CC:  gdb@sourceware.org
>>
>>What if I put a watch on p->f where there is a visible p, then execution
>>goes somewhere where p is not visible, but p still exists?  For example,
>>suppose p is local to function foo, and foo calls non-nested function bar.
> 
> 
> This doesn't qualify as going out of scope, because p is still on the
> stack.  Only when the function where p is declared returns, will p go
> out of scope and the watchpoint be deleted.
> 
> 
>>Or, I haven't placed the watch yet and first stop execution in bar.  Can
>>I now place this watch after moving up the stack to foo's frame?
> 
> 
> Yes, because p is in scope in any function called from foo.

Ah, so "goes out of scope" means means "is deallocated", not "becomes not
visible by the scope rules".  I guess I should have gotten that from
"when the execution leaves the block in which these variables were defined".

So the pattern I think I now see is this:  The constant reevaluation of the
expression involves reevaluating the operators and resampling the contents
of the variables, but not relooking the variables up by name.  Which means
my mention of changing context is irrelevant, because it would only affect
looking up by name.

Instead, the lookup of names is done exactly once, when the expression is
typed by the user, in the context of the current frame.  Thereafter, the only
context changes that matter are deallocation of one of the variables.  Do I
have it right?

If so, it still leaves me with a couple of different questions about things
that seem hard to implement:

If p is local to an inner block, but the compiler did the common thing of
flattening p and all its cousins into one activation record for the containing
function, does the watchpoint really get deleted when execution leaves the
block, or when the containing function returns?

If the expression is *p and p stays in scope, but points to a local variable
that goes out of scope, does the watch get deleted then?

Presumably, if p points to a heap object that is deallocated, this is too
hard to detect and the watchpoint remains on the machine address.  Since
"deallocation" is often done by programmer-written allocators that the
language has no knowledge of, it would be hard to even define what it
means to deallocate.
> 

-- 
-------------------------------------------------------------
Rodney M. Bates, retired assistant professor
Dept. of Computer Science, Wichita State University
Wichita, KS 67260-0083
316-978-3922
rodney.bates@wichita.edu


  reply	other threads:[~2006-10-22 15:20 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-19 20:10 Erik Leunissen
2006-10-19 20:12 ` Daniel Jacobowitz
2006-10-19 20:24   ` Erik Leunissen
2006-10-19 20:25     ` Daniel Jacobowitz
2006-10-19 20:28       ` Erik Leunissen
2006-10-20  6:31     ` Eli Zaretskii
2006-10-20 14:27       ` Daniel Jacobowitz
2006-10-21 13:20         ` [commit] Fix annotations-related index entries (was: breakpoint for accessing memory location) Eli Zaretskii
2006-10-20 16:56       ` breakpoint for accessing memory location Erik Leunissen
2006-10-20 17:39         ` Eli Zaretskii
2006-10-21 12:58         ` Eli Zaretskii
2006-10-21 22:28           ` Erik Leunissen
2006-10-22  4:20             ` Eli Zaretskii
2006-10-22  9:11               ` Erik Leunissen
2006-10-22  9:19                 ` Erik Leunissen
2006-10-22 22:16                 ` Eli Zaretskii
2006-10-23  7:41                   ` Erik Leunissen
2006-10-21 15:06       ` Rodney M. Bates
2006-10-21 15:27         ` Daniel Jacobowitz
2006-10-21 15:29         ` Eli Zaretskii
2006-10-21 15:51           ` Daniel Jacobowitz
2006-10-21 21:26             ` Eli Zaretskii
2006-10-21 22:32               ` Daniel Jacobowitz
2006-10-22  4:18                 ` Eli Zaretskii
2006-10-22  4:22                   ` Daniel Jacobowitz
2006-10-22 12:18                     ` Robert Dewar
2006-10-22 22:18                       ` Eli Zaretskii
2006-10-22 22:21                         ` Daniel Jacobowitz
2006-10-22 22:29                           ` Eli Zaretskii
2006-10-22 22:49                             ` Robert Dewar
2006-10-22 23:18                             ` Daniel Jacobowitz
2006-10-23  2:03                               ` Robert Dewar
2006-10-23  4:11                               ` Eli Zaretskii
2006-10-23 12:36                                 ` Daniel Jacobowitz
2006-10-22 22:48                         ` Robert Dewar
2006-10-22 22:51                           ` Eli Zaretskii
2006-10-22 22:55                             ` Robert Dewar
2006-10-23  4:10                               ` Eli Zaretskii
2006-10-22 20:40                     ` Mark Kettenis
2006-10-21 18:07           ` Rodney M. Bates
2006-10-21 21:42             ` Eli Zaretskii
2006-10-21 18:55           ` Rodney M. Bates
2006-10-21 21:53             ` Eli Zaretskii
2006-10-22 15:20               ` Rodney M. Bates [this message]
2006-10-22 17:24                 ` Daniel Jacobowitz
2006-10-22 22:22                   ` Eli Zaretskii
2006-10-23 22:02                     ` Jim Blandy
2006-10-24  4:32                       ` Eli Zaretskii
2006-10-24 12:57                         ` Daniel Jacobowitz
2006-10-24 17:37                           ` Eli Zaretskii
2006-10-24 17:41                             ` Daniel Jacobowitz

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=453B8C22.3010206@wichita.edu \
    --to=rodney.bates@wichita.edu \
    --cc=eliz@gnu.org \
    --cc=gdb@sourceware.org \
    /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