If --sysroot is supplied, then it should just work as you say. The platform code will be asked to locate the file and the remote-linux platform is failing here and needs to be fixed.
Greg > On Jul 23, 2018, at 2:42 AM, Pavel Labath via lldb-dev > <lldb-dev@lists.llvm.org> wrote: > > Instead of "image search-paths add" you should be able to do a > "settings append target.exec-search-paths /your/sysroot". That one > should not require a running target or anything like that. > > However, I agree that it would be nice for the platform sysroot to > work out of the box. Particularly, as we can then use it to do other > nice things (e.g. prevent matching of files in the main filesystem, so > we can avoid the ld-linux-x86-64.so.2 problem you encountered). > > For the patch, can you create a review on the LLVM phabricator > <https://reviews.llvm.org/differential>? We can discuss the approach > there. > > On Fri, 20 Jul 2018 at 23:55, Eugene Birukov via lldb-dev > <lldb-dev@lists.llvm.org> wrote: >> >> I have a small fix – pass platform sysroot to ModuleList::GetSharedModule. >> The fix works for me. >> >> >> >> What should I do to get it reviewed? >> >> >> >> Thanks, >> >> Eugene >> >> >> >> diff --git a/include/lldb/Core/ModuleList.h b/include/lldb/Core/ModuleList.h >> >> index 4b637c9..3214291 100644 >> >> --- a/include/lldb/Core/ModuleList.h >> >> +++ b/include/lldb/Core/ModuleList.h >> >> @@ -541,7 +541,8 @@ public: >> >> const FileSpecList *module_search_paths_ptr, >> >> lldb::ModuleSP *old_module_sp_ptr, >> >> bool *did_create_ptr, >> >> - bool always_create = false); >> >> + bool always_create = false, >> >> + const char* sysroot = nullptr); >> >> >> >> static bool RemoveSharedModule(lldb::ModuleSP &module_sp); >> >> >> >> diff --git a/source/Core/ModuleList.cpp b/source/Core/ModuleList.cpp >> >> index 3970052..f2db3bb 100644 >> >> --- a/source/Core/ModuleList.cpp >> >> +++ b/source/Core/ModuleList.cpp >> >> @@ -707,7 +707,11 @@ Status ModuleList::GetSharedModule(const ModuleSpec >> &module_spec, >> >> ModuleSP &module_sp, >> >> const FileSpecList >> *module_search_paths_ptr, >> >> ModuleSP *old_module_sp_ptr, >> >> - bool *did_create_ptr, bool >> always_create) { >> >> + bool *did_create_ptr, bool always_create, >> >> + const char* sysroot) { >> >> + // Make sure no one else can try and get or create a module while this >> >> + // function is actively working on it by doing an extra lock on the >> >> + // global mutex list. >> >> ModuleList &shared_module_list = GetSharedModuleList(); >> >> std::lock_guard<std::recursive_mutex> guard( >> >> shared_module_list.m_modules_mutex); >> >> @@ -726,9 +730,6 @@ Status ModuleList::GetSharedModule(const ModuleSpec >> &module_spec, >> >> const FileSpec &module_file_spec = module_spec.GetFileSpec(); >> >> const ArchSpec &arch = module_spec.GetArchitecture(); >> >> >> >> - // Make sure no one else can try and get or create a module while this >> >> - // function is actively working on it by doing an extra lock on the >> >> - // global mutex list. >> >> if (!always_create) { >> >> ModuleList matching_module_list; >> >> const size_t num_matching_modules = >> >> @@ -762,7 +763,11 @@ Status ModuleList::GetSharedModule(const ModuleSpec >> &module_spec, >> >> if (module_sp) >> >> return error; >> >> >> >> - module_sp.reset(new Module(module_spec)); >> >> + auto resolved_module_spec(module_spec); >> >> + if (sysroot != nullptr) >> >> + resolved_module_spec.GetFileSpec().PrependPathComponent(sysroot); >> >> + >> >> + module_sp.reset(new Module(resolved_module_spec)); >> >> // Make sure there are a module and an object file since we can specify >> >> // a valid file path with an architecture that might not be in that file. >> >> // By getting the object file we can guarantee that the architecture >> matches >> >> diff --git a/source/Target/Platform.cpp b/source/Target/Platform.cpp >> >> index 5d60bb7..19161cc 100644 >> >> --- a/source/Target/Platform.cpp >> >> +++ b/source/Target/Platform.cpp >> >> @@ -225,13 +225,14 @@ Status Platform::GetSharedModule(const ModuleSpec >> &module_spec, >> >> if (IsHost()) >> >> return ModuleList::GetSharedModule( >> >> module_spec, module_sp, module_search_paths_ptr, old_module_sp_ptr, >> >> - did_create_ptr, false); >> >> + did_create_ptr, false, m_sdk_sysroot.AsCString()); >> >> >> >> return GetRemoteSharedModule(module_spec, process, module_sp, >> >> [&](const ModuleSpec &spec) { >> >> Status error = ModuleList::GetSharedModule( >> >> spec, module_sp, >> module_search_paths_ptr, >> >> - old_module_sp_ptr, did_create_ptr, >> false); >> >> + old_module_sp_ptr, did_create_ptr, >> false, >> >> + m_sdk_sysroot.AsCString()); >> >> if (error.Success() && module_sp) >> >> module_sp->SetPlatformFileSpec( >> >> spec.GetFileSpec()); >> >> >> >> From: lldb-dev <lldb-dev-boun...@lists.llvm.org> On Behalf Of Eugene Birukov >> via lldb-dev >> Sent: Friday, July 20, 2018 12:21 PM >> To: Ted Woodward <ted.woodw...@codeaurora.org>; lldb-dev@lists.llvm.org >> Subject: Re: [lldb-dev] LLDB does not respect platform sysroot when loading >> core on Linux >> >> >> >> Shouldn’t platform trick work? >> This doesn’t work too. “image” command is rejected if I don’t have the >> target created. But if I issue it after I got target, the module list gets >> practically empty. Only the modules I have exactly matching between my >> machine and the target are left. >> >> >> >> Another problem: ld-linux-x86-64.so.2 has matched from my machine, but this >> is actually a different file. >> >> >> >> (lldb) image search-paths add / /tmp/debugcore.3WyoW4/lib2/ >> >> error: invalid target >> >> >> >> (lldb) target create -c core bin/executable >> >> Core file … (x86_64) was loaded. >> >> (lldb) target mod list >> >> [ 0] EB1EC4C1-8C92-1BBC-5EEC-98AAD9006691-2E1FE735 >> /tmp/debugcore.3WyoW4/bin/executable >> >> [ 1] BBCFB8B3-D0D8-9B97-9231-645196845E00-CB55E7D0 >> /opt/xxxxx/bin/../lib/libc++.so.1 >> >> [ 2] AF1A7705-DAC0-8661-7411-8DEFE8281C64-AED273A9 >> /opt/xxxxx/bin/../lib/libc++abi.so.1 >> >> [ 3] 5D7B6259-5522-75A3-C17B-D4C3FD05F5A6-BF40CAA5 >> /lib64/ld-linux-x86-64.so.2 >> >> [ 4] F40CF56C-9984-4493-6E56-9E905018C61A-446E19F3 0x00007ffd3f9d2000 >> [vdso] (0x00007ffd3f9d2000) >> >> [ 5] 402F8E9C-0000-0000-0000-000000000000 0x00007f0e8094e000 >> /lib64/libpthread.so.0 (0x00007f0e8094e000) >> >> [ 6] C36E0F49-0000-0000-0000-000000000000 0x00007f0e80746000 >> /lib64/librt.so.1 (0x00007f0e80746000) >> >> [ 7] DA7C854B-0000-0000-0000-000000000000 0x00007f0e80542000 >> /lib64/libdl.so.2 (0x00007f0e80542000) >> >> [ 8] 9EFAADB9-0000-0000-0000-000000000000 0x00007f0e7feb2000 >> /lib64/libcrypto.so.10 (0x00007f0e7feb2000) >> >> [ 9] 1B54BC7F-0000-0000-0000-000000000000 0x00007f0e7fc44000 >> /lib64/libssl.so.10 (0x00007f0e7fc44000) >> >> [ 10] 0E999CDE-0000-0000-0000-000000000000 0x00007f0e7fa38000 >> /lib64/libnuma.so.1 (0x00007f0e7fa38000) >> >> [ 11] 51C7A74C-0000-0000-0000-000000000000 0x00007f0e7f7ea000 >> /lib64/libgssapi_krb5.so.2 (0x00007f0e7f7ea000) >> >> [ 12] D74EFC55-0000-0000-0000-000000000000 0x00007f0e7f503000 >> /lib64/libkrb5.so.3 (0x00007f0e7f503000) >> >> [ 13] 57A9AB75-0000-0000-0000-000000000000 0x00007f0e7f2d1000 >> /lib64/libk5crypto.so.3 (0x00007f0e7f2d1000) >> >> [ 14] 93F50DD9-0000-0000-0000-000000000000 0x00007f0e7f0cd000 >> /lib64/libcom_err.so.2 (0x00007f0e7f0cd000) >> >> [ 15] 04DA7429-0000-0000-0000-000000000000 0x00007f0e7ee8f000 >> /lib64/libblkid.so.1 (0x00007f0e7ee8f000) >> >> [ 16] 0D4800F4-0000-0000-0000-000000000000 0x00007f0e7ec8a000 >> /lib64/libsss_nss_idmap.so.0 (0x00007f0e7ec8a000) >> >> [ 17] 07CAC506-0000-0000-0000-000000000000 0x00007f0e7ea85000 >> /lib64/libuuid.so.1 (0x00007f0e7ea85000) >> >> [ 18] A69E7F20-0000-0000-0000-000000000000 0x00007f0e7e537000 >> /lib64/libm.so.6 (0x00007f0e7e537000) >> >> [ 19] 9FAE7CD0-0000-0000-0000-000000000000 0x00007f0e7e321000 >> /lib64/libgcc_s.so.1 (0x00007f0e7e321000) >> >> [ 20] 02E59CD0-0000-0000-0000-000000000000 0x00007f0e7df60000 >> /lib64/libc.so.6 (0x00007f0e7df60000) >> >> [ 21] 9FCA7001-0000-0000-0000-000000000000 0x00007f0e7dc58000 >> /lib64/libstdc++.so.6 (0x00007f0e7dc58000) >> >> [ 22] EADDCF0A-0000-0000-0000-000000000000 0x00007f0e7da42000 >> /lib64/libz.so.1 (0x00007f0e7da42000) >> >> [ 23] 4158BE15-0000-0000-0000-000000000000 0x00007f0e7d833000 >> /lib64/libkrb5support.so.0 (0x00007f0e7d833000) >> >> [ 24] 9213C8BE-0000-0000-0000-000000000000 0x00007f0e7d62f000 >> /lib64/libkeyutils.so.1 (0x00007f0e7d62f000) >> >> [ 25] DA713559-0000-0000-0000-000000000000 0x00007f0e7d415000 >> /lib64/libresolv.so.2 (0x00007f0e7d415000) >> >> [ 26] 7EC8B5FA-0000-0000-0000-000000000000 0x00007f0e7d1ee000 >> /lib64/libselinux.so.1 (0x00007f0e7d1ee000) >> >> [ 27] B618A715-0000-0000-0000-000000000000 0x00007f0e7cf8d000 >> /lib64/libpcre.so.1 (0x00007f0e7cf8d000) >> >> [ 28] 7BC742F6-EC7C-B8E9-3251-08C749F25E46-D76FE69D >> /opt/xxxxx/bin/../lib/libunwind.so.8 >> >> [ 29] A3A6D23F-0000-0000-0000-000000000000 0x00007f0e75e24000 >> /lib64/liblzma.so.5 (0x00007f0e75e24000) >> >> [ 30] 682FA1FE-0000-0000-0000-000000000000 0x00007f0e2f531000 >> /usr/lib64/gssproxy/proxymech.so (0x00007f0e2f531000) >> >> [ 31] DA479E71-0000-0000-0000-000000000000 0x00007f0e2f305000 >> /lib64/libgssrpc.so.4 (0x00007f0e2f305000) >> >> [ 32] D10ACB70-0000-0000-0000-000000000000 0x00007f0e2b9ef000 >> /lib64/libnss_files.so.2 (0x00007f0e2b9ef000) >> >> [ 33] 8A5852DC-0000-0000-0000-000000000000 0x00007f0e2b7e9000 >> /lib64/libnss_dns.so.2 (0x00007f0e2b7e9000) >> >> [ 34] A19B4645-0000-0000-0000-000000000000 0x00007f0e2b733000 >> /lib64/libnss_myhostname.so.2 (0x00007f0e2b733000) >> >> [ 35] CB72796B-0000-0000-0000-000000000000 0x00007f0e2b52e000 >> /lib64/libcap.so.2 (0x00007f0e2b52e000) >> >> [ 36] 312FFEED-0000-0000-0000-000000000000 0x00007f0e2b2e6000 >> /lib64/libdw.so.1 (0x00007f0e2b2e6000) >> >> [ 37] 1B32E461-0000-0000-0000-000000000000 0x00007f0e2b0e1000 >> /lib64/libattr.so.1 (0x00007f0e2b0e1000) >> >> [ 38] 280E50A8-0000-0000-0000-000000000000 0x00007f0e2aec9000 >> /lib64/libelf.so.1 (0x00007f0e2aec9000) >> >> [ 39] FFB3D20E-0000-0000-0000-000000000000 0x00007f0e2acb9000 >> /lib64/libbz2.so.1 (0x00007f0e2acb9000) >> >> (lldb) image search-paths add / /tmp/debugcore.3WyoW4/lib2/ >> >> (lldb) target mod list >> >> [ 0] EB1EC4C1-8C92-1BBC-5EEC-98AAD9006691-2E1FE735 >> /tmp/debugcore.3WyoW4/bin/executable >> >> [ 1] BBCFB8B3-D0D8-9B97-9231-645196845E00-CB55E7D0 >> /opt/xxxxx/bin/../lib/libc++.so.1 >> >> [ 2] AF1A7705-DAC0-8661-7411-8DEFE8281C64-AED273A9 >> /opt/xxxxx/bin/../lib/libc++abi.so.1 >> >> [ 3] 5D7B6259-5522-75A3-C17B-D4C3FD05F5A6-BF40CAA5 >> /lib64/ld-linux-x86-64.so.2 >> >> (lldb) >> >> >> >> Thanks, >> >> Eugene >> >> >> >> From: Ted Woodward <ted.woodw...@codeaurora.org> >> Sent: Friday, July 20, 2018 12:01 PM >> To: Eugene Birukov <eugen...@microsoft.com>; lldb-dev@lists.llvm.org >> Subject: RE: [lldb-dev] LLDB does not respect platform sysroot when loading >> core on Linux >> >> >> >> Instead of setting the sysroot, try the command >> >> image search-paths add / /path/to/remote/shared/libraries/ >> >> >> >> That adds to the list that the dynamic loader uses to map shared object >> paths. >> >> >> >> It uses a simple text substitution, so in the above case, >> >> /usr/lib/libc.so >> >> Becomes >> >> /path/to/remote/shared/libraries/usr/lib/libc.so >> >> >> >> Matching up trailing slashes is critical, as I learned the hard way! >> >> >> >> Ted >> >> >> >> -- >> >> Qualcomm Innovation Center, Inc. >> >> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a >> Linux Foundation Collaborative Project >> >> >> >> From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Eugene >> Birukov via lldb-dev >> Sent: Friday, July 20, 2018 1:13 PM >> To: lldb-dev@lists.llvm.org >> Subject: [lldb-dev] LLDB does not respect platform sysroot when loading core >> on Linux >> >> >> >> Hello, >> >> >> >> I would appreciate advise how to fix this correctly… >> >> >> >> I have a core dump from somebody’s RHEL Linux and I am trying to open it on >> my Ubuntu. I have all the shared libraries from the target sitting under my >> local directory. So, GDB happily opens the core after I issue “set sysroot >> /path/to/local/root”, but LLDB release_60 fails to do it. >> >> >> >> I follow instructions from Greg’s Clayton mail >> http://lists.llvm.org/pipermail/lldb-dev/2016-January/009236.html : >> >> >> >> (lldb) platform select --sysroot /path/to/remote/shared/libraries >> remote-linux >> >> (lldb) <load core> >> >> >> >> Under debugger, I see that LLDB successfully created Platform object with >> m_sdk_root set to my path and the Target uses it as its platform: >> >> >> >> (gdb) p target_sp->m_platform_sp->m_sdk_sysroot >> >> $42 = { >> >> m_string = 0x80e070 "/tmp/debugcore.3WyoW4/lib2" >> >> } >> >> >> >> But this value is not used when it comes to >> DynamicLoaderPOSIXDYLD::LoadAllCurrentModules. >> >> (gdb) bt >> >> #0 lldb_private::ModuleList::GetSharedModule (module_spec=..., >> module_sp=std::shared_ptr (empty) 0x0, >> >> module_search_paths_ptr=0x83ad60, old_module_sp_ptr=0x7fffffffbb50, >> did_create_ptr=0x7fffffffbb07, >> >> always_create=false) at >> /home/eugene/llvm/tools/lldb/source/Core/ModuleList.cpp:710 >> >> #1 0x00007fffedc2d130 in lldb_private::Platform::<lambda(const >> lldb_private::ModuleSpec&)>::operator()(const lldb_private::ModuleSpec &) >> const (__closure=0x8581b0, spec=...) >> >> at /home/eugene/llvm/tools/lldb/source/Target/Platform.cpp:234 >> >> #2 0x00007fffedc34ff2 in std::_Function_handler<lldb_private::Status(const >> lldb_private::ModuleSpec&), lldb_private::Platform::GetSharedModule(const >> lldb_private::ModuleSpec&, lldb_private::Process*, lldb::ModuleSP&, const >> lldb_private::FileSpecList*, lldb::ModuleSP*, bool*)::<lambda(const >> lldb_private::ModuleSpec&)> >::_M_invoke(const std::_Any_data &, const >> lldb_private::ModuleSpec &) (__functor=..., __args#0=...) at >> /usr/include/c++/5/functional:1857 >> >> #3 0x00007fffedc37978 in std::function<lldb_private::Status >> (lldb_private::ModuleSpec const&)>::operator()(lldb_private::ModuleSpec >> const&) const (this=0x7fffffffba80, __args#0=...) at >> /usr/include/c++/5/functional:2267 >> >> #4 0x00007fffedc3375a in >> lldb_private::Platform::GetRemoteSharedModule(lldb_private::ModuleSpec >> const&, lldb_private::Process*, std::shared_ptr<lldb_private::Module>&, >> std::function<lldb_private::Status (lldb_private::ModuleSpec const&)> >> const&, bool*) (this=0x839330, module_spec=..., process=0x84d310, >> module_sp=std::shared_ptr (empty) 0x0, >> >> module_resolver=..., did_create_ptr=0x7fffffffbb07) >> >> at /home/eugene/llvm/tools/lldb/source/Target/Platform.cpp:1628 >> >> #5 0x00007fffedc2d2cd in lldb_private::Platform::GetSharedModule >> (this=0x839330, module_spec=..., >> >> process=0x84d310, module_sp=std::shared_ptr (empty) 0x0, >> module_search_paths_ptr=0x83ad60, >> >> old_module_sp_ptr=0x7fffffffbb50, did_create_ptr=0x7fffffffbb07) >> >> at /home/eugene/llvm/tools/lldb/source/Target/Platform.cpp:240 >> >> #6 0x00007fffedc9957c in lldb_private::Target::GetSharedModule >> (this=0x846960, module_spec=..., error_ptr=0x0) >> >> at /home/eugene/llvm/tools/lldb/source/Target/Target.cpp:1952 >> >> #7 0x00007fffef8e0d11 in lldb_private::DynamicLoader::LoadModuleAtAddress >> (this=0x9a0a70, file=..., >> >> link_map_addr=139700267943784, base_addr=139700263510016, >> base_addr_is_offset=true) >> >> at /home/eugene/llvm/tools/lldb/source/Core/DynamicLoader.cpp:171 >> >> #8 0x00007fffedd8fb55 in DynamicLoaderPOSIXDYLD::LoadAllCurrentModules >> (this=0x9a0a70) >> >> at >> /home/eugene/llvm/tools/lldb/source/Plugins/DynamicLoader/POSIX-DYLD/DynamicLoaderPOSIXDYLD.cpp:537 >> >> #9 0x00007fffedd8de52 in DynamicLoaderPOSIXDYLD::DidAttach (this=0x9a0a70) >> >> at >> /home/eugene/llvm/tools/lldb/source/Plugins/DynamicLoader/POSIX-DYLD/DynamicLoaderPOSIXDYLD.cpp:171 >> >> #10 0x00007fffedc476d9 in lldb_private::Process::LoadCore (this=0x84d310) >> >> at /home/eugene/llvm/tools/lldb/source/Target/Process.cpp:2853 >> >> >> >> I simply do not see any reference to sysroot in the GetSharedModule() code. >> What is there – it is only scanning module_search_paths_ptr looking for >> file. This would not work because the scan ignores the directory part of the >> module: it takes the next path from the list and appends the file name. What >> I need instead – take m_sdk_sysroot from Platform and append the full module >> – including directory – to it. >> >> >> >> Unfortunately, GetSharedModule() is a static method and does not have any >> clue what is current platform or current target. So, should I pass another >> argument down there with sysroot or what? I have correct platform object at >> frame 4. >> >> >> >> 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 _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
