From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16970 invoked by alias); 30 Sep 2007 19:10:41 -0000 Received: (qmail 16962 invoked by uid 22791); 30 Sep 2007 19:10:40 -0000 X-Spam-Status: No, hits=-1.3 required=5.0 tests=AWL,BAYES_05,DK_POLICY_SIGNSOME,FORGED_RCVD_HELO X-Spam-Check-By: sourceware.org Received: from wildebeest.demon.nl (HELO gnu.wildebeest.org) (83.160.170.119) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 30 Sep 2007 19:10:38 +0000 Received: from wildebeest.demon.nl ([83.160.170.119] helo=[127.0.0.1]) by gnu.wildebeest.org with esmtp (Exim 4.63) (envelope-from ) id 1Ic4BW-00084G-GV; Sun, 30 Sep 2007 21:10:35 +0200 Subject: Re: Optimizing watchpoints From: Mark Wielaard To: Phil Muldoon Cc: Frysk Hackers In-Reply-To: <46FD7036.2010500@redhat.com> References: <46FD7036.2010500@redhat.com> Content-Type: text/plain Date: Sun, 30 Sep 2007 19:10:00 -0000 Message-Id: <1191179433.3275.14.camel@hermans.wildebeest.org> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 (2.10.3-4.fc7) Content-Transfer-Encoding: 7bit X-Spam-Score: -4.4 (----) X-IsSubscribed: yes Mailing-List: contact frysk-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: frysk-owner@sourceware.org X-SW-Source: 2007-q3/txt/msg00413.txt.bz2 Hi Phil, On Fri, 2007-09-28 at 22:20 +0100, Phil Muldoon wrote: > Given that debug registers are very scarce, and that typically there > might be a scenario where we could better optimize watching similar > addresses and ranges, is there an established protocol for this? > > I thought about checking addresses and ranges as a simple "we are > already watching this address in another register and scope". But as > usual things get hairy in C when you add in pointers (that pointer to > pointers in structures and so on). We are already doing a simple version of this for low level breakpoints. For each Code observer added at the proc level there is a simple map, BreakpointAddresses, that keeps track of whether or not an actual breakpoint instruction is already there. So whenever a Code observer is added or removed at a particular address the BreakpointAddresses map is consulted to see whether an existing one can be reused, or should be kept, because other Code observers are monitoring the address. For watchpoints you don't just have simple addresses, but also a range. That makes your 'overlapping' detection a little less straightforward than in the Code observer case. But BreakpointAddresses does already give a simple version that can find breakpoint addressses given a range of memory, public Iterator getBreakpoints(long from, long till). Something like this, based on a TreeSet of addresses plus ranges can probably be used to implement your watchpoint address range overlapping detection. I wouldn't worry too much about the particulars of hairy C structures. That should be handled at a higher language level by installing multiple proc watchpoint observers. Cheers, Mark