From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19698 invoked by alias); 21 Nov 2001 13:06:53 -0000 Mailing-List: contact gdb-help@sourceware.cygnus.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 19632 invoked from network); 21 Nov 2001 13:06:43 -0000 Received: from unknown (HELO cerbere.u-strasbg.fr) (130.79.112.7) by sourceware.cygnus.com with SMTP; 21 Nov 2001 13:06:43 -0000 Received: from laocoon (laocoon.u-strasbg.fr [130.79.112.72]) by cerbere.u-strasbg.fr (8.9.3/8.8.7) with ESMTP id OAA09071 for ; Wed, 21 Nov 2001 14:06:42 +0100 Message-Id: <4.2.0.58.20011121140420.01afe368@ics.u-strasbg.fr> X-Sender: muller@ics.u-strasbg.fr X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Sat, 10 Nov 2001 09:44:00 -0000 To: gdb@sources.redhat.com From: Pierre Muller Subject: Bug with i386 watchpoints In-Reply-To: <4.2.0.58.20011121131718.01644a48@ics.u-strasbg.fr> References: <4.2.0.58.20011121130736.016b6e80@ics.u-strasbg.fr> <4.2.0.58.20011121124943.00a4a288@ics.u-strasbg.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-SW-Source: 2001-11/txt/msg00102.txt.bz2 At 13:22 21/11/2001 , Pierre Muller a écrit: >At 13:12 21/11/2001 , Pierre Muller a écrit: >>At 13:01 21/11/2001 , vous avez écrit: >> >>> There seems to be a big problem with >>>hardware watchpoints under Linux. >>> >>> If I compile a simple program : >>> >>>/* START of twatch.c */ >>>static int x,y; >>>int >>>main () >>>{ >>> x = 5; >>> y = x * 2; >>> x = y / 2; >>> x = 7; >>> return 0; >>>} >>>/* END of twatch.c */ >>>and set a hardware watchpoint on variable 'x', >>>the debugger correctly stops at each program location where this global >>>var is changed. >>> >>> But at the second run, the program is never stopped because >>>of the changes to this global variable. >>> >>> It seems like there is a problem with the hardware watchpoint >>>resetting. >>> >>> I tested this on only one Linux machine, >>>but both the main and the 5.1 branches show this problem. >>> >>> >>> The current main CVS tree with a patch (not yet submitted) >>>to add hardware watchpoints on cygwin target does not >>>have this problem (It works but there are still some problems). >> >>Whoops, I was too fast once again... >> >>I do see the same problem in my cygwin implementation ... > > I now see : > only the go32-nat.c code does call > i386_clean_dregs function. >I didn't have it in my cygwin patch, >and it also does not appear in >any other gdb dir source. > > This is probably the cause of the problem, >it does indeed solve the bug for cygwin if I add this call to >child_mourn_inferior as go32-nat code does. > > Probably the same will fix the bug for linux too, but I can't try this > out now... I tried to look into the i386 linux files but I don't really know into which file we should add this call to i386_cleanup_dregs. Eli, does the i386_cleanup_dregs also get called if you kill your debugged program ? I suspect not, maybe this should be tested. Are there other i386 targets that might suffer from the lack of call to i386_cleanup_dregs ? Pierre Muller Institut Charles Sadron 6,rue Boussingault F 67083 STRASBOURG CEDEX (France) mailto:muller@ics.u-strasbg.fr Phone : (33)-3-88-41-40-07 Fax : (33)-3-88-41-40-99