From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24523 invoked by alias); 28 Jul 2010 19:50:53 -0000 Received: (qmail 24508 invoked by uid 22791); 28 Jul 2010 19:50:51 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (74.125.121.35) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 28 Jul 2010 19:50:39 +0000 Received: from kpbe11.cbf.corp.google.com (kpbe11.cbf.corp.google.com [172.25.105.75]) by smtp-out.google.com with ESMTP id o6SJoaeg003046 for ; Wed, 28 Jul 2010 12:50:37 -0700 Received: from vws20 (vws20.prod.google.com [10.241.21.148]) by kpbe11.cbf.corp.google.com with ESMTP id o6SJo7eJ024643 for ; Wed, 28 Jul 2010 12:50:35 -0700 Received: by vws20 with SMTP id 20so5250193vws.24 for ; Wed, 28 Jul 2010 12:50:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.127.94 with SMTP id f30mr6480895vcs.75.1280346607448; Wed, 28 Jul 2010 12:50:07 -0700 (PDT) Received: by 10.220.186.74 with HTTP; Wed, 28 Jul 2010 12:50:07 -0700 (PDT) In-Reply-To: References: Date: Wed, 28 Jul 2010 19:50:00 -0000 Message-ID: Subject: Re: Command for number of cores From: Doug Evans To: Marc Khouzam Cc: "gdb@sourceware.org" Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true 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: 2010-07/txt/msg00113.txt.bz2 On Tue, Jul 27, 2010 at 12:55 PM, Marc Khouzam wrote: > Hi, > > I need a way to know how many cores are on my target (where gdbserver is running). > I'm wondering if GDB already has this information? > > If not, I was thinking of adding 'info cores' or 'show cores'. > Or maybe a convenience variable '$numcores'? > > I'm thinking 'info cores'. > > If this makes sense, I'll give it a try. > > Thanks > > Marc If this is on linux, the following should work: (gdb) remote get /proc/cpuinfo foo (gdb) shell cat foo Alas it gives: Remote I/O error: Invalid argument [lseek on /proc/cpuinfo failing?] I think that's a bug though (not the lseek failing, but that "remote get /proc/cpuinfo foo" fails). If this is linux, and this is indeed a bug and it were fixed, would that suffice? I hesitate to add "info cores" because it seems a bit esoteric, and you'd have to hack gdb, gdbserver, and document it all when "remote get" could suffice.