From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26599 invoked by alias); 19 Dec 2008 16:24:39 -0000 Received: (qmail 26588 invoked by uid 22791); 19 Dec 2008 16:24:39 -0000 X-SWARE-Spam-Status: No, hits=-3.1 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from igw1.br.ibm.com (HELO igw1.br.ibm.com) (32.104.18.24) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 19 Dec 2008 16:23:55 +0000 Received: from d24relay01.br.ibm.com (unknown [9.8.31.16]) by igw1.br.ibm.com (Postfix) with ESMTP id 1560C32C06D for ; Fri, 19 Dec 2008 14:19:23 -0200 (BRDT) Received: from d24av02.br.ibm.com (d24av02.br.ibm.com [9.18.232.47]) by d24relay01.br.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id mBJHNQT03960876 for ; Fri, 19 Dec 2008 14:23:26 -0300 Received: from d24av02.br.ibm.com (loopback [127.0.0.1]) by d24av02.br.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id mBJGNqcl020786 for ; Fri, 19 Dec 2008 14:23:52 -0200 Received: from [9.8.1.77] ([9.8.1.77]) by d24av02.br.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id mBJGNqLR020754; Fri, 19 Dec 2008 14:23:52 -0200 Subject: Re: RFC: "info proc map" for corefiles From: =?ISO-8859-1?Q?S=E9rgio?= Durigan =?ISO-8859-1?Q?J=FAnior?= To: tromey@redhat.com Cc: Michael Snyder , Mark Kettenis , "gdb-patches@sourceware.org" In-Reply-To: References: <1229620702.6602.12.camel@miki> <200812181846.mBIIkTgK015985@brahms.sibelius.xs4all.nl> <1229626216.6602.15.camel@miki> <494AC2D3.9090705@vmware.com> <1229702034.6602.18.camel@miki> Content-Type: text/plain; charset=iso-8859-1 Date: Fri, 19 Dec 2008 16:24:00 -0000 Message-Id: <1229703833.6602.28.camel@miki> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-12/txt/msg00348.txt.bz2 Hey Tom, On Fri, 2008-12-19 at 09:05 -0700, Tom Tromey wrote: > I agree that "info proc" a misnomer. But, it seems to me it would be > nice for the user to use the same command in both cases. How about a > new command (not "info core"), with the old "info proc map" aliased to > it? IIUC we are creating this new command because "info proc" was initially designed to provide information about a live process, right? So what if we change the "design assumptions" of it? What if "info proc" could be used to display info about a process, whether it's running or not? Ok, just in case you don't agree with what I proposed above, what do you think if this new command (to which "info proc map" would be aliased) to be called "info mapping"? Don't know if it's a good name, but I tried to make it represent both "info proc map" and "info core map" :-). Regards, -- Sérgio Durigan Júnior Linux on Power Toolchain - Software Engineer Linux Technology Center - LTC IBM Brazil