From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15243 invoked by alias); 29 Mar 2005 23:29:07 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 15156 invoked from network); 29 Mar 2005 23:29:03 -0000 Received: from unknown (HELO lakermmtao05.cox.net) (68.230.240.34) by sourceware.org with SMTP; 29 Mar 2005 23:29:03 -0000 Received: from white ([68.9.64.121]) by lakermmtao05.cox.net (InterMail vM.6.01.04.00 201-2131-118-20041027) with ESMTP id <20050329232903.LVCN3789.lakermmtao05.cox.net@white>; Tue, 29 Mar 2005 18:29:03 -0500 Received: from bob by white with local (Exim 3.35 #1 (Debian)) id 1DGR3k-0001XB-00; Tue, 29 Mar 2005 19:27:48 -0500 Date: Tue, 29 Mar 2005 23:29:00 -0000 From: Bob Rossi To: Eli Zaretskii Cc: GDB Subject: Re: [mi] watchpoint-scope exec async command Message-ID: <20050330002748.GA5882@white> Mail-Followup-To: Eli Zaretskii , GDB References: <01c53207$Blat.v2.4$3def9b00@zahav.net.il> <20050328225619.GB3413@white> <20050328224101.GA629@nevyn.them.org> <20050328235310.GA3699@white> <20050328230048.GA1697@nevyn.them.org> <20050329014203.GB3801@white> <20050329013634.GB6373@nevyn.them.org> <20050329024945.GC3957@white> <20050329020123.GA7266@nevyn.them.org> <01c534a6$Blat.v2.4$944e44a0@zahav.net.il> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01c534a6$Blat.v2.4$944e44a0@zahav.net.il> User-Agent: Mutt/1.3.28i X-SW-Source: 2005-03/txt/msg00291.txt.bz2 On Tue, Mar 29, 2005 at 11:29:48PM +0200, Eli Zaretskii wrote: > [Sorry for a late response: I needed to refresh my memory of how the > related code works.] Are you serious? That was like the speed of light compared to what I'm used to. > Let's not forget that software watchpoints also share some (most?) of > the code used for hardware data-write watchpoints. I'm quite sure > that the scope breakpoint was invented for software watchpoints, > because hardware watchpoints simply don't need it: they incur no > overhead if they are not deleted, as long as they are not hit; and > once they are hit and we find them to be out of scope, we do TRT: mark > both the watchpoint and its related breakpoint for deletion at next > stop. (I suspect that we don't delete them right away due to some > peculiarity of software watchpoints that are implemented by > single-stepping the inferior.) > > Bob, could you also try the same program with a software watchpoint, > and see if you hit the same bug or not? If the behavior is different, > please show where the GDB execution thread goes a different way and > how it avoids the crash. (Forcing software watchpoints might not be > easy. One way, on a x86 machine, is to watch a region that is more > than 16 bytes long. Another way is to build a hacked version of GDB > that uses only software watchpoints.) It'll be a little bit before I can figure out how to present all the information that you need. However, in case it clear's things up for you, here's some more information. (this info makes me even *more* confused.) When running with software breakpoints, the crash does not happen, and valgrind is happy. Now, what confuses me is that the memory for the related_breakpoint is still deleted in delete_breakpoint and when we set the disposition of the deleted "related_breakpoint" at breakpoint.c:1022(insert_bp_location), things seem to work OK. I don't understand this, but i will present you with the information you asked for as soon as possible. Bob Rossi