From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17736 invoked by alias); 10 Sep 2007 19:03:37 -0000 Received: (qmail 17728 invoked by uid 22791); 10 Sep 2007 19:03:36 -0000 X-Spam-Check-By: sourceware.org Received: from mtagate2.de.ibm.com (HELO mtagate2.de.ibm.com) (195.212.29.151) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 10 Sep 2007 19:03:30 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.13.8/8.13.8) with ESMTP id l8AJ3Qs0204700 for ; Mon, 10 Sep 2007 19:03:26 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 l8AJ3QBL2257022 for ; Mon, 10 Sep 2007 21:03:26 +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 l8AJ3Qeg012171 for ; Mon, 10 Sep 2007 21:03:26 +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 l8AJ3Q7W012168; Mon, 10 Sep 2007 21:03:26 +0200 Message-Id: <200709101903.l8AJ3Q7W012168@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Mon, 10 Sep 2007 21:03:26 +0200 Subject: Re: [patch 0/1] Threaded Watchpoints To: drow@false.org (Daniel Jacobowitz) Date: Mon, 10 Sep 2007 19:03:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org In-Reply-To: <20070910185427.GA20125@caradoc.them.org> from "Daniel Jacobowitz" at Sep 10, 2007 02:54:27 PM 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-09/txt/msg00146.txt.bz2 Daniel Jacobowitz wrote: > On Mon, Sep 10, 2007 at 08:44:22PM +0200, Ulrich Weigand wrote: > > I guess your new way makes more sense. This means we can remove > > HAVE_CONTINUABLE_WATCHPOINTS completely, though. (As a related > > point, I think it would be good to fix the oddity that nonsteppable > > watchpoints are reported as a gdbarch property while steppable > > watchpoints are reported as a target property ...) > > I totally agree. I just don't know which one makes more sense. > Probably gdbarch but I'm sure I'll break something if I try to > change it. 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 ... > > Hmm, I see. This assumes that after every new-thread event, the new > > thread is selected as inferior_ptid, though. > > I don't think it assumes that. s390_resume should be called once for > each thread, and not depend on inferior_ptid at all; only > linux_nat_resume has to check for ptid == -1, schedlocking, et cetera. Doh! You're right, of course. That should work fine then. Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com