From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8261 invoked by alias); 19 Sep 2007 13:05:22 -0000 Received: (qmail 8253 invoked by uid 22791); 19 Sep 2007 13:05:21 -0000 X-Spam-Check-By: sourceware.org Received: from dmz.mips-uk.com (HELO dmz.mips-uk.com) (194.74.144.194) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 19 Sep 2007 13:05:16 +0000 Received: from internal-mx1 ([192.168.192.240] helo=ukservices1.mips.com) by dmz.mips-uk.com with esmtp (Exim 3.35 #1 (Debian)) id 1IXzEu-0006WU-00; Wed, 19 Sep 2007 14:05:12 +0100 Received: from perivale.mips.com ([192.168.192.200]) by ukservices1.mips.com with esmtp (Exim 3.36 #1 (Debian)) id 1IXzEk-0004YA-00; Wed, 19 Sep 2007 14:05:02 +0100 Received: from macro (helo=localhost) by perivale.mips.com with local-esmtp (Exim 4.63) (envelope-from ) id 1IXzEk-0000jK-R6; Wed, 19 Sep 2007 14:05:02 +0100 Date: Wed, 19 Sep 2007 13:05:00 -0000 From: "Maciej W. Rozycki" To: Daniel Jacobowitz cc: gdb-patches@sourceware.org, "Maciej W. Rozycki" Subject: Re: mips-tdep.c: Fix sw watchpoint-out-of-scope events In-Reply-To: <20070919123827.GA27457@caradoc.them.org> Message-ID: References: <20070918155400.GA1128@caradoc.them.org> <20070919123827.GA27457@caradoc.them.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-MIPS-Technologies-UK-MailScanner: Found to be clean X-MIPS-Technologies-UK-MailScanner-From: macro@mips.com Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2007-09/txt/msg00250.txt.bz2 On Wed, 19 Sep 2007, Daniel Jacobowitz wrote: > Could you give me an example? The watchpoint shouldn't go out of > scope before the scope breakpoint is hit. The problem is, instead, Well, the scope breakpoint is set up in the caller of the function providing the frame containing the variable being watched. So by definition at the point it is hit the watchpoint has always gone away already. This is how it works with hw watchpoints. > that it appears to change value. There's two cases. In the epilogue > of the function containing the watched variable, the stack frame gets > destroyed, so the watchpoint is no longer valid... but we don't have > any marker to indicate that. In the epilogue of other called > functions, the watchpoint is still valid but we fail to backtrace > correctly so we don't find the original function on the stack. Correct. There is actually a third case which is somewhere inbetween -- where the function containing the watched variable ends by jumping to a sibling call. For a C program from the language's point of view the watchpoint is still in the scope during the execution of the sibling call, while in reality its stack frame has gone away already. > Both of these can happen for hardware watchpoints too, e.g., if the > user is single stepping or has other breakpoints set. In practice > they rarely do. True. > I think I wasn't clear. I'm asking if returning to the original call > line, the way MIPS o32 PIC does, should be a PASS. Other platforms > that have teardown after function calls will show the same behavior. Well, that sounds reasonable given the complication around getting things perfect here. Ideally the out-of-scope event should happen at the same place where "finish" from the function in question would stop; in my opinion at least. Maciej