> On Jan 6, 2016, at 3:39 PM, Eugene Birukov <eugen...@hotmail.com> wrote:
>
> OK, I'll try to see what happens with the platform. The truth is that shipped
> lldb-3.7.0 does not load core on Linux at all and I am using custom version
> that has been patched (by restoring some 3.6.0 code). So, there might be a
> problem there.
>
> Meanwhile, I found a way around. In my C++ code I do this:
>
> m_Target = m_Debugger.CreateTarget(target);
> m_Debugger.HandleCommand("target modules search-paths add
> /lib/x86_64-linux-gnu /home/eugene/tmp");
> m_Debugger.HandleCommand("target modules search-paths add
> /usr/lib/x86_64-linux-gnu /home/eugene/tmp");
> m_Process = m_Target.LoadCore(core);
>
> This does get the stacks right. Still, I have a problem with it: when I try
> to disassemble the code, it is all zeroes. Any advice where I should look to
> figure out what's wrong?
You can check ProcessElfCore::DoReadMemory() to see what happens when it reads
the memory it is trying to disassemble. What you type "disassemble --frame", it
will try and read the memory from the process (and instance of ProcessElfCore)
and the memory read will try to read the data from the core memory. Make sure
this is correctly accessing the memory and getting non-zeroes back from the
memory read. Anything that was mapped into the process should be saved in the
core file and be available to read as valid memory.
What does the output of "image list" show? It should show the load addresses of
all the shared libraries as the location that it was loaded when the core file
was made. If you see a bunch of zeros as the load location, then maybe the
shared libraries aren't getting loaded correctly?
> Also, if I iterate loaded modules, all of the shared libraries are mentioned
> twice, which doesn't look right:
>
> Modules: 20
> (x86_64) /home/eugene/tmp/a.out
> (x86_64) /home/eugene/tmp/libpthread.so.0
> (x86_64) /home/eugene/tmp/librt.so.1
> (x86_64) /home/eugene/tmp/libdl.so.2
> (x86_64) /home/eugene/tmp/libjemalloc.so.1
> (x86_64) /home/eugene/tmp/libc++.so.1
> (x86_64) /home/eugene/tmp/libm.so.6
> (x86_64) /home/eugene/tmp/libgcc_s.so.1
> (x86_64) /home/eugene/tmp/libc.so.6
> (x86_64) /home/eugene/tmp/ld-linux-x86-64.so.2
> (x86_64) /home/eugene/tmp/libpthread.so.0
> (x86_64) /home/eugene/tmp/librt.so.1
> (x86_64) /home/eugene/tmp/libdl.so.2
> (x86_64) /home/eugene/tmp/libjemalloc.so.1
> (x86_64) /home/eugene/tmp/libc++.so.1
> (x86_64) /home/eugene/tmp/libm.so.6
> (x86_64) /home/eugene/tmp/libgcc_s.so.1
> (x86_64) /home/eugene/tmp/libc.so.6
> (x86_64) /home/eugene/tmp/libunwind.so.8
> (x86_64) /home/eugene/tmp/liblzma.so.5
That is probably your problem... The first copy is probably not loaded, but the
second one is? It will be interesting to see what the output of the "image
list" command shows. The first one might claim 0x0 as the load location and the
second one might be valid. This seems like this is a bug in the dynamic loader
plugin (DynamicLoaderPOSIXDYLD). So try to figure out why two copies are
getting added and then make sure they are loaded at valid non-overlapping
addresses.
> Eugene
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
