From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20628 invoked by alias); 9 Nov 2009 16:17:53 -0000 Received: (qmail 20617 invoked by uid 22791); 9 Nov 2009 16:17:51 -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 imr1.ericy.com (HELO imr1.ericy.com) (198.24.6.9) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 09 Nov 2009 16:17:45 +0000 Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id nA9GHZwR007342; Mon, 9 Nov 2009 10:17:40 -0600 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.50]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 10:16:49 -0600 Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 10:16:49 -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 11:16:48 -0500 From: Marc Khouzam To: "'Vladimir Prus'" CC: "'gdb@sources.redhat.com'" Date: Mon, 09 Nov 2009 16:42: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> In-Reply-To: <200911091739.12743.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/msg00087.txt.bz2 =20 > -----Original Message----- > From: gdb-owner@sourceware.org=20 > [mailto:gdb-owner@sourceware.org] On Behalf Of Vladimir Prus > Sent: Monday, November 09, 2009 9:39 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 > >=20 > > > -----Original Message----- > > > From: gdb-owner@sourceware.org=20 > > > [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=20 > to show cores > > >=20 > > >=20 > > > 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. > > >=20 > > > 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=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 Is there currently thread information in the output of "--available"? > > > -list-thread-groups --available, named 'core' that 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 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', 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=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 (LWP 21257)",cor= es=3D[1] frame=3D{level=3D"0",addr=3D"0xffffe410",func=3D"__kernel_vsyscall",arg= s=3D[]},state=3D"running"}, > > > Related to that, it would be somewhat inefficient to issue=20 > > > -list-thread-groups > > > for every avaialable process to discover the full list of=20 > > > threads on specific > > > core, so it would be nice to pass several thread groups, like so: > > >=20 > > > -list-thread-groups 17 18 > > > ^done,groups=3D[{id=3D"17", types=3D"process", ...,=20 > > > threads=3D[{id=3D"2",target-id=3D"Thread=20 > > > 0xb7e14b90 (LWP 21257)",cores=3D[1]}]}, > > > {id=3D"18", types=3D"process", ...,=20 > >=20 > > 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=20 > threads belong to, > > since the will be multiple list of threads. > > But how will that affect the ouput of=20 > > -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") >=20 > Yes, "types" should be "type". Basically, we have a=20 > 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=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 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' 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=3D", one for each process? Something like: -list-thread-groups 17 18 ^done,threads=3D[{id=3D"2",group=3D"17", target-id=3D"Thread 0xb7e14b90 (L= WP 21257)",cores=3D[1] frame=3D{level=3D"0",addr=3D"0xffffe410",func=3D"__kernel_vsyscall",arg= s=3D[]},state=3D"running"}}], threads=3D[{id=3D"3",group=3D"18", target-id=3D"Thread 0xb7e14b90 (LWP 21= 257)",cores=3D[1] frame=3D{level=3D"0",addr=3D"0xfffff410",func=3D"__kernel_vsyscall",arg= s=3D[]},state=3D"running"}}]=20 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 gro= uping. Does this go against the rules of MI?=20 > 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=20 need to code for both outputs. Keeping the output backwards compatible=20 will allow future frontends that don't want to use mutliple parameters to -list-thread-groups to have one way of parsing the output. Marc