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? 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
Eugene
> Subject: Re: [lldb-dev] How to load core on a different machine?
> From: gclay...@apple.com
> Date: Wed, 6 Jan 2016 11:37:02 -0800
> CC: lldb-dev@lists.llvm.org
> To: eugen...@hotmail.com
>
>
> So this should work:
>
> (lldb) platform select --sysroot /path/to/remote/shared/libraries remote-linux
> (lldb) <load core>
>
> So you need to make sure that your sysroot
> ("/path/to/remote/shared/libraries") contains files as they would appear on
> the remote system with the right paths ("/usr/lib/libc.so" should be in
> "/path/to/remote/shared/libraries/usr/lib/libc.so"). If that is true and you
> still are getting the wrong stack backtraces, then there are bugs in LLDB
> possibly in ProcessElfCore or possibly in DynamicLoaderPOSIXDYLD. What should
> happen is when we are asked to find "/usr/lib/libc.so", the platform that is
> selected should be the one that is asked to find "/usr/lib/libc.so", and it
> should check if the platform has a sysroot (like
> "/path/to/remote/shared/libraries") and it should prepend this when looking
> for "/usr/lib/libc.so", so it should be checking
> "/path/to/remote/shared/libraries/usr/lib/libc.so". So you will need to step
> through Target::GetSharedModule() and see what is going wrong.
>
> If that still fails, it seems we do have a way around this with the "target
> modules search-paths add" command:
>
> (lldb) target modules search-paths add /usr/lib /tmp
>
> So if you have "/usr/lib/libc.so", it should look in "/tmp/libc.so". But I
> would prefer it if we get this working by the platform method by debugging
> what is going wrong in Target::GetSharedModule(). The target has a platform
> and it should consult the platform when asked to find a module given a
> ModuleSpec. The ModuleSpec contains the path, and optionally the architecture
> and UUID. If any code in ProcessElfCore or DynamicLoaderPOSIXDYLD is not
> using Target::GetSharedModule(), then that might be the bug (code should
> never just call the static ModuleList::GetSharedModule() to locate files for
> a target.
>
> Let me know what you come up with,
>
> Greg Clayton
>
>
>
> > On Jan 6, 2016, at 11:03 AM, Eugene Birukov <eugen...@hotmail.com> wrote:
> >
> > Hmm... neither approach really works.
> >
> > 1. I created platform from lldb prompt, but when I create target from core
> > file I see exactly the same wrong stacks. It seems that platform is ignored
> > during core load in my case.
> > 2. chroot requires the whole set of binaries there in the new root. I
> > simply cannot copy everything from the server. Even if I do, lldb will use
> > copied binaries which is not a good idea...
> >
> > root@eugenebi-L2:~# chroot /home/eugene/tmp
> > chroot: failed to run command ‘/bin/bash’: No such file or directory
> >
> > 3. I tried SBDebugger::SetCurrentPlatformSDKRoot() but it does not have any
> > visible effect on load core, not sure what it is supposed to do :)
> >
> > Eugene
> >
> > > Subject: Re: [lldb-dev] How to load core on a different machine?
> > > From: gclay...@apple.com
> > > Date: Tue, 5 Jan 2016 15:04:36 -0800
> > > CC: lldb-dev@lists.llvm.org
> > > To: eugen...@hotmail.com
> > >
> > > Try this:
> > >
> > > % lldb
> > > (lldb) platform select --sysroot /path/to/remote/shared/libraries
> > > remote-linux
> > > (lldb) <load core>
> > >
> > > If this works, there are SBPlatform class calls in the API you can use
> > > the select the platform as done above if you need to not do this from the
> > > command line.
> > >
> > > The other option is to chroot into /path/to/remote/shared/libraries and
> > > you will need to copy your core file into
> > > /path/to/remote/shared/libraries, then just run LLDB normally and it
> > > should work.
> > >
> > > Greg Clayton
> > >
> > > > On Jan 5, 2016, at 12:53 PM, Eugene Birukov via lldb-dev
> > > > <lldb-dev@lists.llvm.org> wrote:
> > > >
> > > > Hi,
> > > >
> > > > I am using LLDB-3.7 on Ubuntu Linux.
> > > >
> > > > I have a core dump file and all shared libraries from my server but I
> > > > want to investigate them on a dev box. But I fail to correctly load it
> > > > in LLDB - it shows wrong stacks. I.e. I am looking for something
> > > > equivalent to GDB commands "set solib-absolute-prefix" and "set
> > > > solib-search-path".
> > > >
> > > > I tried to play with "target modules search-paths insert", but I cannot
> > > > use it if there is no target and I cannot load core after I have a
> > > > target - not sure what this command is intended to do...
> > > >
> > > > Now, what I really need to do - it is load core in my custom debugger
> > > > that uses C++ API. Here I made some progress:
> > > > • Create target with NULL file name
> > > > • Load core using SBTarget::LoadCore()
> > > > • Manually load all executables - the initial a.out and all the shared
> > > > libraries using SBTarget::AddModule() and
> > > > SBTarget::SetModuleLoadAddress()
> > > > This kind of works, but there are two problems:
> > > > • How would I find the list of modules and addresses to load from the
> > > > core file? Currently I did it by loading core in the debugger on the
> > > > server, but this is not acceptable for production run...
> > > > • LLDB correctly prints stacks and resolves symbols, but I cannot
> > > > disassembly any code - the ReadMemory retuns all zeroes from code
> > > > addresses.
> > > >
> > > > Any help would be greatly appreciated.
> > > >
> > > > Thanks,
> > > > Eugene
> > > > _______________________________________________
> > > > lldb-dev mailing list
> > > > lldb-dev@lists.llvm.org
> > > > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> > >
>
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
