[lldb][windows] print an error if python.dll is not in the DLL search path #164893

charles-zablit · 2025-10-23T20:57:19Z

This is a follow up to #162509.

Using the SearchPathW API, we can ensure that the correct version of Python is installed before liblldb is loaded (and python.dll subsequently). If it's not, we try to add it to the search path with the methods introduced in #162509. If that fails or if that method is #ifdef'd out, we print an error which will appear before lldb crashes due to the missing dll.

Before #162509, when invoked from Powershell, lldb would silently crash (no error message/crash report). After #162509, it crashes without any indications that the root cause is the missing python.dll. With this patch, we print the error before crashing.

… path

llvmbot · 2025-10-23T20:58:06Z

@llvm/pr-subscribers-lldb

Author: Charles Zablit (charles-zablit)

Changes

This is a follow up to #162509.

Using the SearchPathW API, we can ensure that the correct version of Python is installed before liblldb is loaded (and python.dll subsequently). If it's not, we try to add it to the search path with the methods introduced in #162509. If that fails or if that method is #ifdef'd out, we print an error which will appear before lldb crashes due to the missing dll.

Before #162509, when invoked from Powershell, lldb would silently crash (no error message/crash report). After #162509, it crashes without any indications that the root cause is the missing python.dll. With this patch, we print the error before crashing.

Full diff: https://github.com/llvm/llvm-project/pull/164893.diff

3 Files Affected:

(modified) lldb/CMakeLists.txt (+4)
(modified) lldb/tools/driver/CMakeLists.txt (+3)
(modified) lldb/tools/driver/Driver.cpp (+35-10)

diff --git a/lldb/CMakeLists.txt b/lldb/CMakeLists.txt
index e3b72e94d4beb..7c85c6fa8b825 100644
--- a/lldb/CMakeLists.txt
+++ b/lldb/CMakeLists.txt
@@ -61,6 +61,8 @@ if (LLDB_ENABLE_PYTHON)
     "Path to python interpreter exectuable, relative to python's install prefix")
   set(cachestring_LLDB_PYTHON_EXT_SUFFIX
     "Filename extension for native code python modules")
+  set(cachestring_LLDB_PYTHON_SHARED_LIBRARY_NAME
+    "Filename of Python's shared library")
 
   foreach(var LLDB_PYTHON_RELATIVE_PATH LLDB_PYTHON_EXE_RELATIVE_PATH LLDB_PYTHON_EXT_SUFFIX)
     if(NOT DEFINED ${var} AND NOT CMAKE_CROSSCOMPILING)
@@ -87,6 +89,8 @@ if (LLDB_ENABLE_PYTHON)
       set(LLDB_PYTHON_EXT_SUFFIX "_d${LLDB_PYTHON_EXT_SUFFIX}")
     endif()
   endif()
+  set(LLDB_PYTHON_SHARED_LIBRARY_FILENAME
+    "python${Python3_VERSION_MAJOR}${Python3_VERSION_MINOR}${CMAKE_SHARED_LIBRARY_SUFFIX}")
 endif ()
 
 if (LLDB_ENABLE_LUA)
