[lldb-dev] LLDB does not respect platform sysroot when loading core on Linux

Eugene Birukov via lldb-dev lldb-dev at lists.llvm.org
Fri Jul 20 15:55:26 PDT 2018


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-bounces at lists.llvm.org<mailto:lldb-dev-bounces at lists.llvm.org>> On Behalf Of Eugene Birukov via lldb-dev
Sent: Friday, July 20, 2018 12:21 PM
To: Ted Woodward <ted.woodward at codeaurora.org<mailto:ted.woodward at codeaurora.org>>; lldb-dev at lists.llvm.org<mailto:lldb-dev at 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] 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.woodward at codeaurora.org<mailto:ted.woodward at codeaurora.org>>
Sent: Friday, July 20, 2018 12:01 PM
To: Eugene Birukov <eugenebi at microsoft.com<mailto:eugenebi at microsoft.com>>; lldb-dev at lists.llvm.org<mailto:lldb-dev at 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-bounces at lists.llvm.org] On Behalf Of Eugene Birukov via lldb-dev
Sent: Friday, July 20, 2018 1:13 PM
To: lldb-dev at lists.llvm.org<mailto:lldb-dev at 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&data=02%7C01%7Ceugenebi%40microsoft.com%7C67abfbf5b91544808a7208d5ee75e30b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636677112459207377&sdata=GjpfyATISLCQX16hmCP2gwc37hIsIZuEOijCTj87Fm8%3D&reserved=0> :

(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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20180720/7bd18839/attachment-0001.html>


More information about the lldb-dev mailing list