From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17416 invoked by alias); 18 Dec 2015 18:47:35 -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 17405 invoked by uid 89); 18 Dec 2015 18:47:34 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=ides, problem! X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 18 Dec 2015 18:47:33 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id 213DCC0B7E04; Fri, 18 Dec 2015 18:47:32 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tBIIlUND015773; Fri, 18 Dec 2015 13:47:31 -0500 Message-ID: <567454C2.1000502@redhat.com> Date: Fri, 18 Dec 2015 18:47:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Joel Brobecker CC: gdb-patches@sourceware.org Subject: Re: [PATCH] Per-inferior thread IDs References: <1450206316-25680-1-git-send-email-palves@redhat.com> <20151218175307.GC29928@adacore.com> In-Reply-To: <20151218175307.GC29928@adacore.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-12/txt/msg00379.txt.bz2 On 12/18/2015 05:53 PM, Joel Brobecker wrote: >> 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. Exactly, no change at all. > 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... Yeah. > > 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. Indeed, hadn't thought of that point. In an earlier revision of the patch I followed the numeric approach. I had a couple new fields to -thread-info output, like: - ^done,threads=[{id="6", ...} ... + ^done,threads=[{thread-group="i2", per-tg-id="3",id="6", ...} ... and: - =thread-created,id=3,group-id="i2" + =thread-created,id=3,group-id="i2",per-tg-id="3" But after chatting with Marc Khouzam (Eclipse CDT) about the whole change's impact, we came to the conclusion that we can add this later when we find a needed. So I left that out of the patch for now. Maybe we should need the new field in the =thread-created event, not sure. Or we go through everywhere and make sure we're consistent. I'm just dodging thinking about all that for now. :-) > > 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... > That's my hope. :-) Thanks, Pedro Alves