From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28474 invoked by alias); 14 Nov 2005 11:34:41 -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 28464 invoked by uid 22791); 14 Nov 2005 11:34:38 -0000 Received: from lon-del-04.spheriq.net (HELO lon-del-04.spheriq.net) (195.46.50.101) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Mon, 14 Nov 2005 11:34:38 +0000 Received: from lon-out-01.spheriq.net ([195.46.50.129]) by lon-del-04.spheriq.net with ESMTP id jAEBYZgd012076 for ; Mon, 14 Nov 2005 11:34:35 GMT Received: from lon-cus-01.spheriq.net (lon-cus-01.spheriq.net [195.46.50.37]) by lon-out-01.spheriq.net with ESMTP id jAEBYX65023304 for ; Mon, 14 Nov 2005 11:34:34 GMT Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by lon-cus-01.spheriq.net with ESMTP id jAEBYV2k010514 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Mon, 14 Nov 2005 11:34:32 GMT Received: from zeta.dmz-eu.st.com (ns2.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 9465BDA45; Mon, 14 Nov 2005 11:34:31 +0000 (GMT) Received: by zeta.dmz-eu.st.com (STMicroelectronics, from userid 60012) id 5499A47465; Mon, 14 Nov 2005 11:37:29 +0000 (GMT) Received: from zeta.dmz-eu.st.com (localhost [127.0.0.1]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 164A875969; Mon, 14 Nov 2005 11:37:29 +0000 (UTC) Received: from mail1.bri.st.com (mail1.bri.st.com [164.129.8.218]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 994A447464; Mon, 14 Nov 2005 11:37:28 +0000 (GMT) Received: from [164.129.15.13] (terrorhawk.bri.st.com [164.129.15.13]) by mail1.bri.st.com (MOS 3.5.8-GR) with ESMTP id CGZ17619 (AUTH "andrew stubbs"); Mon, 14 Nov 2005 11:34:29 GMT Message-ID: <437875B0.4000007@st.com> Date: Mon, 14 Nov 2005 16:34:00 -0000 From: Andrew STUBBS User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) MIME-Version: 1.0 To: Daniel Jacobowitz Cc: gdb-patches@sources.redhat.com Subject: Re: [PATCH] Disable thread specific breakpoints when thread dies References: <43723446.7000903@st.com> <20051113184515.GG3599@nevyn.them.org> In-Reply-To: <20051113184515.GG3599@nevyn.them.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-O-Spoofed: Not Scanned X-O-General-Status: No X-O-Spam1-Status: Not Scanned X-O-Spam2-Status: Not Scanned X-O-URL-Status: Not Scanned X-O-Virus1-Status: No X-O-Virus2-Status: Not Scanned X-O-Virus3-Status: No X-O-Virus4-Status: No X-O-Virus5-Status: Not Scanned X-O-Image-Status: Not Scanned X-O-Attach-Status: Not Scanned X-SpheriQ-Ver: 4.1.07 X-SW-Source: 2005-11/txt/msg00189.txt.bz2 Daniel Jacobowitz wrote: > 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. So you want to disable it 'unofficially'? I suppose that would be preferable, but I wouldn't know that best way to achieve it. I'll have a look though. GDB already plays with watchpoints (deletes them in fact). At least it did in 6.3. That said I wouldn't complain if somebody 'fixed' them so that they were reinstated when the program returned to the right context. Thanks Andrew