From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20220 invoked by alias); 12 Jun 2008 14:18:55 -0000 Received: (qmail 20207 invoked by uid 22791); 12 Jun 2008 14:18:54 -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; Thu, 12 Jun 2008 14:18:30 +0000 Received: from mailhub1.br.ibm.com (unknown [9.18.232.109]) by igw3.br.ibm.com (Postfix) with ESMTP id 5D9DD39014A for ; Thu, 12 Jun 2008 11:02:11 -0300 (BRST) Received: from d24av01.br.ibm.com (d24av01.br.ibm.com [9.18.232.46]) by mailhub1.br.ibm.com (8.13.8/8.13.8/NCO v9.0) with ESMTP id m5CEISYR1184068 for ; Thu, 12 Jun 2008 11:18:28 -0300 Received: from d24av01.br.ibm.com (loopback [127.0.0.1]) by d24av01.br.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m5CEINHJ031293 for ; Thu, 12 Jun 2008 11:18:24 -0300 Received: from [9.18.227.115] ([9.18.227.115]) by d24av01.br.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m5CEIN3v031282 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Jun 2008 11:18:23 -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: <200806121357.m5CDvgJt023870@d12av02.megacenter.de.ibm.com> References: <200806121357.m5CDvgJt023870@d12av02.megacenter.de.ibm.com> Content-Type: text/plain Date: Thu, 12 Jun 2008 14:18:00 -0000 Message-Id: <1213280300.18445.1.camel@gargoyle.br.ibm.com> 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/msg00111.txt.bz2 On Thu, 2008-06-12 at 15:57 +0200, Ulrich Weigand wrote: > Luis Machado wrote: > > > /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 > > I see. However, "info target" will show all sections from shared > libraries as well, e.g. > > Local core dump file: > `/home/uweigand/fsf/gdb-head-build64/gdb/testsuite/gdb.base/corefile', file type elf64-powerpc. > 0x0000000000100000 - 0x0000000000113000 is load1 > 0x0000000010000000 - 0x0000000010001000 is load2 > 0x0000000010010000 - 0x0000000010012000 is load3 > 0x0000000010012000 - 0x0000000010035000 is load4 > 0x00000080ae050000 - 0x00000080ae051000 is load5a > 0x00000080ae051000 - 0x00000080ae079000 is load5b > 0x00000080ae08f000 - 0x00000080ae090000 is load6 > 0x00000080ae090000 - 0x00000080ae093000 is load7 > 0x00000080ae0a0000 - 0x00000080ae0a1000 is load8a > 0x00000080ae0a1000 - 0x00000080ae21f000 is load8b > 0x00000080ae22c000 - 0x00000080ae230000 is load10 > 0x00000080ae230000 - 0x00000080ae240000 is load11 > 0x00000080ae240000 - 0x00000080ae244000 is load12 > 0x00000080ae280000 - 0x00000080ae281000 is load13a > 0x00000080ae281000 - 0x00000080ae339000 is load13b > 0x00000080ae34f000 - 0x00000080ae350000 is load15 > 0x00000080ae350000 - 0x00000080ae359000 is load16 > 0x0000040000000000 - 0x0000040000001000 is load17 > 0x000004000001a000 - 0x000004000001c000 is load19 > 0x00000fffffa3e000 - 0x00000fffffa53000 is load20 > 0x00000080ae280238 - 0x00000080ae280258 is .note.ABI-tag in /lib64/libm.so.6 > 0x00000080ae280258 - 0x00000080ae2817bc is .gnu.hash in /lib64/libm.so.6 > 0x00000080ae2817c0 - 0x00000080ae2841c0 is .dynsym in /lib64/libm.so.6 > 0x00000080ae2841c0 - 0x00000080ae284999 is .dynstr in /lib64/libm.so.6 > 0x00000080ae28499a - 0x00000080ae284d1a is .gnu.version in /lib64/libm.so.6 > 0x00000080ae284d20 - 0x00000080ae284d7c is .gnu.version_d in /lib64/libm.so.6 > 0x00000080ae284d80 - 0x00000080ae284db0 is .gnu.version_r in /lib64/libm.so.6 > 0x00000080ae284db0 - 0x00000080ae28faa8 is .rela.dyn in /lib64/libm.so.6 > 0x00000080ae28faa8 - 0x00000080ae28fd00 is .rela.plt in /lib64/libm.so.6 > 0x00000080ae28fd00 - 0x00000080ae28fd30 is .init in /lib64/libm.so.6 > 0x00000080ae28fd30 - 0x00000080ae2f4c98 is .text in /lib64/libm.so.6 > 0x00000080ae2f4c98 - 0x00000080ae2f4cc0 is .fini in /lib64/libm.so.6 > 0x00000080ae2f4cc0 - 0x00000080ae336980 is .rodata in /lib64/libm.so.6 > 0x00000080ae336980 - 0x00000080ae336998 is .interp in /lib64/libm.so.6 > 0x00000080ae336998 - 0x00000080ae336a6c is .eh_frame_hdr in /lib64/libm.so.6 > 0x00000080ae336a70 - 0x00000080ae336ce4 is .eh_frame in /lib64/libm.so.6 > 0x00000080ae336ce8 - 0x00000080ae33815c is .hash in /lib64/libm.so.6 > 0x00000080ae34fdf0 - 0x00000080ae34fe00 is .ctors in /lib64/libm.so.6 > 0x00000080ae34fe00 - 0x00000080ae34fe10 is .dtors in /lib64/libm.so.6 > 0x00000080ae34fe10 - 0x00000080ae34fe18 is .jcr in /lib64/libm.so.6 > 0x00000080ae34fe18 - 0x00000080ae34fe20 is .data.rel.ro in /lib64/libm.so.6 > 0x00000080ae34fe20 - 0x00000080ae350000 is .dynamic in /lib64/libm.so.6 > 0x00000080ae350000 - 0x00000080ae350240 is .data in /lib64/libm.so.6 > 0x00000080ae350240 - 0x00000080ae350278 is .toc1 in /lib64/libm.so.6 > 0x00000080ae350278 - 0x00000080ae351f80 is .opd in /lib64/libm.so.6 > 0x00000080ae351f80 - 0x00000080ae3585f0 is .got in /lib64/libm.so.6 > 0x00000080ae3585f0 - 0x00000080ae358860 is .plt in /lib64/libm.so.6 > 0x00000080ae358860 - 0x00000080ae358868 is .bss in /lib64/libm.so.6 > > Is this what you're looking for? > > Bye, > Ulrich Does the libraries' mappings correspond exactly to what we had before in the output of "info proc mappings" for the live process? Right before the core file was generated? Luis