From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27137 invoked by alias); 9 Jun 2008 15:04:06 -0000 Received: (qmail 27122 invoked by uid 22791); 9 Jun 2008 15:04:05 -0000 X-Spam-Check-By: sourceware.org Received: from igw3.br.ibm.com (HELO igw3.br.ibm.com) (32.104.18.26) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 09 Jun 2008 15:03:39 +0000 Received: from mailhub3.br.ibm.com (unknown [9.18.232.110]) by igw3.br.ibm.com (Postfix) with ESMTP id 9ADD6390124 for ; Mon, 9 Jun 2008 11:47:30 -0300 (BRST) Received: from d24av02.br.ibm.com (d24av02.br.ibm.com [9.18.232.47]) by mailhub3.br.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id m59F2IXB1818838 for ; Mon, 9 Jun 2008 12:02:19 -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 m59F2CbC020473 for ; Mon, 9 Jun 2008 12:02:13 -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 m59F26Ft020228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Jun 2008 12:02:11 -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: Bruce Korb Cc: Andreas Schwab , gdb@sourceware.org, Eli Zaretskii , Michael Snyder In-Reply-To: <200806071301.09679.Bruce.Korb@gmail.com> References: <668c430c0806061345m3c480d95nac5d19b02998715c@mail.gmail.com> <484AD008.8845E46E@dessent.net> <200806071301.09679.Bruce.Korb@gmail.com> Content-Type: text/plain Date: Mon, 09 Jun 2008 15:04:00 -0000 Message-Id: <1213023726.10042.78.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/msg00051.txt.bz2 On Sat, 2008-06-07 at 13:01 -0700, Bruce Korb wrote: > On Saturday 07 June 2008 11:28:55 am Andreas Schwab wrote: > > Brian Dessent writes: > > > > > Local core dump file: > > > `/home/brian/core', file type elf32-i386. > > > 0x08054000 - 0x08055000 is load2 > > > 0x08055000 - 0x08058000 is load3 > > > 0x40016000 - 0x40017000 is load5 > > > 0xbffff000 - 0xc0000000 is load6 > > > 0xffffe000 - 0xfffff000 is load7 > > > > > > Though I suppose those section names are not really all that useful, > > > > Those are not sections (a corefile does not contain any sections), but > > segments (which are unnamed). > > And are what I was looking for. "info target" just wasn't jumping out as > the way to get the list of mapped data. The list is a little weird with > zero length sections, but I can tell what's mapped now. Thank you!! > > Perhaps put "memory map" in the index and point to > "info target"? I went for that phrase due to the well-known "pmap": > NAME > pmap - display information about process memory mappings > > SYNOPSIS > pmap [ -d | -q | -h | -V ] pid > > DESCRIPTION > pmap(1) displays information about a process's memory mappings, such as > its stack, data segment, mapped files, and so on. > > Thank you for your help! Regards, Bruce This is, indeed, a limitation we have right now. Memory mapping information is only available for a live process through the /proc//maps entry. When a core dump is created, this information is read entirely, by GDB, in order to create the various LOAD segments we have in the core file. Even the names of the mappings are read by GDB, but it's unfortunately discarded. We're left with what can be seen with "maint info sections", but the lack of descriptive names is really bad for precise analysis of the mappings. In order for this information to be readily available through a core file, enhancements need to be done in the kernel itself. So, now that we've touched this topic, what do you think about this? For debugging purposes, this would be valuable information to have in GDB. Best regards, Luis