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

[Michael Snyder]

Post by 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

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

[Eli Zaretskii]

Date: Fri, 06 Jun 2008 14:54:19 -0700

Post by 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

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?

[Bruce Korb]

Post by Eli Zaretskii

Post by Michael Snyder

Post by 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

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

[Eli Zaretskii]

Date: Sat, 7 Jun 2008 09:30:21 -0700
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.

[Brian Dessent]

Post by Bruce Korb
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

[Andreas Schwab]

Post by Brian Dessent
`/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.

[Bruce Korb]

Post by Andreas Schwab

Post by Brian Dessent
`/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

[Luis Machado]

Post by Bruce Korb

Post by Andreas Schwab

Post by Brian Dessent
`/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
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

[Daniel Jacobowitz]

Post by Luis Machado
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.

[Luis Machado]

Post by Daniel Jacobowitz

Post by Luis Machado
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

[Daniel Jacobowitz]

Post by Luis Machado
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?

[Luis Machado]

Post by Daniel Jacobowitz

Post by Luis Machado
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

[Ulrich Weigand]

Post by Luis Machado
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

[Luis Machado]

Post by Ulrich Weigand

Post by Luis Machado
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

[Ulrich Weigand]

Post by Luis Machado
/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.
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

[Luis Machado]

Post by Ulrich Weigand

Post by Luis Machado
/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.
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.
`/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

[Ulrich Weigand]

Post by Luis Machado
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

[Michael Snyder]

Post by Luis Machado

Post by Daniel Jacobowitz

Post by Luis Machado
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?

[Bruce Korb]

Hi,

Post by Daniel Jacobowitz
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