examining memory mappings from a core file - Linux

This is a discussion on examining memory mappings from a core file - Linux ; I'm wondering if there is a tool or gdb command or some other way to examine the memory mappings by looking at a core file. I'm familiar with the Solaris "pmap" command, which does this, but the linux pmap command ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: examining memory mappings from a core file

  1. examining memory mappings from a core file

    I'm wondering if there is a tool or gdb command or some other way to
    examine the memory mappings by looking at a core file. I'm familiar
    with the Solaris "pmap" command, which does this, but the linux pmap
    command can only print the mappings from a running process.

    Any help? Thanks!

    Rob


  2. Re: examining memory mappings from a core file

    > a tool or gdb command or some other way to
    > examine the memory mappings by looking at a core file.


    $ file
    : ELF 32-bit LSB core file Intel 80386, version 1 (SYSV), \
    SVR4-style, from ''
    $ readelf --headers
    Program Headers:
    Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
    NOTE 0x0001f4 0x00000000 0x00000000 0x001d8 0x00000 0
    LOAD 0x001000 0x00511000 0x00000000 0x01000 0x01000 R E 0x1000
    LOAD 0x002000 0x00512000 0x00000000 0x00000 0x1a000 R E 0x1000

    Readelf is in the binutils package. The PT_LOAD you see are the non-.text
    pieces. Recover the .text pieces using 'file' and 'ldd'. Beware of
    address-space randomization done to shared libraries by recent kernels;
    this information is not readily recoverable.

    --

  3. Re: examining memory mappings from a core file

    On Jun 11, 4:44 pm, John Reiser wrote:
    > > a tool or gdb command or some other way to
    > > examine the memory mappings by looking at a core file.

    >
    > $ file
    > : ELF 32-bit LSB core file Intel 80386, version 1 (SYSV), \
    > SVR4-style, from ''
    > $ readelf --headers
    > Program Headers:
    > Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
    > NOTE 0x0001f4 0x00000000 0x00000000 0x001d8 0x00000 0
    > LOAD 0x001000 0x00511000 0x00000000 0x01000 0x01000 R E 0x1000
    > LOAD 0x002000 0x00512000 0x00000000 0x00000 0x1a000 R E 0x1000
    >
    > Readelf is in the binutils package. The PT_LOAD you see are the non-.text
    > pieces. Recover the .text pieces using 'file' and 'ldd'. Beware of
    > address-space randomization done to shared libraries by recent kernels;
    > this information is not readily recoverable.
    >
    > --


    Thanks! Now, is there a way to determine either a) which sections are
    heap sections ([anon] right?) or b) which sections go to which
    libraries that ldd reports?

    Rob


  4. Re: examining memory mappings from a core file

    On Jun 12, 7:29 am, Rob wrote:
    > On Jun 11, 4:44 pm, John Reiser wrote:
    >
    >
    >
    > > > a tool or gdb command or some other way to
    > > > examine the memory mappings by looking at a core file.

    >
    > > $ file
    > > : ELF 32-bit LSB core file Intel 80386, version 1 (SYSV), \
    > > SVR4-style, from ''
    > > $ readelf --headers
    > > Program Headers:
    > > Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
    > > NOTE 0x0001f4 0x00000000 0x00000000 0x001d8 0x00000 0
    > > LOAD 0x001000 0x00511000 0x00000000 0x01000 0x01000 R E 0x1000
    > > LOAD 0x002000 0x00512000 0x00000000 0x00000 0x1a000 R E 0x1000

    >
    > > Readelf is in the binutils package. The PT_LOAD you see are the non-.text
    > > pieces. Recover the .text pieces using 'file' and 'ldd'. Beware of
    > > address-space randomization done to shared libraries by recent kernels;
    > > this information is not readily recoverable.

    >
    > > --

    >
    > Thanks! Now, is there a way to determine either a) which sections are
    > heap sections ([anon] right?) or b) which sections go to which
    > libraries that ldd reports?
    >
    > Rob


    I seem to have found out some of this information - using readelf on
    each library shows me mappings which appear to correspond to the
    mappings in the core file, though I'm not sure how I'm convinced they
    couldn't be relocated to a different offset if there was a conflict...

    There are still mappings in the original process that don't correspond
    to any mappings in the loaded libraries, but they generally show up
    between two mappings, so I'm sort of comfortable with that.

    And I do see random mappings for non-system libraries, both with ldd
    and pmap when running. Do you have any advice for these? I think for
    my purposes it would be very important to get these mappings as
    well...

    One thought: what if I was to start up the process (again), then run
    pmap; would the results be in the same order as the ones in the core
    file? They appear to be at first glance, but I wasn't sure. If
    that's the case, then I might be able to reconstruct the library
    mappings by re-running pmap and "lining" up the output with the LOAD
    sections in the core file...

    Does that sound crazy?

    Thanks!

    Rob


  5. Re: examining memory mappings from a core file

    >>>Beware of
    >>>address-space randomization done to shared libraries by recent kernels;
    >>>this information is not readily recoverable.


    If a shared library was prelink-ed (the .p_vaddr is not 0) and something
    else does not already occupy the prelinked range, then usually the kernel
    will place the shared library at the prelink address. If a shared library
    was not prelink-ed (the .p_vaddr is 0) then the kernel may choose
    a random address for the shared library. [The mechanism: ld-linux.so
    calls mmap(.p_vaddr, ...) and takes what the kernel chooses.]
    Some kernels choose ascending addresses above TASK_SIZE/3 (frequently
    TASK_SIZE for x86 is 0xc0000000 or 0x80000000, giving a "shared
    library base" of 0x40000000 or 0x2aaab000.) Some kernels choose
    random addresses. If the kernel chooses a random address, then it
    may be difficult to determine the address by looking only at a coredump.

    --

+ Reply to Thread