[lldb-dev] How to load core on a different machine?

[Greg Clayton via lldb-dev]

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 <eugenebi at 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 at 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: gclayton at apple.com
> > Date: Tue, 5 Jan 2016 15:04:36 -0800
> > CC: lldb-dev at lists.llvm.org
> > To: eugenebi at 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 at 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 at lists.llvm.org
> > > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> >