From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26593 invoked by alias); 4 Jun 2009 03:29:32 -0000 Received: (qmail 26585 invoked by uid 22791); 4 Jun 2009 03:29:32 -0000 X-Spam-Check-By: sourceware.org Received: from pool-98-110-183-121.bstnma.fios.verizon.net (HELO cgf.cx) (98.110.183.121) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 04 Jun 2009 03:29:27 +0000 Received: from ednor.cgf.cx (ednor.casa.cgf.cx [192.168.187.5]) by cgf.cx (Postfix) with ESMTP id 70AA013C0C3 for ; Wed, 3 Jun 2009 23:29:17 -0400 (EDT) Received: by ednor.cgf.cx (Postfix, from userid 201) id 4600911A06D; Wed, 3 Jun 2009 23:29:17 -0400 (EDT) Date: Thu, 04 Jun 2009 03:29:00 -0000 From: Christopher Faylor To: gdb-patches@sourceware.org Subject: Re: [RFA] Fix a windows bug if two watchpoints are used Message-ID: <20090604032917.GA27487@ednor.casa.cgf.cx> Mail-Followup-To: gdb-patches@sourceware.org References: <000301c9e49e$c479eba0$4d6dc2e0$@u-strasbg.fr> <000601c9e4a3$b2f2f980$18d8ec80$@u-strasbg.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) 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: 2009-06/txt/msg00059.txt.bz2 On Wed, Jun 03, 2009 at 11:16:39PM -0400, Eli Zaretskii wrote: >Pierre Muller wrote: >>>Shouldn't we instead fix the logic of i386_stopped_data_address, to get >>>out of the loop on the first watchpoint that is found to be hit? The >>>function does not support more than one watchpoint anyway, so why >>>continue checking the bits in dr[6] after we've found one set already? >>> >>>Would such a change fix your problem without the other complications? >> >>It would hide the problem. > >Why hide, and what problem are we talking about? The situation you >describe has no rational explanation, and looks more like a Windows bug >than anything else: you in effect show a contradiction between two >debug registers that should tell a coherent story, but don't. Fixing >such problems without a good understanding of their exact reasons is >always a bit phenomenological. My phenomenology is based on the >premise that the OS uses the debug registers in the order we scan the >bits in dr[6], so the first one we find set has better chances to be >consistent with what really happened than anything else. > >>But what happens if you have different watchpoints on the same address >>(say one 'watch' and one 'awatch')? Are you sure your suggestion would >>not affect such cases? > >It will work even in those cases, yes. We only support multiple >watchpoints that break simultaneously if they watch the same address, >anyway (there's only one address that i386_stopped_data_address >returns). The i386 debug register support code will use a single debug >register for watching such an address, no matter how many watchpoints >the user sets and of what kind. We do this sharing of debug registers >entirely in GDB (see i386_insert_aligned_watchpoint and the >dr_ref_count[] array it uses); the OS is never told to use more than >one debug register for every address we watch, even if we watch it with >several watchpoints. The callers of i386_stopped_data_address take the >address it returns, and check all the watchpoints that watch this >address to see which one(s) of them triggered and which did not. That >code is in breakpoint.c, AFAIR. FWIW, I agree with Eli's assessments here. cgf