Re: reconstructing process memory map from core

[Hui Zhu <teawater at gmail dot com>]

Try ".dynamic" for linux.

Hui

On Wed, Feb 10, 2010 at 06:00, ineya ineya <ineyaa@gmail.com> wrote:
> How is symbol loading handled when shared libraries come to play?
>
> This is my story:
> I have a mips embedded device, which has little memory. So I decided
> to dump the heap as the last thing, so in case there is little space
> left on device, I would get at least stack, .got, etc. from binary and
> shared libraries, and heap would be incomplete. I thought, that having
> stack, .got, .dynsym, etc. would be enough for gdb to load symbols
> from all binaries and shared libraries, and I could at least resolve
> symbols from registers or stack.
>
> 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?
>
> I thought all that is needed is to have:
> - list of external function - in .dynsym I guess
> - .got from runtime
> and the address where shared library was in memory is computed by data
> present in .got and relative position of function in .so.
>
> Thank you for any hints.
>