From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16912 invoked by alias); 24 Jan 2008 07:35:39 -0000 Received: (qmail 16903 invoked by uid 22791); 24 Jan 2008 07:35:38 -0000 X-Spam-Check-By: sourceware.org Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.8) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 24 Jan 2008 07:35:11 +0000 Received: from kahikatea.snap.net.nz (93.61.255.123.dynamic.snap.net.nz [123.255.61.93]) by viper.snap.net.nz (Postfix) with ESMTP id 699083DA185; Thu, 24 Jan 2008 20:35:07 +1300 (NZDT) Received: by kahikatea.snap.net.nz (Postfix, from userid 1000) id BF2E08FC6D; Thu, 24 Jan 2008 20:35:02 +1300 (NZDT) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18328.16293.286454.235065@kahikatea.snap.net.nz> Date: Thu, 24 Jan 2008 12:41:00 -0000 To: Vladimir Prus Cc: gdb-patches@sources.redhat.com Subject: Re: [PATCH] Variable objects in multi-threaded programs In-Reply-To: References: <18328.5277.85018.374650@kahikatea.snap.net.nz> X-Mailer: VM 7.19 under Emacs 23.0.50.36 X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-01/txt/msg00581.txt.bz2 > I'm somewhat concerned that this patch makes gdb traverse stacks of all > threads -- it can take quite some time. Would a better solution be > to store thread id inside varobj? Yes I think it would. As an element of struct varobj_root? Perhaps this should also included as a field in the output of -var-create, the frontend could organise the display of watch expressions by thread. If we use the GDB thread id, this would be consistent with infrun.c -- Nick http://www.inet.net.nz/~nickrob