From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26246 invoked by alias); 26 Nov 2007 19:21:03 -0000 Received: (qmail 26238 invoked by uid 22791); 26 Nov 2007 19:21:02 -0000 X-Spam-Check-By: sourceware.org Received: from bluesmobile.specifix.com (HELO bluesmobile.specifix.com) (216.129.118.140) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 26 Nov 2007 19:20:58 +0000 Received: from [127.0.0.1] (bluesmobile.specifix.com [216.129.118.140]) by bluesmobile.specifix.com (Postfix) with ESMTP id 0F27A3C119; Mon, 26 Nov 2007 10:59:21 -0800 (PST) Subject: Re: inconsistency in thread naming From: Michael Snyder To: Douglas Evans Cc: gdb@sourceware.org In-Reply-To: References: Content-Type: text/plain Date: Mon, 26 Nov 2007 19:21:00 -0000 Message-Id: <1196104123.2501.49.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 (2.10.3-4.fc7) Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2007-11/txt/msg00232.txt.bz2 On Wed, 2007-11-21 at 16:23 -0800, Douglas Evans wrote: > When gdb switches to a particular thread it prints something like > > [Switching to Thread 12345] > > But the "thread" command takes thread numbers, e.g. > > (gdb) thread 3 > > This inconsistency is a pain. Any objections to making things more > consistent? Any opinions on how this should work? A minimalist > solution might be to include the thread number (3 in the above > example) in the [Switching to ...] message. If there was a consistent > way to distinguish thread number(3) from thread id(12345) [apologies > if my terminology if wrong], then the "thread" command could take > either. E.g. one might support "thread 3" or "thread #12345". I > don't have a strong opinion on what to choose, I'm just thinking out > loud. I see that you understand the context. There are two ways to identify a thread -- the "native" way, with an ID that is assigned by the native system (a process id, LWP id, or whatever), and the gdb internal way, with a small counting integer starting with 1. The gdb-assigned thread ids are analogous to breakpoint ids, and are much easier to type. All gdb commands take the counting-integer-type thread ids as arguments. I think both of your suggestions are good: (1) Identify the internal thread ID in the "Switching to" and "New Thread" messages. (2) Provide a syntax (eg. prefix character) with which the user may use the native thread id instead of the gdb thread id as a command argument. By the way, "info threads" is your interface for discovering the mapping between gdb thread id and native thread id. Cheers, Michael