From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7539 invoked by alias); 21 Oct 2006 18:07:12 -0000 Received: (qmail 7360 invoked by uid 22791); 21 Oct 2006 18:07:10 -0000 X-Spam-Check-By: sourceware.org Received: from centrmmtao04.cox.net (HELO centrmmtao04.cox.net) (70.168.83.80) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 21 Oct 2006 18:07:06 +0000 Received: from eastrmimpo02.cox.net ([68.1.16.120]) by centrmmtao04.cox.net (InterMail vM.6.01.06.01 201-2131-130-101-20060113) with ESMTP id <20061021180706.ZKPO16408.centrmmtao04.cox.net@eastrmimpo02.cox.net>; Sat, 21 Oct 2006 14:07:06 -0400 Received: from [192.168.1.2] ([68.102.92.133]) by eastrmimpo02.cox.net with bizsmtp id d66R1V00b2seT0L0000000 Sat, 21 Oct 2006 14:06:26 -0400 Message-ID: <453A61C5.5010605@wichita.edu> Date: Sat, 21 Oct 2006 18:07:00 -0000 From: "Rodney M. Bates" User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050322) MIME-Version: 1.0 To: Eli Zaretskii CC: gdb@sourceware.org Subject: Re: breakpoint for accessing memory location References: <4537DBC6.1030807@hccnet.nl> <20061019201214.GA32332@nevyn.them.org> <4537DEDC.5000008@hccnet.nl> <453A3758.5090602@wichita.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-10/txt/msg00178.txt.bz2 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