From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3331 invoked by alias); 10 Sep 2007 19:31:37 -0000 Received: (qmail 3323 invoked by uid 22791); 10 Sep 2007 19:31:37 -0000 X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO brahms.sibelius.xs4all.nl) (82.92.89.47) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 10 Sep 2007 19:31:32 +0000 Received: from brahms.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) by brahms.sibelius.xs4all.nl (8.14.1/8.14.0) with ESMTP id l8AJVPcP001337; Mon, 10 Sep 2007 21:31:25 +0200 (CEST) Received: (from kettenis@localhost) by brahms.sibelius.xs4all.nl (8.14.1/8.14.1/Submit) id l8AJVP7l017940; Mon, 10 Sep 2007 21:31:25 +0200 (CEST) Date: Mon, 10 Sep 2007 19:31:00 -0000 Message-Id: <200709101931.l8AJVP7l017940@brahms.sibelius.xs4all.nl> From: Mark Kettenis To: uweigand@de.ibm.com CC: drow@false.org, gdb-patches@sourceware.org In-reply-to: <200709101903.l8AJ3Q7W012168@d12av02.megacenter.de.ibm.com> (uweigand@de.ibm.com) Subject: Re: [patch 0/1] Threaded Watchpoints References: <200709101903.l8AJ3Q7W012168@d12av02.megacenter.de.ibm.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/msg00148.txt.bz2 > Date: Mon, 10 Sep 2007 21:03:26 +0200 (CEST) > From: "Ulrich Weigand" > > I'd tend to agree with Andrew's comment in mips-tdep.c: > > /* FIXME: cagney/2003-08-29: The macros HAVE_STEPPABLE_WATCHPOINT, > HAVE_NONSTEPPABLE_WATCHPOINT, and HAVE_CONTINUABLE_WATCHPOINT > need to all be folded into the target vector. Since they are > being used as guards for STOPPED_BY_WATCHPOINT, why not have > STOPPED_BY_WATCHPOINT return the type of watchpoint that the code > is sitting on? */ > > Since all other watchpoint-related callbacks are in the target > vector, having nonsteppable_watchpoint as a gdbarch property > does look somewhat odd. > > The only problem with moving HAVE_NONSTEPPABLE_WATCHPOINT into the > target vector might be the remote targets. Is this information > available via the remote protocol somehow? If not, I guess it has > to stay in gdbarch ... That really is the wrong way to think about this; we shouldn't keep gdb criplled forever, just because some bad decision was made years and years ago. So the real question here is, whether HAVE_NONSTEPPABLE_WATCHPOINT and these other properties mentions above are really a fundamental property of the architecture (ISA or OS ABI). Or if they are properties of a particular debug interface (ptrace, remote, jtag). In some cases it may actually make sense to have something as a property of the architecture but making it possible for the target vector to override it. Mark