From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5558 invoked by alias); 31 Jul 2006 14:00:47 -0000 Received: (qmail 5549 invoked by uid 22791); 31 Jul 2006 14:00:46 -0000 X-Spam-Check-By: sourceware.org Received: from lon-del-04.spheriq.net (HELO lon-del-04.spheriq.net) (195.46.50.101) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 31 Jul 2006 14:00:39 +0000 Received: from lon-out-01.spheriq.net ([195.46.50.129]) by lon-del-04.spheriq.net with ESMTP id k6VE0aN5015531 for ; Mon, 31 Jul 2006 14:00:36 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 k6VE0ZTs005667 for ; Mon, 31 Jul 2006 14:00:35 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 k6VE0VJW006618 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Mon, 31 Jul 2006 14:00: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 44CC0DA65; Mon, 31 Jul 2006 14:00:01 +0000 (GMT) Received: from mail1.cro.st.com (mail1.cro.st.com [164.129.40.131]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id DFC3147677; Mon, 31 Jul 2006 14:00:00 +0000 (GMT) Received: from crx549.cro.st.com (crx549.cro.st.com [164.129.44.49]) by mail1.cro.st.com (MOS 3.5.8-GR) with ESMTP id CIC27589 (AUTH "frederic riss"); Mon, 31 Jul 2006 15:59:59 +0200 (CEST) Subject: Re: [RFC] New threadnum command for breakpoints From: Frederic RISS To: Daniel Jacobowitz Cc: Andreas Schwab , gdb-patches@sources.redhat.com In-Reply-To: <20060731125311.GA1272@nevyn.them.org> References: <1154093921.28300.236.camel@crx549.cro.st.com> <1154093921.28300.236.camel@crx549.cro.st.com> <20060728141339.GA15103@nevyn.them.org> <1154098563.28300.282.camel@crx549.cro.st.com> <20060728151434.GA17238@nevyn.them.org> <1154334744.28300.302.camel@crx549.cro.st.com> <20060731125311.GA1272@nevyn.them.org> Content-Type: text/plain Date: Mon, 31 Jul 2006 14:00:00 -0000 Message-Id: <1154354425.28300.335.camel@crx549.cro.st.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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 X-SW-Source: 2006-07/txt/msg00429.txt.bz2 On Mon, 2006-07-31 at 08:53 -0400, Daniel Jacobowitz wrote: > > I must be missing something. If thread hops have to be handled > > separately, you must be able to distinguish a condition that indicates > > 'wrong thread' from another that just says 'wrong condition', no? > [..] > > I have the feeling we could treat "wrong thread" and "wrong condition" > exactly identically, and everything would still work. OK. I've got the same feeling, but given the complexity of the execution control machinery I was reluctant to change it. bpstat_stop_status already checks for the thread match, so removing the breakpoint_thread_match test in handle_inferior_event seems right and should give us nearly identical code paths for thread tests carried out using bp->thread or the $_gdb_thread variable. I'll follow up soon with a patch doing this. BTW, noone answered your request for comments about the variable name, so I'll do the first iteration using $_gdb_thread. Fred.