This is the mail archive of the gdb@sourceware.org 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: breakpoint for accessing memory location




Eli Zaretskii wrote:

Are there any more examples beyond p->f?  That is, what other
situations are there where the context can matter?  Are we talking
only about portions of expression going out of context (and thus
becoming invalid), or are there other problems?

(You see, I don't think I understand what you mean by ``the semantics
of evaluating a watchpoint expression'', and a single example you gave
is not enough for me to figure that out.)


Well, an expression in a program is always interpreted by looking up any unqualified identifiers according to the scope rules, at the place in the code where the expression appears. But with a watchpoint, that place keeps changing. p can go out of scope, come back in, or a different p could become visible. So more example questions (same expression, different contexts):

If execution gets to where there is no p visible, does the watch get
permanently disabled?  Does execution stop?  Does the watch just get ignored
for now.  If execution comes back into the original scope, does the
expression start getting watched again?

If execution goes somewhere where a different p is visible, does the
watch get disabled?  temporarily ignored?  Is the expression reevaluated
using the new p?  What if this is type-incorrect (e.g. p is not a pointer, or
points to something that doesn't have an f)?  What if a different p points
to the same struct type or a different struct type that also has an f,
and the second f is the same type as the first, or a different type?

What if p is a variable in the original context but a type name in a later
context?  (Maybe there are no expressions that would be legal both ways?)

If the expression is illegal at the place where the program is stopped
when the watch is typed, is it rejected then and there, or kept around
in case, e.g., a p comes into scope.

I realize that the answer to one of my first questions could make the rest
of them irrelevant.  And I presume that just a change in the value of the
same p, while it remains in scope, means the watch now looks for changes to
the f of the new struct p points to, but even this might be worth explaining
explicitly.

As for different expressions, the only thing I think of that could matter
is each occurrence of an unqualified identifier, and these would all presumably
be independent.

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


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