Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Luis Machado <luisgpm@linux.vnet.ibm.com>
To: Ulrich Weigand <uweigand@de.ibm.com>
Cc: Daniel Jacobowitz <drow@false.org>,
	Bruce Korb <bruce.korb@gmail.com>,
	        Andreas Schwab <schwab@suse.de>,
	gdb@sourceware.org,         Eli Zaretskii <eliz@gnu.org>,
	Michael Snyder <msnyder@specifix.com>
Subject: Re: How can I get a memory map out of a core file?
Date: Thu, 12 Jun 2008 14:18:00 -0000	[thread overview]
Message-ID: <1213280300.18445.1.camel@gargoyle.br.ibm.com> (raw)
In-Reply-To: <200806121357.m5CDvgJt023870@d12av02.megacenter.de.ibm.com>


On Thu, 2008-06-12 at 15:57 +0200, Ulrich Weigand wrote:
> Luis Machado wrote:
> 
> > /proc/<pid>/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


  reply	other threads:[~2008-06-12 14:18 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-06 20:46 Bruce Korb
2008-06-06 21:54 ` Michael Snyder
2008-06-07  6:30   ` Eli Zaretskii
2008-06-07 16:31     ` Bruce Korb
2008-06-07 16:58       ` Eli Zaretskii
2008-06-07 18:14       ` Brian Dessent
2008-06-07 18:29         ` Andreas Schwab
2008-06-07 20:01           ` Bruce Korb
2008-06-09 15:04             ` Luis Machado
2008-06-09 15:24               ` Daniel Jacobowitz
2008-06-09 15:32                 ` Luis Machado
2008-06-09 15:40                   ` Daniel Jacobowitz
2008-06-09 16:28                     ` Luis Machado
2008-06-09 17:52                       ` Ulrich Weigand
2008-06-09 18:03                         ` Luis Machado
2008-06-12 13:58                           ` Ulrich Weigand
2008-06-12 14:18                             ` Luis Machado [this message]
2008-06-12 14:30                               ` Ulrich Weigand
2008-06-09 22:32                       ` Michael Snyder
2008-06-09 15:37                 ` Bruce Korb

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1213280300.18445.1.camel@gargoyle.br.ibm.com \
    --to=luisgpm@linux.vnet.ibm.com \
    --cc=bruce.korb@gmail.com \
    --cc=drow@false.org \
    --cc=eliz@gnu.org \
    --cc=gdb@sourceware.org \
    --cc=msnyder@specifix.com \
    --cc=schwab@suse.de \
    --cc=uweigand@de.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox