Re: breakpoint for accessing memory location

Rodney M. Bates
2006-10-22T15:20:10Z

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