From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9714 invoked by alias); 19 Dec 2008 19:46:10 -0000 Received: (qmail 9706 invoked by uid 22791); 19 Dec 2008 19:46:09 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from smtp-outbound-2.vmware.com (HELO smtp-outbound-2.vmware.com) (65.115.85.73) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 19 Dec 2008 19:45:34 +0000 Received: from mailhost5.vmware.com (mailhost5.vmware.com [10.16.68.131]) by smtp-outbound-2.vmware.com (Postfix) with ESMTP id 746474A001; Fri, 19 Dec 2008 11:45:32 -0800 (PST) Received: from [10.20.92.151] (promb-2s-dhcp151.eng.vmware.com [10.20.92.151]) by mailhost5.vmware.com (Postfix) with ESMTP id 6B705DC08B; Fri, 19 Dec 2008 11:45:32 -0800 (PST) Message-ID: <494BF8A2.4030104@vmware.com> Date: Fri, 19 Dec 2008 19:46:00 -0000 From: Michael Snyder User-Agent: Thunderbird 1.5.0.12 (X11/20080411) MIME-Version: 1.0 To: Eli Zaretskii CC: =?ISO-8859-1?Q?S=E9rgio_Durigan_J=FAnior?= , "tromey@redhat.com" , "mark.kettenis@xs4all.nl" , "gdb-patches@sourceware.org" Subject: Re: RFC: "info proc map" for corefiles 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> <1229703833.6602.28.camel@miki> In-Reply-To: Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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/msg00353.txt.bz2 Eli Zaretskii wrote: >> From: =?ISO-8859-1?Q?S=E9rgio?= Durigan =?ISO-8859-1?Q?J=FAnior?= >> Cc: Michael Snyder , Mark Kettenis , "gdb-patches@sourceware.org" >> Date: Fri, 19 Dec 2008 14:23:53 -0200 >> >> Hey Tom, >> >> IIUC we are creating this new command because "info proc" was initially >> designed to provide information about a live process, right? > > No, "info proc" was designed to provide information recorded about a > process in the /proc filesystem. And a process that is dead does not > have any information about it in /proc. Oh yeah, I guess that's right. "info proc" first appeared in solaris-gdb, and then the other hosts that shared procfs.c (like Irix, I think) -- and then eventually appeared in linux gdb (although /proc in linux doesn't remotely resemble /proc everywhere else). Are there any other gdb configs where the command appears? That is, other than linux and systems that use procfs.c?