From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18939 invoked by alias); 9 Nov 2009 18:48:36 -0000 Received: (qmail 18927 invoked by uid 22791); 9 Nov 2009 18:48:35 -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 18:48:31 +0000 Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id nA9ImDRY022757; Mon, 9 Nov 2009 12:48:21 -0600 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.56]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 12:48:20 -0600 Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 12:48:20 -0600 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.4]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Mon, 9 Nov 2009 13:48:20 -0500 From: Marc Khouzam To: "'Vladimir Prus'" CC: "'gdb@sources.redhat.com'" Date: Mon, 09 Nov 2009 20:02: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: 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/msg00097.txt.bz2 =20 > -----Original Message----- > From: gdb-owner@sourceware.org=20 > [mailto:gdb-owner@sourceware.org] On Behalf Of Marc Khouzam > Sent: Monday, November 09, 2009 12:15 PM > To: 'Vladimir Prus' > Cc: 'gdb@sources.redhat.com' > Subject: RE: [MI] Extending -list-thread-groups --available=20 > to show cores >=20 >=20 > > -----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=20 > threads are > > > > > > migrated between cores. However, it's useful for=20 > both custom=20 > > > > > > Linux applications that specifically pin threads to=20 > > > > specific cores, > > > > > > and for embedded systems. Therefore, I plan to add=20 > 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. >=20 > Sorry, I had not understood from the spec that you would be adding > thread information to the output to "--availabe" I just thought that the -list-thread-group --availabe output is already very large; if we add threads, it will be huge. What about adding an option to indicate if threads should be listed or not? Like -list-thread-groups --available [print-details] where 'print-details' could be different values that would indicate what kinds of detail level was requested (like 'threads')? >=20 > > > > > > -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. >=20 > Ok. > But that means you are also proposing to support: > -list-thread-groups --available [group] >=20 > 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=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=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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 ... >=20 > > > > 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,=20 > 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=20 > 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? >=20 > 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 >=20 > In my opinion, if it is possible, the two should have the same format, > as long as backwards-compatibility can be preserved. >=20 > But maybe that is just me? >=20 > Marc >=20 >=20