From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21748 invoked by alias); 22 Oct 2006 17:24:38 -0000 Received: (qmail 21738 invoked by uid 22791); 22 Oct 2006 17:24:37 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Sun, 22 Oct 2006 17:24:35 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1Gbh3o-00049D-0O; Sun, 22 Oct 2006 13:24:32 -0400 Date: Sun, 22 Oct 2006 17:24:00 -0000 From: Daniel Jacobowitz To: "Rodney M. Bates" Cc: Eli Zaretskii , gdb@sourceware.org Subject: Re: breakpoint for accessing memory location Message-ID: <20061022172431.GA15887@nevyn.them.org> Mail-Followup-To: "Rodney M. Bates" , Eli Zaretskii , gdb@sourceware.org References: <4537DBC6.1030807@hccnet.nl> <20061019201214.GA32332@nevyn.them.org> <4537DEDC.5000008@hccnet.nl> <453A3758.5090602@wichita.edu> <453A6D1D.1080009@wichita.edu> <453B8C22.3010206@wichita.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <453B8C22.3010206@wichita.edu> User-Agent: Mutt/1.5.13 (2006-08-11) 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/msg00194.txt.bz2 On Sun, Oct 22, 2006 at 10:20:02AM -0500, Rodney M. Bates wrote: > 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? When the debug info says it goes out of scope, or more specifically, when GDB no longer knows where to find it. > 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? We have no way of knowing this, nor is it generally desirable (that could be the very bug you are chasing). > 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. Ditto. -- Daniel Jacobowitz CodeSourcery