From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8164 invoked by alias); 17 Nov 2009 13:49:55 -0000 Received: (qmail 8152 invoked by uid 22791); 17 Nov 2009 13:49:53 -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; Tue, 17 Nov 2009 13:48:49 +0000 Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id nAHDmFYh010992; Tue, 17 Nov 2009 07:48:46 -0600 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.79]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Tue, 17 Nov 2009 08:48:11 -0500 From: Marc Khouzam To: "'Vladimir Prus'" CC: "'gdb@sources.redhat.com'" Date: Thu, 19 Nov 2009 07:11: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> <200911171043.54727.vladimir@codesourcery.com> In-Reply-To: <200911171043.54727.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/msg00159.txt.bz2 =20 > -----Original Message----- > From: Vladimir Prus [mailto:vladimir@codesourcery.com]=20 > Sent: Tuesday, November 17, 2009 2:44 AM > [...] > > > [CONSIDER: Shall -list-target-features report if=20 > --available + recurse works?] > >=20 > > Say a target does not support this, do you forsee a=20 > performance impact if the=20 > > frontend still uses --recurse in this case? If not, then a=20 > frontend could > > figure out if this is supported by looking at the result of=20 > the command. I think > > that would be enough.=20=20 > >=20 > > In fact, if there is a performance impact, a frontend could=20 > stop using "--recurse" > > when it first noticed the missing "thread=3D" from the=20 > output. But in that case,=20 > > using -list-target-features would be more elegant. > >=20 > > That being say, it won't hurt any FEs if=20 > -list-target-features did report this > > anyway. (In Eclipse, we don't use -list-target-features=20 > yet because we've focused > > on Linux targets, but I think we should improved the=20 > support of other targets by=20 > > using -list-target-features.) >=20 > I don't think that there's any perfomance impact for getting=20 > --recurse when > it's not supported. And on the other hand, there's some=20 > trickery involved > in reporting --recurse support, specifically over a remote connection. > I'm gonna skip this for now, unless a real need to test for=20 > this up-front will surface. Sounds good to me. [...] > > > Example: > > >=20 > > > -list-thread-groups --available --recurse 1 17 18 > > > ^done,groups=3D[{id=3D"17",=20 > types=3D"process",pid=3D"yyy",num_children=3D"2",cores=3D[1,2], > > > threads=3D[{id=3D"1",target-id=3D"Thread=20 > 0xb7e14b90",cores=3D[1]}, > > > {id=3D"2",target-id=3D"Thread=20 > 0xb7e14b90",cores=3D[2]}]}] > >=20 > > Above it says that "--recurse" is for -list-thread-groups=20 > without parameters. > > I guess the example should be=20 > > -list-thread-groups --available 17 18 > > Would using --recurse here cause an error, or be ignored? >=20 > In fact, I did not meant to prohibit --available + --recurse=20 > + several groups. I've adjust the wording above. So, all combinations are allowed. That is great. My last comment on the new revision. It stills says: "2. To cut down on the number of roundtrips, the=20 --list-thread-groups without parameters may optionally=20 ^^^^^^^^^^^^^^^^^^ recurse into the thread hierarchy" It shouldn't say "without parameters", since --recurse will be allowed all the time. Thanks Marc