This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: reconstructing process memory map from core

Try ".dynamic" for linux.


On Wed, Feb 10, 2010 at 06:00, ineya ineya <> 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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]