From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22783 invoked by alias); 24 Dec 2010 11:28:29 -0000 Received: (qmail 22772 invoked by uid 22791); 24 Dec 2010 11:28:28 -0000 X-SWARE-Spam-Status: No, hits=-1.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_SOFTFAIL X-Spam-Check-By: sourceware.org Received: from mtaout21.012.net.il (HELO mtaout21.012.net.il) (80.179.55.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 24 Dec 2010 11:28:22 +0000 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0LDX00500JSOFQ00@a-mtaout21.012.net.il> for gdb-patches@sourceware.org; Fri, 24 Dec 2010 13:27:54 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.229.167.122]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LDX0057TJUEC570@a-mtaout21.012.net.il>; Fri, 24 Dec 2010 13:27:53 +0200 (IST) Date: Sat, 25 Dec 2010 14:13:00 -0000 From: Eli Zaretskii Subject: Re: [patch 2/3] Implement support for PowerPC BookE ranged watchpoints In-reply-to: <201012232017.11120.pedro@codesourcery.com> To: Pedro Alves Cc: gdb-patches@sourceware.org, bauerman@br.ibm.com, jan.kratochvil@redhat.com, brobecker@adacore.com Reply-to: Eli Zaretskii Message-id: <83k4ize7jx.fsf@gnu.org> References: <1290549100.3164.47.camel@hactar> <201011271747.39053.pedro@codesourcery.com> <1293130182.14239.21.camel@hactar> <201012232017.11120.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: 2010-12/txt/msg00458.txt.bz2 > From: Pedro Alves > Date: Thu, 23 Dec 2010 20:16:45 +0000 > Cc: Thiago Jung Bauermann , > Jan Kratochvil , > Joel Brobecker , > Eli Zaretskii > > The resource accounting bits, I still say that they should all just > go away (at some point), and gdb should just try to insert the > watchpoint immediately, and see if the target refuses. I agree -- assuming, that is, that all the targets we support that can do hardware watchpoints allow us to insert the watchpoints separately from resuming the debuggee. If there are targets that actually insert the watchpoints as part as resuming the debuggee, those targets will be unable to tell us anything useful about the watchpoint resources until we actually resume the debuggee. For those targets, we will need to have some resource accounting in GDB, to give the user reasonable feedback about resource over-booking.