From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2750 invoked by alias); 8 Jan 2010 12:26:11 -0000 Received: (qmail 2727 invoked by uid 22791); 8 Jan 2010 12:26:10 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 08 Jan 2010 12:26:06 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 296A22BAB8D; Fri, 8 Jan 2010 07:26:05 -0500 (EST) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id O8TI8NoP-P03; Fri, 8 Jan 2010 07:26:05 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 99CB72BAB59; Fri, 8 Jan 2010 07:26:04 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id 8CF9DF595E; Fri, 8 Jan 2010 16:25:55 +0400 (RET) Date: Fri, 08 Jan 2010 12:26:00 -0000 From: Joel Brobecker To: Eli Zaretskii Cc: gdb-patches@sourceware.org Subject: Re: [RFC] Wrong hw_watchpoint_used_count? (multiple location watchpoints) Message-ID: <20100108122555.GD29312@adacore.com> References: <20100108075701.GE4589@adacore.com> <83fx6gc43p.fsf@gnu.org> <20100108102955.GC29312@adacore.com> <83aawobxze.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83aawobxze.fsf@gnu.org> User-Agent: Mutt/1.5.20 (2009-06-14) 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: 2010-01/txt/msg00165.txt.bz2 > The current boundary is the places where breakpoint.c calls the > various target_* methods which return information that only the target > knows. Right - my point is that the design itself is unclear. Your example of the x86 watchpoint support is one of the examples where this is particularly weird in terms of user interface, and where the implementation implements a form of support that is different from what I *thought* the spirit of watchpoint support in GDB was. I thought that the design would be that GDB would ask the target if they still have enough resources to add an extra hardware watchpoint, and automatically downgrade to a software watchpoint if not. On x86, my guess when I read the code, is that it won't even allow the user to continue the debugging until some watchpoints are removed. > One unpleasant side effect is that we only > announce at "continue" time that too many hardware resources were > required; we should have announced that at "watchpoint" time. Fully agreed. > In particular, I think that the bookkeeping of the various locations > where watchpoints are inserted should be left to the target. That > would allow, e.g., targets that don't support range watchpoints to > emulate them with multiple watchpoints. I agree as well. -- Joel