How can I get a memory map out of a core file?

How can I get a memory map out of a core file?

[Bruce Korb]

Hi,

"jmap" looked really nice, but that is Solaris only.
"pmap" is almost what I want, but there's no /proc/pid directory
for my core dump any more.
If there is some GDB command I can use, I haven't found it.
I haven't seen any obvious way to emulate it either.
Surely someone, somewhere has solved this problem.
Anyone know where the solution is hiding?  :)
Thank you.  Regards - Bruce

Re: How can I get a memory map out of a core file?

[Michael Snyder]

On Fri, 2008-06-06 at 13:45 -0700, Bruce Korb wrote:
> Hi,
> 
> "jmap" looked really nice, but that is Solaris only.
> "pmap" is almost what I want, but there's no /proc/pid directory
> for my core dump any more.
> If there is some GDB command I can use, I haven't found it.
> I haven't seen any obvious way to emulate it either.
> Surely someone, somewhere has solved this problem.
> Anyone know where the solution is hiding?  :)
> Thank you.  Regards - Bruce

Try "help info proc mappings".  It may be the closest we've got
to what you want.

Re: How can I get a memory map out of a core file?

[Eli Zaretskii]

> From: Michael Snyder <msnyder@specifix.com>
> Cc: gdb@sourceware.org
> Date: Fri, 06 Jun 2008 14:54:19 -0700
> 
> On Fri, 2008-06-06 at 13:45 -0700, Bruce Korb wrote:
> > Hi,
> > 
> > "jmap" looked really nice, but that is Solaris only.
> > "pmap" is almost what I want, but there's no /proc/pid directory
> > for my core dump any more.
> > If there is some GDB command I can use, I haven't found it.
> > I haven't seen any obvious way to emulate it either.
> > Surely someone, somewhere has solved this problem.
> > Anyone know where the solution is hiding?  :)
> > Thank you.  Regards - Bruce
> 
> Try "help info proc mappings".  It may be the closest we've got
> to what you want.

How can this help in a core file?  The process is already dead, so
it's not in /proc, right?  Or am I missing something?

Re: How can I get a memory map out of a core file?

[Bruce Korb]

On Friday 06 June 2008 11:29:29 pm Eli Zaretskii wrote:
> > On Fri, 2008-06-06 at 13:45 -0700, Bruce Korb wrote:
> > > Hi,
> > > 
> > > "jmap" looked really nice, but that is Solaris only.
> > > "pmap" is almost what I want, but there's no /proc/pid directory
> > > for my core dump any more.
> > > If there is some GDB command I can use, I haven't found it.
> > > I haven't seen any obvious way to emulate it either.
> > > Surely someone, somewhere has solved this problem.
> > > Anyone know where the solution is hiding?  :)
> > > Thank you.  Regards - Bruce
> > 
> > Try "help info proc mappings".  It may be the closest we've got
> > to what you want.
> 
> How can this help in a core file?  The process is already dead, so
> it's not in /proc, right?  Or am I missing something?

Hi Eli,

Nope.  You're right, Eli.  It doesn't help.  I tried it.  I also tried sourcing
a file that had a series of "x/3x 0xNNN00000" commands at 1 Meg steps.
That didn't work either because GDB quit as soon as an invalid address
was attempted.  So, for me, the ideal solution is a command that yields
(figures out) the valid address ranges, and an adequate backup would
be to tell the "source" command to keep going after a failed command.
Perhaps this is a "request for enhancement", though I hoped there might
already be some hackish way of accomplishing what I need.

Thanks!  Cheers - Bruce

Re: How can I get a memory map out of a core file?

[Eli Zaretskii]

> Date: Sat, 7 Jun 2008 09:30:21 -0700
> Cc: Michael Snyder <msnyder@specifix.com>,
>  gdb@sourceware.org
> From: Bruce Korb <bruce.korb@gmail.com>
> 
> So, for me, the ideal solution is a command that yields
> (figures out) the valid address ranges, and an adequate backup would
> be to tell the "source" command to keep going after a failed command.
> Perhaps this is a "request for enhancement", though I hoped there might
> already be some hackish way of accomplishing what I need.

Along the hackish avenue -- does readelf provide the functionality you
need?  If so, perhaps you could incorporate what it outputs into some
user-defined command, and use that?

Just a thought.

Re: How can I get a memory map out of a core file?

[Brian Dessent]

Bruce Korb wrote:

> was attempted.  So, for me, the ideal solution is a command that yields
> (figures out) the valid address ranges, and an adequate backup would

Doesn't "info target" do this?

$ ulimit -c 10000; top & kill -ABRT $! && fg %1
[1] 2347
top
Aborted (core dumped)

