forked from OSchip/llvm-project
004a264f8c
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 |
||
|---|---|---|
| .. | ||
| ConnectionGenericFileWindows.cpp | ||
| EditLineWin.cpp | ||
| FileSystem.cpp | ||
| Host.cpp | ||
| HostInfoWindows.cpp | ||
| HostProcessWindows.cpp | ||
| HostThreadWindows.cpp | ||
| LockFileWindows.cpp | ||
| PipeWindows.cpp | ||
| ProcessLauncherWindows.cpp | ||
| ProcessRunLock.cpp | ||
| Windows.cpp | ||