From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24253 invoked by alias); 19 Sep 2007 12:38:42 -0000 Received: (qmail 24241 invoked by uid 22791); 19 Sep 2007 12:38:42 -0000 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 19 Sep 2007 12:38:31 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 3E54898298; Wed, 19 Sep 2007 12:38:29 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id C567898152; Wed, 19 Sep 2007 12:38:28 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.67) (envelope-from ) id 1IXyp1-0007BB-Eu; Wed, 19 Sep 2007 08:38:27 -0400 Date: Wed, 19 Sep 2007 12:38:00 -0000 From: Daniel Jacobowitz To: "Maciej W. Rozycki" Cc: gdb-patches@sourceware.org, "Maciej W. Rozycki" Subject: Re: mips-tdep.c: Fix sw watchpoint-out-of-scope events Message-ID: <20070919123827.GA27457@caradoc.them.org> Mail-Followup-To: "Maciej W. Rozycki" , gdb-patches@sourceware.org, "Maciej W. Rozycki" References: <20070918155400.GA1128@caradoc.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.15 (2007-04-09) X-IsSubscribed: yes 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/msg00249.txt.bz2 On Wed, Sep 19, 2007 at 01:31:29PM +0100, Maciej W. Rozycki wrote: > Well, actually then, I have thought, rather than trying to fix the > unfixable, why don't we mimic the behaviour of hardware watchpoints? As > they do not single-step (the whole point of them, at least for the write > watchpoints) a scope software breakpoint is placed at the return target of > the scope covered. We could do the same for software watchpoints -- > insert a scope software breakpoint, single-step till the watchpoints goes > out of scope and then resume at the full speed till the scope breakpoint > is hit. Was there any particular reason for not doing so in the first > place? Could you give me an example? The watchpoint shouldn't go out of scope before the scope breakpoint is hit. The problem is, instead, 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. 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. > > Hmm, do you think we should accept that line as a pass then? The same > > will happen on other architectures too. > > Well, it depends on the policy we have (if we have any in this area) -- > the patch fixes non-PIC o32 and presumably new ABIs (I'll try to see > whether I have a way to test it), but does not quite so for PIC o32 > (beacuse of the load to $gp after the return). There may be other > architectures with a similar problem, but if MIPS o32 was to be the only > one affected, then a PASS would be reasonable, as stated originally. > Though I have no idea how to take care of the load to $gp at the moment -- > perhaps some logic from the scope breakpoint calculation could be reused. 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. I think there's at least one other test which allows it. -- Daniel Jacobowitz CodeSourcery