From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8577 invoked by alias); 23 Nov 2001 12:08:35 -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 8076 invoked from network); 23 Nov 2001 12:08:27 -0000 Received: from unknown (HELO cerbere.u-strasbg.fr) (130.79.112.7) by sourceware.cygnus.com with SMTP; 23 Nov 2001 12:08:27 -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 NAA13748; Fri, 23 Nov 2001 13:08:19 +0100 Message-Id: <4.2.0.58.20011123123941.00acc290@ics.u-strasbg.fr> X-Sender: muller@ics.u-strasbg.fr X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Sun, 11 Nov 2001 13:01:00 -0000 To: Eli Zaretskii From: Pierre Muller Subject: Re: Bug with i386 watchpoints Cc: gdb@sources.redhat.com In-Reply-To: <8296-Wed21Nov2001203519+0200-eliz@is.elta.co.il> References: <4.2.0.58.20011121140420.01afe368@ics.u-strasbg.fr> <4.2.0.58.20011121130736.016b6e80@ics.u-strasbg.fr> <4.2.0.58.20011121124943.00a4a288@ics.u-strasbg.fr> <4.2.0.58.20011121140420.01afe368@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/msg00117.txt.bz2 At 19:35 21/11/2001 , Eli Zaretskii a écrit: > > Date: Wed, 21 Nov 2001 14:07:03 +0100 > > From: Pierre Muller > > > > >>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. > >I don't think the missing call to i386_cleanup_dregs is the reason >for the problems you see. That function shouldn't be needed for any >Unix style port of GDB, because when the debuggee exits, the OS >should clean up the watchpoint information from its own internal data >structures. > >The DJGPP port does call i386_cleanup_dregs because in that port, the >OS doesn't know diddley-squat about the watchpoints (or, indeed, about >the fact that GDB is running another program), and so go32-nat.c >inserts the watchpoints every time it is going to run the debuggee. >To insert the watchpoints, go32-nat.c uses the data in the dr_* >arrays, so if they are not cleaned up when the debuggee exits, >go32-nat.c will not DTRT (insert watchpoints you don't want, etc.). > >I suggest to use the maint show-debug-regs command to see what is >going wrong with the watchpoints when you restart the debuggee. If >you cannot figure out what the output tells, post it here. The problem (checked by remove the call to i386_cleanup_dregs in my cygwin implementation) that the last call before program end is a insert_watchpoint. This leads to the fact the the refcount is then set to more the one when I do rerun the debuggee. Each time a debuggee is rerun (after normal exit at least, I didn't check what happens with kill) the refcount gets incremented by one. If I add a new watchpoint, it gets caught the first run after I set it, (i.e. when refcount is one) but never in the runs after... The reason it does not work if refcount is > 0 is that I386_DR_LOW_SET_CONTROL is not used in that case .... So I really think that there is a bug here that can easily be solved, either by adding i386_cleanup_dregs to all targets using i386 hardware watchpoints or by calling I386_DR_LOW_SET_CONTROL even if refcount is > 0, but this really is a bad hack has the refcount will still be wrong.... 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