diff --git a/lldb/tools/driver/CMakeLists.txt b/lldb/tools/driver/CMakeLists.txt
index 67956af7fe3fb..467ca9f91b3c1 100644
--- a/lldb/tools/driver/CMakeLists.txt
+++ b/lldb/tools/driver/CMakeLists.txt
@@ -37,6 +37,9 @@ add_dependencies(lldb
 if(DEFINED LLDB_PYTHON_DLL_RELATIVE_PATH)
   target_compile_definitions(lldb PRIVATE LLDB_PYTHON_DLL_RELATIVE_PATH="${LLDB_PYTHON_DLL_RELATIVE_PATH}")
 endif()
+if(DEFINED LLDB_PYTHON_SHARED_LIBRARY_FILENAME)
+  target_compile_definitions(lldb PRIVATE LLDB_PYTHON_SHARED_LIBRARY_FILENAME="${LLDB_PYTHON_SHARED_LIBRARY_FILENAME}")
+endif()
 
 if(LLDB_BUILD_FRAMEWORK)
   # In the build-tree, we know the exact path to the framework directory.
diff --git a/lldb/tools/driver/Driver.cpp b/lldb/tools/driver/Driver.cpp
index ba0041111045b..96157525f3703 100644
--- a/lldb/tools/driver/Driver.cpp
+++ b/lldb/tools/driver/Driver.cpp
@@ -433,7 +433,8 @@ SBError Driver::ProcessArgs(const opt::InputArgList &args, bool &exiting) {
   return error;
 }
 
-#if defined(_WIN32) && defined(LLDB_PYTHON_DLL_RELATIVE_PATH)
+#ifdef _WIN32
+#ifdef LLDB_PYTHON_DLL_RELATIVE_PATH
 /// Returns the full path to the lldb.exe executable.
 inline std::wstring GetPathToExecutableW() {
   // Iterate until we reach the Windows API maximum path length (32,767).
@@ -447,32 +448,51 @@ inline std::wstring GetPathToExecutableW() {
   return L"";
 }
 
-/// Resolve the full path of the directory defined by
+/// \brief Resolve the full path of the directory defined by
 /// LLDB_PYTHON_DLL_RELATIVE_PATH. If it exists, add it to the list of DLL
 /// search directories.
-void AddPythonDLLToSearchPath() {
+/// \return `true` if the library was added to the search path.
+/// `false` otherwise.
+bool AddPythonDLLToSearchPath() {
   std::wstring modulePath = GetPathToExecutableW();
   if (modulePath.empty()) {
-    llvm::errs() << "error: unable to find python.dll." << '\n';
-    return;
+    return false;
   }
 
   SmallVector<char, MAX_PATH> utf8Path;
   if (sys::windows::UTF16ToUTF8(modulePath.c_str(), modulePath.length(),
                                 utf8Path))
-    return;
+    return false;
   sys::path::remove_filename(utf8Path);
   sys::path::append(utf8Path, LLDB_PYTHON_DLL_RELATIVE_PATH);
   sys::fs::make_absolute(utf8Path);
 
   SmallVector<wchar_t, 1> widePath;
   if (sys::windows::widenPath(utf8Path.data(), widePath))
-    return;
+    return false;
 
   if (sys::fs::exists(utf8Path))
-    SetDllDirectoryW(widePath.data());
+    return SetDllDirectoryW(widePath.data());
+  return false;
+}
+#endif
+
+#ifdef LLDB_PYTHON_SHARED_LIBRARY_FILENAME
+/// Returns whether `python3x.dll` is in the DLL search path.
+bool IsPythonDLLInPath() {
+#define WIDEN2(x) L##x
+#define WIDEN(x) WIDEN2(x)
+  WCHAR foundPath[MAX_PATH];
+  DWORD result =
+      SearchPathW(nullptr, WIDEN(LLDB_PYTHON_SHARED_LIBRARY_FILENAME), nullptr,
+                  MAX_PATH, foundPath, nullptr);
+#undef WIDEN2
+#undef WIDEN
+
+  return result > 0;
 }
 #endif
+#endif
 
 std::string EscapeString(std::string arg) {
   std::string::size_type pos = 0;
@@ -776,8 +796,13 @@ int main(int argc, char const *argv[]) {
                         "~/Library/Logs/DiagnosticReports/.\n");
 #endif
 
-#if defined(_WIN32) && defined(LLDB_PYTHON_DLL_RELATIVE_PATH)
-  AddPythonDLLToSearchPath();
+#if defined(_WIN32) && defined(LLDB_PYTHON_SHARED_LIBRARY_FILENAME)
+  if (!IsPythonDLLInPath())
+#ifdef LLDB_PYTHON_DLL_RELATIVE_PATH
+    if (!AddPythonDLLToSearchPath())
+#endif
+      llvm::errs() << "error: unable to find "
+                   << LLDB_PYTHON_SHARED_LIBRARY_FILENAME << ".\n";
 #endif
 
   // Parse arguments.

charles-zablit · 2025-10-23T21:07:02Z

I'm debating if, when SearchPathW fails to find python.dll, we should exit or let lldb crash.

Right now, the error looks like this and I think it's lost in the details of the crash. Gracefully exiting would allow to just have the error message without the stack dump which I think is a better user experience.

However, I don't want to prevent lldb from starting if we think python.dll is not available, even though it is.

mstorsjo · 2025-10-23T21:11:11Z

lldb/CMakeLists.txt

    endif()
  endif()
+  set(LLDB_PYTHON_SHARED_LIBRARY_FILENAME
+    "python${Python3_VERSION_MAJOR}${Python3_VERSION_MINOR}${CMAKE_SHARED_LIBRARY_SUFFIX}")


You may wish to include a cmake variable for the prefix as well; on mingw, it's libpython3.12.dll - I'm sure that there's a cmake variable that expands to lib for mingw but nothing for msvc like environments.

Also; if i understand this correctly, this variable gets set automatically, but is it possible to override this string through cmake parameters?

I switched to using Python3_RUNTIME_LIBRARY which points directly to the correct dll. Hopefully that also works in mingw and other environment.

Also; if i understand this correctly, this variable gets set automatically, but is it possible to override this string through cmake parameters?

From my understanding of Cmake, it will be overwritten by the set, so the answer is no. Do you think it would be a useful variable to expose?

If we pick the right name for all configurations, then no, we probably don't need to expose it. From a distributor freedom point of view, it maybe would be good to have the possibility to do that. But on the other hand, we can go with this first, and make it settable if someone later tells us they'd want to do that.

mstorsjo · 2025-10-23T21:14:32Z

lldb/tools/driver/Driver.cpp

-  AddPythonDLLToSearchPath();
+#if defined(_WIN32) && defined(LLDB_PYTHON_SHARED_LIBRARY_FILENAME)
+  if (!IsPythonDLLInPath())
+#ifdef LLDB_PYTHON_DLL_RELATIVE_PATH


This condition nesting doesn't seem right. If we have LLDB_PYTHON_DLL_RELATIVE_PATH defined, but we don't have LLDB_PYTHON_SHARED_LIBRARY_FILENAME, then we no longer will call AddPythonDLLToSearchPath at all - which we did before. Not sure what the neatest form of this is; maybe an #elif defined(LLDB_PYTHON_DLL_RELATIVE_PATH) AddPythonDLLToSearchPath(); #endif?

My initial assumption was that LLDB_PYTHON_SHARED_LIBRARY_FILENAME would always be set if LLDB_PYTHON_DLL_RELATIVE_PATH is set, because it's set if we are linking against Python.

To resolve this I've extracted the logic into a function which made it easier by using return to control the execution flow.

Yes, practically speaking (as that variable is set automatically by cmake), it should always be defined. But it might be good to have the code robust for all potential combinations anyway?

Yes, practically speaking (as that variable is set automatically by cmake), it should always be defined. But it might be good to have the code robust for all potential combinations anyway?

I agree, the new logic allows for either of them (or both) to be defined.

mstorsjo · 2025-10-23T21:20:31Z

I'm debating if, when SearchPathW fails to find python.dll, we should exit or let lldb crash.

However, I don't want to prevent lldb from starting if we think python.dll is not available, even though it is.

I agree, I think this is the better call. As mentioned above, the current guesstimate of the python DLL name would be wrong on mingw, so I'd rather have a spurious error message than exiting altogether.

(Also, I wonder if there's some way one can learn the actual python library name through the CMake FindPython scripts, rather than having to guess it; guessing it seems brittle. E.g. if we manage to switch over to the Python stable API, it can be just python3.dll instead of python312.dll.)

… search path

charles-zablit · 2025-10-23T22:26:10Z

(Also, I wonder if there's some way one can learn the actual python library name through the CMake FindPython scripts, rather than having to guess it; guessing it seems brittle. E.g. if we manage to switch over to the Python stable API, it can be just python3.dll instead of python312.dll.)

I ended up using Python3_RUNTIME_LIBRARY which points to python310.dll or its equivalent. I could not find a variable which points to python3.dll.

… search path

Nerixyz · 2025-10-24T07:47:29Z

I could not find a variable which points to python3.dll.

According to the documentation of FindPython3.cmake, this should be in Python3_SABI_LIBRARY (CMake 3.26+).

mstorsjo · 2025-10-24T08:33:31Z

I ended up using Python3_RUNTIME_LIBRARY which points to python310.dll or its equivalent. I could not find a variable which points to python3.dll.

Ok, that sounds reasonable - especially as long as that is what we actually link against right now.

mstorsjo · 2025-10-24T08:39:20Z

lldb/tools/driver/Driver.cpp

+    return;
+#ifdef LLDB_PYTHON_DLL_RELATIVE_PATH
+  if (AddPythonDLLToSearchPath())
+    return


Do you want a trailing ; here, or do you want this to expand to return (void expression);?

From the code logic, I think you want return; here, and reduce the indent level of the llvm::errs()<<... below?

Do you want a trailing ; here, or do you want this to expand to return (void expression);?

I should add a ;, that's an omission. That's probably why clang-format did that weird formatting form llvm::errs().

mstorsjo · 2025-10-24T09:20:37Z

lldb/tools/driver/CMakeLists.txt

  target_compile_definitions(lldb PRIVATE LLDB_PYTHON_DLL_RELATIVE_PATH="${LLDB_PYTHON_DLL_RELATIVE_PATH}")
 endif()
+if(DEFINED LLDB_PYTHON_SHARED_LIBRARY_FILENAME)
+  target_compile_definitions(lldb PRIVATE LLDB_PYTHON_SHARED_LIBRARY_FILENAME="${LLDB_PYTHON_SHARED_LIBRARY_FILENAME}")


This seems broken/mismatched right now; this uses LLDB_PYTHON_SHARED_LIBRARY_FILENAME while the rest of CMake, and the C++ code, uses LLDB_PYTHON_RUNTIME_LIBRARY_FILENAME.

Fixed, thanks 👍

mstorsjo · 2025-10-24T09:21:50Z

lldb/CMakeLists.txt

+  set(cachestring_LLDB_PYTHON_RUNTIME_LIBRARY_FILENAME
+    "Filename of Python's runtime library")

  foreach(var LLDB_PYTHON_RELATIVE_PATH LLDB_PYTHON_EXE_RELATIVE_PATH LLDB_PYTHON_EXT_SUFFIX)


If the cachestring_ above is to be used, we should include LLDB_PYTHON_RUNTIME_LIBRARY_FILENAME in this loop too (if that makes sense? not familiar with what this does...). Otherwise the cachestring_ variable isn't used at all.

Removed it, thanks 👍

mstorsjo · 2025-10-24T09:22:40Z

I ended up using Python3_RUNTIME_LIBRARY which points to python310.dll or its equivalent. I could not find a variable which points to python3.dll.

Python3_RUNTIME_LIBRARY doesn't seem to be set in my case (when cross compiling from Linux). I don't find it documented at https://cmake.org/cmake/help/latest/module/FindPython3.html either.

charles-zablit · 2025-10-24T19:21:31Z

I could not find a variable which points to python3.dll.

According to the documentation of FindPython3.cmake, this should be in Python3_SABI_LIBRARY (CMake 3.26+).

My understanding is that this is a variable we set ourselves, rather than one that CMake resolves:

To solve special cases, it is possible to specify directly the artifacts by setting the following variables:

charles-zablit · 2025-10-24T19:27:40Z

I ended up using Python3_RUNTIME_LIBRARY which points to python310.dll or its equivalent. I could not find a variable which points to python3.dll.

Python3_RUNTIME_LIBRARY doesn't seem to be set in my case (when cross compiling from Linux). I don't find it documented at cmake.org/cmake/help/latest/module/FindPython3.html either.

I'm confused as to where this variable comes from in the first place, because it's not documented and now that I did a clean build, it's gone.

I'm still trying to find a proper way of getting the dll name, there does not seem to be any variable that return the path/name. Python3_SABI_LIBRARIES is empty unless Python3_SABI_LIBRARY is set.

charles-zablit · 2025-10-24T19:37:43Z

That's where it's set: https://gitlab.kitware.com/cmake/cmake/blob/master/Modules/FindPython/Support.cmake#L3865

… search path

github-actions · 2025-10-24T21:33:46Z

✅ With the latest revision this PR passed the C/C++ code formatter.

charles-zablit · 2025-10-24T21:43:13Z

@mstorsjo my understanding is that Python3_RUNTIME_LIBRARY should always be set to something (according to https://gitlab.kitware.com/cmake/cmake/blob/master/Modules/FindPython/Support.cmake#L3868-3874) and that it's an undocumented public variable.

I see 2 solutions:

We either rely on this public variable even though it's not documented.
We try to guess the Python shared library based on the environment: if MSVC "python310.dll" else "lib python3.10.dll". This is only needed on Windows anyways (for now).

I prefer the first solution because it defers the logic to CMake, but you are saying that Python3_RUNTIME_LIBRARY and _ Python3_RUNTIME_LIBRARY_RELEASE and _ Python3_RUNTIME_LIBRARY_DEBUG are empty when you run it?

compnerd · 2025-10-24T22:00:48Z

Pushing this into CMake feels like the right thing IMO. I think that we should be able to do something more aggressive if we want. We could query the IMPORTED_LIBNAME property on the runtime target, and then use get_filename_component to get the basename and pass that value to the executable. This gives us the most pristine information directly from CMake allowing the user to configure things as appropriate. If that is too aggressive, we can also use the IMPORTED_LIBRARY_LOCATION as the value (technically, IMPORTED_LIBNAME could be a linker option).

charles-zablit · 2025-10-24T22:32:24Z

Using IMPORTED_LIBRARY_LOCATION works great, thanks @compnerd !

mstorsjo · 2025-10-25T20:19:45Z

First replying to the older messages:

I'm confused as to where this variable comes from in the first place, because it's not documented and now that I did a clean build, it's gone.

@mstorsjo my understanding is that Python3_RUNTIME_LIBRARY should always be set to something (according to https://gitlab.kitware.com/cmake/cmake/blob/master/Modules/FindPython/Support.cmake#L3868-3874) and that it's an undocumented public variable.

I see 2 solutions:

We either rely on this public variable even though it's not documented.

We try to guess the Python shared library based on the environment: if MSVC "python310.dll" else "lib python3.10.dll". This is only needed on Windows anyways (for now).

I prefer the first solution because it defers the logic to CMake, but you are saying that Python3_RUNTIME_LIBRARY and _ Python3_RUNTIME_LIBRARY_RELEASE and _ Python3_RUNTIME_LIBRARY_DEBUG are empty when you run it?

I don't see alternative 1 as an option, as you yourself also said that it wasn't set for you after doing a clean build?

Anyway, the current suggestion of using get_target_property(_Python3_LIB_PATH Python3::Python IMPORTED_LIBRARY_LOCATION) doesn't seem to work for me - I'm getting these warnings:

CMake Error at /home/martin/code/llvm-project/lldb/CMakeLists.txt:90 (get_target_property):
  get_target_property() called with non-existent target "Python3::Python".

It's probably relevant to say, that in my cross compiling setup, I'm not letting FindPython do all the digging of locating Python, as that's not necessarily very workable in a cross compile. What I do, is that I configure the LLVM/LLDB build with these parameters:

-DLLDB_ENABLE_PYTHON=ON
-DPYTHON_HOME=$PREFIX/python
-DLLDB_PYTHON_HOME=../python
# Relative to the lldb install root
-DLLDB_PYTHON_RELATIVE_PATH=$PYTHON_RELATIVE_PATH # e.g. python/lib/python3.11/site-packages
# Relative to LLDB_PYTHON_HOME
-DLLDB_PYTHON_EXE_RELATIVE_PATH=bin/python3.exe
-DLLDB_PYTHON_EXT_SUFFIX=$EXT_SUFFIX # e.g. .cp311-mingw_x86_64_clang.pyd

-DPython3_INCLUDE_DIRS=$PYTHON_INCLUDE_DIR # e.g. /home/martin/clang-cross-x86_64/python/include/python3.11
-DPython3_LIBRARIES=$PYTHON_LIB # e.g. /home/martin/clang-cross-x86_64/python/lib/libpython3.11.dll.a

mstorsjo · 2025-10-25T20:33:56Z

Anyway, so with my setup of manually setting Python3_LIBRARIES and Python3_INCLUDE_DIRS rather than letting FindPython set it all up, I guess it's reasonable for me to not get this set automatically either, if we can't. In this case, the built LLDB won't get the potential warning on startup, and that's also probably fine.

I did check the original approach, of guessing the library name, and that does seem to work to the point of getting the version number right and all. It does need adding ${CMAKE_SHARED_LIBRARY_PREFIX} at the start though.

I.e. this snippet seems to work for me:

  set(LLDB_PYTHON_SHARED_LIBRARY_FILENAME
    "${CMAKE_SHARED_LIBRARY_PREFIX}python${Python3_VERSION_MAJOR}${Python3_VERSION_MINOR}${CMAKE_SHARED_LIBRARY_SUFFIX}")

But I don't mind keeping the current suggestion, as it won't produce any spurious runtime warnings in LLDB anyway. It would be nice to check if the target Python3::Python actually exists to avoid the cmake warning I quoted above though, but it's not critical.

compnerd

This looks good, but I think that merging the two paths for the relative and regular behavior is desirable before merging.

lldb/tools/driver/Driver.cpp

compnerd · 2025-10-27T12:33:08Z

lldb/tools/driver/Driver.cpp

+    return;
+#endif
+  llvm::errs() << "error: unable to find "
+               << LLDB_PYTHON_RUNTIME_LIBRARY_FILENAME << ".\n";


Should we quote the library name in the style of literals in diagnostics (e.g. 'python311.dll').

compnerd · 2025-10-27T12:35:03Z

lldb/tools/driver/Driver.cpp

+#elif defined(LLDB_PYTHON_DLL_RELATIVE_PATH)
+  if (!AddPythonDLLToSearchPath())
+    llvm::errs() << "error: unable to find the Python runtime library.\n";
+#endif


I think that we can merge the two paths and just conditionally emit the diagnostic, the handling feels identical otherwise.

My reasoning for keeping the two paths separate is to make sure the installed Python's dll takes precedence over the one we might bundle in the installer (LLDB_PYTHON_DLL_RELATIVE_PATH).

charles-zablit · 2025-10-27T21:35:52Z

But I don't mind keeping the current suggestion, as it won't produce any spurious runtime warnings in LLDB anyway. It would be nice to check if the target Python3::Python actually exists to avoid the cmake warning I quoted above though, but it's not critical.

I added a check to make sure the target is defined before trying to access its properties. This should remove the CMake warning.

mstorsjo · 2025-10-27T22:25:13Z

But I don't mind keeping the current suggestion, as it won't produce any spurious runtime warnings in LLDB anyway. It would be nice to check if the target Python3::Python actually exists to avoid the cmake warning I quoted above though, but it's not critical.

I added a check to make sure the target is defined before trying to access its properties. This should remove the CMake warning.

Thanks! Yes, the warning seems to be gone for me now.

mstorsjo

Looking mostly good, but another question about the warnings in the current form.

Other than that, this looks good to me now, if you've verified that it actually does work as expected in the final form.

mstorsjo · 2025-10-27T22:25:05Z

lldb/tools/driver/Driver.cpp

+#ifdef LLDB_PYTHON_DLL_RELATIVE_PATH
+  if (AddPythonDLLToSearchPath())
+    return;
+#endif


In an earlier revision of this PR, we did a second IsPythonDLLInPath() check after a successful AddPythonDLLToSearchPath() - even though we did add a path, we don't still really know if it does contain the DLL we want or not.

compnerd · 2025-10-28T02:59:23Z

lldb/tools/driver/Driver.cpp

+#elif defined(LLDB_PYTHON_DLL_RELATIVE_PATH)
+  if (!AddPythonDLLToSearchPath())
+    llvm::errs() << "error: unable to find the Python runtime library.\n";
+#endif


I'm confused - why do we need the AddPythonDLLToSearchPath twice?

We want to be sure to check that python.dll is in the Path and/or try to add it to the Path whether LLDB_PYTHON_RUNTIME_LIBRARY_FILENAME and LLDB_PYTHON_DLL_RELATIVE_PATH are both set or only one or the other.

If only LLDB_PYTHON_RUNTIME_LIBRARY_FILENAME is set:

Check if python.dll is in the Path

Print a warning if it's not.

If only LLDB_PYTHON_DLL_RELATIVE_PATH is set:

Try to add python.dll to the Path

If both are set:

Check if python.dll is in the Path.

If it's not try to add it.

Check again if it's in the Path (not implemented yet).

Print a warning if it's not.

[lldb][windows] print an error if python.dll is not in the DLL search…

3d2976b

… path

charles-zablit requested a review from JDevlieghere as a code owner October 23, 2025 20:57

charles-zablit requested review from compnerd and removed request for JDevlieghere October 23, 2025 20:57

llvmbot added the lldb label Oct 23, 2025

charles-zablit requested review from JDevlieghere and Nerixyz October 23, 2025 20:57

charles-zablit self-assigned this Oct 23, 2025

charles-zablit requested a review from adrian-prantl October 23, 2025 20:57

charles-zablit requested a review from mstorsjo October 23, 2025 21:07

mstorsjo reviewed Oct 23, 2025

View reviewed changes

charles-zablit added 2 commits October 23, 2025 23:12

fixup! [lldb][windows] print an error if python.dll is not in the DLL…

d502ba9

… search path

fixup! [lldb][windows] print an error if python.dll is not in the DLL…

c73bf5f

… search path

fixup! [lldb][windows] print an error if python.dll is not in the DLL…

71178bb

… search path

mstorsjo reviewed Oct 24, 2025

View reviewed changes

fixup! [lldb][windows] print an error if python.dll is not in the DLL…

6071b08

… search path

formatting fixup

855a405

use IMPORTED_LIBRARY_LOCATION

6ee7fce

compnerd reviewed Oct 27, 2025

View reviewed changes

check if the Python target is defined

8b34fea

mstorsjo reviewed Oct 27, 2025

View reviewed changes

compnerd reviewed Oct 28, 2025

View reviewed changes

Uh oh!

[lldb][windows] print an error if python.dll is not in the DLL search path #164893

Are you sure you want to change the base?

[lldb][windows] print an error if python.dll is not in the DLL search path #164893

Conversation

charles-zablit commented Oct 23, 2025

Uh oh!

llvmbot commented Oct 23, 2025

Uh oh!

charles-zablit commented Oct 23, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mstorsjo commented Oct 23, 2025

Uh oh!

charles-zablit commented Oct 23, 2025

Uh oh!

Nerixyz commented Oct 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mstorsjo commented Oct 24, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mstorsjo commented Oct 24, 2025

Uh oh!

charles-zablit commented Oct 24, 2025

Uh oh!

charles-zablit commented Oct 24, 2025

Uh oh!

charles-zablit commented Oct 24, 2025

Uh oh!

github-actions bot commented Oct 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

charles-zablit commented Oct 24, 2025

Uh oh!

compnerd commented Oct 24, 2025

Uh oh!

charles-zablit commented Oct 24, 2025

Uh oh!

mstorsjo commented Oct 25, 2025

Uh oh!

mstorsjo commented Oct 25, 2025

Uh oh!

compnerd left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

charles-zablit commented Oct 27, 2025

Uh oh!

mstorsjo commented Oct 27, 2025

Nerixyz commented Oct 24, 2025 •

edited

Loading

github-actions bot commented Oct 24, 2025 •

edited

Loading