[Lldb-commits] [lldb] [lldb][windows] print an error if python.dll is not in the DLL search path (PR #164893)

2025-10-24 Thread Charles Zablit via lldb-commits

https://github.com/charles-zablit updated 
https://github.com/llvm/llvm-project/pull/164893

>From 3d2976b3e251bee88b9dee88fef0dcd9460dded2 Mon Sep 17 00:00:00 2001
From: Charles Zablit 
Date: Thu, 23 Oct 2025 13:48:29 -0700
Subject: [PATCH 1/7] [lldb][windows] print an error if python.dll is not in
 the DLL search path

---
 lldb/CMakeLists.txt  |  4 +++
 lldb/tools/driver/CMakeLists.txt |  3 +++
 lldb/tools/driver/Driver.cpp | 45 +---
 3 files changed, 42 insertions(+), 10 deletions(-)

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 ba004045b..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 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 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_PYT

[Lldb-commits] [lldb] [lldb][windows] print an error if python.dll is not in the DLL search path (PR #164893)

2025-10-24 Thread Charles Zablit via lldb-commits

charles-zablit wrote:

Using `IMPORTED_LIBRARY_LOCATION` works great, thanks @compnerd !

https://github.com/llvm/llvm-project/pull/164893
___
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] 10a975b - [lldb] Introduce internal stop hooks (#164506)

2025-10-24 Thread via lldb-commits

Author: Julian Lettner
Date: 2025-10-24T17:08:25-07:00
New Revision: 10a975be0f4c6337fe981c4086d90c582a970010

URL: 
https://github.com/llvm/llvm-project/commit/10a975be0f4c6337fe981c4086d90c582a970010
DIFF: 
https://github.com/llvm/llvm-project/commit/10a975be0f4c6337fe981c4086d90c582a970010.diff

LOG: [lldb] Introduce internal stop hooks (#164506)

Introduce the concept of internal stop hooks.
These are similar to LLDB's internal breakpoints:
LLDB itself will add them and users of LLDB will
not be able to add or remove them.

This change adds the following 3
independently-useful concepts:
* Maintain a list of internal stop hooks that will be populated by LLDB
and cannot be added to or removed from by users. They are managed in a
separate list in `Target::m_internal_stop_hooks`.
* `StopHookKind:CodeBased` and `StopHookCoded` represent a stop hook
defined by a C++ code callback (instead of command line expressions or a
Python class).
* Stop hooks that do not print any output can now also suppress the
printing of their header and description when they are hit via
`StopHook::GetSuppressOutput`.

Combining these 3 concepts we can model "internal
stop hooks" which serve the same function as
LLDB's internal breakpoints: executing built-in,
LLDB-defined behavior, leveraging the existing
mechanism of stop hooks.

This change also simplifies
`Target::RunStopHooks`.  We already have to
materialize a new list for combining internal and
user stop hooks. Filter and only add active hooks to this list to avoid
the need for "isActive?"
checks later on.

Added: 
lldb/test/Shell/ExecControl/StopHook/stop-hook-list.test

Modified: 
lldb/include/lldb/Target/Target.h
lldb/source/Commands/CommandCompletions.cpp
lldb/source/Commands/CommandObjectBreakpoint.cpp
lldb/source/Commands/CommandObjectTarget.cpp
lldb/source/Commands/Options.td
lldb/source/Target/Target.cpp

Removed: 




diff  --git a/lldb/include/lldb/Target/Target.h 
b/lldb/include/lldb/Target/Target.h
index f4a09237ce897..c375df248154f 100644
--- a/lldb/include/lldb/Target/Target.h
+++ b/lldb/include/lldb/Target/Target.h
@@ -1356,7 +1356,11 @@ class Target : public 
std::enable_shared_from_this,
 StopHook(const StopHook &rhs);
 virtual ~StopHook() = default;
 
-enum class StopHookKind  : uint32_t { CommandBased = 0, ScriptBased };
+enum class StopHookKind : uint32_t {
+  CommandBased = 0,
+  ScriptBased,
+  CodeBased,
+};
 enum class StopHookResult : uint32_t {
   KeepStopped = 0,
   RequestContinue,
@@ -1403,6 +1407,12 @@ class Target : public 
std::enable_shared_from_this,
 
 bool GetRunAtInitialStop() const { return m_at_initial_stop; }
 
+void SetSuppressOutput(bool suppress_output) {
+  m_suppress_output = suppress_output;
+}
+
+bool GetSuppressOutput() const { return m_suppress_output; }
+
 void GetDescription(Stream &s, lldb::DescriptionLevel level) const;
 virtual void GetSubclassDescription(Stream &s,
 lldb::DescriptionLevel level) const = 
0;
@@ -1414,6 +1424,7 @@ class Target : public 
std::enable_shared_from_this,
 bool m_active = true;
 bool m_auto_continue = false;
 bool m_at_initial_stop = true;
+bool m_suppress_output = false;
 
 StopHook(lldb::TargetSP target_sp, lldb::user_id_t uid);
   };
@@ -1433,8 +1444,8 @@ class Target : public 
std::enable_shared_from_this,
 
   private:
 StringList m_commands;
-// Use CreateStopHook to make a new empty stop hook. The GetCommandPointer
-// and fill it with commands, and SetSpecifier to set the specifier shared
+// Use CreateStopHook to make a new empty stop hook. Use 
SetActionFromString
+// to fill it with commands, and SetSpecifier to set the specifier shared
 // pointer (can be null, that will match anything.)
 StopHookCommandLine(lldb::TargetSP target_sp, lldb::user_id_t uid)
 : StopHook(target_sp, uid) {}
@@ -1460,19 +1471,56 @@ class Target : public 
std::enable_shared_from_this,
 StructuredDataImpl m_extra_args;
 lldb::ScriptedStopHookInterfaceSP m_interface_sp;
 
-/// Use CreateStopHook to make a new empty stop hook. The GetCommandPointer
-/// and fill it with commands, and SetSpecifier to set the specifier shared
-/// pointer (can be null, that will match anything.)
+/// Use CreateStopHook to make a new empty stop hook. Use SetScriptCallback
+/// to set the script to execute, and SetSpecifier to set the specifier
+/// shared pointer (can be null, that will match anything.)
 StopHookScripted(lldb::TargetSP target_sp, lldb::user_id_t uid)
 : StopHook(target_sp, uid) {}
 friend class Target;
   };
 
+  class StopHookCoded : public StopHook {
+  public:
+~StopHookCoded() override = default;
+
+using HandleStopCallback = StopHookResult(ExecutionContext &exc_ctx,
+   

[Lldb-commits] [lldb] [lldb] Introduce internal stop hooks (PR #164506)

2025-10-24 Thread Julian Lettner via lldb-commits

https://github.com/yln closed https://github.com/llvm/llvm-project/pull/164506
___
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] Enable LLDB to load large dSYM files. (PR #164471)

2025-10-24 Thread Greg Clayton via lldb-commits

https://github.com/clayborg updated 
https://github.com/llvm/llvm-project/pull/164471

>From 1673e1b93b9c4e5a99323ca9bdf8232c6d5fdfad Mon Sep 17 00:00:00 2001
From: Greg Clayton 
Date: Tue, 21 Oct 2025 11:19:30 -0700
Subject: [PATCH 1/6] Enable LLDB to load large dSYM files.

llvm-dsymutil can produce mach-o files where some sections in __DWARF exceed 
the 4GB barrier and subsequent sections in the dSYM will be inaccessible 
because the mach-o section_64 structure only has a 32 bit file offset. This 
patch enables LLDB to load a large dSYM file by figuring out when this happens 
and properly adjusting the file offset of the LLDB sections.

I was unable to add a test as obj2yaml and yaml2obj are broken for mach-o files 
and they can't convert a yaml file back into a valid mach-o object file. Any 
suggestions for adding a test would be appreciated.
---
 .../ObjectFile/Mach-O/ObjectFileMachO.cpp | 26 ++-
 1 file changed, 19 insertions(+), 7 deletions(-)

diff --git a/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp 
b/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
index 9cdb8467bfc60..6878f7331e0f5 100644
--- a/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
+++ b/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
@@ -1674,6 +1674,10 @@ void ObjectFileMachO::ProcessSegmentCommand(
   uint32_t segment_sect_idx;
   const lldb::user_id_t first_segment_sectID = context.NextSectionIdx + 1;
 
+  // dSYM files can create sections whose data exceeds the 4GB barrier, but
+  // mach-o sections only have 32 bit offsets. So keep track of when we
+  // overflow and fix the sections offsets as we iterate.
+  uint64_t section_offset_adjust = 0;
   const uint32_t num_u32s = load_cmd.cmd == LC_SEGMENT ? 7 : 8;
   for (segment_sect_idx = 0; segment_sect_idx < load_cmd.nsects;
++segment_sect_idx) {
@@ -1697,6 +1701,14 @@ void ObjectFileMachO::ProcessSegmentCommand(
 // isn't stored in the abstracted Sections.
 m_mach_sections.push_back(sect64);
 
+// Make sure we can load dSYM files whose __DWARF sections exceed the 4GB
+// barrier. llvm::MachO::section_64 have only 32 bit file offsets for the
+// section contents.
+const uint64_t section_file_offset = sect64.offset + section_offset_adjust;
+// If this section overflows a 4GB barrier, then we need to adjust any
+// subsequent the section offsets.
+if (is_dsym && ((uint64_t)sect64.offset + sect64.size) >= UINT32_MAX)
+  section_offset_adjust += 0x1ull;
 if (add_section) {
   ConstString section_name(
   sect64.sectname, strnlen(sect64.sectname, sizeof(sect64.sectname)));
@@ -1736,13 +1748,13 @@ void ObjectFileMachO::ProcessSegmentCommand(
   }
 
   // Grow the section size as needed.
-  if (sect64.offset) {
+  if (section_file_offset) {
 const lldb::addr_t segment_min_file_offset =
 segment->GetFileOffset();
 const lldb::addr_t segment_max_file_offset =
 segment_min_file_offset + segment->GetFileSize();
 
-const lldb::addr_t section_min_file_offset = sect64.offset;
+const lldb::addr_t section_min_file_offset = section_file_offset;
 const lldb::addr_t section_max_file_offset =
 section_min_file_offset + sect64.size;
 const lldb::addr_t new_file_offset =
@@ -1770,9 +1782,9 @@ void ObjectFileMachO::ProcessSegmentCommand(
   sect64.addr, // File VM address == addresses as they are
   // found in the object file
   sect64.size,   // VM size in bytes of this section
-  sect64.offset, // Offset to the data for this section in
+  section_file_offset, // Offset to the data for this section in
   // the file
-  sect64.offset ? sect64.size : 0, // Size in bytes of
+  section_file_offset ? sect64.size : 0, // Size in bytes of
   // this section as
   // found in the file
   sect64.align,
@@ -1792,14 +1804,14 @@ void ObjectFileMachO::ProcessSegmentCommand(
   SectionSP section_sp(new Section(
   segment_sp, module_sp, this, ++context.NextSectionIdx, section_name,
   sect_type, sect64.addr - segment_sp->GetFileAddress(), sect64.size,
-  sect64.offset, sect64.offset == 0 ? 0 : sect64.size, sect64.align,
-  sect64.flags));
+  section_file_offset, section_file_offset == 0 ? 0 : sect64.size,
+  sect64.align, sect64.flags));
   // Set the section to be encrypted to match the segment
 
   bool section_is_encrypted = false;
   if (!segment_is_encrypted && load_cmd.filesize != 0)
 section_is_encrypted = context.EncryptedRanges.FindEntryThatContains(
-   sect64.offset) != nullptr;
+   section_file_offset) != nullptr;
 
   section_sp->SetIsEncrypted(segment_i

[Lldb-commits] [lldb] 9b80fc3 - [lldb] Add missing function call in test (NFC)

2025-10-24 Thread Adrian Prantl via lldb-commits

Author: Adrian Prantl
Date: 2025-10-24T15:29:14-07:00
New Revision: 9b80fc39606f6f02b88a21ac29e98a74b0b7426a

URL: 
https://github.com/llvm/llvm-project/commit/9b80fc39606f6f02b88a21ac29e98a74b0b7426a
DIFF: 
https://github.com/llvm/llvm-project/commit/9b80fc39606f6f02b88a21ac29e98a74b0b7426a.diff

LOG: [lldb] Add missing function call in test (NFC)

Added: 


Modified: 
lldb/test/API/macosx/posix_spawn/TestLaunchProcessPosixSpawn.py

Removed: 




diff  --git a/lldb/test/API/macosx/posix_spawn/TestLaunchProcessPosixSpawn.py 
b/lldb/test/API/macosx/posix_spawn/TestLaunchProcessPosixSpawn.py
index 8a321b2ff6324..0f40dfd09c958 100644
--- a/lldb/test/API/macosx/posix_spawn/TestLaunchProcessPosixSpawn.py
+++ b/lldb/test/API/macosx/posix_spawn/TestLaunchProcessPosixSpawn.py
@@ -40,7 +40,7 @@ def run_arch(self, exe, arch):
 launch_info = target.GetLaunchInfo()
 error = lldb.SBError()
 process = target.Launch(launch_info, error)
-self.assertTrue(error.Success, str(error))
+self.assertTrue(error.Success(), str(error))
 self.assertState(process.GetState(), lldb.eStateExited)
 self.assertIn("slice: {}".format(arch), process.GetSTDOUT(1000))
 



___
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb][windows] print an error if python.dll is not in the DLL search path (PR #164893)

2025-10-24 Thread Saleem Abdulrasool via lldb-commits

compnerd wrote:

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).

https://github.com/llvm/llvm-project/pull/164893
___
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb][windows] print an error if python.dll is not in the DLL search path (PR #164893)

2025-10-24 Thread Charles Zablit via lldb-commits


@@ -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

charles-zablit wrote:

>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.

https://github.com/llvm/llvm-project/pull/164893
___
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb][windows] print an error if python.dll is not in the DLL search path (PR #164893)

2025-10-24 Thread Charles Zablit via lldb-commits

charles-zablit wrote:

> > I could not find a variable which points to `python3.dll`.
> 
> According to the documentation of 
> [`FindPython3.cmake`](https://cmake.org/cmake/help/latest/module/FindPython3.html#artifacts-specification),
>  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:

https://github.com/llvm/llvm-project/pull/164893
___
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb][windows] print an error if python.dll is not in the DLL search path (PR #164893)

2025-10-24 Thread Charles Zablit via lldb-commits


@@ -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}")

charles-zablit wrote:

Fixed, thanks 👍 

https://github.com/llvm/llvm-project/pull/164893
___
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb][windows] print an error if python.dll is not in the DLL search path (PR #164893)

2025-10-24 Thread Charles Zablit via lldb-commits


@@ -447,30 +448,66 @@ 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 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 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_RUNTIME_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_RUNTIME_LIBRARY_FILENAME), 
nullptr,
+  MAX_PATH, foundPath, nullptr);
+#undef WIDEN2
+#undef WIDEN
+
+  return result > 0;
+}
+#endif
+
+void SetupPythonRuntimeLibrary() {
+#ifdef LLDB_PYTHON_RUNTIME_LIBRARY_FILENAME
+  if (IsPythonDLLInPath())
+return;
+#ifdef LLDB_PYTHON_DLL_RELATIVE_PATH
+  if (AddPythonDLLToSearchPath())
+return

charles-zablit wrote:

> 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()`.

https://github.com/llvm/llvm-project/pull/164893
___
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb][windows] print an error if python.dll is not in the DLL search path (PR #164893)

2025-10-24 Thread Charles Zablit via lldb-commits

charles-zablit wrote:

> > 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](https://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.

https://github.com/llvm/llvm-project/pull/164893
___
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] Enable LLDB to load large dSYM files. (PR #164471)

2025-10-24 Thread Greg Clayton via lldb-commits

https://github.com/clayborg updated 
https://github.com/llvm/llvm-project/pull/164471

>From 1673e1b93b9c4e5a99323ca9bdf8232c6d5fdfad Mon Sep 17 00:00:00 2001
From: Greg Clayton 
Date: Tue, 21 Oct 2025 11:19:30 -0700
Subject: [PATCH 1/2] Enable LLDB to load large dSYM files.

llvm-dsymutil can produce mach-o files where some sections in __DWARF exceed 
the 4GB barrier and subsequent sections in the dSYM will be inaccessible 
because the mach-o section_64 structure only has a 32 bit file offset. This 
patch enables LLDB to load a large dSYM file by figuring out when this happens 
and properly adjusting the file offset of the LLDB sections.

I was unable to add a test as obj2yaml and yaml2obj are broken for mach-o files 
and they can't convert a yaml file back into a valid mach-o object file. Any 
suggestions for adding a test would be appreciated.
---
 .../ObjectFile/Mach-O/ObjectFileMachO.cpp | 26 ++-
 1 file changed, 19 insertions(+), 7 deletions(-)

diff --git a/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp 
b/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
index 9cdb8467bfc60..6878f7331e0f5 100644
--- a/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
+++ b/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
@@ -1674,6 +1674,10 @@ void ObjectFileMachO::ProcessSegmentCommand(
   uint32_t segment_sect_idx;
   const lldb::user_id_t first_segment_sectID = context.NextSectionIdx + 1;
 
+  // dSYM files can create sections whose data exceeds the 4GB barrier, but
+  // mach-o sections only have 32 bit offsets. So keep track of when we
+  // overflow and fix the sections offsets as we iterate.
+  uint64_t section_offset_adjust = 0;
   const uint32_t num_u32s = load_cmd.cmd == LC_SEGMENT ? 7 : 8;
   for (segment_sect_idx = 0; segment_sect_idx < load_cmd.nsects;
++segment_sect_idx) {
@@ -1697,6 +1701,14 @@ void ObjectFileMachO::ProcessSegmentCommand(
 // isn't stored in the abstracted Sections.
 m_mach_sections.push_back(sect64);
 
+// Make sure we can load dSYM files whose __DWARF sections exceed the 4GB
+// barrier. llvm::MachO::section_64 have only 32 bit file offsets for the
+// section contents.
+const uint64_t section_file_offset = sect64.offset + section_offset_adjust;
+// If this section overflows a 4GB barrier, then we need to adjust any
+// subsequent the section offsets.
+if (is_dsym && ((uint64_t)sect64.offset + sect64.size) >= UINT32_MAX)
+  section_offset_adjust += 0x1ull;
 if (add_section) {
   ConstString section_name(
   sect64.sectname, strnlen(sect64.sectname, sizeof(sect64.sectname)));
@@ -1736,13 +1748,13 @@ void ObjectFileMachO::ProcessSegmentCommand(
   }
 
   // Grow the section size as needed.
-  if (sect64.offset) {
+  if (section_file_offset) {
 const lldb::addr_t segment_min_file_offset =
 segment->GetFileOffset();
 const lldb::addr_t segment_max_file_offset =
 segment_min_file_offset + segment->GetFileSize();
 
-const lldb::addr_t section_min_file_offset = sect64.offset;
+const lldb::addr_t section_min_file_offset = section_file_offset;
 const lldb::addr_t section_max_file_offset =
 section_min_file_offset + sect64.size;
 const lldb::addr_t new_file_offset =
@@ -1770,9 +1782,9 @@ void ObjectFileMachO::ProcessSegmentCommand(
   sect64.addr, // File VM address == addresses as they are
   // found in the object file
   sect64.size,   // VM size in bytes of this section
-  sect64.offset, // Offset to the data for this section in
+  section_file_offset, // Offset to the data for this section in
   // the file
-  sect64.offset ? sect64.size : 0, // Size in bytes of
+  section_file_offset ? sect64.size : 0, // Size in bytes of
   // this section as
   // found in the file
   sect64.align,
@@ -1792,14 +1804,14 @@ void ObjectFileMachO::ProcessSegmentCommand(
   SectionSP section_sp(new Section(
   segment_sp, module_sp, this, ++context.NextSectionIdx, section_name,
   sect_type, sect64.addr - segment_sp->GetFileAddress(), sect64.size,
-  sect64.offset, sect64.offset == 0 ? 0 : sect64.size, sect64.align,
-  sect64.flags));
+  section_file_offset, section_file_offset == 0 ? 0 : sect64.size,
+  sect64.align, sect64.flags));
   // Set the section to be encrypted to match the segment
 
   bool section_is_encrypted = false;
   if (!segment_is_encrypted && load_cmd.filesize != 0)
 section_is_encrypted = context.EncryptedRanges.FindEntryThatContains(
-   sect64.offset) != nullptr;
+   section_file_offset) != nullptr;
 
   section_sp->SetIsEncrypted(segment_i

[Lldb-commits] [lldb] Enable LLDB to load large dSYM files. (PR #164471)

2025-10-24 Thread Greg Clayton via lldb-commits

clayborg wrote:

All inline suggestions have been fixed. I also tried to make a minimal yaml 
file that could create a large enough file, but it complains when trying to 
emit the file as it runs into the 32 bit section offset limiation and refuses 
to make a bad mach-o file. So no easy way to test this with yaml.

https://github.com/llvm/llvm-project/pull/164471
___
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] Enable LLDB to load large dSYM files. (PR #164471)

2025-10-24 Thread Greg Clayton via lldb-commits

https://github.com/clayborg updated 
https://github.com/llvm/llvm-project/pull/164471

>From 1673e1b93b9c4e5a99323ca9bdf8232c6d5fdfad Mon Sep 17 00:00:00 2001
From: Greg Clayton 
Date: Tue, 21 Oct 2025 11:19:30 -0700
Subject: [PATCH 1/3] Enable LLDB to load large dSYM files.

llvm-dsymutil can produce mach-o files where some sections in __DWARF exceed 
the 4GB barrier and subsequent sections in the dSYM will be inaccessible 
because the mach-o section_64 structure only has a 32 bit file offset. This 
patch enables LLDB to load a large dSYM file by figuring out when this happens 
and properly adjusting the file offset of the LLDB sections.

I was unable to add a test as obj2yaml and yaml2obj are broken for mach-o files 
and they can't convert a yaml file back into a valid mach-o object file. Any 
suggestions for adding a test would be appreciated.
---
 .../ObjectFile/Mach-O/ObjectFileMachO.cpp | 26 ++-
 1 file changed, 19 insertions(+), 7 deletions(-)

diff --git a/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp 
b/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
index 9cdb8467bfc60..6878f7331e0f5 100644
--- a/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
+++ b/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
@@ -1674,6 +1674,10 @@ void ObjectFileMachO::ProcessSegmentCommand(
   uint32_t segment_sect_idx;
   const lldb::user_id_t first_segment_sectID = context.NextSectionIdx + 1;
 
+  // dSYM files can create sections whose data exceeds the 4GB barrier, but
+  // mach-o sections only have 32 bit offsets. So keep track of when we
+  // overflow and fix the sections offsets as we iterate.
+  uint64_t section_offset_adjust = 0;
   const uint32_t num_u32s = load_cmd.cmd == LC_SEGMENT ? 7 : 8;
   for (segment_sect_idx = 0; segment_sect_idx < load_cmd.nsects;
++segment_sect_idx) {
@@ -1697,6 +1701,14 @@ void ObjectFileMachO::ProcessSegmentCommand(
 // isn't stored in the abstracted Sections.
 m_mach_sections.push_back(sect64);
 
+// Make sure we can load dSYM files whose __DWARF sections exceed the 4GB
+// barrier. llvm::MachO::section_64 have only 32 bit file offsets for the
+// section contents.
+const uint64_t section_file_offset = sect64.offset + section_offset_adjust;
+// If this section overflows a 4GB barrier, then we need to adjust any
+// subsequent the section offsets.
+if (is_dsym && ((uint64_t)sect64.offset + sect64.size) >= UINT32_MAX)
+  section_offset_adjust += 0x1ull;
 if (add_section) {
   ConstString section_name(
   sect64.sectname, strnlen(sect64.sectname, sizeof(sect64.sectname)));
@@ -1736,13 +1748,13 @@ void ObjectFileMachO::ProcessSegmentCommand(
   }
 
   // Grow the section size as needed.
-  if (sect64.offset) {
+  if (section_file_offset) {
 const lldb::addr_t segment_min_file_offset =
 segment->GetFileOffset();
 const lldb::addr_t segment_max_file_offset =
 segment_min_file_offset + segment->GetFileSize();
 
-const lldb::addr_t section_min_file_offset = sect64.offset;
+const lldb::addr_t section_min_file_offset = section_file_offset;
 const lldb::addr_t section_max_file_offset =
 section_min_file_offset + sect64.size;
 const lldb::addr_t new_file_offset =
@@ -1770,9 +1782,9 @@ void ObjectFileMachO::ProcessSegmentCommand(
   sect64.addr, // File VM address == addresses as they are
   // found in the object file
   sect64.size,   // VM size in bytes of this section
-  sect64.offset, // Offset to the data for this section in
+  section_file_offset, // Offset to the data for this section in
   // the file
-  sect64.offset ? sect64.size : 0, // Size in bytes of
+  section_file_offset ? sect64.size : 0, // Size in bytes of
   // this section as
   // found in the file
   sect64.align,
@@ -1792,14 +1804,14 @@ void ObjectFileMachO::ProcessSegmentCommand(
   SectionSP section_sp(new Section(
   segment_sp, module_sp, this, ++context.NextSectionIdx, section_name,
   sect_type, sect64.addr - segment_sp->GetFileAddress(), sect64.size,
-  sect64.offset, sect64.offset == 0 ? 0 : sect64.size, sect64.align,
-  sect64.flags));
+  section_file_offset, section_file_offset == 0 ? 0 : sect64.size,
+  sect64.align, sect64.flags));
   // Set the section to be encrypted to match the segment
 
   bool section_is_encrypted = false;
   if (!segment_is_encrypted && load_cmd.filesize != 0)
 section_is_encrypted = context.EncryptedRanges.FindEntryThatContains(
-   sect64.offset) != nullptr;
+   section_file_offset) != nullptr;
 
   section_sp->SetIsEncrypted(segment_i

[Lldb-commits] [lldb] [lldb] Refactor LLDB Breakpoint Event Notifications to centralize and eliminate code duplication (PR #164739)

2025-10-24 Thread Piyush Jaiswal via lldb-commits

https://github.com/piyushjaiswal98 updated 
https://github.com/llvm/llvm-project/pull/164739

>From e04bbb2579b91a08a99fd208739a17313de969ab Mon Sep 17 00:00:00 2001
From: Piyush Jaiswal 
Date: Wed, 22 Oct 2025 17:37:29 -0700
Subject: [PATCH 1/4] Refactor Breakpoint event notification

---
 lldb/include/lldb/Target/Target.h | 15 +++
 lldb/source/Breakpoint/Breakpoint.cpp | 11 ---
 lldb/source/Breakpoint/BreakpointList.cpp |  7 +--
 lldb/source/Breakpoint/BreakpointLocation.cpp |  6 ++
 lldb/source/Target/Target.cpp | 17 +
 5 files changed, 39 insertions(+), 17 deletions(-)

diff --git a/lldb/include/lldb/Target/Target.h 
b/lldb/include/lldb/Target/Target.h
index f4a09237ce897..88267c3ab74f8 100644
--- a/lldb/include/lldb/Target/Target.h
+++ b/lldb/include/lldb/Target/Target.h
@@ -1346,6 +1346,21 @@ class Target : public 
std::enable_shared_from_this,
const lldb_private::RegisterFlags &flags,
uint32_t byte_size);
 
+  /// Sends a breakpoint notification event if any listener is registered.
+  /// \param[in] bp
+  /// The breakpoint that was hit.
+  /// \param[in] eventKind
+  /// The kind of event that occurred.
+  void NotifyBreakpointChanged(Breakpoint &bp,
+   lldb::BreakpointEventType eventKind);
+  /// Sends a breakpoint notification event if any listener is registered.
+  /// \param[in] bp
+  /// The breakpoint that was hit.
+  /// \param[in] data
+  /// The data associated with the event.
+  void NotifyBreakpointChanged(Breakpoint &bp,
+   const lldb::EventDataSP &breakpoint_data_sp);
+
   llvm::Expected
   ReadInstructions(const Address &start_addr, uint32_t count,
const char *flavor_string = nullptr);
diff --git a/lldb/source/Breakpoint/Breakpoint.cpp 
b/lldb/source/Breakpoint/Breakpoint.cpp
index b23d1143d60c4..9306335888d77 100644
--- a/lldb/source/Breakpoint/Breakpoint.cpp
+++ b/lldb/source/Breakpoint/Breakpoint.cpp
@@ -1099,12 +1099,11 @@ bool 
Breakpoint::EvaluatePrecondition(StoppointCallbackContext &context) {
 
 void Breakpoint::SendBreakpointChangedEvent(
 lldb::BreakpointEventType eventKind) {
-  if (!IsInternal() && GetTarget().EventTypeHasListeners(
-   Target::eBroadcastBitBreakpointChanged)) {
+  if (!IsInternal()) {
 std::shared_ptr data =
 std::make_shared(eventKind, shared_from_this());
 
-GetTarget().BroadcastEvent(Target::eBroadcastBitBreakpointChanged, data);
+GetTarget().NotifyBreakpointChanged(*this, eventKind);
   }
 }
 
@@ -1113,10 +1112,8 @@ void Breakpoint::SendBreakpointChangedEvent(
   if (!breakpoint_data_sp)
 return;
 
-  if (!IsInternal() &&
-  
GetTarget().EventTypeHasListeners(Target::eBroadcastBitBreakpointChanged))
-GetTarget().BroadcastEvent(Target::eBroadcastBitBreakpointChanged,
-   breakpoint_data_sp);
+  if (!IsInternal())
+GetTarget().NotifyBreakpointChanged(*this, breakpoint_data_sp);
 }
 
 const char *Breakpoint::BreakpointEventTypeAsCString(BreakpointEventType type) 
{
diff --git a/lldb/source/Breakpoint/BreakpointList.cpp 
b/lldb/source/Breakpoint/BreakpointList.cpp
index 779490ae0316a..8fb01e97c40ca 100644
--- a/lldb/source/Breakpoint/BreakpointList.cpp
+++ b/lldb/source/Breakpoint/BreakpointList.cpp
@@ -17,12 +17,7 @@ using namespace lldb_private;
 
 static void NotifyChange(const BreakpointSP &bp, BreakpointEventType event) {
   Target &target = bp->GetTarget();
-  if (target.EventTypeHasListeners(Target::eBroadcastBitBreakpointChanged)) {
-auto event_data_sp =
-std::make_shared(event, bp);
-target.BroadcastEvent(Target::eBroadcastBitBreakpointChanged,
-  event_data_sp);
-  }
+  target.NotifyBreakpointChanged(*bp, event);
 }
 
 BreakpointList::BreakpointList(bool is_internal)
diff --git a/lldb/source/Breakpoint/BreakpointLocation.cpp 
b/lldb/source/Breakpoint/BreakpointLocation.cpp
index 22c98acda8c59..f25209c15e007 100644
--- a/lldb/source/Breakpoint/BreakpointLocation.cpp
+++ b/lldb/source/Breakpoint/BreakpointLocation.cpp
@@ -749,13 +749,11 @@ void BreakpointLocation::Dump(Stream *s) const {
 
 void BreakpointLocation::SendBreakpointLocationChangedEvent(
 lldb::BreakpointEventType eventKind) {
-  if (!m_owner.IsInternal() && m_owner.GetTarget().EventTypeHasListeners(
-   Target::eBroadcastBitBreakpointChanged)) {
+  if (!m_owner.IsInternal()) {
 auto data_sp = std::make_shared(
 eventKind, m_owner.shared_from_this());
 data_sp->GetBreakpointLocationCollection().Add(shared_from_this());
-m_owner.GetTarget().BroadcastEvent(Target::eBroadcastBitBreakpointChanged,
-   data_sp);
+m_owner.GetTarget().NotifyBreakpointChanged(m_owner, data_sp);
   }
 }
 
diff --git a/lldb/source/Target/Target.cpp

[Lldb-commits] [lldb] [lldb] Refactor LLDB Breakpoint Event Notifications to centralize and eliminate code duplication (PR #164739)

2025-10-24 Thread Piyush Jaiswal via lldb-commits

https://github.com/piyushjaiswal98 updated 
https://github.com/llvm/llvm-project/pull/164739

>From e04bbb2579b91a08a99fd208739a17313de969ab Mon Sep 17 00:00:00 2001
From: Piyush Jaiswal 
Date: Wed, 22 Oct 2025 17:37:29 -0700
Subject: [PATCH 1/4] Refactor Breakpoint event notification

---
 lldb/include/lldb/Target/Target.h | 15 +++
 lldb/source/Breakpoint/Breakpoint.cpp | 11 ---
 lldb/source/Breakpoint/BreakpointList.cpp |  7 +--
 lldb/source/Breakpoint/BreakpointLocation.cpp |  6 ++
 lldb/source/Target/Target.cpp | 17 +
 5 files changed, 39 insertions(+), 17 deletions(-)

diff --git a/lldb/include/lldb/Target/Target.h 
b/lldb/include/lldb/Target/Target.h
index f4a09237ce897..88267c3ab74f8 100644
--- a/lldb/include/lldb/Target/Target.h
+++ b/lldb/include/lldb/Target/Target.h
@@ -1346,6 +1346,21 @@ class Target : public 
std::enable_shared_from_this,
const lldb_private::RegisterFlags &flags,
uint32_t byte_size);
 
+  /// Sends a breakpoint notification event if any listener is registered.
+  /// \param[in] bp
+  /// The breakpoint that was hit.
+  /// \param[in] eventKind
+  /// The kind of event that occurred.
+  void NotifyBreakpointChanged(Breakpoint &bp,
+   lldb::BreakpointEventType eventKind);
+  /// Sends a breakpoint notification event if any listener is registered.
+  /// \param[in] bp
+  /// The breakpoint that was hit.
+  /// \param[in] data
+  /// The data associated with the event.
+  void NotifyBreakpointChanged(Breakpoint &bp,
+   const lldb::EventDataSP &breakpoint_data_sp);
+
   llvm::Expected
   ReadInstructions(const Address &start_addr, uint32_t count,
const char *flavor_string = nullptr);
diff --git a/lldb/source/Breakpoint/Breakpoint.cpp 
b/lldb/source/Breakpoint/Breakpoint.cpp
index b23d1143d60c4..9306335888d77 100644
--- a/lldb/source/Breakpoint/Breakpoint.cpp
+++ b/lldb/source/Breakpoint/Breakpoint.cpp
@@ -1099,12 +1099,11 @@ bool 
Breakpoint::EvaluatePrecondition(StoppointCallbackContext &context) {
 
 void Breakpoint::SendBreakpointChangedEvent(
 lldb::BreakpointEventType eventKind) {
-  if (!IsInternal() && GetTarget().EventTypeHasListeners(
-   Target::eBroadcastBitBreakpointChanged)) {
+  if (!IsInternal()) {
 std::shared_ptr data =
 std::make_shared(eventKind, shared_from_this());
 
-GetTarget().BroadcastEvent(Target::eBroadcastBitBreakpointChanged, data);
+GetTarget().NotifyBreakpointChanged(*this, eventKind);
   }
 }
 
@@ -1113,10 +1112,8 @@ void Breakpoint::SendBreakpointChangedEvent(
   if (!breakpoint_data_sp)
 return;
 
-  if (!IsInternal() &&
-  
GetTarget().EventTypeHasListeners(Target::eBroadcastBitBreakpointChanged))
-GetTarget().BroadcastEvent(Target::eBroadcastBitBreakpointChanged,
-   breakpoint_data_sp);
+  if (!IsInternal())
+GetTarget().NotifyBreakpointChanged(*this, breakpoint_data_sp);
 }
 
 const char *Breakpoint::BreakpointEventTypeAsCString(BreakpointEventType type) 
{
diff --git a/lldb/source/Breakpoint/BreakpointList.cpp 
b/lldb/source/Breakpoint/BreakpointList.cpp
index 779490ae0316a..8fb01e97c40ca 100644
--- a/lldb/source/Breakpoint/BreakpointList.cpp
+++ b/lldb/source/Breakpoint/BreakpointList.cpp
@@ -17,12 +17,7 @@ using namespace lldb_private;
 
 static void NotifyChange(const BreakpointSP &bp, BreakpointEventType event) {
   Target &target = bp->GetTarget();
-  if (target.EventTypeHasListeners(Target::eBroadcastBitBreakpointChanged)) {
-auto event_data_sp =
-std::make_shared(event, bp);
-target.BroadcastEvent(Target::eBroadcastBitBreakpointChanged,
-  event_data_sp);
-  }
+  target.NotifyBreakpointChanged(*bp, event);
 }
 
 BreakpointList::BreakpointList(bool is_internal)
diff --git a/lldb/source/Breakpoint/BreakpointLocation.cpp 
b/lldb/source/Breakpoint/BreakpointLocation.cpp
index 22c98acda8c59..f25209c15e007 100644
--- a/lldb/source/Breakpoint/BreakpointLocation.cpp
+++ b/lldb/source/Breakpoint/BreakpointLocation.cpp
@@ -749,13 +749,11 @@ void BreakpointLocation::Dump(Stream *s) const {
 
 void BreakpointLocation::SendBreakpointLocationChangedEvent(
 lldb::BreakpointEventType eventKind) {
-  if (!m_owner.IsInternal() && m_owner.GetTarget().EventTypeHasListeners(
-   Target::eBroadcastBitBreakpointChanged)) {
+  if (!m_owner.IsInternal()) {
 auto data_sp = std::make_shared(
 eventKind, m_owner.shared_from_this());
 data_sp->GetBreakpointLocationCollection().Add(shared_from_this());
-m_owner.GetTarget().BroadcastEvent(Target::eBroadcastBitBreakpointChanged,
-   data_sp);
+m_owner.GetTarget().NotifyBreakpointChanged(m_owner, data_sp);
   }
 }
 
diff --git a/lldb/source/Target/Target.cpp

[Lldb-commits] [lldb] [lldb] Refactor LLDB Breakpoint Event Notifications to centralize and eliminate code duplication (PR #164739)

2025-10-24 Thread Piyush Jaiswal via lldb-commits


@@ -1346,6 +1346,13 @@ class Target : public 
std::enable_shared_from_this,
const lldb_private::RegisterFlags &flags,
uint32_t byte_size);
 
+  /// Sends a breakpoint notification event if any listener is registered.

piyushjaiswal98 wrote:

Makes senseUpdated

https://github.com/llvm/llvm-project/pull/164739
___
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] Enable LLDB to load large dSYM files. (PR #164471)

2025-10-24 Thread Ellis Hoag via lldb-commits


@@ -1697,6 +1701,15 @@ void ObjectFileMachO::ProcessSegmentCommand(
 // isn't stored in the abstracted Sections.
 m_mach_sections.push_back(sect64);
 
+// Make sure we can load sections in mach-o files where some sections cross
+// a 4GB boundary. llvm::MachO::section_64 have only 32 bit file offsets
+// for the file offset of the section contents, so we need to track and
+// sections that overflow and adjust the offsets accordingly.
+const uint64_t section_file_offset = sect64.offset + section_offset_adjust;
+const uint64_t end_section_offset = (uint64_t)sect64.offset + sect64.size;

ellishg wrote:

Do we need to convert `sect64.offset` to `uint64_t`? And if we do, why not do 
the same on the line before?
```suggestion
const uint64_t section_file_offset = sect64.offset + section_offset_adjust;
const uint64_t end_section_offset = sect64.offset + sect64.size;
```

https://github.com/llvm/llvm-project/pull/164471
___
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] Enable LLDB to load large dSYM files. (PR #164471)

2025-10-24 Thread Peter Rong via lldb-commits


@@ -1697,6 +1701,15 @@ void ObjectFileMachO::ProcessSegmentCommand(
 // isn't stored in the abstracted Sections.
 m_mach_sections.push_back(sect64);
 
+// Make sure we can load sections in mach-o files where some sections cross
+// a 4GB boundary. llvm::MachO::section_64 have only 32 bit file offsets
+// for the file offset of the section contents, so we need to track and
+// sections that overflow and adjust the offsets accordingly.
+const uint64_t section_file_offset = sect64.offset + section_offset_adjust;
+const uint64_t end_section_offset = (uint64_t)sect64.offset + sect64.size;

DataCorrupted wrote:

I believe both should be converted.
```suggestion
const uint64_t section_file_offset = (uint64_t)sect64.offset + 
section_offset_adjust;
const uint64_t end_section_offset = (uint64_t)sect64.offset + sect64.size;
```

https://github.com/llvm/llvm-project/pull/164471
___
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb] Introduce internal stop hooks (PR #164506)

2025-10-24 Thread Julian Lettner via lldb-commits

https://github.com/yln updated https://github.com/llvm/llvm-project/pull/164506

>From 5f6caec8cbd40aa92233045e231ee791b6fba136 Mon Sep 17 00:00:00 2001
From: Julian Lettner 
Date: Tue, 21 Oct 2025 14:23:17 -0700
Subject: [PATCH 1/6] [lldb] Introduce internal stop hooks

Introduce the concept of internal stop hooks.
These are similar to LLDB's internal breakpoints:
LLDB itself will add them and users of LLDB will
not be able to add or remove them.

This change adds the following 3
independently-useful concepts:
* Maintain a list of internal stop hooks that will
  be populated by LLDB and cannot be added to or
  removed from by users.  They are managed in a
  separate list in
  `Target::m_internal_stop_hooks`.
* `StopHookKind:CodeBased` and `StopHookCoded`
  represent a stop hook defined by a C++ code
  callback (instead of command line expressions or
  a Python class).
* Stop hooks that do not print any output can now
  also suppress the printing of their header and
  description when they are hit via
  `StopHook::GetSuppressOutput`.

Combining these 3 concepts we can model "internal
stop hooks" which serve the same function as
LLDB's internal breakpoints: executing built-in,
LLDB-defined behavior, leveraging the existing
mechanism of stop hooks.

This change also simplifies
`Target::RunStopHooks`.  We already have to
materialize a new list for combining internal and
user stop hooks.  Filter and only add active hooks
to this list to avoid the need for "isActive?"
checks later on.
---
 lldb/include/lldb/Target/Target.h | 63 +++
 lldb/source/Target/Target.cpp | 60 +
 2 files changed, 91 insertions(+), 32 deletions(-)

diff --git a/lldb/include/lldb/Target/Target.h 
b/lldb/include/lldb/Target/Target.h
index f4a09237ce897..e745cb93eae9a 100644
--- a/lldb/include/lldb/Target/Target.h
+++ b/lldb/include/lldb/Target/Target.h
@@ -1356,7 +1356,11 @@ class Target : public 
std::enable_shared_from_this,
 StopHook(const StopHook &rhs);
 virtual ~StopHook() = default;
 
-enum class StopHookKind  : uint32_t { CommandBased = 0, ScriptBased };
+enum class StopHookKind : uint32_t {
+  CommandBased = 0,
+  ScriptBased,
+  CodeBased,
+};
 enum class StopHookResult : uint32_t {
   KeepStopped = 0,
   RequestContinue,
@@ -1403,6 +1407,12 @@ class Target : public 
std::enable_shared_from_this,
 
 bool GetRunAtInitialStop() const { return m_at_initial_stop; }
 
+void SetSuppressOutput(bool suppress_output) {
+  m_suppress_output = suppress_output;
+}
+
+bool GetSuppressOutput() const { return m_suppress_output; }
+
 void GetDescription(Stream &s, lldb::DescriptionLevel level) const;
 virtual void GetSubclassDescription(Stream &s,
 lldb::DescriptionLevel level) const = 
0;
@@ -1414,6 +1424,7 @@ class Target : public 
std::enable_shared_from_this,
 bool m_active = true;
 bool m_auto_continue = false;
 bool m_at_initial_stop = true;
+bool m_suppress_output = false;
 
 StopHook(lldb::TargetSP target_sp, lldb::user_id_t uid);
   };
@@ -1433,7 +1444,7 @@ class Target : public 
std::enable_shared_from_this,
 
   private:
 StringList m_commands;
-// Use CreateStopHook to make a new empty stop hook. The GetCommandPointer
+// Use CreateStopHook to make a new empty stop hook. The 
SetActionFromString
 // and fill it with commands, and SetSpecifier to set the specifier shared
 // pointer (can be null, that will match anything.)
 StopHookCommandLine(lldb::TargetSP target_sp, lldb::user_id_t uid)
@@ -1460,19 +1471,56 @@ class Target : public 
std::enable_shared_from_this,
 StructuredDataImpl m_extra_args;
 lldb::ScriptedStopHookInterfaceSP m_interface_sp;
 
-/// Use CreateStopHook to make a new empty stop hook. The GetCommandPointer
-/// and fill it with commands, and SetSpecifier to set the specifier shared
-/// pointer (can be null, that will match anything.)
+/// Use CreateStopHook to make a new empty stop hook. Use SetScriptCallback
+/// to set the script to execute, and SetSpecifier to set the specifier
+/// shared pointer (can be null, that will match anything.)
 StopHookScripted(lldb::TargetSP target_sp, lldb::user_id_t uid)
 : StopHook(target_sp, uid) {}
 friend class Target;
   };
 
+  class StopHookCoded : public StopHook {
+  public:
+~StopHookCoded() override = default;
+
+using HandleStopCallback = StopHookResult(ExecutionContext &exc_ctx,
+  lldb::StreamSP output);
+
+void SetCallback(llvm::StringRef name, HandleStopCallback *callback) {
+  m_name = name;
+  m_callback = callback;
+}
+
+StopHookResult HandleStop(ExecutionContext &exc_ctx,
+  lldb::StreamSP output) override {
+  return m_callback(exc_ctx, output);
+}
+
+void GetSubclassDescription(Stream &s,
+

[Lldb-commits] [lldb] [lldb][windows] print an error if python.dll is not in the DLL search path (PR #164893)

2025-10-24 Thread Martin Storsjö via lldb-commits


@@ -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}")

mstorsjo wrote:

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.

https://github.com/llvm/llvm-project/pull/164893
___
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb][windows] print an error if python.dll is not in the DLL search path (PR #164893)

2025-10-24 Thread Martin Storsjö via lldb-commits


@@ -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

mstorsjo wrote:

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?

https://github.com/llvm/llvm-project/pull/164893
___
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb][windows] print an error if python.dll is not in the DLL search path (PR #164893)

2025-10-24 Thread Martin Storsjö via lldb-commits

mstorsjo wrote:

> 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.

https://github.com/llvm/llvm-project/pull/164893
___
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb][windows] print an error if python.dll is not in the DLL search path (PR #164893)

2025-10-24 Thread via lldb-commits

Nerixyz wrote:

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

According to the documentation of 
[`FindPython3.cmake`](https://cmake.org/cmake/help/latest/module/FindPython3.html#artifacts-specification),
 this should be in `Python3_SABI_LIBRARY`.

https://github.com/llvm/llvm-project/pull/164893
___
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] Avoid stalls when MainLoop::Interrupt fails to wake up the MainLoop (PR #164905)

2025-10-24 Thread Alex Langford via lldb-commits

https://github.com/bulbazord edited 
https://github.com/llvm/llvm-project/pull/164905
___
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] Avoid stalls when MainLoop::Interrupt fails to wake up the MainLoop (PR #164905)

2025-10-24 Thread Alex Langford via lldb-commits

https://github.com/bulbazord approved this pull request.

Premise makes sense to me. With the limited scope of this change, I don't have 
any objections. I left one minor suggestion otherwise.

https://github.com/llvm/llvm-project/pull/164905
___
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] Avoid stalls when MainLoop::Interrupt fails to wake up the MainLoop (PR #164905)

2025-10-24 Thread Alex Langford via lldb-commits


@@ -387,10 +387,13 @@ void MainLoopPosix::ProcessSignal(int signo) {
   }
 }
 
-void MainLoopPosix::Interrupt() {
+bool MainLoopPosix::Interrupt() {
   if (m_interrupting.exchange(true))
-return;
+return true;
 
   char c = '.';
-  cantFail(m_interrupt_pipe.Write(&c, 1));
+  llvm::Expected result = m_interrupt_pipe.Write(&c, 1);
+  if (result && *result != 0)
+return true;
+  return false;

bulbazord wrote:

Minor Suggestion: `return result && *result != 0`

https://github.com/llvm/llvm-project/pull/164905
___
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] 4e7a845 - [lldb] Improve error logging in test (NFC)

2025-10-24 Thread Adrian Prantl via lldb-commits

Author: Adrian Prantl
Date: 2025-10-24T11:29:11-07:00
New Revision: 4e7a8456b316bb20874cc1343747b36869eab7a2

URL: 
https://github.com/llvm/llvm-project/commit/4e7a8456b316bb20874cc1343747b36869eab7a2
DIFF: 
https://github.com/llvm/llvm-project/commit/4e7a8456b316bb20874cc1343747b36869eab7a2.diff

LOG: [lldb] Improve error logging in test (NFC)

Added: 


Modified: 
lldb/test/API/macosx/posix_spawn/TestLaunchProcessPosixSpawn.py

Removed: 




diff  --git a/lldb/test/API/macosx/posix_spawn/TestLaunchProcessPosixSpawn.py 
b/lldb/test/API/macosx/posix_spawn/TestLaunchProcessPosixSpawn.py
index ffb6ef0fe4a18..8a321b2ff6324 100644
--- a/lldb/test/API/macosx/posix_spawn/TestLaunchProcessPosixSpawn.py
+++ b/lldb/test/API/macosx/posix_spawn/TestLaunchProcessPosixSpawn.py
@@ -36,9 +36,11 @@ def no_apple_silicon(self):
 
 def run_arch(self, exe, arch):
 self.runCmd("target create -arch {} {}".format(arch, exe))
-self.runCmd("run")
-
-process = self.dbg.GetSelectedTarget().process
+target = self.dbg.GetSelectedTarget()
+launch_info = target.GetLaunchInfo()
+error = lldb.SBError()
+process = target.Launch(launch_info, error)
+self.assertTrue(error.Success, str(error))
 self.assertState(process.GetState(), lldb.eStateExited)
 self.assertIn("slice: {}".format(arch), process.GetSTDOUT(1000))
 



___
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb] Introduce internal stop hooks (PR #164506)

2025-10-24 Thread Julian Lettner via lldb-commits


@@ -3098,6 +3107,23 @@ void Target::SetAllStopHooksActiveState(bool 
active_state) {
   }
 }
 
+// FIXME:  Ideally we would like to return a `const &` (const reference) 
instead

yln wrote:

```
typedef std::map StopHookCollection;
StopHookCollection m_stop_hooks;
```
Iteration order of `std::map` is defined by its keys (ascending).

Previously, we were *also* using `std::map` iteration order, just in a really 
convoluted/inefficient way:
```
size_t GetNumStopHooks() const { return m_stop_hooks.size(); }

StopHookSP GetStopHookAtIndex(size_t index) {  // <<< this is 0-based index, 
not the "user ID"
  if (index >= GetNumStopHooks())
return StopHookSP();
  StopHookCollection::iterator pos = m_stop_hooks.begin();   // <<< std::map 
iterator

  while (index > 0) {
pos++;
index--;
  }
  return (*pos).second;
}

// Call sites:
  size_t num_hooks = target.GetNumStopHooks(); 
  for (size_t i = 0; i < num_hooks; i++) {
Target::StopHookSP hook = target.GetStopHookAtIndex(i);
...
  }
```



https://github.com/llvm/llvm-project/pull/164506
___
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb][windows] print an error if python.dll is not in the DLL search path (PR #164893)

2025-10-24 Thread Charles Zablit via lldb-commits

charles-zablit wrote:

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

https://github.com/llvm/llvm-project/pull/164893
___
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb] Introduce internal stop hooks (PR #164506)

2025-10-24 Thread Julian Lettner via lldb-commits


@@ -3098,6 +3107,23 @@ void Target::SetAllStopHooksActiveState(bool 
active_state) {
   }
 }
 
+// FIXME:  Ideally we would like to return a `const &` (const reference) 
instead

yln wrote:

Added new test to pin down the behavior: 27b1441d3e27a12a4
Made sure it goes red when order is messed up, for example:
```
for (auto &[_, hook] : llvm::reverse(m_stop_hooks))
stop_hooks.push_back(hook);
```

https://github.com/llvm/llvm-project/pull/164506
___
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb] Introduce internal stop hooks (PR #164506)

2025-10-24 Thread via lldb-commits

https://github.com/jimingham approved this pull request.

LGTM

https://github.com/llvm/llvm-project/pull/164506
___
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] Add a `breakpoint add` command to fix the option-madness that is `breakpoint set` (PR #156067)

2025-10-24 Thread via lldb-commits

jimingham wrote:

Gentle ping to reviewers...

https://github.com/llvm/llvm-project/pull/156067
___
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] Enable LLDB to load large dSYM files. (PR #164471)

2025-10-24 Thread Daniel Rodríguez Troitiño via lldb-commits

https://github.com/drodriguez edited 
https://github.com/llvm/llvm-project/pull/164471
___
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] Enable LLDB to load large dSYM files. (PR #164471)

2025-10-24 Thread Daniel Rodríguez Troitiño via lldb-commits


@@ -1697,6 +1701,15 @@ void ObjectFileMachO::ProcessSegmentCommand(
 // isn't stored in the abstracted Sections.
 m_mach_sections.push_back(sect64);
 
+// Make sure we can load sections in mach-o files where some sections cross
+// a 4GB boundary. llvm::MachO::section_64 have only 32 bit file offsets
+// for the file offset of the section contents, so we need to track and
+// sections that overflow and adjust the offsets accordingly.
+const uint64_t section_file_offset = sect64.offset + section_offset_adjust;
+const uint64_t end_section_offset = (uint64_t)sect64.offset + sect64.size;

drodriguez wrote:

The integer promotion rules quick in with that `+`. In the first line `uint32_t 
+ uint64_t`, so the left hand side is promoted to `uint64_t`. In the second 
line it would be `uint32_t + uint64_t` as well if the casting was not there, so 
the left hand would be promoted. The casting is not necessary, but I think it 
leaves clear the author knows what they are doing. I would like the consistency 
of both having or not having the casting, thought.

https://github.com/llvm/llvm-project/pull/164471
___
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] Enable LLDB to load large dSYM files. (PR #164471)

2025-10-24 Thread Daniel Rodríguez Troitiño via lldb-commits

https://github.com/drodriguez commented:

> I also tried to make a minimal yaml file that could create a large enough 
> file, but it complains when trying to emit the file as it runs into the 32 
> bit section offset limiation and refuses to make a bad mach-o file. So no 
> easy way to test this with yaml.

Since it is difficult to generate an invalid Mach-O, I wonder if in this case a 
compressed file that's mostly zeros can be added to the repository. Uncompress 
during the test, hope the contributor has the 4 GBs to spare, then delete as 
one of the last things on the test (because nobody wants a silly 4 GB in their 
system).

https://github.com/llvm/llvm-project/pull/164471
___
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb][windows] print an error if python.dll is not in the DLL search path (PR #164893)

2025-10-24 Thread Charles Zablit via lldb-commits

https://github.com/charles-zablit updated 
https://github.com/llvm/llvm-project/pull/164893

>From 3d2976b3e251bee88b9dee88fef0dcd9460dded2 Mon Sep 17 00:00:00 2001
From: Charles Zablit 
Date: Thu, 23 Oct 2025 13:48:29 -0700
Subject: [PATCH 1/5] [lldb][windows] print an error if python.dll is not in
 the DLL search path

---
 lldb/CMakeLists.txt  |  4 +++
 lldb/tools/driver/CMakeLists.txt |  3 +++
 lldb/tools/driver/Driver.cpp | 45 +---
 3 files changed, 42 insertions(+), 10 deletions(-)

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 ba004045b..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 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 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_PYT

[Lldb-commits] [lldb] [lldb][windows] print an error if python.dll is not in the DLL search path (PR #164893)

2025-10-24 Thread Charles Zablit via lldb-commits


@@ -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_RUNTIME_LIBRARY_FILENAME
+"Filename of Python's runtime library")
 
   foreach(var LLDB_PYTHON_RELATIVE_PATH LLDB_PYTHON_EXE_RELATIVE_PATH 
LLDB_PYTHON_EXT_SUFFIX)

charles-zablit wrote:

Removed it, thanks 👍 

https://github.com/llvm/llvm-project/pull/164893
___
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb][windows] print an error if python.dll is not in the DLL search path (PR #164893)

2025-10-24 Thread Charles Zablit via lldb-commits

https://github.com/charles-zablit updated 
https://github.com/llvm/llvm-project/pull/164893

>From 3d2976b3e251bee88b9dee88fef0dcd9460dded2 Mon Sep 17 00:00:00 2001
From: Charles Zablit 
Date: Thu, 23 Oct 2025 13:48:29 -0700
Subject: [PATCH 1/6] [lldb][windows] print an error if python.dll is not in
 the DLL search path

---
 lldb/CMakeLists.txt  |  4 +++
 lldb/tools/driver/CMakeLists.txt |  3 +++
 lldb/tools/driver/Driver.cpp | 45 +---
 3 files changed, 42 insertions(+), 10 deletions(-)

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 ba004045b..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 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 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_PYT

[Lldb-commits] [lldb] [lldb][windows] print an error if python.dll is not in the DLL search path (PR #164893)

2025-10-24 Thread via lldb-commits

github-actions[bot] wrote:




:warning: C/C++ code formatter, clang-format found issues in your code. 
:warning:



You can test this locally with the following command:


``bash
git-clang-format --diff origin/main HEAD --extensions cpp -- 
lldb/tools/driver/Driver.cpp --diff_from_common_commit
``

:warning:
The reproduction instructions above might return results for more than one PR
in a stack if you are using a stacked PR workflow. You can limit the results by
changing `origin/main` to the base branch/commit you want to compare against.
:warning:





View the diff from clang-format here.


``diff
diff --git a/lldb/tools/driver/Driver.cpp b/lldb/tools/driver/Driver.cpp
index 7fefa537b..96d9fc622 100644
--- a/lldb/tools/driver/Driver.cpp
+++ b/lldb/tools/driver/Driver.cpp
@@ -502,7 +502,7 @@ void SetupPythonRuntimeLibrary() {
 return;
 #endif
   llvm::errs() << "error: unable to find "
-<< LLDB_PYTHON_RUNTIME_LIBRARY_FILENAME << ".\n";
+   << LLDB_PYTHON_RUNTIME_LIBRARY_FILENAME << ".\n";
   return;
 #elif defined(LLDB_PYTHON_DLL_RELATIVE_PATH)
   if (!AddPythonDLLToSearchPath())

``




https://github.com/llvm/llvm-project/pull/164893
___
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb][DWARFASTParserClang] Added a check for the specialization existence (PR #154123)

2025-10-24 Thread Timur Golubovich via lldb-commits

tgs-sc wrote:

@DavidSpickett, Hi!
I am sorry to bother you third time in this week, but can you please also merge 
this PR as I don't have commit access?
@Michael137 approved it, and we were waiting when this one 
(https://github.com/llvm/llvm-project/pull/157674) would be merged. I thought 
that this patch was already merged, but actually it not yet.

https://github.com/llvm/llvm-project/pull/154123
___
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb][test] skip Lua tests when the Lua interpreter is not found (PR #164793)

2025-10-24 Thread Vincent Palatin via lldb-commits


@@ -158,7 +158,11 @@ def get_tests(self):
 return tests
 
 def test_lua_api(self):
-if "LUA_EXECUTABLE" not in os.environ or 
len(os.environ["LUA_EXECUTABLE"]) == 0:
+if (
+"LUA_EXECUTABLE" not in os.environ
+or len(os.environ["LUA_EXECUTABLE"]) == 0
+or "NOTFOUND" in os.environ["LUA_EXECUTABLE"]
+):

vpalatin wrote:

yes, it's a nicest and more generic way, I will update the patch.

By the way,  while verifying the patch for the maybe-exotic corner case, I 
noticed that `LUAANDSWIG_FOUND` is incorrectly defined (to `1`) too as the 
`find_package_handle_standard_args(LuaAndSwig` call in 
`lldb/cmake/modules/FindLuaAndSwig.cmake` is not checking the `LUA_EXECUTABLE` 
variable (which is `LUA_EXECUTABLE-NOTFOUND` in this case. I think it is worth 
adding too.

https://github.com/llvm/llvm-project/pull/164793
___
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb][test] skip Lua tests when the Lua interpreter is not found (PR #164793)

2025-10-24 Thread Vincent Palatin via lldb-commits

https://github.com/vpalatin updated 
https://github.com/llvm/llvm-project/pull/164793

>From 4e9d7a60d213e49370707708bfa9e9fb4e51537d Mon Sep 17 00:00:00 2001
From: Vincent Palatin 
Date: Thu, 23 Oct 2025 12:02:19 +0200
Subject: [PATCH] [lldb][test] skip Lua tests when the Lua interpreter is not
 found

When Swig is installed but not any Lua interpreter, the cmake script in
`lldb/cmake/modules/FindLuaAndSwig.cmake` will execute
`find_program(LUA_EXECUTABLE, ...)` and this will set the `LUA_EXECUTABLE`
variable to `LUA_EXECUTABLE-NOTFOUND`.

Ensure that in this case we are skipping the Lua tests requiring the
interpreter and the `LUAANDSWIG_FOUND` is not set.
---
 lldb/cmake/modules/FindLuaAndSwig.cmake | 1 +
 lldb/test/API/lua_api/TestLuaAPI.py | 4 +++-
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/lldb/cmake/modules/FindLuaAndSwig.cmake 
b/lldb/cmake/modules/FindLuaAndSwig.cmake
index 33fadb2a09740..c5df29e8d0a92 100644
--- a/lldb/cmake/modules/FindLuaAndSwig.cmake
+++ b/lldb/cmake/modules/FindLuaAndSwig.cmake
@@ -34,6 +34,7 @@ else()
 FOUND_VAR
   LUAANDSWIG_FOUND
 REQUIRED_VARS
+  LUA_EXECUTABLE
   LUA_LIBRARIES
   LUA_INCLUDE_DIR
   LUA_VERSION_MINOR
diff --git a/lldb/test/API/lua_api/TestLuaAPI.py 
b/lldb/test/API/lua_api/TestLuaAPI.py
index 4ac795d696425..e78ed9de72375 100644
--- a/lldb/test/API/lua_api/TestLuaAPI.py
+++ b/lldb/test/API/lua_api/TestLuaAPI.py
@@ -158,7 +158,9 @@ def get_tests(self):
 return tests
 
 def test_lua_api(self):
-if "LUA_EXECUTABLE" not in os.environ or 
len(os.environ["LUA_EXECUTABLE"]) == 0:
+if "LUA_EXECUTABLE" not in os.environ or not os.path.exists(
+os.environ["LUA_EXECUTABLE"]
+):
 self.skipTest("Lua API tests could not find Lua executable.")
 return
 lua_executable = os.environ["LUA_EXECUTABLE"]

___
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb][attempt #3] update lldb-server platform help parsing (PR #164904)

2025-10-24 Thread David Spickett via lldb-commits

DavidSpickett wrote:

I'll let Adrian approve or not since they had the problems with that specific 
test.

> Remove test that starts and listens on a socket to avoid timeout issues

We have API tests for lldb-server in `lldb/test/API/tools/lldb-server/` and 
there is a utility function `lldbutil.wait_for_file_on_target` you could use.

I'd rather have the tests that do work landed, but if you do want to recreate 
that test, that's the things to look at.

https://github.com/llvm/llvm-project/pull/164904
___
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb][attempt #3] update lldb-server platform help parsing (PR #164904)

2025-10-24 Thread David Spickett via lldb-commits

DavidSpickett wrote:

Added Adrian on review and removed the mentions in the PR description (which 
have a habit of persisting across forks).

https://github.com/llvm/llvm-project/pull/164904
___
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb][attempt #3] update lldb-server platform help parsing (PR #164904)

2025-10-24 Thread David Spickett via lldb-commits

https://github.com/DavidSpickett edited 
https://github.com/llvm/llvm-project/pull/164904
___
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb][windows] print an error if python.dll is not in the DLL search path (PR #164893)

2025-10-24 Thread Martin Storsjö via lldb-commits


@@ -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}")

mstorsjo wrote:

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`.

https://github.com/llvm/llvm-project/pull/164893
___
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb][windows] print an error if python.dll is not in the DLL search path (PR #164893)

2025-10-24 Thread Martin Storsjö via lldb-commits


@@ -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_RUNTIME_LIBRARY_FILENAME
+"Filename of Python's runtime library")
 
   foreach(var LLDB_PYTHON_RELATIVE_PATH LLDB_PYTHON_EXE_RELATIVE_PATH 
LLDB_PYTHON_EXT_SUFFIX)

mstorsjo wrote:

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.

https://github.com/llvm/llvm-project/pull/164893
___
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb][windows] print an error if python.dll is not in the DLL search path (PR #164893)

2025-10-24 Thread Martin Storsjö via lldb-commits

mstorsjo wrote:

> 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.

https://github.com/llvm/llvm-project/pull/164893
___
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb][windows] print an error if python.dll is not in the DLL search path (PR #164893)

2025-10-24 Thread Charles Zablit via lldb-commits

charles-zablit wrote:

@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?

https://github.com/llvm/llvm-project/pull/164893
___
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] Enable LLDB to load large dSYM files. (PR #164471)

2025-10-24 Thread Ellis Hoag via lldb-commits

https://github.com/ellishg approved this pull request.


https://github.com/llvm/llvm-project/pull/164471
___
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] Enable LLDB to load large dSYM files. (PR #164471)

2025-10-24 Thread Greg Clayton via lldb-commits

https://github.com/clayborg updated 
https://github.com/llvm/llvm-project/pull/164471

>From c6ef435f628b964949b72cd6b78199493be9dfa9 Mon Sep 17 00:00:00 2001
From: Greg Clayton 
Date: Tue, 21 Oct 2025 11:19:30 -0700
Subject: [PATCH 1/6] Enable LLDB to load large dSYM files.

llvm-dsymutil can produce mach-o files where some sections in __DWARF exceed 
the 4GB barrier and subsequent sections in the dSYM will be inaccessible 
because the mach-o section_64 structure only has a 32 bit file offset. This 
patch enables LLDB to load a large dSYM file by figuring out when this happens 
and properly adjusting the file offset of the LLDB sections.

I was unable to add a test as obj2yaml and yaml2obj are broken for mach-o files 
and they can't convert a yaml file back into a valid mach-o object file. Any 
suggestions for adding a test would be appreciated.
---
 .../ObjectFile/Mach-O/ObjectFileMachO.cpp | 26 ++-
 1 file changed, 19 insertions(+), 7 deletions(-)

diff --git a/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp 
b/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
index 9cdb8467bfc60..6878f7331e0f5 100644
--- a/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
+++ b/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
@@ -1674,6 +1674,10 @@ void ObjectFileMachO::ProcessSegmentCommand(
   uint32_t segment_sect_idx;
   const lldb::user_id_t first_segment_sectID = context.NextSectionIdx + 1;
 
+  // dSYM files can create sections whose data exceeds the 4GB barrier, but
+  // mach-o sections only have 32 bit offsets. So keep track of when we
+  // overflow and fix the sections offsets as we iterate.
+  uint64_t section_offset_adjust = 0;
   const uint32_t num_u32s = load_cmd.cmd == LC_SEGMENT ? 7 : 8;
   for (segment_sect_idx = 0; segment_sect_idx < load_cmd.nsects;
++segment_sect_idx) {
@@ -1697,6 +1701,14 @@ void ObjectFileMachO::ProcessSegmentCommand(
 // isn't stored in the abstracted Sections.
 m_mach_sections.push_back(sect64);
 
+// Make sure we can load dSYM files whose __DWARF sections exceed the 4GB
+// barrier. llvm::MachO::section_64 have only 32 bit file offsets for the
+// section contents.
+const uint64_t section_file_offset = sect64.offset + section_offset_adjust;
+// If this section overflows a 4GB barrier, then we need to adjust any
+// subsequent the section offsets.
+if (is_dsym && ((uint64_t)sect64.offset + sect64.size) >= UINT32_MAX)
+  section_offset_adjust += 0x1ull;
 if (add_section) {
   ConstString section_name(
   sect64.sectname, strnlen(sect64.sectname, sizeof(sect64.sectname)));
@@ -1736,13 +1748,13 @@ void ObjectFileMachO::ProcessSegmentCommand(
   }
 
   // Grow the section size as needed.
-  if (sect64.offset) {
+  if (section_file_offset) {
 const lldb::addr_t segment_min_file_offset =
 segment->GetFileOffset();
 const lldb::addr_t segment_max_file_offset =
 segment_min_file_offset + segment->GetFileSize();
 
-const lldb::addr_t section_min_file_offset = sect64.offset;
+const lldb::addr_t section_min_file_offset = section_file_offset;
 const lldb::addr_t section_max_file_offset =
 section_min_file_offset + sect64.size;
 const lldb::addr_t new_file_offset =
@@ -1770,9 +1782,9 @@ void ObjectFileMachO::ProcessSegmentCommand(
   sect64.addr, // File VM address == addresses as they are
   // found in the object file
   sect64.size,   // VM size in bytes of this section
-  sect64.offset, // Offset to the data for this section in
+  section_file_offset, // Offset to the data for this section in
   // the file
-  sect64.offset ? sect64.size : 0, // Size in bytes of
+  section_file_offset ? sect64.size : 0, // Size in bytes of
   // this section as
   // found in the file
   sect64.align,
@@ -1792,14 +1804,14 @@ void ObjectFileMachO::ProcessSegmentCommand(
   SectionSP section_sp(new Section(
   segment_sp, module_sp, this, ++context.NextSectionIdx, section_name,
   sect_type, sect64.addr - segment_sp->GetFileAddress(), sect64.size,
-  sect64.offset, sect64.offset == 0 ? 0 : sect64.size, sect64.align,
-  sect64.flags));
+  section_file_offset, section_file_offset == 0 ? 0 : sect64.size,
+  sect64.align, sect64.flags));
   // Set the section to be encrypted to match the segment
 
   bool section_is_encrypted = false;
   if (!segment_is_encrypted && load_cmd.filesize != 0)
 section_is_encrypted = context.EncryptedRanges.FindEntryThatContains(
-   sect64.offset) != nullptr;
+   section_file_offset) != nullptr;
 
   section_sp->SetIsEncrypted(segment_i

[Lldb-commits] [lldb] Enable LLDB to load large dSYM files. (PR #164471)

2025-10-24 Thread Greg Clayton via lldb-commits

https://github.com/clayborg updated 
https://github.com/llvm/llvm-project/pull/164471

>From 1673e1b93b9c4e5a99323ca9bdf8232c6d5fdfad Mon Sep 17 00:00:00 2001
From: Greg Clayton 
Date: Tue, 21 Oct 2025 11:19:30 -0700
Subject: [PATCH 1/4] Enable LLDB to load large dSYM files.

llvm-dsymutil can produce mach-o files where some sections in __DWARF exceed 
the 4GB barrier and subsequent sections in the dSYM will be inaccessible 
because the mach-o section_64 structure only has a 32 bit file offset. This 
patch enables LLDB to load a large dSYM file by figuring out when this happens 
and properly adjusting the file offset of the LLDB sections.

I was unable to add a test as obj2yaml and yaml2obj are broken for mach-o files 
and they can't convert a yaml file back into a valid mach-o object file. Any 
suggestions for adding a test would be appreciated.
---
 .../ObjectFile/Mach-O/ObjectFileMachO.cpp | 26 ++-
 1 file changed, 19 insertions(+), 7 deletions(-)

diff --git a/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp 
b/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
index 9cdb8467bfc60..6878f7331e0f5 100644
--- a/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
+++ b/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
@@ -1674,6 +1674,10 @@ void ObjectFileMachO::ProcessSegmentCommand(
   uint32_t segment_sect_idx;
   const lldb::user_id_t first_segment_sectID = context.NextSectionIdx + 1;
 
+  // dSYM files can create sections whose data exceeds the 4GB barrier, but
+  // mach-o sections only have 32 bit offsets. So keep track of when we
+  // overflow and fix the sections offsets as we iterate.
+  uint64_t section_offset_adjust = 0;
   const uint32_t num_u32s = load_cmd.cmd == LC_SEGMENT ? 7 : 8;
   for (segment_sect_idx = 0; segment_sect_idx < load_cmd.nsects;
++segment_sect_idx) {
@@ -1697,6 +1701,14 @@ void ObjectFileMachO::ProcessSegmentCommand(
 // isn't stored in the abstracted Sections.
 m_mach_sections.push_back(sect64);
 
+// Make sure we can load dSYM files whose __DWARF sections exceed the 4GB
+// barrier. llvm::MachO::section_64 have only 32 bit file offsets for the
+// section contents.
+const uint64_t section_file_offset = sect64.offset + section_offset_adjust;
+// If this section overflows a 4GB barrier, then we need to adjust any
+// subsequent the section offsets.
+if (is_dsym && ((uint64_t)sect64.offset + sect64.size) >= UINT32_MAX)
+  section_offset_adjust += 0x1ull;
 if (add_section) {
   ConstString section_name(
   sect64.sectname, strnlen(sect64.sectname, sizeof(sect64.sectname)));
@@ -1736,13 +1748,13 @@ void ObjectFileMachO::ProcessSegmentCommand(
   }
 
   // Grow the section size as needed.
-  if (sect64.offset) {
+  if (section_file_offset) {
 const lldb::addr_t segment_min_file_offset =
 segment->GetFileOffset();
 const lldb::addr_t segment_max_file_offset =
 segment_min_file_offset + segment->GetFileSize();
 
-const lldb::addr_t section_min_file_offset = sect64.offset;
+const lldb::addr_t section_min_file_offset = section_file_offset;
 const lldb::addr_t section_max_file_offset =
 section_min_file_offset + sect64.size;
 const lldb::addr_t new_file_offset =
@@ -1770,9 +1782,9 @@ void ObjectFileMachO::ProcessSegmentCommand(
   sect64.addr, // File VM address == addresses as they are
   // found in the object file
   sect64.size,   // VM size in bytes of this section
-  sect64.offset, // Offset to the data for this section in
+  section_file_offset, // Offset to the data for this section in
   // the file
-  sect64.offset ? sect64.size : 0, // Size in bytes of
+  section_file_offset ? sect64.size : 0, // Size in bytes of
   // this section as
   // found in the file
   sect64.align,
@@ -1792,14 +1804,14 @@ void ObjectFileMachO::ProcessSegmentCommand(
   SectionSP section_sp(new Section(
   segment_sp, module_sp, this, ++context.NextSectionIdx, section_name,
   sect_type, sect64.addr - segment_sp->GetFileAddress(), sect64.size,
-  sect64.offset, sect64.offset == 0 ? 0 : sect64.size, sect64.align,
-  sect64.flags));
+  section_file_offset, section_file_offset == 0 ? 0 : sect64.size,
+  sect64.align, sect64.flags));
   // Set the section to be encrypted to match the segment
 
   bool section_is_encrypted = false;
   if (!segment_is_encrypted && load_cmd.filesize != 0)
 section_is_encrypted = context.EncryptedRanges.FindEntryThatContains(
-   sect64.offset) != nullptr;
+   section_file_offset) != nullptr;
 
   section_sp->SetIsEncrypted(segment_i

[Lldb-commits] [lldb] Enable LLDB to load large dSYM files. (PR #164471)

2025-10-24 Thread Greg Clayton via lldb-commits

https://github.com/clayborg updated 
https://github.com/llvm/llvm-project/pull/164471

>From 1673e1b93b9c4e5a99323ca9bdf8232c6d5fdfad Mon Sep 17 00:00:00 2001
From: Greg Clayton 
Date: Tue, 21 Oct 2025 11:19:30 -0700
Subject: [PATCH 1/5] Enable LLDB to load large dSYM files.

llvm-dsymutil can produce mach-o files where some sections in __DWARF exceed 
the 4GB barrier and subsequent sections in the dSYM will be inaccessible 
because the mach-o section_64 structure only has a 32 bit file offset. This 
patch enables LLDB to load a large dSYM file by figuring out when this happens 
and properly adjusting the file offset of the LLDB sections.

I was unable to add a test as obj2yaml and yaml2obj are broken for mach-o files 
and they can't convert a yaml file back into a valid mach-o object file. Any 
suggestions for adding a test would be appreciated.
---
 .../ObjectFile/Mach-O/ObjectFileMachO.cpp | 26 ++-
 1 file changed, 19 insertions(+), 7 deletions(-)

diff --git a/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp 
b/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
index 9cdb8467bfc60..6878f7331e0f5 100644
--- a/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
+++ b/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
@@ -1674,6 +1674,10 @@ void ObjectFileMachO::ProcessSegmentCommand(
   uint32_t segment_sect_idx;
   const lldb::user_id_t first_segment_sectID = context.NextSectionIdx + 1;
 
+  // dSYM files can create sections whose data exceeds the 4GB barrier, but
+  // mach-o sections only have 32 bit offsets. So keep track of when we
+  // overflow and fix the sections offsets as we iterate.
+  uint64_t section_offset_adjust = 0;
   const uint32_t num_u32s = load_cmd.cmd == LC_SEGMENT ? 7 : 8;
   for (segment_sect_idx = 0; segment_sect_idx < load_cmd.nsects;
++segment_sect_idx) {
@@ -1697,6 +1701,14 @@ void ObjectFileMachO::ProcessSegmentCommand(
 // isn't stored in the abstracted Sections.
 m_mach_sections.push_back(sect64);
 
+// Make sure we can load dSYM files whose __DWARF sections exceed the 4GB
+// barrier. llvm::MachO::section_64 have only 32 bit file offsets for the
+// section contents.
+const uint64_t section_file_offset = sect64.offset + section_offset_adjust;
+// If this section overflows a 4GB barrier, then we need to adjust any
+// subsequent the section offsets.
+if (is_dsym && ((uint64_t)sect64.offset + sect64.size) >= UINT32_MAX)
+  section_offset_adjust += 0x1ull;
 if (add_section) {
   ConstString section_name(
   sect64.sectname, strnlen(sect64.sectname, sizeof(sect64.sectname)));
@@ -1736,13 +1748,13 @@ void ObjectFileMachO::ProcessSegmentCommand(
   }
 
   // Grow the section size as needed.
-  if (sect64.offset) {
+  if (section_file_offset) {
 const lldb::addr_t segment_min_file_offset =
 segment->GetFileOffset();
 const lldb::addr_t segment_max_file_offset =
 segment_min_file_offset + segment->GetFileSize();
 
-const lldb::addr_t section_min_file_offset = sect64.offset;
+const lldb::addr_t section_min_file_offset = section_file_offset;
 const lldb::addr_t section_max_file_offset =
 section_min_file_offset + sect64.size;
 const lldb::addr_t new_file_offset =
@@ -1770,9 +1782,9 @@ void ObjectFileMachO::ProcessSegmentCommand(
   sect64.addr, // File VM address == addresses as they are
   // found in the object file
   sect64.size,   // VM size in bytes of this section
-  sect64.offset, // Offset to the data for this section in
+  section_file_offset, // Offset to the data for this section in
   // the file
-  sect64.offset ? sect64.size : 0, // Size in bytes of
+  section_file_offset ? sect64.size : 0, // Size in bytes of
   // this section as
   // found in the file
   sect64.align,
@@ -1792,14 +1804,14 @@ void ObjectFileMachO::ProcessSegmentCommand(
   SectionSP section_sp(new Section(
   segment_sp, module_sp, this, ++context.NextSectionIdx, section_name,
   sect_type, sect64.addr - segment_sp->GetFileAddress(), sect64.size,
-  sect64.offset, sect64.offset == 0 ? 0 : sect64.size, sect64.align,
-  sect64.flags));
+  section_file_offset, section_file_offset == 0 ? 0 : sect64.size,
+  sect64.align, sect64.flags));
   // Set the section to be encrypted to match the segment
 
   bool section_is_encrypted = false;
   if (!segment_is_encrypted && load_cmd.filesize != 0)
 section_is_encrypted = context.EncryptedRanges.FindEntryThatContains(
-   sect64.offset) != nullptr;
+   section_file_offset) != nullptr;
 
   section_sp->SetIsEncrypted(segment_i

[Lldb-commits] [lldb] [lldb] Introduce internal stop hooks (PR #164506)

2025-10-24 Thread Julian Lettner via lldb-commits


@@ -1114,9 +1114,7 @@ class CommandObjectBreakpointList : public 
CommandObjectParsed {
   CommandObjectBreakpointList(CommandInterpreter &interpreter)
   : CommandObjectParsed(
 interpreter, "breakpoint list",
-"List some or all breakpoints at configurable levels of detail.",
-nullptr) {
-CommandArgumentData bp_id_arg;
+"List some or all breakpoints at configurable levels of detail.") {

yln wrote:

Yes, this was just a cleanup.

https://github.com/llvm/llvm-project/pull/164506
___
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [clang] [clang-tools-extra] [flang] [lldb] [llvm] [clang] Move options from clangDriver into new clangOptions library (NFC) (PR #163659)

2025-10-24 Thread Naveen Seth Hanig via lldb-commits

naveen-seth wrote:

Ping

https://github.com/llvm/llvm-project/pull/163659
___
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb] Introduce internal stop hooks (PR #164506)

2025-10-24 Thread via lldb-commits


@@ -3098,6 +3107,23 @@ void Target::SetAllStopHooksActiveState(bool 
active_state) {
   }
 }
 
+// FIXME:  Ideally we would like to return a `const &` (const reference) 
instead

jimingham wrote:

Are you sure that using the iterator of the map will preserve the order of the 
stop-hooks in this listing?  I'm not concerned about internal stop-hooks, but 
it wouldn't be good if you added a bunch of stop hooks, then deleted some, and 
then the order of the stop-hooks in the listing got scrambled.
Might be good to add a test to ensure that this ordering is maintained to 
ensure that.

https://github.com/llvm/llvm-project/pull/164506
___
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb] Refactor LLDB Breakpoint Event Notifications to centralize and eliminate code duplication (PR #164739)

2025-10-24 Thread via lldb-commits


@@ -1346,6 +1346,13 @@ class Target : public 
std::enable_shared_from_this,
const lldb_private::RegisterFlags &flags,
uint32_t byte_size);
 
+  /// Sends a breakpoint notification event if any listener is registered.

jimingham wrote:

Other than that comment comment, this looks fine to em.

https://github.com/llvm/llvm-project/pull/164739
___
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits