From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26341 invoked by alias); 3 May 2011 09:58:56 -0000 Received: (qmail 26326 invoked by uid 22791); 3 May 2011 09:58:54 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 03 May 2011 09:58:40 +0000 Received: (qmail 24987 invoked from network); 3 May 2011 09:58:39 -0000 Received: from unknown (HELO scottsdale.localnet) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 3 May 2011 09:58:39 -0000 From: Pedro Alves To: gdb-patches@sourceware.org, Eli Zaretskii Subject: Re: [RFA 2/3] Demote to sw watchpoint only in update_watchpoint Date: Tue, 03 May 2011 09:58:00 -0000 User-Agent: KMail/1.13.5 (Linux/2.6.35-28-generic; KDE/4.6.2; x86_64; ; ) Cc: Thiago Jung Bauermann , uweigand@de.ibm.com References: <201104291726.p3THQVaC029608@d06av02.portsmouth.uk.ibm.com> <1304398546.2245.80.camel@hactar> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201105031058.44489.pedro@codesourcery.com> X-IsSubscribed: yes 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: 2011-05/txt/msg00050.txt.bz2 On Tuesday 03 May 2011 07:05:35, Eli Zaretskii wrote: > We should resolve this conflict in the most direct way: introduce a > method, to be implemented by each target, that will answer these > questions. It should accept the exact spec of the new watchpoint, and > it should have access to the watchpoints and breakpoints already set, > including their full specs. With that information in hand, a target > can reliably produce a definitive response, at least in the vast > majority of cases, when the corresponding resources are under GDB > control. Consider: gdb core -> target_ops -> remote -> remote stub -> debug API (something that actually inserts/remove watchpoints, and hides resource accounting details) Currently, the accounting is done between gdb core and the target_ops implementation, using target methods. Many debug support libraries (that abstract access to jtag, for example), and debug APIs (like ptrace) don't expose programatic methods to do resource accounting to be able to implement such new method either. They may even do watchpoint merging themselves (e.g., overlapping watchpoints consume only one registers, instead of two), making it impossibly to implement the new method other than always returning "it fits". With such targets, the only reliable way to know whether the watchpoint resources haven't been exausted, is to actually try to insert the watchpoint. But this should work for the simplest APIs, like those where the backend manages a finite set of debug registers (like most i386 backends). What if we tried to make GDB do that instead? (try inserting watchpoint immediately, instead of trying to do any sort of accounting.) -- Pedro Alves