From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19204 invoked by alias); 2 May 2002 15:43:09 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 19190 invoked from network); 2 May 2002 15:43:08 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 2 May 2002 15:43:08 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 6A3553D74; Thu, 2 May 2002 11:43:10 -0400 (EDT) Message-ID: <3CD15E8E.3020100@cygnus.com> Date: Thu, 02 May 2002 08:43:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0rc1) Gecko/20020429 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Elizabeth Chastain Cc: fnf@redhat.com, msnyder@redhat.com, gdb-patches@sources.redhat.com Subject: Re: [RFA] Fix problem with watchpoint test in gdb.base/commands.exp References: <200205021534.g42FYPq19248@duracef.shout.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-05/txt/msg00038.txt.bz2 > gdb.texinfo says: > > @value{GDBN} automatically deletes watchpoints that watch local > (automatic) variables, or expressions that involve such variables, when > they go out of scope, that is, when the execution leaves the block in > which these variables were defined. > > I interpret "go out of scope" to be talking about stack frames, > but it's likely that gdb can have bugs where it's checking for scope > by looking at line numbers. FYI, out of scope includes: foo () { int bar; .... { int bar; .... } } so there may not necessarily be a frame change. However, if the frame has gone (or is being destroyed) the variable is out of scope. > So actually I think that the right result for this use case is > UNRESOLVED, which means that a human has to look at it each time. > > So I don't recommend this patch as is. > > How about this: enhance watchpoint_command_test to be two tests, > one non-recursive, and one recursive. Then the non-recursive one > will be simple non-controversial and it can PASS on either the last > line of the callee or the next line of the caller. The recursive > one will be trickier, it will have to look at the value of some > recursion variable to make sure that it is in the correct scope. > > Michael C Andrew