From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11243 invoked by alias); 5 Jun 2008 18:27:29 -0000 Received: (qmail 11214 invoked by uid 22791); 5 Jun 2008 18:27:28 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 05 Jun 2008 18:27:08 +0000 Received: (qmail 16062 invoked from network); 5 Jun 2008 18:27:05 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 5 Jun 2008 18:27:05 -0000 From: Pedro Alves To: Daniel Jacobowitz Subject: Re: remove global stop_bpstat dependency from breakpoints module Date: Thu, 05 Jun 2008 18:27:00 -0000 User-Agent: KMail/1.9.9 Cc: gdb-patches@sourceware.org References: <200805080222.04976.pedro@codesourcery.com> <20080605180331.GB16610@caradoc.them.org> In-Reply-To: <20080605180331.GB16610@caradoc.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200806051927.07953.pedro@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-06/txt/msg00047.txt.bz2 A Thursday 05 June 2008 19:03:31, Daniel Jacobowitz wrote: > On Thu, May 08, 2008 at 02:22:04AM +0100, Pedro Alves wrote: > > I had missed this on the non-stop series. I'll need to context switch > > stop_bpstat in non-stop mode, because there, we'll have simultaneous > > independant stop events, one per thread, and each should have its own > > stop_bpstat. That's a small change to patch 4 in series I posted. > > The implementation makes it look like this will work for watchpoints > too. If we want to preserve that - which is not the documented > behavior - then I agree we should context-switch stop_bpstat. But > I'm thinking it makes more sense to restrict this to breakpoints, > and search for a breakpoint at the current PC. Well, I can't say if we want to preserve that. I never use this functionality, so I wouldn't missed it. The "ignore" command gets me the same functionality anyway. Notice that I was proposing context switching it in non-stop only. The current implementation sets the ignore count on the breakpoint that we stopped last. If we just read current PC, we may be reading it from the wrong thread: Breakpoint 1, at xxx thread 2 c 10 we could use get_last_target_status to get at the correct PC if we do want to preserve this behaviour in all-stop. In non-stop, I'd read from the current thread always. But, the help doc: "Continue program being debugged, after signal or breakpoint. If proceeding from breakpoint, a number N may be used as an argument, which means to set the ignore count of that breakpoint to N - 1 (so that the breakpoint won't break until the Nth time it is reached)" ... doesn't make it clear, if "proceeding" was meant to apply to the last breakpoint, or to the breakpoint under PC. As I said, I would mind at all to change this to the read the PC of the current thread. Just pointing out the current behaviour. > > What do you think? Also, does that remove the only reason to > context-switch stop_bpstat? If so, we don't need this patch at all. > Yes. > > One way to fix it, would be to also loop through all threads to update > > their version of stop_bpstat, but I'd like better. > > If we do need to context-switch stop_bpstat, it seems like checking > all of those would be simpler than this patch as posted. Well, simpler yes, but adds even more coupling. I thought this was a nice cleanup. It's mentioned a few times in comments throughout breakpoints.c. -- Pedro Alves