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 &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 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
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
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]
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/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 /opt/x/bin/../lib/libunwind.so.8 [ 29] A3A6D23F---- 0x7f0e75e24000 /lib64/liblzma.so.5 (0x7f0e75e24000) [ 30] 682FA1FE---- 0x7f0e2f531000 /usr/lib64/gssproxy/proxymech.so (0x7f0e2f531000) [ 31] DA479E71---- 0x7f0e2f305000 /lib64/libgssrpc.so.4 (0x7f0e2f305000) [ 32] D10ACB70---- 0x7f0e2b9ef000 /lib64/libnss_files.so.2 (0x7f0e2b9ef000) [ 33] 8A5852DC---- 0x7f0e2b7e9000 /lib64/libnss_dns.so.2 (0x7f0e2b7e9000) [ 34] A19B4645---- 0x7f0e2b733000 /lib64/libnss_myhostname.so.2 (0x7f0e2b733000) [ 35] CB72796B---- 0x7f0e2b52e000 /lib64/libcap.so.2 (0x7f0e2b52e000) [ 36] 312FFEED---- 0x7f0e2b2e6000 /lib64/libdw.so.1 (0x7f0e2b2e6000) [ 37] 1B32E461---- 0x7f0e2b0e1000 /lib64/libattr.so.1 (0x7f0e2b0e1000) [ 38] 280E50A8---- 0x7f0e2aec9000 /lib64/libelf.so.1 (0x7f0e2aec9000) [ 39] FFB3D20E---- 0x7f0e2acb9000 /lib64/libbz2.so.1 (0x7f0e2acb9000) (lldb) image search-paths add / /tmp/debugcore.3WyoW4/lib2/ (lldb) target mod list [ 0] EB1EC4C1-8C92-1BBC-5EEC-98AAD9006691-2E1FE735 /tmp/debugcore.3WyoW4/
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 have correct platform object at
frame 4.
Thanks,
Eugene
___
[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
