From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31205 invoked by alias); 31 Mar 2005 04:48:45 -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 31177 invoked from network); 31 Mar 2005 04:48:36 -0000 Received: from unknown (HELO romy.inter.net.il) (192.114.186.66) by sourceware.org with SMTP; 31 Mar 2005 04:48:36 -0000 Received: from zaretski (IGLD-80-230-68-88.inter.net.il [80.230.68.88]) by romy.inter.net.il (MOS 3.5.6-GR) with ESMTP id AWJ53485 (AUTH halo1); Thu, 31 Mar 2005 06:48:34 +0200 (IST) Date: Thu, 31 Mar 2005 04:48:00 -0000 From: "Eli Zaretskii" To: GDB Message-ID: <01c535ac$Blat.v2.4$8e31c2c0@zahav.net.il> Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=ISO-8859-1 In-reply-to: <20050331023307.GA8637@nevyn.them.org> (message from Daniel Jacobowitz on Wed, 30 Mar 2005 21:33:07 -0500) Subject: Re: [mi] watchpoint-scope exec async command Reply-to: Eli Zaretskii References: <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> <20050329214414.GA3498@nevyn.them.org> <01c53564$Blat.v2.4$1da3c140@zahav.net.il> <20050331023307.GA8637@nevyn.them.org> X-SW-Source: 2005-03/txt/msg00309.txt.bz2 > Date: Wed, 30 Mar 2005 21:33:07 -0500 > From: Daniel Jacobowitz > Cc: GDB > > No, we're crashing earlier than that. This was in one of Bob's earlier > messages; we crash here: > > 1021 if (bpt->owner->related_breakpoint) > 1022 bpt->owner->related_breakpoint->disposition = disp_del_at_next_stop; > 1023 bpt->owner->disposition = disp_del_at_next_stop; Right. > > If we don't arrange a scope breakpoint for a hardware watchpoint, we > > won't hit the problem Bob reported. > > I think this would be pretty tricky. We would have to recognize that > if the next thing to trigger is the watchpoint, it doesn't "count". Sorry, I'm not following. What I meant was this: when we _create_ the watchpoint, if it's a hardware-assisted watchpoint, we should simply not arrange a scope breakpoint for it. How is that tricky, and why would we need to know that the next thing to trigger is the watchpoint? > The second seems marginally cleaner to me. I wouldn't mind the second alternative too much. > Even better would be deleting the software watchpoint at the same > time How is this different from what I said? I said: > The second alternative is to treat scope breakpoints specially in > breakpoint_auto_delete: when we see a scope breakpoint that is marked > for deletion, we will have to find its watchpoint, and if that > watchpoint is a hardware watchpoint, we will have to delete that > watchpoint as well.