From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23904 invoked by alias); 28 Nov 2001 19:30:16 -0000 Mailing-List: contact gdb-patches-help@sourceware.cygnus.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 23877 invoked from network); 28 Nov 2001 19:30:14 -0000 Received: from unknown (HELO lacrosse.corp.redhat.com) (207.175.42.154) by hostedprojects.ges.redhat.com with SMTP; 28 Nov 2001 19:30:14 -0000 Received: from trixie.bosbc.com (cgf.cipe.redhat.com [10.0.1.172]) by lacrosse.corp.redhat.com (8.11.6/8.9.3) with ESMTP id fASJUCq09851 for ; Wed, 28 Nov 2001 14:30:13 -0500 Received: (from cgf@localhost) by trixie.bosbc.com (8.11.6/8.8.7) id fASJUB706584 for gdb-patches@sources.redhat.com; Wed, 28 Nov 2001 14:30:11 -0500 Date: Sat, 17 Nov 2001 20:21:00 -0000 From: Christopher Faylor To: gdb-patches@sources.redhat.com Subject: Re: [RFC/RFA] Add hardware watchpoint support for cygwin target. Message-ID: <20011128193011.GA6502@redhat.com> Mail-Followup-To: gdb-patches@sources.redhat.com References: <4.2.0.58.20011128183252.00acd198@ics.u-strasbg.fr> <8011-Wed28Nov2001201312+0200-eliz@is.elta.co.il> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8011-Wed28Nov2001201312+0200-eliz@is.elta.co.il> User-Agent: Mutt/1.3.23.1i X-SW-Source: 2001-11/txt/msg00326.txt.bz2 On Wed, Nov 28, 2001 at 08:13:12PM +0200, Eli Zaretskii wrote: >> Date: Wed, 28 Nov 2001 18:44:44 +0100 >> From: Pierre Muller >> >> But te are some annoying things, >> the most annoying is that an exception seems to be generated >> on read access of the watched area even if you only set a normal >> watchpoint (which should use a write-only debug feature). > >So you are saying that watch, rwatch, and awatch all yield the same >behavior? > >Are you sure that you pass the watchpoint information correctly to >the OS? For example, is the format of DR7 as the OS wants it >identical to what GDB uses? The layout of bits in dr_control_mirror >follows Intel documentation, but the OS might want those bits in a >different format (that's what the corresponding DPMI call does, for >example). I don't have Windows docs, so I cannot check this. > >> > /* Get the value of the DR6 debug status register from the inferior. >> > Here we just return the value stored in D_REGS, as we've got it >> > from the last go32_wait call. */ > >I believe you didn't really mean ``go32_wait'' here ;-) I'd like some clarification on this before I can accept the patch. It seems like the described behavior would be annoying indeed. It would be nice to fix this. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christopher Faylor To: gdb-patches@sources.redhat.com Subject: Re: [RFC/RFA] Add hardware watchpoint support for cygwin target. Date: Wed, 28 Nov 2001 11:30:00 -0000 Message-ID: <20011128193011.GA6502@redhat.com> References: <4.2.0.58.20011128183252.00acd198@ics.u-strasbg.fr> <8011-Wed28Nov2001201312+0200-eliz@is.elta.co.il> X-SW-Source: 2001-11/msg00541.html Message-ID: <20011128113000.reNn5TPI7zZkEly5Z4sMm6D6o3j587TFPn_zd7PUigs@z> On Wed, Nov 28, 2001 at 08:13:12PM +0200, Eli Zaretskii wrote: >> Date: Wed, 28 Nov 2001 18:44:44 +0100 >> From: Pierre Muller >> >> But te are some annoying things, >> the most annoying is that an exception seems to be generated >> on read access of the watched area even if you only set a normal >> watchpoint (which should use a write-only debug feature). > >So you are saying that watch, rwatch, and awatch all yield the same >behavior? > >Are you sure that you pass the watchpoint information correctly to >the OS? For example, is the format of DR7 as the OS wants it >identical to what GDB uses? The layout of bits in dr_control_mirror >follows Intel documentation, but the OS might want those bits in a >different format (that's what the corresponding DPMI call does, for >example). I don't have Windows docs, so I cannot check this. > >> > /* Get the value of the DR6 debug status register from the inferior. >> > Here we just return the value stored in D_REGS, as we've got it >> > from the last go32_wait call. */ > >I believe you didn't really mean ``go32_wait'' here ;-) I'd like some clarification on this before I can accept the patch. It seems like the described behavior would be annoying indeed. It would be nice to fix this.