From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21329 invoked by alias); 19 Sep 2007 12:31:49 -0000 Received: (qmail 21316 invoked by uid 22791); 19 Sep 2007 12:31:47 -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 12:31:38 +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 1IXyiM-0002Zy-00; Wed, 19 Sep 2007 13:31:34 +0100 Received: from perivale.mips.com ([192.168.192.200]) by ukservices1.mips.com with esmtp (Exim 3.36 #1 (Debian)) id 1IXyiH-0002gC-00; Wed, 19 Sep 2007 13:31:29 +0100 Received: from macro (helo=localhost) by perivale.mips.com with local-esmtp (Exim 4.63) (envelope-from ) id 1IXyiH-0008WI-G0; Wed, 19 Sep 2007 13:31:29 +0100 Date: Wed, 19 Sep 2007 12:31: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: <20070918155400.GA1128@caradoc.them.org> Message-ID: References: <20070918155400.GA1128@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/msg00248.txt.bz2 On Tue, 18 Sep 2007, Daniel Jacobowitz wrote: > This patch is fine. I wish it wasn't necessary, but for now it is. 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? I'll go forward with the patch regardless as it would become obsolete automatically if we accepted the hw watchpoint model for sw ones too as in_function_epilogue_p() would become irrelevant then as far as I can tell. > 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. Maciej