From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24497 invoked by alias); 3 May 2011 18:12:53 -0000 Received: (qmail 24479 invoked by uid 22791); 3 May 2011 18:12:50 -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 18:12:36 +0000 Received: (qmail 2119 invoked from network); 3 May 2011 18:12:35 -0000 Received: from unknown (HELO scottsdale.localnet) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 3 May 2011 18:12:35 -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 18:12:00 -0000 User-Agent: KMail/1.13.5 (Linux/2.6.35-28-generic; KDE/4.6.2; x86_64; ; ) Cc: bauerman@br.ibm.com, uweigand@de.ibm.com References: <201104291726.p3THQVaC029608@d06av02.portsmouth.uk.ibm.com> <201105031841.46949.pedro@codesourcery.com> <83hb9b4q80.fsf@gnu.org> In-Reply-To: <83hb9b4q80.fsf@gnu.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201105031912.43042.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/msg00073.txt.bz2 On Tuesday 03 May 2011 19:02:39, Eli Zaretskii wrote: > > The main point/win of the suggestion was avoiding the whole > > resource accounting infrastructure, getting away without adding > > a bunch of (what looks to me at this point, unnecessary) target > > methods/packets/logic. > > At least for x86, the resource accounting is necessary, because that > is what allows us to have several watchpoints sharing the same debug > register. Right, I meant the accounting instructure on the core side. For x86, i386-nat.c would stay as is. The merging is done at insert time currently, and it would stay the same. The difference would be that gdb would insert the watchpoint as soon as the user wanted it, instead of calling some "may I create this?" mechanism. > Targets that already have this resource accounting may well > use it to return accurate results to target_can_use_hardware_watchpoint > without actually going to the metal or the kernel. I'm proposing getting rid of target_can_use_hardware_watchpoint as being part of the core accounting infrastructure. I'm trying to think of a use case that makes it necessary to know if the watchpoints will fit before creating them, but I'm not coming up with any. -- Pedro Alves