From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4333 invoked by alias); 14 Oct 2007 19:55:18 -0000 Received: (qmail 4324 invoked by uid 22791); 14 Oct 2007 19:55:18 -0000 X-Spam-Check-By: sourceware.org Received: from mtagate7.de.ibm.com (HELO mtagate7.de.ibm.com) (195.212.29.156) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 14 Oct 2007 19:55:15 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate7.de.ibm.com (8.13.8/8.13.8) with ESMTP id l9EJtCJF444190 for ; Sun, 14 Oct 2007 19:55:12 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.5) with ESMTP id l9EJtCNq2138280 for ; Sun, 14 Oct 2007 21:55:12 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l9EJtCXi031305 for ; Sun, 14 Oct 2007 21:55:12 +0200 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with SMTP id l9EJtCNc031302; Sun, 14 Oct 2007 21:55:12 +0200 Message-Id: <200710141955.l9EJtCNc031302@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Sun, 14 Oct 2007 21:55:11 +0200 Subject: Re: Remote watchpoint support for FRV To: drow@false.org (Daniel Jacobowitz) Date: Sun, 14 Oct 2007 20:13:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org In-Reply-To: <20071005135640.GA17031@caradoc.them.org> from "Daniel Jacobowitz" at Oct 05, 2007 09:56:40 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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-10/txt/msg00371.txt.bz2 Daniel Jacobowitz wrote: > On Fri, Oct 05, 2007 at 03:47:53PM +0200, Ulrich Weigand wrote: > > Hello, > > > > the tm-frv.h header file overrides a number of watchpoint related > > target macros, in particular: > > > > #define STOPPED_BY_WATCHPOINT(W) \ > > ((W).kind == TARGET_WAITKIND_STOPPED \ > > && (W).value.sig == TARGET_SIGNAL_TRAP \ > > && frv_have_stopped_data_address()) > > Kevin, you were the last person to work on the FRV target (far as I > can tell); do you know anything about this? Any updates on this? I've had another look at this, and it appears to me that this wasn't actually functional in mainline GDB anyway: Up until your recent breakpoint.c change, watchpoints were active only if either HAVE_STEPPABLE_WATCHPOINT, HAVE_NONSTEPPABLE_WATCHPOINT, or HAVE_CONTINUABLE_WATIPOINT were defined. In this particular case, the tm file doesn't define any of these (the #define HAVE_STEPPABLE_WATCHPOINT is commented out), an nm file doesn't apply, the remote target does not define to_have_continuable_watchpoint, and frv-tdep does not use set_gdbarch_nonsteppable_watchpoint. Thus it would appear that the STOPPED_BY_WATCHPOINT and target_stopped_data_address macros defined in the tm-frv.h header file aren't actually ever called. (Since the recent watchpoint change, they *are* active, but probably not correctly as common code now assumes continuable watchpoint behaviour). Note that the HAVE_STEPPABLE_WATCHPOINT macro is commented out since the very first version of tm-frv.h checked into the GDB CVS, so I'm not sure what to think of that ... Did this ever work? If it actually didn't ever work, I'd say we should just remove the tm file now; if somebody wants to get remote watchpoint support on frv working, they can (and should) use the existing mechanism. > Ulrich, there's a third option, but I don't know if it's practical. > Can we somehow specialize the remote target based on the architecture? > It's not the first time I've thought it would be useful. But we > already have the target adjusting the architecture and adding > something in the other direction might be awkward. I agree this would probably be a bit awkward ... Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com