From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13584 invoked by alias); 2 May 2002 15:34:32 -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 13490 invoked from network); 2 May 2002 15:34:28 -0000 Received: from unknown (HELO duracef.shout.net) (204.253.184.12) by sources.redhat.com with SMTP; 2 May 2002 15:34:28 -0000 Received: (from mec@localhost) by duracef.shout.net (8.11.6/8.11.6) id g42FYPq19248; Thu, 2 May 2002 10:34:25 -0500 Date: Thu, 02 May 2002 08:34:00 -0000 From: Michael Elizabeth Chastain Message-Id: <200205021534.g42FYPq19248@duracef.shout.net> To: fnf@redhat.com, msnyder@redhat.com Subject: Re: [RFA] Fix problem with watchpoint test in gdb.base/commands.exp Cc: gdb-patches@sources.redhat.com X-SW-Source: 2002-05/txt/msg00037.txt.bz2 Michael Snyder writes: > I think this is a good idea (hmm... didn't somebody else recently > submit this same change, with a different implementation?) > I get bitten by this testsuite glitch all the time. > My only concern is, can this cause us to miss an actual bug? > Such as if this (watchpoint out of scope event) were to trigger > in, say, the wrong frame of the recursive call? Yes, I think it would cause the test to miss this kind of bug: main() calls foo() user sets watchpoint in foo() foo() calls foo() foo() returns gdb deletes watchpoint (which belonged to first foo) 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. 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