From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-26638-listarch-gdb=sources.redhat.com@sourceware.org>
Received: (qmail 24262 invoked by alias); 22 Oct 2006 22:22:35 -0000
Received: (qmail 24253 invoked by uid 22791); 22 Oct 2006 22:22:33 -0000
X-Spam-Check-By: sourceware.org
Received: from nitzan.inter.net.il (HELO nitzan.inter.net.il) (192.114.186.20)     by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 22 Oct 2006 22:22:32 +0000
Received: from HOME-C4E4A596F7 (IGLD-84-228-212-131.inter.net.il [84.228.212.131]) 	by nitzan.inter.net.il (MOS 3.7.3a-GA) 	with ESMTP id EZF32486 (AUTH halo1); 	Mon, 23 Oct 2006 00:22:27 +0200 (IST)
Date: Sun, 22 Oct 2006 22:22:00 -0000
Message-Id: <ud58kvvmk.fsf@gnu.org>
From: Eli Zaretskii <eliz@gnu.org>
To: Daniel Jacobowitz <drow@false.org>
CC: rodney.bates@wichita.edu, gdb@sourceware.org
In-reply-to: <20061022172431.GA15887@nevyn.them.org> (message from Daniel 	Jacobowitz on Sun, 22 Oct 2006 13:24:31 -0400)
Subject: Re: breakpoint for accessing memory location
Reply-to: Eli Zaretskii <eliz@gnu.org>
References: <4537DBC6.1030807@hccnet.nl> <20061019201214.GA32332@nevyn.them.org> <4537DEDC.5000008@hccnet.nl> <u4ptzqz0b.fsf@gnu.org> <453A3758.5090602@wichita.edu> <ufydhpu0o.fsf@gnu.org> <453A6D1D.1080009@wichita.edu> <ubqo5pc7y.fsf@gnu.org> <453B8C22.3010206@wichita.edu> <20061022172431.GA15887@nevyn.them.org>
X-IsSubscribed: yes
Mailing-List: contact gdb-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Subscribe: <mailto:gdb-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb/>
List-Post: <mailto:gdb@sourceware.org>
List-Help: <mailto:gdb-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-owner@sourceware.org
X-SW-Source: 2006-10/txt/msg00200.txt.bz2

> Date: Sun, 22 Oct 2006 13:24:31 -0400
> From: Daniel Jacobowitz <drow@false.org>
> Cc: Eli Zaretskii <eliz@gnu.org>, gdb@sourceware.org
> 
> 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.

Don't we record the frame in the watchpoint structure?  If so, the
watchpoint is deleted when its frame is popped off the stack.