From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25707 invoked by alias); 9 Nov 2009 16:29:30 -0000 Received: (qmail 25697 invoked by uid 22791); 9 Nov 2009 16:29:28 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=AWL,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 16:29:24 +0000 Received: (qmail 32709 invoked from network); 9 Nov 2009 16:29:22 -0000 Received: from unknown (HELO wind.localnet) (vladimir@127.0.0.2) by mail.codesourcery.com with ESMTPA; 9 Nov 2009 16:29:22 -0000 From: Vladimir Prus To: Marc Khouzam Subject: Re: [MI] Extending -list-thread-groups --available to show cores Date: Mon, 09 Nov 2009 17:20: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> <200911091739.12743.vladimir@codesourcery.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200911091929.23231.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/msg00089.txt.bz2 On Monday 09 November 2009 Marc Khouzam wrote: > > > > 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 > > Is there currently thread information in the output of "--available"? No. > > > > -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. > > It is just that in the original email, the examples you gave were > not for the "--available" case :-) > > -list-thread-groups > ^done,groups=[{id="17",type="process",pid="yyy",num_children="2",cores=[1,2]}] > -list-thread-groups 17 > ^done,threads=[{id="2",target-id="Thread 0xb7e14b90 (LWP 21257)",cores=[1] > frame={level="0",addr="0xffffe410",func="__kernel_vsyscall",args=[]},state="running"}, I've accidentally left out --available; it should be there. > > 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: > > > > 1- add 'process' parent link to each thread > > 2- 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? > > What about #1 and having multiple "threads=", one for each process? > Something like: > > -list-thread-groups 17 18 > ^done,threads=[{id="2",group="17", target-id="Thread 0xb7e14b90 (LWP 21257)",cores=[1] > frame={level="0",addr="0xffffe410",func="__kernel_vsyscall",args=[]},state="running"}}], > threads=[{id="3",group="18", target-id="Thread 0xb7e14b90 (LWP 21257)",cores=[1] > frame={level="0",addr="0xfffff410",func="__kernel_vsyscall",args=[]},state="running"}}] > > This would make "-list-thread-groups 17" only get new backwards-compatible fields, > while allowing "-list-thread-groups 17 18" to show threads as part of a grouping. > Does this go against the rules of MI? While there's no explicit rule that names of fields are unique, having them non-unique sounds a bit hacky to me. E.g. KDevelop parser would not even be able to access such fields. > > Well, we probably can declare that -list-thread-groups is so new that > > we can break backward compatibility -- what do you think? > > This is tempting. However, even if no other frontend is using this now, > if a frontend wants to support GDB 7.0 and the next GDB, they would > need to code for both outputs. Keeping the output backwards compatible > will allow future frontends that don't want to use mutliple parameters > to -list-thread-groups to have one way of parsing the output. Then, maybe we should trick to the output I have originally suggested. It looks like having the frontend recognize both 'groups' and 'threads' as top-level element in response is just as good as having duplicate field names. What do you think? - Volodya > > Marc > >