From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15911 invoked by alias); 9 Nov 2009 14:39:20 -0000 Received: (qmail 15896 invoked by uid 22791); 9 Nov 2009 14:39:19 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 09 Nov 2009 14:39:14 +0000 Received: (qmail 20598 invoked from network); 9 Nov 2009 14:39:12 -0000 Received: from unknown (HELO wind.localnet) (vladimir@127.0.0.2) by mail.codesourcery.com with ESMTPA; 9 Nov 2009 14:39:12 -0000 From: Vladimir Prus To: Marc Khouzam Subject: Re: [MI] Extending -list-thread-groups --available to show cores Date: Mon, 09 Nov 2009 16:25:00 -0000 User-Agent: KMail/1.12.90 (Linux/2.6.24-25-generic; KDE/4.3.73; i686; svn-1043485; 2009-11-01) Cc: "'gdb@sources.redhat.com'" References: <200911081804.31988.vladimir@codesourcery.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200911091739.12743.vladimir@codesourcery.com> 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: 2009-11/txt/msg00085.txt.bz2 On Monday 09 November 2009 Marc Khouzam wrote: > > > -----Original Message----- > > From: gdb-owner@sourceware.org > > [mailto:gdb-owner@sourceware.org] On Behalf Of Vladimir Prus > > Sent: Sunday, November 08, 2009 10:05 AM > > To: gdb@sources.redhat.com > > Subject: [MI] Extending -list-thread-groups --available to show cores > > > > > > Current GDB has a MI command -list-thread-groups to nagivate > > the hierarchy of the debugged thing. This command also the the > > --available option that cause GDB to report the processes that > > can be attached to, as opposed to processes currently being > > debugged. > > > > We were recently asked to slightly extend the returned information > > to include the core where each thread runs. Such information is > > of little use for typical Linux application, since threads are > > migrated between cores. However, it's useful for both custom > > Linux applications that specifically pin threads to specific cores, > > and for embedded systems. Therefore, I plan to add a new field > > to the thread information that is output by > > -list-thread-groups --available, named 'core' that will give the > > number of the core. E.g. > > I assume you didn't mean to restrict this output to the "--available" > form of "-list-thread-groups", but meant to say that it would affect > all forms of "-list-thread-groups", right? I actually did mean to restrict to --available ;-) But if 'core' will be beneficial for ordinary '-list-thread-group', please assume it's there. > > Related to that, it would be somewhat inefficient to issue > > -list-thread-groups > > for every avaialable process to discover the full list of > > threads on specific > > core, so it would be nice to pass several thread groups, like so: > > > > -list-thread-groups 17 18 > > ^done,groups=[{id="17", types="process", ..., > > threads=[{id="2",target-id="Thread > > 0xb7e14b90 (LWP 21257)",cores=[1]}]}, > > {id="18", types="process", ..., > > This is unclear to me. > I see that you are adding the details of the processes before each > process's list of threads. I guess this is necessary because a > frontend will need to know which process the list of threads belong to, > since the will be multiple list of threads. > But how will that affect the ouput of > -list-thread-groups 17 > which currently does not show the details of the process? I assume > it will also include the process info? > (BTW, is "types" in that output meant to be "type") Yes, "types" should be "type". Basically, we have a compatibility issue here. Now, -list-thread-groups 17 prints only threads in that process. And if we make '-list -thread-groups 17 18' print only threads in one list, there will be no way to figure what process each thread belongs to. We can either: - add 'process' parent link to each thread - show groups, with threads inside them, as the above output shows The second approach seems easier for frontend, since it won't be required to group threads itself. But it makes the output for '17' and '17 18' cases be different in structure, so a frontend should be prepared to both outputs. Does not seem like we can do much better? Well, we probably can declare that -list-thread-groups is so new that we can break backward compatibility -- what do you think? - Volodya