From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13685 invoked by alias); 13 Nov 2005 18:45:19 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 13674 invoked by uid 22791); 13 Nov 2005 18:45:17 -0000 Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Sun, 13 Nov 2005 18:45:17 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1EbMqp-00018U-Ux; Sun, 13 Nov 2005 13:45:16 -0500 Date: Sun, 13 Nov 2005 21:13:00 -0000 From: Daniel Jacobowitz To: Andrew STUBBS Cc: gdb-patches@sources.redhat.com Subject: Re: [PATCH] Disable thread specific breakpoints when thread dies Message-ID: <20051113184515.GG3599@nevyn.them.org> Mail-Followup-To: Andrew STUBBS , gdb-patches@sources.redhat.com References: <43723446.7000903@st.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43723446.7000903@st.com> User-Agent: Mutt/1.5.8i X-SW-Source: 2005-11/txt/msg00175.txt.bz2 On Wed, Nov 09, 2005 at 05:39:18PM +0000, Andrew STUBBS wrote: > Hi, > > The attached patch disables thread specific breakpoints if they are hit > (in another thread) after the specific thread has died. > > The rationale is that, once dead, the thread in question can never come > back, and the breakpoint is then only a, potentially serious, > performance drain. Even if another thread can be created with that ID it > would not be appropriate to 'hit' the breakpoint. > > The breakpoint is not deleted, only disabled. It may still be easily > re-enabled when the program is re-run. > > Is this OK? Sorry, I don't like this. First, minor formatting problems: - printf_filtered should take a _("gettextized") string now. - spaces before opening parentheses (other than in the gettext case) - Capital letters and periods in comments. But about the actual patch... I'd like to minimize the amount that GDB plays with the user visible state of breakpoints. Can we arrange to just not insert breakpoints, if they are thread-specific to a dead thread? I think that'll work too. -- Daniel Jacobowitz CodeSourcery, LLC