From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4699 invoked by alias); 28 Jul 2006 14:59:20 -0000 Received: (qmail 4683 invoked by uid 22791); 28 Jul 2006 14:59:18 -0000 X-Spam-Check-By: sourceware.org Received: from lon-del-01.spheriq.net (HELO lon-del-01.spheriq.net) (195.46.50.97) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 28 Jul 2006 14:59:01 +0000 Received: from lon-out-01.spheriq.net ([195.46.50.129]) by lon-del-01.spheriq.net with ESMTP id k6SEwPvr010246 for ; Fri, 28 Jul 2006 14:58:38 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 k6SEwPJP016575 for ; Fri, 28 Jul 2006 14:58:25 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 k6SEwMS0010602 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Fri, 28 Jul 2006 14:58:24 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 2E9C9DA91; Fri, 28 Jul 2006 14:57:27 +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 B284547951; Fri, 28 Jul 2006 14:56:01 +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 CIB87430 (AUTH "frederic riss"); Fri, 28 Jul 2006 16:56: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: <20060728141339.GA15103@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> Content-Type: text/plain Date: Fri, 28 Jul 2006 14:59:00 -0000 Message-Id: <1154098563.28300.282.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/msg00419.txt.bz2 On Fri, 2006-07-28 at 10:13 -0400, Daniel Jacobowitz wrote: > On Fri, Jul 28, 2006 at 03:38:41PM +0200, Frederic RISS wrote: > > Maybe the alternate approach of adding a $thread variable to use in bp > > conditions ( http://www.sourceware.org/ml/gdb/2006-02/msg00017.html ) > > should be implemented instead ? > > I think that's a better idea. Although, Vlad used interior_ptid.pid; > I would have thought that the better choice would be to use GDB's > internal thread numbering. (In fact .pid wouldn't even work, that can > be the same between threads). Yes. Moreover the user has always access to GDB thread ids (info threads), but access to other process/thread information isn't enforced by our target_ops. I'm all in favor of this idea (mainly because it allows to test for multiple threads for the same breakpoint), but I think it might be an issue in some cases: * 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) * I'm also a bit concerned about performance. Evaluating expressions is heavier that just comparing thread ids. At least in the context I use this functionality, the faster we resume, the better my system behaves. I haven't done any real profiling on this this point might be moot. Fred.