From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8564 invoked by alias); 31 Mar 2005 06:00:46 -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 8055 invoked from network); 31 Mar 2005 06:00:36 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 31 Mar 2005 06:00:36 -0000 Received: from drow by nevyn.them.org with local (Exim 4.50 #1 (Debian)) id 1DGrhK-0003Is-TJ; Wed, 30 Mar 2005 23:54:27 -0500 Date: Thu, 31 Mar 2005 06:00:00 -0000 From: Daniel Jacobowitz To: Eli Zaretskii Cc: GDB Subject: Re: [mi] watchpoint-scope exec async command Message-ID: <20050331045426.GA12661@nevyn.them.org> Mail-Followup-To: Eli Zaretskii , GDB References: <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> <01c535ac$Blat.v2.4$8e31c2c0@zahav.net.il> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01c535ac$Blat.v2.4$8e31c2c0@zahav.net.il> User-Agent: Mutt/1.5.6+20040907i X-SW-Source: 2005-03/txt/msg00311.txt.bz2 On Thu, Mar 31, 2005 at 06:45:06AM +0200, Eli Zaretskii wrote: > > 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? Creating it is easy. Handling it when it goes out of scope, however, is harder - if the next thing to trigger a stop is the watchpoint, and we discover there that it has gone out of scope. I don't know, this may just work. But it feels more complicated to me, for whatever that's worth. I like the idea of keeping the multiple watchpoint types as similar as possible. > > 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. You said "if that watchpoint is a hardware watchpoint". I'm just suggesting treating software watchpoints the same way. -- Daniel Jacobowitz CodeSourcery, LLC