From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26858 invoked by alias); 9 Jun 2008 18:03:38 -0000 Received: (qmail 26849 invoked by uid 22791); 9 Jun 2008 18:03:37 -0000 X-Spam-Check-By: sourceware.org Received: from igw2.br.ibm.com (HELO igw2.br.ibm.com) (32.104.18.25) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 09 Jun 2008 18:03:16 +0000 Received: from mailhub1.br.ibm.com (mailhub1 [9.18.232.109]) by igw2.br.ibm.com (Postfix) with ESMTP id 8E73017F588 for ; Mon, 9 Jun 2008 14:51:38 -0300 (BRST) Received: from d24av02.br.ibm.com (d24av02.br.ibm.com [9.18.232.47]) by mailhub1.br.ibm.com (8.13.8/8.13.8/NCO v9.0) with ESMTP id m59I3EgU852240 for ; Mon, 9 Jun 2008 15:03:14 -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 m59I3AWx022331 for ; Mon, 9 Jun 2008 15:03:10 -0300 Received: from [9.8.3.207] ([9.8.3.207]) by d24av02.br.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m59I38X2022282 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Jun 2008 15:03:09 -0300 Subject: Re: How can I get a memory map out of a core file? From: Luis Machado Reply-To: luisgpm@linux.vnet.ibm.com To: Ulrich Weigand Cc: Daniel Jacobowitz , Bruce Korb , Andreas Schwab , gdb@sourceware.org, Eli Zaretskii , Michael Snyder In-Reply-To: <200806091751.m59HpSSv020533@d12av02.megacenter.de.ibm.com> References: <200806091751.m59HpSSv020533@d12av02.megacenter.de.ibm.com> Content-Type: text/plain Date: Mon, 09 Jun 2008 18:03:00 -0000 Message-Id: <1213034588.10042.120.camel@gargoyle> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: 7bit 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: 2008-06/txt/msg00058.txt.bz2 On Mon, 2008-06-09 at 19:51 +0200, Ulrich Weigand wrote: > Luis Machado wrote: > > > Yes. Mainly giving the user the option to show exactly what we had > > in /proc//maps right before the crash, so we know where things were > > in memory, like the heap, stack and some specific shared libraries' > > mappings. > > > > We currently can't do that. There's some information in the program > > headers from a core file, like the one below, that show us a bit of > > mapping-related information, but not enough so we can actually track > > them down to a shared library. > > But shared library information should be available via > "info sharedlibrary" (which uses the in-memory data structures > allocated by ld.so, which are present in the core file) ... > > What is the extra information /proc//maps provides that > you're concerned about? > > Bye, > Ulrich /proc//maps provides different types of mappings for the same library. Like the .text section mapping or .data section mapping. "info shared" only shows the .text section IIRC. For example: Start Addr End Addr Size Offset objfile 0x4000008d000 0x400001fc000 0x16f000 0 /lib64/libc-2.4.so 0x400001fc000 0x4000020b000 0xf000 0x16f000 /lib64/libc-2.4.so 0x4000020b000 0x4000020e000 0x3000 0x16e000 /lib64/libc-2.4.so 0x4000020e000 0x40000225000 0x17000 0x171000 /lib64/libc-2.4.so Luis