From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20396 invoked by alias); 31 Jul 2006 08:32:24 -0000 Received: (qmail 20340 invoked by uid 22791); 31 Jul 2006 08:32:23 -0000 X-Spam-Check-By: sourceware.org Received: from fra-del-03.spheriq.net (HELO fra-del-03.spheriq.net) (195.46.51.99) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 31 Jul 2006 08:32:17 +0000 Received: from fra-out-01.spheriq.net (fra-out-01.spheriq.net [195.46.51.129]) by fra-del-03.spheriq.net with ESMTP id k6V8WEM3026213 for ; Mon, 31 Jul 2006 08:32:15 GMT Received: from fra-cus-02.spheriq.net (fra-cus-02.spheriq.net [195.46.51.38]) by fra-out-01.spheriq.net with ESMTP id k6V8WAIb015920 for ; Mon, 31 Jul 2006 08:32:13 GMT Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by fra-cus-02.spheriq.net with ESMTP id k6V8W7Rk023300 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Mon, 31 Jul 2006 08:32:10 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 8A25DDA4B; Mon, 31 Jul 2006 08:32:02 +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 3A2664749C; Mon, 31 Jul 2006 08:32:02 +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 CIC20525 (AUTH "frederic riss"); Mon, 31 Jul 2006 10:32:00 +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: <20060728151434.GA17238@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> Content-Type: text/plain Date: Mon, 31 Jul 2006 08:32:00 -0000 Message-Id: <1154334744.28300.302.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/msg00423.txt.bz2 On Fri, 2006-07-28 at 11:14 -0400, Daniel Jacobowitz wrote: > On Fri, Jul 28, 2006 at 04:56:03PM +0200, Frederic RISS wrote: > > * infrun.c detects breakpoint thread mismatch early and has code to > > handle thread hops correctly. This code won't be used in case the thread > > mismatch is detected only in the breakpoint condition. Couldn't that > > cause some problems? (If it's not an issue, we could certainly cleanup > > handle_inferior_event to remove that code) > > It could probably be rearranged to only happen late. 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? Or maybe by 'happen late' you mean later in time and not later in the code... but still I don't see how we could keep the current code semantics. Fred.