From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3735 invoked by alias); 18 Dec 2015 17:53:15 -0000 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 Received: (qmail 3726 invoked by uid 89); 18 Dec 2015 17:53:14 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 spammy=ides, Hx-languages-length:1242, problem! X-HELO: rock.gnat.com Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Fri, 18 Dec 2015 17:53:13 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id F23BA116845; Fri, 18 Dec 2015 12:53:11 -0500 (EST) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id DEsaAAq5NMvm; Fri, 18 Dec 2015 12:53:11 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 98266116831; Fri, 18 Dec 2015 12:53:11 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id 7E08C406CD; Fri, 18 Dec 2015 21:53:07 +0400 (RET) Date: Fri, 18 Dec 2015 17:53:00 -0000 From: Joel Brobecker To: Pedro Alves Cc: gdb-patches@sourceware.org Subject: Re: [PATCH] Per-inferior thread IDs Message-ID: <20151218175307.GC29928@adacore.com> References: <1450206316-25680-1-git-send-email-palves@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1450206316-25680-1-git-send-email-palves@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-SW-Source: 2015-12/txt/msg00371.txt.bz2 > However, before I dig deeper, I thought I'd post this for feedback. FWIW, I think that this is a fairly nice way of addressing the problem! The only question I have is that I'm a little unclear as to what it will look like with GDB/MI. From what I can tell, there is no real change at all, meaning that the "thread-id" is the thread's global ID. But perhaps it wouuld be nice to add an extra field giving the thread's ID in string form. Newer IDEs knowing about this new feature would then have an easy way to present the list of threads using the same representation as the one we see with the CLI interface. Just a thought... Another way would be to provide the per-inferior-thread-id in numeric form, which should be sufficient, since I think the inferior-id is already provided. It has a cleaner feel to it, but on the other hand, it forces the IDEs to rebuild the thread ID by hand - which is not so simple, since we have this exception where if there is one inferior whose ID is 1, we don't use the composite thread ID. That being said, maybe the IDEs don't even (need to) display that ID... So we could also leave that question open for debate when the need actually materializes... -- Joel