Re: reconstructing process memory map from core

[ineya ineya <ineyaa at gmail dot com>]

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