reconstructing process memory map from core

reconstructing process memory map from core

[ineya ineya]

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.

Re: reconstructing process memory map from core

[Daniel Jacobowitz]

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

Re: reconstructing process memory map from core

[Hui Zhu]

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.
>

Re: reconstructing process memory map from core

[ineya ineya]

>> 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.

Well, in .got I can see where the function was at runtime, from
read-only sections I can find out which libraries are needed. So I
would only need to find the library which defines this function. Then
get its relative address, compute the relative position from start of
this shared library - by subtracting "Entry point address" of this
shared library. And finally subtract the result from value in .got,
and the result should be start of shared library in memory. Or not?

In .got of binaryA I have:
0x2ac0fd88 - for function TraceLog::logExc

from libraryA I know:
Entry point address:               0x2a20
.symtab
214: 00004d88     0 FUNC    GLOBAL DEFAULT    9 _ZN8TraceLog6logExcEPKcS1
so relative from start: 0x4d88 - 0x2a20 = 0x2368

subtract this from what .got
0x2ac0fd88 - 0x2368 = 0x2ac0da20

Looking at "info shared" to see where GDB loaded the binary shows:
0x2ac0da20  0x2ac12480  Yes         libraryA

So I assume, there is a catch somewhere, where this approach would
fail, I just can't see it yet.