Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Luis Machado <luisgpm@linux.vnet.ibm.com>
To: Daniel Jacobowitz <drow@false.org>
Cc: 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: Mon, 09 Jun 2008 16:28:00 -0000	[thread overview]
Message-ID: <1213028867.10042.101.camel@gargoyle> (raw)
In-Reply-To: <20080609153944.GA22846@caradoc.them.org>

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


  reply	other threads:[~2008-06-09 16:28 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 [this message]
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
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=1213028867.10042.101.camel@gargoyle \
    --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 \
    /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