From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7603 invoked by alias); 9 Nov 2009 14:25:48 -0000 Received: (qmail 7547 invoked by uid 22791); 9 Nov 2009 14:25:47 -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 14:25:42 +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 nA9EPbGZ004405; Mon, 9 Nov 2009 08:25:38 -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 08:24:50 -0600 Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 08:24:50 -0600 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.4]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Mon, 9 Nov 2009 09:24:50 -0500 From: Marc Khouzam To: "'Vladimir Prus'" , "'gdb@sources.redhat.com'" Date: Mon, 09 Nov 2009 16:17:00 -0000 Subject: RE: [MI] Extending -list-thread-groups --available to show cores Message-ID: References: <200911081804.31988.vladimir@codesourcery.com> In-Reply-To: <200911081804.31988.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/msg00084.txt.bz2 =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 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 specific cores, > and for embedded systems. Therefore, I plan to add a new field > to the thread information that is output by=20 > -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? > -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]}] Nice. > -list-thread-groups 17 > ^done,threads=3D[{id=3D"2",target-id=3D"Thread 0xb7e14b90=20 > (LWP 21257)",cores=3D[1] > frame=3D{level=3D"0",addr=3D"0xffffe410",func=3D"__kernel_vsyscall",ar > gs=3D[]},state=3D"running"}, Also nice. =20=09=20=20=20 =20 > 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 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 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") > Finally, we were asked to make the *stopped notification to=20 > report the core on which > the stop has happened, as additional field. Valuable. Interesting stuff! Thanks Marc