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

2018-07-23 Thread Greg Clayton via lldb-dev
// 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

2018-07-23 Thread Eugene Birukov via lldb-dev
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

2018-07-23 Thread Pavel Labath via lldb-dev
 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

2018-07-20 Thread Eugene Birukov via lldb-dev
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

2018-07-20 Thread Eugene Birukov via lldb-dev
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

2018-07-20 Thread Ted Woodward via lldb-dev
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

2018-07-20 Thread Eugene Birukov via lldb-dev
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