This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: reconstructing process memory map from core
- From: Daniel Jacobowitz <dan at codesourcery dot com>
- To: ineya ineya <ineyaa at gmail dot com>
- Cc: gdb at sourceware dot org
- Date: Tue, 9 Feb 2010 17:08:19 -0500
- Subject: Re: reconstructing process memory map from core
- References: <7b8592a1002091400y5b901e90s8cb26f75c057ffab@mail.gmail.com>
On Tue, Feb 09, 2010 at 11:00:34PM +0100, ineya ineya wrote:
> But it doesn't work, gdb is trying to read something from heap, and if
> this fails, no symbols are loaded. So I was wondering why gdb needs to
> access heap? Or more generally how are symbols loaded / how is the
> process memory map reconstructed from core file?
The dynamic linker maintains a linked list of loaded shared
libraries, in the heap.
> I thought all that is needed is to have:
> - list of external function - in .dynsym I guess
> - .got from runtime
Neither of these are useful for determining shared library load
addresses. .dynsym is not useful at all; it is read-only so we can
recover it from the executable.
--
Daniel Jacobowitz
CodeSourcery