From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10404 invoked by alias); 16 Nov 2009 14:52:48 -0000 Received: (qmail 10380 invoked by uid 22791); 16 Nov 2009 14:52:46 -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, 16 Nov 2009 14:51:42 +0000 Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id nAGEpcNH004612; Mon, 16 Nov 2009 08:51:39 -0600 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.79]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Mon, 16 Nov 2009 09:51:38 -0500 From: Marc Khouzam To: "'Vladimir Prus'" , "'gdb@sources.redhat.com'" Date: Tue, 17 Nov 2009 13:49:00 -0000 Subject: RE: [MI] Extending -list-thread-groups --available to show cores Message-ID: References: <200911081804.31988.vladimir@codesourcery.com> <200911161322.21627.vladimir@codesourcery.com> In-Reply-To: <200911161322.21627.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/msg00156.txt.bz2 =20 > -----Original Message----- > From: Vladimir Prus [mailto:vladimir@codesourcery.com]=20 > Sent: Monday, November 16, 2009 5:22 AM > To: 'gdb@sources.redhat.com'; Marc Khouzam > Subject: Re: [MI] Extending -list-thread-groups --available=20 > to show cores >=20 > On Sunday 08 November 2009 18:04:31 you wrote: >=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. > ... > > While those changes seem relatively minor and in line with=20 > previous MI developments, > > I wanted to pass them here. If there are no objections,=20 > I'll work in implementation > > during coming weeks. >=20 > Here's the updated spec. Comments? >=20 > Core awareness > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > This document specifies MI extensions to inform the client about cores on > which threads are executed.=20 >=20 > While the mapping from thread to core is volatile for traditional Linux > applications, it can be fixed for Linux application that specifically > pin threads, and is often fixed for embedded systems, and for those cases, > making frontend aware of the mapping would be nice. >=20 > The proposed changes affect the 'thread groups' interface, and are as > follows: >=20 > 1. The output of the --list-thread-groups command will include a new > field, 'cores'. For the 'process' thread group it will a list of all > cores on which threads in that group are currently running. For leafs, > that field should be a list with a single element. The new field will > be output regardless of whether the --available option is specified. >=20 > Example: >=20 > -list-thread-groups --available > ^done,groups=3D[{id=3D"17",type=3D"process",pid=3D"yyy",num_children= =3D"2",cores=3D[1,2]}] Great. > 2. To cut down on the number of roundtrips, the --list-thread-groups with= out > parameters may optionally recurse into the thread hierarchy. New option,= =20 > '--recurse N' will be used to control that. Originally, N will be require= d=20 > to be 1. The --recurse option can be used independelty from the --availab= le > option. >=20 > Example: >=20 > -list-thread-groups --available --recurse 1 > ^done,groups=3D[{id=3D"17", types=3D"process",pid=3D"yyy",num_childre= n=3D"2",cores=3D[1,2], > threads=3D[{id=3D"1",target-id=3D"Thread 0xb7e14b90",c= ores=3D[1]}, > {id=3D"2",target-id=3D"Thread 0xb7e14b90",cor= es=3D[2]}]}] Very nice and forward thinking. > Note that in case of --available, recursing into thread groups may not be > supported on a given target. In that case, the 'threads' field will be > skipped. The doc should indicate that a frontend should not assume the presence of "= threads=3D" even when using --recurse. > [CONSIDER: Shall -list-target-features report if --available + recurse wo= rks?] Say a target does not support this, do you forsee a performance impact if t= he=20 frontend still uses --recurse in this case? If not, then a frontend could figure out if this is supported by looking at the result of the command. I= think that would be enough.=20=20 In fact, if there is a performance impact, a frontend could stop using "--r= ecurse" when it first noticed the missing "thread=3D" from the output. But in that= case,=20 using -list-target-features would be more elegant. That being say, it won't hurt any FEs if -list-target-features did report t= his anyway. (In Eclipse, we don't use -list-target-features yet because we've = focused on Linux targets, but I think we should improved the support of other targe= ts by=20 using -list-target-features.) =20 > 3. It will be possible to pass several group ids to --list-thread-groups.= In > that case, the output will be identical to that of '-list-thread-groups' > without parameters, except that thread groups that were not listed as > parameters will not be output. For clarity, there should be a point 2.5 which says that the --available op= tion will now be allowed for --list-thread-groups with parameters. I like this addition which will allow to get information about an individual process wi= thout having to list all available processes. As for the output format, you have convinced me. However, I suggest the doc clearly indicates that when using the single-par= ameter=20 form of --list-thread-groups the output will not contain the "group=3D" fie= ld. I think this could become an FAQ kind of FE problem :-) =20 > Example: >=20 > -list-thread-groups --available --recurse 1 17 18 > ^done,groups=3D[{id=3D"17", types=3D"process",pid=3D"yyy",num_childre= n=3D"2",cores=3D[1,2], > threads=3D[{id=3D"1",target-id=3D"Thread 0xb7e14b90",c= ores=3D[1]}, > {id=3D"2",target-id=3D"Thread 0xb7e14b90",cor= es=3D[2]}]}] Above it says that "--recurse" is for -list-thread-groups without parameter= s. I guess the example should be=20 -list-thread-groups --available 17 18 Would using --recurse here cause an error, or be ignored? > 4. The *stopped notification will include a new field 'core', giving the = core > number on which the breakpoint is hit. This field will only be present if > possible. My favorite :-) Good stuff! Thanks Marc