$ gdb -batch -x <(echo 'info target') -c core
Using host libthread_db library "/lib/tls/libthread_db.so.1".
(no debugging symbols found)
Core was generated by `top'.
Program terminated with signal 6, Aborted.
#0  0x40000c20 in ?? ()
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, but
in conjunction with the executable it should be possible to reverse
engineer which library / executable each corresponds to.

Brian

Re: How can I get a memory map out of a core file?

[Andreas Schwab]

Brian Dessent <brian@dessent.net> 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).

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: How can I get a memory map out of a core file?

[Bruce Korb]

On Saturday 07 June 2008 11:28:55 am Andreas Schwab wrote:
> Brian Dessent <brian@dessent.net> 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

Re: How can I get a memory map out of a core file?

[Luis Machado]

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 <brian@dessent.net> 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/<pid>/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

Re: How can I get a memory map out of a core file?

[Daniel Jacobowitz]

On Mon, Jun 09, 2008 at 12:02:05PM -0300, Luis Machado wrote:
> 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.

I don't understand what you have in mind.  These are not sections,
they're segments; there are never names associated with them.

-- 
Daniel Jacobowitz
CodeSourcery

Re: How can I get a memory map out of a core file?

[Luis Machado]

On Mon, 2008-06-09 at 11:23 -0400, Daniel Jacobowitz wrote:
> On Mon, Jun 09, 2008 at 12:02:05PM -0300, Luis Machado wrote:
> > 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.
> 
> I don't understand what you have in mind.  These are not sections,
> they're segments; there are never names associated with them.

The idea is to extend the functionality we have for live processes to
core files.

Luis

Re: How can I get a memory map out of a core file?

[Daniel Jacobowitz]

On Mon, Jun 09, 2008 at 12:30:41PM -0300, Luis Machado wrote:
> The idea is to extend the functionality we have for live processes to
> core files.

Oh, so you mean the names of files backing each segment?

-- 
Daniel Jacobowitz
CodeSourcery

Re: How can I get a memory map out of a core file?

[Luis Machado]

On Mon, 2008-06-09 at 11:39 -0400, Daniel Jacobowitz wrote:
> On Mon, Jun 09, 2008 at 12:30:41PM -0300, Luis Machado wrote:
> > The idea is to extend the functionality we have for live processes to
> > core files.
> 
> Oh, so you mean the names of files backing each segment?

Yes. Mainly giving the user the option to show exactly what we had
in /proc/<pid>/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.

  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x001000 0x00100000 0x00000000 0x00000 0x03000 R E 0x1000
  LOAD           0x001000 0x0fe8b000 0x00000000 0x00000 0x14d000 R E 0x1000
  LOAD           0x001000 0x0ffd8000 0x00000000 0x00000 0x0f000     0x1000

Providing such functionality, though, requires re-working the core
file's format, possibly leading to incompatibilities with old formats.
But it could be worth it for the additional information.

Luis

Re: How can I get a memory map out of a core file?

[Ulrich Weigand]

Luis Machado wrote:

> Yes. Mainly giving the user the option to show exactly what we had
> in /proc/<pid>/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/<pid>/maps provides that 
you're concerned about?

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

Re: How can I get a memory map out of a core file?

[Luis Machado]

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/<pid>/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/<pid>/maps provides that 
> you're concerned about?
> 
> Bye,
> Ulrich

/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

Luis

Re: How can I get a memory map out of a core file?

[Ulrich Weigand]

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

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

Re: How can I get a memory map out of a core file?

[Luis Machado]

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

Re: How can I get a memory map out of a core file?

[Ulrich Weigand]

Luis Machado wrote:

> 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?

Well, it corresponds exactly to what "info target" would have shown on
the live process.  Of course, "info target" and "info proc mappings"
show somewhat different information; "info target" displays *sections*
retrieved from loaded symbol files, while "info proc mappings" display
memory maps as reported by the kernel -- these correspond to the 
*segments* (not sections) of ELF files, and in addition show other
maps (e.g. stack, heap, mmap, ...).

What I'm wondering is basically whether for your purposes, you really
need the segment/mapping information, or whether section data as shown
by "info target" is sufficient.

Bye,
Ulrich


-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

Re: How can I get a memory map out of a core file?

[Michael Snyder]

On Mon, 2008-06-09 at 13:27 -0300, Luis Machado wrote:
> On Mon, 2008-06-09 at 11:39 -0400, Daniel Jacobowitz wrote:
> > On Mon, Jun 09, 2008 at 12:30:41PM -0300, Luis Machado wrote:
> > > The idea is to extend the functionality we have for live processes to
> > > core files.
> > 
> > Oh, so you mean the names of files backing each segment?
> 
> Yes. Mainly giving the user the option to show exactly what we had
> in /proc/<pid>/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.
> 
>   Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
>   LOAD           0x001000 0x00100000 0x00000000 0x00000 0x03000 R E 0x1000
>   LOAD           0x001000 0x0fe8b000 0x00000000 0x00000 0x14d000 R E 0x1000
>   LOAD           0x001000 0x0ffd8000 0x00000000 0x00000 0x0f000     0x1000
> 
> Providing such functionality, though, requires re-working the core
> file's format, possibly leading to incompatibilities with old formats.
> But it could be worth it for the additional information.

Could you put the extra info into a ".note" section, ie. something
that adds to but does not otherwise change that which is already there?

Re: How can I get a memory map out of a core file?

[Bruce Korb]

Hi,

On Mon, Jun 9, 2008 at 8:23 AM, Daniel Jacobowitz <drow@false.org> wrote:
>
> I don't understand what you have in mind.  These are not sections,
> they're segments; there are never names associated with them.

I know your reply was to Luis, but just for the record:  I'm happy now.
I just needed to find the right threads to follow to figure out what
commands were necessary to figure out which sections of virtual
memory were mapped and which were not.  So, an index entry
connecting "memory map" with "maint info sections" would be
really cool for the next person trying to figure out how to do it.  :)
Thanks - Bruce