This is the mail archive of the
mailing list for the GDB project.
Re: reconstructing process memory map from core
>> 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
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.