Re: [lldb-dev] LLDB does not respect platform sysroot when loading core on Linux
// 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 >> _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 ) { >> >> 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 On Behalf Of Eugene Birukov >> via lldb-dev >> Sent: Friday, July 20, 2018 12:21 PM >> To: Ted Woodward ; 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/x/bin/../lib/libc++.so.1 >> >> [ 2] AF1A7705-DAC0-8661-7411-8DEFE8281C64-AED273A9 >> /opt/x/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 0x7ffd3f9d2000 >> [vdso] (0x7ffd3f9d2000) >> >> [ 5] 402F8E9C---- 0x7f0e8094e000 >> /lib64/libpthread.so.0 (0x7f0e8094e000) >> >> [ 6] C36E0F49---- 0x7f0e80746000 >> /lib64/librt.so.1 (0x7f0e80746000) >> >> [ 7] DA7C854B---- 0x7f0e80542000 >> /lib64/libdl.so.2 (0x7f0e80542000) >> >> [ 8] 9EFAADB9---- 0x7f0e7feb2000 >> /lib64/libcrypto.so.10 (0x7f0e7feb2000) >> >> [ 9] 1B54BC7F---- 0x7f0e7fc44000 >> /lib64/libssl.so.10 (0x7f0e7fc44000) >> >> [ 10] 0E999CDE---- 0x7f0e7fa38000 >> /lib64/libnuma.so.1 (0x7f0e7fa38000) >> >> [ 11] 51C7A74C---- 0x7f0e7f7ea000 >> /lib64/libgssapi_krb5.so.2 (0x7f0e7f7ea000) >> >> [ 12] D74EFC55---- 0x7f0e7f503000 >> /lib64/libkrb5.so.3 (0x7f0e7f503000) >> >> [ 13] 57A9AB75---- 0x7f0e7f2d1000 >> /lib64/libk5crypto.so.3 (0x7f0e7f2d1000) >> >> [ 14] 93F50DD9---- 0x7f0e7f0cd000 >> /lib64/libcom_err.so.2 (0x7f0e7f0cd000) >> >> [ 15] 04DA7429---- 0x7f0e7ee8f000 >> /lib64/libblkid.so.1 (0x7f0e7ee8f000) >> >> [
Re: [lldb-dev] LLDB does not respect platform sysroot when loading core on Linux
I believe using search path is not the right approach when opening a core dump. We do not need to search for modules: we know exactly what has been loaded from where when the application crashed. The only problem is that the machine was different, so we need to prepend sysroot and get them form there. Scanning search path chain and grabbing arbitrary files that happen to have matching name would confuse the debugger. If nobody objects, I'll prepare this change in phabricator. -Original Message- From: Pavel Labath Sent: Monday, July 23, 2018 2:42 AM To: Eugene Birukov Cc: LLDB Subject: Re: [lldb-dev] LLDB does not respect platform sysroot when loading core on Linux 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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freviews.llvm.org%2Fdifferentialdata=02%7C01%7Ceugenebi%40microsoft.com%7Cccc0730e45e54303889a08d5f0809ff9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636679357598185483sdata=65R5UyPEArGn2q27sklUPc8bUEAOjPK2OBi91SMVuzM%3Dreserved=0>? We can discuss the approach there. On Fri, 20 Jul 2018 at 23:55, Eugene Birukov via lldb-dev 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 _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 _spec, > > ModuleSP _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 _module_list = GetSharedModuleList(); > >std::lock_guard guard( > >shared_module_list.m_modules_mutex); > > @@ -726,9 +730,6 @@ Status ModuleList::GetSharedModule(const > ModuleSpec _spec, > >const FileSpec _file_spec = module_spec.GetFileSpec(); > >const ArchSpec = 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 _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
Re: [lldb-dev] LLDB does not respect platform sysroot when loading core on Linux
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 On Behalf Of Eugene Birukov > via lldb-dev > Sent: Friday, July 20, 2018 12:21 PM > To: Ted Woodward ; 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/x/bin/../lib/libc++.so.1 > > [ 2] AF1A7705-DAC0-8661-7411-8DEFE8281C64-AED273A9 > /opt/x/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 0x7ffd3f9d2000 [vdso] > (0x7ffd3f9d2000) > > [ 5] 402F8E9C---- 0x7f0e8094e000 > /lib64/libpthread.so.0 (0x7f0e8094e000) > > [ 6] C36E0F49---- 0x7f0e80746000 > /lib64/librt.so.1 (0x7f0e80746000) > > [ 7] DA7C854B---- 0x7f0e80542000 > /lib64/libdl.so.2 (0x7f0e80542000) > > [ 8] 9EFAADB9---- 0x7f0e7feb2000 > /lib64/libcrypto.so.10 (0x7f0e7feb2000) > > [ 9] 1B54BC7F---- 0x7f0e7fc44000 > /lib64/libssl.so.10 (0x7f0e7fc44000) > > [ 10] 0E999CDE---- 0x7f0e7fa38000 > /lib64/libnuma.so.1 (0x7f0e7fa38000) > > [ 11] 51C7A74C---- 0x7f0e7f7ea000 > /lib64/libgssapi_krb5.so.2 (0x7f0e7f7ea000) > > [ 12] D74EFC55---- 0x7f0e7f503000 > /lib64/libkrb5.so.3 (0x7f0e7f503000) > > [ 13] 57A9AB75---- 0x7f0e7f2d1000 > /lib64/libk5crypto.so.3 (0x7f0e7f2d1000) > > [ 14] 93F50DD9---- 0x7f0e7f0cd000 > /lib64/libcom_err.so.2 (0x7f0e7f0cd000) > > [ 15] 04DA7429---- 0x7f0e7ee8f000 > /lib64/libblkid.so.1 (0x7f0e7ee8f000) > > [ 16] 0D4800F4---- 0x7f0e7ec8a000 > /lib64/libsss_nss_idmap.so.0 (0x7f0e7ec8a000) > > [ 17] 07CAC506---- 0x7f0e7ea85000 > /lib64/libuuid.so.1 (0x7f0e7ea85000) > > [ 18] A69E7F20---- 0x7f0e7e537000 > /lib64/libm.so.6 (0x7f0e7e537000) > > [ 19] 9FAE7CD0---- 0x7f0e7e321000 > /lib64/libgcc_s.so.1 (0x7f0e7e321000) > > [ 20] 02E59CD0---- 0x7f0e7df6 > /lib64/libc.so.6 (0x7f0e7df6) > > [ 21] 9FCA7001---- 0x7f0e7dc58000 > /lib64/libstdc++.so.6 (0x7f0e7dc58000) > > [ 22] EADDCF0A---- 0x7f0e7da42000 > /lib64/libz.so.1 (0x7f0e7da42000) > > [ 23] 4158BE15---- 0x7f0e7d833000 > /lib64/libkrb5support.so.0 (0x7f0e7d833000) > > [ 24] 9213C8BE---- 0x7f0e7d62f000 > /lib64/libkeyutils.so.1 (0x7f0e7d62f000) > > [ 25] DA713559---- 0x7f0e7d415000 > /lib64/libresolv.so.2 (0x7f0e7d415000) > > [ 26] 7EC8B5FA---- 0x7f0e7d1ee000 > /lib64/libselinux.so.1 (0x7f0e7d1ee000) > > [ 27] B618A715---- 0x7f0e7cf8d000 > /lib64/libpcre.so.1 (0x7f0e7cf8d000) > > [ 28] 7BC742F6-EC7C-B8E9-3251-08C749F25E46-D76FE69D
Re: [lldb-dev] LLDB does not respect platform sysroot when loading core on Linux
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 _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 _spec, ModuleSP _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 _module_list = GetSharedModuleList(); std::lock_guard guard( shared_module_list.m_modules_mutex); @@ -726,9 +730,6 @@ Status ModuleList::GetSharedModule(const ModuleSpec _spec, const FileSpec _file_spec = module_spec.GetFileSpec(); const ArchSpec = 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 _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 _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 ) { 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 mailto: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 mailto:ted.woodw...@codeaurora.org>>; lldb-dev@lists.llvm.org<mailto:lldb-dev@lists.llvm.org> Subject: Re: [lldb-dev] LLDB does not respect platform sysroot when loading core on Linux 1. Shouldn't platform trick work? 2. 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] EB
Re: [lldb-dev] LLDB does not respect platform sysroot when loading core on Linux
ore.3WyoW4/bin/executable [ 1] BBCFB8B3-D0D8-9B97-9231-645196845E00-CB55E7D0 /opt/x/bin/../lib/libc++.so.1 [ 2] AF1A7705-DAC0-8661-7411-8DEFE8281C64-AED273A9 /opt/x/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 Sent: Friday, July 20, 2018 12:01 PM To: Eugene Birukov ; 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<mailto: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<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.llvm.org%2Fpipermail%2Flldb-dev%2F2016-January%2F009236.html=02%7C01%7Ceugenebi%40microsoft.com%7C0e095f7f9acd4f9dfa6408d5ee733146%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636677100876922006=DacHWP%2Bprfj9gEzF6j1x0syIf%2F29Wa1YoZ5eIcxZplg%3D=0> : (lldb) platform select --sysroot /path/to/remote/shared/libraries remote-linux (lldb) 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=0x7fffbb50, did_create_ptr=0x7fffbb07, always_create=false) at /home/eugene/llvm/tools/lldb/source/Core/ModuleList.cpp:710 #1 0x7fffedc2d130 in lldb_private::Platformoperator()(const lldb_private::ModuleSpec &) const (__closure=0x8581b0, spec=...) at /home/eugene/llvm/tools/lldb/source/Target/Platform.cpp:234 #2 0x7fffedc34ff2 in std::_Function_handler >::_M_invoke(const std::_Any_data &, const lldb_private::ModuleSpec &) (__functor=..., __args#0=...) at /usr/include/c++/5/functional:1857 #3 0x7fffedc37978 in std::function::operator()(lldb_private::ModuleSpec const&) const (this=0x7fffba80, __args#0=...) at /usr/include/c++/5/functional:2267 #4 0x7fffedc3375a in lldb_private::Platform::GetRemoteSharedModule(lldb_private::ModuleSpec const&, lldb_private::Process*, std::shared_ptr&, std::function const&, bool*) (this=0x839330, module_spec=..., process=0x84d310, module_sp=std::shared_ptr (empty) 0x0, module_resolver=..., did_create_ptr=0x7fffbb07) at /home/eugene/llvm/tools/lldb/source/Target/Platform.cpp:1628 #5 0x7fffedc2d2cd 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=0x7fffbb50, did_create_ptr=0x7fffbb07) at /home/eugene/llvm/tools/lldb/source/Target/Platform.cpp:240 #6 0x7fffedc9957c in lldb_private::Target::GetSharedModule (this=0x846960, module_spec=..., error_ptr=0x0) at /home/eugene/llvm/tools/lldb/source/Target/Target.cpp:1952 #7 0x7fffef8e0d11 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 0x7fffedd8fb55 in DynamicLoaderPOSIXDYLD::LoadAllCurrentModules (this=0x9a0a70) at /home/eugene/llvm/tools/lldb/source/Plugins/DynamicLoader/POSIX-DYLD/DynamicLoaderPOSIXDYLD.cpp:537 #9 0x7fffedd8de52 in DynamicLoaderPOSIXDYLD::DidAttach (th
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) 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=0x7fffbb50, did_create_ptr=0x7fffbb07, always_create=false) at /home/eugene/llvm/tools/lldb/source/Core/ModuleList.cpp:710 #1 0x7fffedc2d130 in lldb_private::Platformoperator()(const lldb_private::ModuleSpec &) const (__closure=0x8581b0, spec=...) at /home/eugene/llvm/tools/lldb/source/Target/Platform.cpp:234 #2 0x7fffedc34ff2 in std::_Function_handler >::_M_invoke(const std::_Any_data &, const lldb_private::ModuleSpec &) (__functor=..., __args#0=...) at /usr/include/c++/5/functional:1857 #3 0x7fffedc37978 in std::function::operator()(lldb_private::ModuleSpec const&) const (this=0x7fffba80, __args#0=...) at /usr/include/c++/5/functional:2267 #4 0x7fffedc3375a in lldb_private::Platform::GetRemoteSharedModule(lldb_private::ModuleSpec const&, lldb_private::Process*, std::shared_ptr&, std::function const&, bool*) (this=0x839330, module_spec=..., process=0x84d310, module_sp=std::shared_ptr (empty) 0x0, module_resolver=..., did_create_ptr=0x7fffbb07) at /home/eugene/llvm/tools/lldb/source/Target/Platform.cpp:1628 #5 0x7fffedc2d2cd 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=0x7fffbb50, did_create_ptr=0x7fffbb07) at /home/eugene/llvm/tools/lldb/source/Target/Platform.cpp:240 #6 0x7fffedc9957c in lldb_private::Target::GetSharedModule (this=0x846960, module_spec=..., error_ptr=0x0) at /home/eugene/llvm/tools/lldb/source/Target/Target.cpp:1952 #7 0x7fffef8e0d11 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 0x7fffedd8fb55 in DynamicLoaderPOSIXDYLD::LoadAllCurrentModules (this=0x9a0a70) at /home/eugene/llvm/tools/lldb/source/Plugins/DynamicLoader/POSIX-DYLD/Dynamic LoaderPOSIXDYLD.cpp:537 #9 0x7fffedd8de52 in DynamicLoaderPOSIXDYLD::DidAttach (this=0x9a0a70) at /home/eugene/llvm/tools/lldb/source/Plugins/DynamicLoader/POSIX-DYLD/Dynamic LoaderPOSIXDYLD.cpp:171 #10 0x7fffedc476d9 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 hav
[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) 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=0x7fffbb50, did_create_ptr=0x7fffbb07, always_create=false) at /home/eugene/llvm/tools/lldb/source/Core/ModuleList.cpp:710 #1 0x7fffedc2d130 in lldb_private::Platformoperator()(const lldb_private::ModuleSpec &) const (__closure=0x8581b0, spec=...) at /home/eugene/llvm/tools/lldb/source/Target/Platform.cpp:234 #2 0x7fffedc34ff2 in std::_Function_handler >::_M_invoke(const std::_Any_data &, const lldb_private::ModuleSpec &) (__functor=..., __args#0=...) at /usr/include/c++/5/functional:1857 #3 0x7fffedc37978 in std::function::operator()(lldb_private::ModuleSpec const&) const (this=0x7fffba80, __args#0=...) at /usr/include/c++/5/functional:2267 #4 0x7fffedc3375a in lldb_private::Platform::GetRemoteSharedModule(lldb_private::ModuleSpec const&, lldb_private::Process*, std::shared_ptr&, std::function const&, bool*) (this=0x839330, module_spec=..., process=0x84d310, module_sp=std::shared_ptr (empty) 0x0, module_resolver=..., did_create_ptr=0x7fffbb07) at /home/eugene/llvm/tools/lldb/source/Target/Platform.cpp:1628 #5 0x7fffedc2d2cd 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=0x7fffbb50, did_create_ptr=0x7fffbb07) at /home/eugene/llvm/tools/lldb/source/Target/Platform.cpp:240 #6 0x7fffedc9957c in lldb_private::Target::GetSharedModule (this=0x846960, module_spec=..., error_ptr=0x0) at /home/eugene/llvm/tools/lldb/source/Target/Target.cpp:1952 #7 0x7fffef8e0d11 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 0x7fffedd8fb55 in DynamicLoaderPOSIXDYLD::LoadAllCurrentModules (this=0x9a0a70) at /home/eugene/llvm/tools/lldb/source/Plugins/DynamicLoader/POSIX-DYLD/DynamicLoaderPOSIXDYLD.cpp:537 #9 0x7fffedd8de52 in DynamicLoaderPOSIXDYLD::DidAttach (this=0x9a0a70) at /home/eugene/llvm/tools/lldb/source/Plugins/DynamicLoader/POSIX-DYLD/DynamicLoaderPOSIXDYLD.cpp:171 #10 0x7fffedc476d9 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