From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 81236 invoked by alias); 9 Oct 2018 14:09:08 -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 81202 invoked by uid 89); 9 Oct 2018 14:09:07 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=guaranty, signify, loud, dealt 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 ESMTP; Tue, 09 Oct 2018 14:09:04 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 5BB9856013; Tue, 9 Oct 2018 10:09:03 -0400 (EDT) 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 lrYDFG5yVdWp; Tue, 9 Oct 2018 10:09:03 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 4A9D756012; Tue, 9 Oct 2018 10:09:03 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id A4ACE82C82; Tue, 9 Oct 2018 10:09:02 -0400 (EDT) Date: Tue, 09 Oct 2018 14:09:00 -0000 From: Joel Brobecker To: gdb-patches@sourceware.org Cc: philippe.waroquiers@skynet.be Subject: RFC: using Ada tasks numbers with thread commands Message-ID: <20181009140902.GA3430@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.9.4 (2018-02-28) X-SW-Source: 2018-10/txt/msg00212.txt.bz2 Hello, Philippe and I were discussing how some Ada task commands, and the lack of support for some functionalities that we have for thread commands. For instance, we have "thread apply ...", and Ada users usually prefer to iterate over Ada tasks rather than threads. I was ready to work on implementing equivalent Ada commands, but Philippe instead suggested that we just enhance the thread ID parsing routines to recognize a special syntax that would signify the ID is not a thread, but rather an Ada task. For instance, Philippe suggested something like adding a 't' suffix (eg: 5t); I could imagine something like 'a' for "Ada" instead, as 't' can be both "thread" and "task", and we could play with making it a prefix instead (eg: "a5"). So, existing thread commands would automatically be able to handle Ada task numbers also. Eg: (gdb) thread apply 5a-7a bt What do you guys think of the idea? On my end, I have to say I have some reservations about this; for a single Ada task, why not indeed; but for a range of tasks, there is no guaranty that a range of Ada tasks maps to a range of threads; nor that Ada tasks are going to be listed in the same order as threads. That being said - if people are OK with the syntax above, I think the issues I listed can be easily dealt with, but having the thread ID parser expand the range into a list. But thinking out loud - what if the user used a hybrid range? Would that make any kind of sense? If yes, how do you expand that, knowing again that threads and Ada numbers do not necessarily have a linear mapping. If feels like, at least to start with, we should not allow that at all. Thoughts? -- Joel