From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22569 invoked by alias); 3 May 2012 19:19:56 -0000 Received: (qmail 22561 invoked by uid 22791); 3 May 2012 19:19:55 -0000 X-SWARE-Spam-Status: No, hits=-0.7 required=5.0 tests=BAYES_50,KHOP_THREADED,RCVD_IN_DNSWL_NONE X-Spam-Check-By: sourceware.org Received: from mailrelay020.isp.belgacom.be (HELO mailrelay020.isp.belgacom.be) (195.238.6.95) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 03 May 2012 19:19:41 +0000 X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: At8KACPZok/ZiDto/2dsb2JhbABFizWmIwKBIIEIggQBBAEBBAEIAQEuHgEBBhsLAgMFAgEDISUUAQQaBh4GARoCAQIDAYU3BwGCJxEJuncThjOFTYQSYwSIMIVKmEaCag Received: from 104.59-136-217.adsl-dyn.isp.belgacom.be (HELO soleil) ([217.136.59.104]) by relay.skynet.be with SMTP; 03 May 2012 21:19:40 +0200 Message-ID: <30865C01C5AF4B6B9B01901B792C4EF5@soleil> From: "Philippe Waroquiers" To: "Gustavo, Luis" , "Xin Tong" Cc: References: <4F96A614.3040303@mentor.com> <4F96A812.4000008@mentor.com> <4F96B68C.3050703@mentor.com> <4F96C2A7.2010206@mentor.com> <4F97E547.4070307@mentor.com> Subject: Re: Hardware watchpoint for read Date: Thu, 03 May 2012 19:19:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2012-05/txt/msg00011.txt.bz2 >> what are the performance penalties of having a watchpoint on a memory >> location in the state of the art x86 processor. Because it might be >> implemented with a parallel circuitry in the processor, my guess is >> that it could be cheap. > > Do you mean a hardware watchpoint? It's hard to say for sure without > looking at the processors inner workings, but the penalty is probably > very small. > > When the conditions are satisfied, a TRAP will be generated and it will > get through to the debugger via the kernel. > > Suppose we issue a continue command... For the debugger, the inferior > will run uninterrupted while the hardware watchpoint is active. > > This is not the case with software watchpoints, as the debugger will be > constantly touching the inferior while it runs. Which makes software watchpoints extremely slow, while hardware watchpoints have limitations (e.g. in nr or size). Note that the Valgrind gdbserver (in 3.7.0) provides "unlimited simulated hw watchpoints" : these are slower than real hw watchpoints, but "only" suffer from the Valgrind slowdown. Philippe