From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6073 invoked by alias); 9 Nov 2009 17:16:23 -0000 Received: (qmail 6062 invoked by uid 22791); 9 Nov 2009 17:16:22 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from imr2.ericy.com (HELO imr2.ericy.com) (198.24.6.3) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 09 Nov 2009 17:16:18 +0000 Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id nA9HGDMo012266; Mon, 9 Nov 2009 11:16:15 -0600 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.51]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 11:14:46 -0600 Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 11:14:45 -0600 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.4]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Mon, 9 Nov 2009 12:14:45 -0500 From: Marc Khouzam To: "'Vladimir Prus'" CC: "'gdb@sources.redhat.com'" Date: Mon, 09 Nov 2009 17:33:00 -0000 Subject: RE: [MI] Extending -list-thread-groups --available to show cores Message-ID: References: <200911081804.31988.vladimir@codesourcery.com> <200911091739.12743.vladimir@codesourcery.com> <200911091929.23231.vladimir@codesourcery.com> In-Reply-To: <200911091929.23231.vladimir@codesourcery.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-IsSubscribed: yes 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/msg00091.txt.bz2 > -----Original Message----- > From: Vladimir Prus [mailto:vladimir@codesourcery.com]=20 > Sent: Monday, November 09, 2009 11:29 AM > To: Marc Khouzam > Cc: 'gdb@sources.redhat.com' > Subject: Re: [MI] Extending -list-thread-groups --available=20 > to show cores >=20 > On Monday 09 November 2009 Marc Khouzam wrote: >=20 > > > > > We were recently asked to slightly extend the=20 > returned information > > > > > to include the core where each thread runs. Such=20 > information is > > > > > of little use for typical Linux application, since threads are > > > > > migrated between cores. However, it's useful for both custom=20 > > > > > Linux applications that specifically pin threads to=20 > > > specific cores, > > > > > and for embedded systems. Therefore, I plan to add a new field > > > > > to the thread information that is output by=20 > >=20 > > Is there currently thread information in the output of=20 > "--available"? >=20 > No. Sorry, I had not understood from the spec that you would be adding thread information to the output to "--availabe" > > > > > -list-thread-groups --available, named 'core' that=20 > will give the > > > > > number of the core. E.g. > > > >=20 > > > > I assume you didn't mean to restrict this output to the=20 > > > "--available" > > > > form of "-list-thread-groups", but meant to say that it=20 > would affect > > > > all forms of "-list-thread-groups", right? > > >=20 > > > I actually did mean to restrict to --available ;-) But if 'core' > > > will be beneficial for ordinary '-list-thread-group',=20 > please assume > > > it's there. > >=20 > > It is just that in the original email, the examples you gave were > > not for the "--available" case :-) > >=20 > > -list-thread-groups > >=20=09 > ^done,groups=3D[{id=3D"17",type=3D"process",pid=3D"yyy",num_children=3D" > 2",cores=3D[1,2]}] > > -list-thread-groups 17 > > ^done,threads=3D[{id=3D"2",target-id=3D"Thread 0xb7e14b90=20 > (LWP 21257)",cores=3D[1] > >=20=09=20=20=20 > frame=3D{level=3D"0",addr=3D"0xffffe410",func=3D"__kernel_vsyscall",ar > gs=3D[]},state=3D"running"}, >=20 > I've accidentally left out --available; it should be there. Ok. But that means you are also proposing to support: -list-thread-groups --available [group] I'm just clarifying 'cause that is not suported today. If fact, you are also suggesting -list-thread-groups --available [group1] [group2] ... right? are you also suggesting=20 -list-thread-groups [group1] [group2] ... or not? =20 > > > Yes, "types" should be "type". Basically, we have a=20 > > > compatibility issue > > > here. Now, -list-thread-groups 17 prints only threads in=20 > that process. > > > And if we make '-list -thread-groups 17 18' print only=20 > threads in one > > > list, there will be no way to figure what process each thread=20 > > > belongs to. > > > We can either: > > >=20 > > > 1- add 'process' parent link to each thread > > > 2- show groups, with threads inside them, as the above=20 > output shows > > >=20 > > > The second approach seems easier for frontend, since it won't=20 > > > be required > > > to group threads itself. But it makes the output for '17'=20 > and '17 18' > > > cases be different in structure, so a frontend should be=20 > prepared to > > > both outputs. Does not seem like we can do much better? > >=20 > > What about #1 and having multiple "threads=3D", one for each process? > > Something like: > >=20 > > -list-thread-groups 17 18 > > ^done,threads=3D[{id=3D"2",group=3D"17", target-id=3D"Thread=20 > 0xb7e14b90 (LWP 21257)",cores=3D[1] > >=20=09=20=20=20 > frame=3D{level=3D"0",addr=3D"0xffffe410",func=3D"__kernel_vsyscall",ar > gs=3D[]},state=3D"running"}}], > > threads=3D[{id=3D"3",group=3D"18", target-id=3D"Thread=20 > 0xb7e14b90 (LWP 21257)",cores=3D[1] > >=20=09=20=20=20 > frame=3D{level=3D"0",addr=3D"0xfffff410",func=3D"__kernel_vsyscall",ar > gs=3D[]},state=3D"running"}}]=20 > >=20 > > This would make "-list-thread-groups 17" only get new=20 > backwards-compatible fields, > > while allowing "-list-thread-groups 17 18" to show threads=20 > as part of a grouping. > > Does this go against the rules of MI?=20 >=20 > While there's no explicit rule that names of fields are=20 > unique, having them > non-unique sounds a bit hacky to me. E.g. KDevelop parser=20 > would not even > be able to access such fields. But even if a frontend does not support this format now,=20 it is still a backwards compatible solution since having non-unique fields would only occur in this case when using the new multiple-arg form of -list-thread-groups. Would it be hard to have this concept supported by KDevelop? I didn't try it in DSF-GDB, but since we loop over all fields, each field, unique or not, should eventually be accessed, so it should work quite easily. One could argue that if a frontend cannot handle non-unique fields, it should limit itself to issuing multiple -list-thread-groups and not use the new -list-thread-groups ... > > > Well, we probably can declare that -list-thread-groups is=20 > so new that > > > we can break backward compatibility -- what do you think? > >=20 > > This is tempting. However, even if no other frontend is=20 > using this now, > > if a frontend wants to support GDB 7.0 and the next GDB, they would=20 > > need to code for both outputs. Keeping the output=20 > backwards compatible=20 > > will allow future frontends that don't want to use mutliple=20 > parameters > > to -list-thread-groups to have one way of parsing the output. >=20 > Then, maybe we should trick to the output I have originally suggested. > It looks like having the frontend recognize both 'groups' and=20 > 'threads' > as top-level element in response is just as good as having duplicate > field names. What do you think? The reason I prefer duplicate field names is that I don't really like the idea of having -list-thread-groups group1 have a different output format than -list-thread-groups group1 group2 In my opinion, if it is possible, the two should have the same format, as long as backwards-compatibility can be preserved. But maybe that is just me? Marc