From 004a264f8c923922ecd34255bcb10f4adaa27ac5 Mon Sep 17 00:00:00 2001 From: Pavel Labath Date: Mon, 15 Feb 2021 21:51:32 +0100 Subject: [lldb] Fix shared library directory computation on windows Our code for locating the shared library directory works via dladdr (or the windows equivalent) to locate the path of an address known to reside in liblldb. This works great for C++ programs, but there's a catch. When (lib)lldb is used from python (like in our test suite), this dladdr call will return a path to the _lldb.so (or such) file in the python directory. To compensate for this, we have code which attempts to resolve this symlink, to ensure we get the canonical location. However, here's the second catch. On windows, this file is not a symlink (but a copy), so this logic fails. Since most of our other paths are derived from the liblldb location, all of these paths will be wrong, when running the test suite. One effect of this was the failure to find lldb-server in D96202. To fix this issue, I add some windows-specific code to locate the liblldb directory. Since it cannot rely on symlinks, it works by manually walking the directory tree -- essentially doing the opposite of what we do when computing the python directory. To avoid python leaking back into the host code, I implement this with the help of a callback which can be passed to HostInfo::Initialize in order to assist with the directory location. The callback lives inside the python plugin. I also strenghten the existing path test to ensure the returned path is the right one. Differential Revision: https://reviews.llvm.org/D96779 --- .../Python/ScriptInterpreterPython.cpp | 25 ++++++++++++++++++++++ 1 file changed, 25 insertions(+) (limited to 'lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp') diff --git a/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp b/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp index c2fd1f2..68409b7 100644 --- a/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp +++ b/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp @@ -410,6 +410,31 @@ FileSpec ScriptInterpreterPython::GetPythonDir() { return g_spec; } +void ScriptInterpreterPython::SharedLibraryDirectoryHelper( + FileSpec &this_file) { + // When we're loaded from python, this_file will point to the file inside the + // python package directory. Replace it with the one in the lib directory. +#ifdef _WIN32 + // On windows, we need to manually back out of the python tree, and go into + // the bin directory. This is pretty much the inverse of what ComputePythonDir + // does. + if (this_file.GetFileNameExtension() == ConstString(".pyd")) { + this_file.RemoveLastPathComponent(); // _lldb.pyd or _lldb_d.pyd + this_file.RemoveLastPathComponent(); // lldb + for (auto it = llvm::sys::path::begin(LLDB_PYTHON_RELATIVE_LIBDIR), + end = llvm::sys::path::end(LLDB_PYTHON_RELATIVE_LIBDIR); + it != end; ++it) + this_file.RemoveLastPathComponent(); + this_file.AppendPathComponent("bin"); + this_file.AppendPathComponent("liblldb.dll"); + } +#else + // The python file is a symlink, so we can find the real library by resolving + // it. We can do this unconditionally. + FileSystem::Instance().ResolveSymbolicLink(this_file, this_file); +#endif +} + lldb_private::ConstString ScriptInterpreterPython::GetPluginNameStatic() { static ConstString g_name("script-python"); return g_name; -- cgit v1.1