This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: How can I get a memory map out of a core file?
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