reconstructing process memory map from core

[ineya ineya <ineyaa@gmail.com>]

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.