From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19895 invoked by alias); 25 Apr 2012 11:51:45 -0000 Received: (qmail 19885 invoked by uid 22791); 25 Apr 2012 11:51:43 -0000 X-SWARE-Spam-Status: No, hits=-4.2 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 25 Apr 2012 11:51:30 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1SN0ks-00060W-C8 from Luis_Gustavo@mentor.com ; Wed, 25 Apr 2012 04:51:30 -0700 Received: from NA1-MAIL.mgc.mentorg.com ([147.34.98.181]) by svr-orw-fem-01.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 25 Apr 2012 04:51:30 -0700 Received: from [0.0.0.0] ([172.16.63.104]) by NA1-MAIL.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 25 Apr 2012 04:51:29 -0700 Message-ID: <4F97E547.4070307@mentor.com> Date: Wed, 25 Apr 2012 11:51:00 -0000 From: Luis Gustavo Reply-To: "Gustavo, Luis" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.27) Gecko/20120216 Lightning/1.0b2 Thunderbird/3.1.19 MIME-Version: 1.0 To: Xin Tong CC: gdb@sourceware.org Subject: Re: Hardware watchpoint for read References: <4F96A614.3040303@mentor.com> <4F96A812.4000008@mentor.com> <4F96B68C.3050703@mentor.com> <4F96C2A7.2010206@mentor.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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-04/txt/msg00211.txt.bz2 On 04/24/2012 10:15 PM, Xin Tong wrote: > On Tue, Apr 24, 2012 at 11:11 AM, Luis Gustavo wrote: >> On 04/24/2012 12:06 PM, Xin Tong wrote: >>> >>> On Tue, Apr 24, 2012 at 10:19 AM, Luis Gustavo >>> wrote: >>>> >>>> On 04/24/2012 11:17 AM, Xin Tong wrote: >>>>> >>>>> >>>>> On Tue, Apr 24, 2012 at 9:18 AM, Luis Gustavo >>>>> wrote: >>>>>> >>>>>> >>>>>> On 04/24/2012 10:15 AM, Xin Tong wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Tue, Apr 24, 2012 at 9:09 AM, Luis Gustavo >>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> >>>>>>>> On 04/24/2012 10:02 AM, Xin Tong wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Hello >>>>>>>>> >>>>>>>>> I am wondering that can gdb insert hardware watch point for read to >>>>>>>>> the watched memory ? can other debugger do that ? is it supported in >>>>>>>>> hardware watchpoint ? >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> >>>>>>>>> Xin >>>>>>>>> >>>>>>>> >>>>>>>> Read watchpoints are hard to implement as soft-watchpoints, so >>>>>>>> they're >>>>>>>> usually implemented as hardware watchpoints. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> software write watchpoint is easier to implement ? do not software >>>>>>> watchpoint need to watch all memory accesses (read and write) to a >>>>>>> memory location in software ? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Writes are "easier" to implemenet due to the fact that they usually >>>>>> change >>>>>> memory contents. Reads don't. >>>>> >>>>> >>>>> >>>>> Either way, do not gdb need to instrument every memory accesses if a >>>>> software watch point is used ? >>>> >>>> >>>> >>>> It does things lazily. It single-steps instruction-by-instruction and >>>> checks >>>> for change of contents. >>> >>> >>> ok, i see. so it does not dissasmble the instructions. but for read, >>> it may need to disassemble the instructions which makes it harder to >>> implement. >> >> >> Yes, this is the problem with read watchpoints implemented as software >> watchpoints. It's hard to determine a trigger without making it painfully >> slow, and the debugger needs knowledge about the arch's instructions. >> >> >>>> >>>> >>>>>> >>>>>> >>>>>>> >>>>>>>> >>>>>>>> If a debugger knows how to properly set the bits in the hardware, >>>>>>>> either >>>>>>>> through ptrace or other means, it can configure a >>>>>>>> read/write/read-write >>>>>>>> watchpoint. Depends on hardware support really. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> do you know whether this is supported on the x86 chips ? is thee a way >>>>>>> to try this out in gdb ? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> All those modes should be supported in x86. Try "watch", "rwatch" and >>>>>> "awatch". >>>>> >>>>> >>>>> >>>>> how are hardware watch, rwatch and awatch implemented in gdb. make >>>>> call to ptrace apis and ptrace apis program some x86 registers >>>>> through a driver interfaces ? >>>>> >>>> >>>> ptrace calls really. GDB's x86 backend knows how to set those bits. > > 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. > > Xin > >>>> >>>>>> >>>>>>> >>>>>>>> >>>>>>>> Regards, >>>>>>>> Luis >>>>>> >>>>>> >>>>>> >>>>>> >>>> >>