date:20250610

[Lldb-commits] [lldb] [lldb/cmake] Use ADDITIONAL_HEADER(_DIR)?S (PR #142587)

2025-06-10 Thread Pavel Labath via lldb-commits


https://github.com/labath updated 
https://github.com/llvm/llvm-project/pull/142587

>From e040dfb3270ca1101ec0c86d74dce26b2d10914a Mon Sep 17 00:00:00 2001
From: Pavel Labath 
Date: Tue, 3 Jun 2025 13:45:04 +0200
Subject: [PATCH] [lldb/cmake] Use ADDITIONAL_HEADER(_DIR)?S

Replace (questionable) header globs with an explicit argument supported
by llvm_add_library.
---
 lldb/CMakeLists.txt   |  2 ++
 lldb/cmake/modules/AddLLDB.cmake  |  8 +---
 lldb/source/API/CMakeLists.txt|  2 ++
 lldb/source/Breakpoint/CMakeLists.txt |  2 ++
 lldb/source/Core/CMakeLists.txt   |  5 +++--
 lldb/source/DataFormatters/CMakeLists.txt |  2 ++
 lldb/source/Expression/CMakeLists.txt |  2 ++
 lldb/source/Host/CMakeLists.txt   |  2 ++
 lldb/source/Host/macosx/objcxx/CMakeLists.txt |  2 ++
 lldb/source/Initialization/CMakeLists.txt |  2 ++
 lldb/source/Interpreter/CMakeLists.txt|  2 ++
 lldb/source/Interpreter/Interfaces/CMakeLists.txt |  2 ++
 lldb/source/Symbol/CMakeLists.txt |  2 ++
 lldb/source/Target/CMakeLists.txt |  2 ++
 lldb/source/Utility/CMakeLists.txt|  2 ++
 lldb/source/ValueObject/CMakeLists.txt|  2 ++
 lldb/source/Version/CMakeLists.txt| 15 +++
 17 files changed, 39 insertions(+), 17 deletions(-)

diff --git a/lldb/CMakeLists.txt b/lldb/CMakeLists.txt
index 85ba4fde17418..2aaf75dd87bc3 100644
--- a/lldb/CMakeLists.txt
+++ b/lldb/CMakeLists.txt
@@ -38,6 +38,8 @@ endif()
 include(LLDBConfig)
 include(AddLLDB)
 
+set(LLDB_INCLUDE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/include)
+
 # Define the LLDB_CONFIGURATION_xxx matching the build type.
 if(uppercase_CMAKE_BUILD_TYPE STREQUAL "DEBUG" )
   add_definitions(-DLLDB_CONFIGURATION_DEBUG)
diff --git a/lldb/cmake/modules/AddLLDB.cmake b/lldb/cmake/modules/AddLLDB.cmake
index 8b986bf037aac..0108fb22e5a03 100644
--- a/lldb/cmake/modules/AddLLDB.cmake
+++ b/lldb/cmake/modules/AddLLDB.cmake
@@ -68,12 +68,6 @@ function(add_lldb_library name)
 set_property(GLOBAL APPEND PROPERTY LLDB_PLUGINS ${name})
   endif()
 
-  if (MSVC_IDE OR XCODE)
-string(REGEX MATCHALL "/[^/]+" split_path ${CMAKE_CURRENT_SOURCE_DIR})
-list(GET split_path -1 dir)
-file(GLOB_RECURSE headers
-  ../../include/lldb${dir}/*.h)
-  endif()
   if (PARAM_MODULE)
 set(libkind MODULE)
   elseif (PARAM_SHARED)
@@ -92,7 +86,7 @@ function(add_lldb_library name)
 set(pass_NO_INSTALL_RPATH NO_INSTALL_RPATH)
   endif()
 
-  llvm_add_library(${name} ${libkind} ${headers}
+  llvm_add_library(${name} ${libkind}
 ${PARAM_UNPARSED_ARGUMENTS}
 LINK_LIBS ${PARAM_LINK_LIBS}
 ${pass_NO_INSTALL_RPATH}
diff --git a/lldb/source/API/CMakeLists.txt b/lldb/source/API/CMakeLists.txt
index cb5f1f831dac0..f5b25237d1edb 100644
--- a/lldb/source/API/CMakeLists.txt
+++ b/lldb/source/API/CMakeLists.txt
@@ -125,6 +125,8 @@ add_lldb_library(liblldb SHARED ${option_framework}
   ${lldb_python_wrapper}
   ${lldb_lua_wrapper}
 
+  ADDITIONAL_HEADER_DIRS
+${LLDB_INCLUDE_DIR}/lldb/API
   DEPENDS
 lldb-sbapi-dwarf-enums
 
diff --git a/lldb/source/Breakpoint/CMakeLists.txt 
b/lldb/source/Breakpoint/CMakeLists.txt
index d8f8f8cbd055e..de23c8737b324 100644
--- a/lldb/source/Breakpoint/CMakeLists.txt
+++ b/lldb/source/Breakpoint/CMakeLists.txt
@@ -26,6 +26,8 @@ add_lldb_library(lldbBreakpoint NO_PLUGIN_DEPENDENCIES
   WatchpointOptions.cpp
   WatchpointResource.cpp
 
+  ADDITIONAL_HEADER_DIRS
+${LLDB_INCLUDE_DIR}/lldb/Breakpoint
   LINK_COMPONENTS
 Support
   LINK_LIBS
diff --git a/lldb/source/Core/CMakeLists.txt b/lldb/source/Core/CMakeLists.txt
index 53dc031e90d11..d6b75bca7f2d6 100644
--- a/lldb/source/Core/CMakeLists.txt
+++ b/lldb/source/Core/CMakeLists.txt
@@ -57,10 +57,11 @@ add_lldb_library(lldbCore NO_PLUGIN_DEPENDENCIES
   ThreadedCommunication.cpp
   UserSettingsController.cpp
   Value.cpp
+
+  ADDITIONAL_HEADER_DIRS
+${LLDB_INCLUDE_DIR}/lldb/Core
   DEPENDS
 clang-tablegen-targets
-
-
   LINK_COMPONENTS
 Support
 Demangle
diff --git a/lldb/source/DataFormatters/CMakeLists.txt 
b/lldb/source/DataFormatters/CMakeLists.txt
index 097cbdb4526bc..5f84e4ef43d6b 100644
--- a/lldb/source/DataFormatters/CMakeLists.txt
+++ b/lldb/source/DataFormatters/CMakeLists.txt
@@ -18,6 +18,8 @@ add_lldb_library(lldbDataFormatters NO_PLUGIN_DEPENDENCIES
   ValueObjectPrinter.cpp
   VectorType.cpp
 
+  ADDITIONAL_HEADER_DIRS
+${LLDB_INCLUDE_DIR}/lldb/DataFormatters
   LINK_COMPONENTS
 Support
   LINK_LIBS
diff --git a/lldb/source/Expression/CMakeLists.txt 
b/lldb/source/Expression/CMakeLists.txt
index ac129ce49b5d3..08dc536781f9c 100644
--- a/lldb/source/Expression/CMakeLists.txt
+++ b/lldb/source/Expression/CMakeLists.txt
@@ -17,6 +17,8 @@ add_lldb_library(lldbExpression NO_PLUGIN_DEPENDENCIES
   UserExpression.cpp
   UtilityFunction.cpp
 
+  ADDITIONAL_

[Lldb-commits] [lldb] [lldb] Use 1 based row and column for statusline (PR #143385)

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


https://github.com/DavidSpickett closed 
https://github.com/llvm/llvm-project/pull/143385
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] 6ec48b4 - [lldb] Use 1 based row and column for statusline (#143385)

2025-06-10 Thread via lldb-commits


Author: David Spickett
Date: 2025-06-10T09:59:16+01:00
New Revision: 6ec48b449fb60a766d4faf185613f1b4a8638bfa

URL: 
https://github.com/llvm/llvm-project/commit/6ec48b449fb60a766d4faf185613f1b4a8638bfa
DIFF: 
https://github.com/llvm/llvm-project/commit/6ec48b449fb60a766d4faf185613f1b4a8638bfa.diff

LOG: [lldb] Use 1 based row and column for statusline (#143385)

I can't find a proper source for this but many materials say that ANSI
rows and columns start at 1 not 0.

https://www2.math.upenn.edu/~kazdan/210/computer/ansi.html is as good as
I can get:
```
 is a number from 1 through 25 that specifies the row to which the cursor 
is to be moved.
 is a number from 1 through 80 that specifies the column to which the 
cursor is to be moved.
```

0 does work in Windows terminal and Linux terminals, but we might as
well be correct and it's one less thing to reason about when auditing
this code.

>From what I read, some terminals correct 0 back to 1 and some treat 0 as
a missing argument, which also defaults to 1.

Added: 


Modified: 
lldb/source/Core/Statusline.cpp
lldb/test/API/functionalities/statusline/TestStatusline.py

Removed: 




diff  --git a/lldb/source/Core/Statusline.cpp b/lldb/source/Core/Statusline.cpp
index 52f6134123b76..8a8640805cac0 100644
--- a/lldb/source/Core/Statusline.cpp
+++ b/lldb/source/Core/Statusline.cpp
@@ -24,8 +24,8 @@
 #define ANSI_SAVE_CURSOR ESCAPE "7"
 #define ANSI_RESTORE_CURSOR ESCAPE "8"
 #define ANSI_CLEAR_BELOW ESCAPE "[J"
-#define ANSI_SET_SCROLL_ROWS ESCAPE "[0;%ur"
-#define ANSI_TO_START_OF_ROW ESCAPE "[%u;0f"
+#define ANSI_SET_SCROLL_ROWS ESCAPE "[1;%ur"
+#define ANSI_TO_START_OF_ROW ESCAPE "[%u;1f"
 #define ANSI_REVERSE_VIDEO ESCAPE "[7m"
 #define ANSI_UP_ROWS ESCAPE "[%dA"
 

diff  --git a/lldb/test/API/functionalities/statusline/TestStatusline.py 
b/lldb/test/API/functionalities/statusline/TestStatusline.py
index 53ac7432f4ba1..68c5ad3090cfd 100644
--- a/lldb/test/API/functionalities/statusline/TestStatusline.py
+++ b/lldb/test/API/functionalities/statusline/TestStatusline.py
@@ -44,7 +44,7 @@ def test(self):
 self.expect(
 "set set show-statusline true",
 [
-"\x1b[0;{}r".format(self.TERMINAL_HEIGHT - 1),
+"\x1b[1;{}r".format(self.TERMINAL_HEIGHT - 1),
 "a.out | main.c:2:11 | breakpoint 1.1",
 ],
 )
@@ -66,7 +66,7 @@ def test(self):
 
 # Hide the statusline and check or the control character.
 self.expect(
-"set set show-statusline false", 
["\x1b[0;{}r".format(self.TERMINAL_HEIGHT)]
+"set set show-statusline false", 
["\x1b[1;{}r".format(self.TERMINAL_HEIGHT)]
 )
 
 def test_no_color(self):



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [LLDB] WIP: Add type summaries for MSVC STL strings (PR #143177)

2025-06-10 Thread via lldb-commits


https://github.com/Nerixyz updated 
https://github.com/llvm/llvm-project/pull/143177

>From 938bc84e55cff4a5e852f0ea093e95418e9b4374 Mon Sep 17 00:00:00 2001
From: Nerixyz 
Date: Fri, 6 Jun 2025 19:23:04 +0200
Subject: [PATCH] [LLDB] Add type summaries for MSVC STL strings

---
 .../lldb/DataFormatters/StringPrinter.h   |  15 ++
 lldb/packages/Python/lldbsuite/test/dotest.py |  21 +++
 .../Python/lldbsuite/test/test_categories.py  |   1 +
 .../Plugins/Language/CPlusPlus/CMakeLists.txt |   1 +
 .../Language/CPlusPlus/CPlusPlusLanguage.cpp  | 114 +
 .../Language/CPlusPlus/CxxStringTypes.cpp | 158 +-
 .../Language/CPlusPlus/CxxStringTypes.h   |  35 
 .../Plugins/Language/CPlusPlus/LibCxx.cpp | 121 +-
 .../Plugins/Language/CPlusPlus/MsvcStl.cpp| 140 
 .../Plugins/Language/CPlusPlus/MsvcStl.h  |  33 
 .../string/TestDataFormatterLibcxxString.py   |   8 +-
 .../TestDataFormatterLibcxxStringView.py  |   8 +-
 .../msvcstl/string/Makefile   |   4 +
 .../string/TestDataFormatterStdString.py  | 117 +
 .../msvcstl/string/main.cpp   |  38 +
 .../msvcstl/u8string/Makefile |   4 +
 .../u8string/TestDataFormatterStdU8String.py  |  31 
 .../msvcstl/u8string/main.cpp |  14 ++
 18 files changed, 706 insertions(+), 157 deletions(-)
 create mode 100644 lldb/source/Plugins/Language/CPlusPlus/MsvcStl.cpp
 create mode 100644 lldb/source/Plugins/Language/CPlusPlus/MsvcStl.h
 create mode 100644 
lldb/test/API/functionalities/data-formatter/data-formatter-stl/msvcstl/string/Makefile
 create mode 100644 
lldb/test/API/functionalities/data-formatter/data-formatter-stl/msvcstl/string/TestDataFormatterStdString.py
 create mode 100644 
lldb/test/API/functionalities/data-formatter/data-formatter-stl/msvcstl/string/main.cpp
 create mode 100644 
lldb/test/API/functionalities/data-formatter/data-formatter-stl/msvcstl/u8string/Makefile
 create mode 100644 
lldb/test/API/functionalities/data-formatter/data-formatter-stl/msvcstl/u8string/TestDataFormatterStdU8String.py
 create mode 100644 
lldb/test/API/functionalities/data-formatter/data-formatter-stl/msvcstl/u8string/main.cpp

diff --git a/lldb/include/lldb/DataFormatters/StringPrinter.h 
b/lldb/include/lldb/DataFormatters/StringPrinter.h
index 4169f53e63f38..4ebe712be60e1 100644
--- a/lldb/include/lldb/DataFormatters/StringPrinter.h
+++ b/lldb/include/lldb/DataFormatters/StringPrinter.h
@@ -152,6 +152,21 @@ class StringPrinter {
   template 
   static bool
   ReadBufferAndDumpToStream(const ReadBufferAndDumpToStreamOptions &options);
+
+  template 
+  static constexpr uint64_t ElementByteSize() {
+switch (element_type) {
+case StringElementType::ASCII:
+case StringElementType::UTF8:
+  return 1;
+case StringElementType::UTF16:
+  return 2;
+case StringElementType::UTF32:
+  return 3;
+default:
+  return 0;
+}
+  }
 };
 
 } // namespace formatters
diff --git a/lldb/packages/Python/lldbsuite/test/dotest.py 
b/lldb/packages/Python/lldbsuite/test/dotest.py
index d7f274ac4f60e..7f15be206acb8 100644
--- a/lldb/packages/Python/lldbsuite/test/dotest.py
+++ b/lldb/packages/Python/lldbsuite/test/dotest.py
@@ -831,6 +831,26 @@ def checkLibstdcxxSupport():
 configuration.skip_categories.append("libstdcxx")
 
 
+def canRunMsvcStlTests():
+from lldbsuite.test import lldbplatformutil
+
+platform = lldbplatformutil.getPlatform()
+if platform == "windows":
+return True, "MSVC STL is present on Windows"
+return False, f"Don't know how to build with MSVC's STL on {platform}"
+
+
+def checkMsvcStlSupport():
+result, reason = canRunMsvcStlTests()
+if result:
+return  # msvcstl supported
+if "msvcstl" in configuration.categories_list:
+return  # msvcstl category explicitly requested, let it run.
+if configuration.verbose:
+print(f"msvcstl tests will not be run because: {reason}")
+configuration.skip_categories.append("msvcstl")
+
+
 def canRunWatchpointTests():
 from lldbsuite.test import lldbplatformutil
 
@@ -1044,6 +1064,7 @@ def run_suite():
 
 checkLibcxxSupport()
 checkLibstdcxxSupport()
+checkMsvcStlSupport()
 checkWatchpointSupport()
 checkDebugInfoSupport()
 checkDebugServerSupport()
diff --git a/lldb/packages/Python/lldbsuite/test/test_categories.py 
b/lldb/packages/Python/lldbsuite/test/test_categories.py
index b585f695adeab..1f6e8a78e0c0d 100644
--- a/lldb/packages/Python/lldbsuite/test/test_categories.py
+++ b/lldb/packages/Python/lldbsuite/test/test_categories.py
@@ -33,6 +33,7 @@
 "lldb-server": "Tests related to lldb-server",
 "lldb-dap": "Tests for the Debug Adapter Protocol with lldb-dap",
 "llgs": "Tests for the gdb-server functionality of lldb-server",
+"msvcstl": "Test for MSVC STL data formatters",
 "pexpect": "Tests requiring the pexpect library to be

[Lldb-commits] [lldb] [lldb] add plugin names to process save-core error output. (PR #143126)

2025-06-10 Thread Ebuka Ezike via lldb-commits


https://github.com/da-viper updated 
https://github.com/llvm/llvm-project/pull/143126

>From 95c61d6a917060d7b3a2bc554575eb6a1086ed6e Mon Sep 17 00:00:00 2001
From: Ebuka Ezike 
Date: Fri, 6 Jun 2025 13:15:41 +0100
Subject: [PATCH 1/4] [lldb] add plugin names to process save-core error
 output.

---
 lldb/include/lldb/Core/PluginManager.h |  2 ++
 lldb/source/Core/PluginManager.cpp | 10 ++
 lldb/source/Symbol/SaveCoreOptions.cpp | 22 --
 3 files changed, 32 insertions(+), 2 deletions(-)

diff --git a/lldb/include/lldb/Core/PluginManager.h 
b/lldb/include/lldb/Core/PluginManager.h
index e2f709ecd2ff7..7996dc3fdf3f3 100644
--- a/lldb/include/lldb/Core/PluginManager.h
+++ b/lldb/include/lldb/Core/PluginManager.h
@@ -212,6 +212,8 @@ class PluginManager {
   static Status SaveCore(const lldb::ProcessSP &process_sp,
  lldb_private::SaveCoreOptions &core_options);
 
+  static llvm::SmallVector GetSaveCorePluginNames();
+
   // ObjectContainer
   static bool RegisterPlugin(
   llvm::StringRef name, llvm::StringRef description,
diff --git a/lldb/source/Core/PluginManager.cpp 
b/lldb/source/Core/PluginManager.cpp
index de815e6308838..d02e3030081dc 100644
--- a/lldb/source/Core/PluginManager.cpp
+++ b/lldb/source/Core/PluginManager.cpp
@@ -800,6 +800,16 @@ Status PluginManager::SaveCore(const lldb::ProcessSP 
&process_sp,
   return error;
 }
 
+llvm::SmallVector PluginManager::GetSaveCorePluginNames() {
+  llvm::SmallVector plugin_names;
+  auto instances = GetObjectFileInstances().GetSnapshot();
+  for (auto &instance : instances) {
+if (instance.save_core)
+  plugin_names.emplace_back(instance.name);
+  }
+  return plugin_names;
+}
+
 #pragma mark ObjectContainer
 
 struct ObjectContainerInstance
diff --git a/lldb/source/Symbol/SaveCoreOptions.cpp 
b/lldb/source/Symbol/SaveCoreOptions.cpp
index d884b00a47b00..c1c85571c8a78 100644
--- a/lldb/source/Symbol/SaveCoreOptions.cpp
+++ b/lldb/source/Symbol/SaveCoreOptions.cpp
@@ -22,8 +22,26 @@ Status SaveCoreOptions::SetPluginName(const char *name) {
   }
 
   if (!PluginManager::IsRegisteredObjectFilePluginName(name)) {
-return Status::FromErrorStringWithFormat(
-"plugin name '%s' is not a valid ObjectFile plugin name", name);
+StreamString stream;
+stream.Printf("plugin name '%s' is not a valid ObjectFile plugin name.",
+  name);
+
+llvm::SmallVector plugin_names =
+PluginManager::GetSaveCorePluginNames();
+if (!plugin_names.empty()) {
+  stream.PutCString(" valid values are: ");
+  bool is_first = true;
+  for (llvm::StringRef plugin_name : plugin_names) {
+llvm::StringRef delimiter = ", ";
+if (is_first) {
+  delimiter = "";
+  is_first = false;
+}
+stream.Printf("%s\"%s\"", delimiter.data(), plugin_name.data());
+  }
+  stream.PutChar('.');
+}
+return Status(stream.GetString().str());
   }
 
   m_plugin_name = name;

>From de106f4b8d350c8ffb8a2b40906a1ce72df3e9a1 Mon Sep 17 00:00:00 2001
From: Ebuka Ezike 
Date: Sun, 8 Jun 2025 19:33:01 +0100
Subject: [PATCH 2/4] add help and completion

---
 .../lldb/Interpreter/CommandCompletions.h |  4 
 .../Interpreter/CommandOptionArgumentTable.h  |  3 +++
 lldb/include/lldb/lldb-enumerations.h |  4 +++-
 lldb/source/Commands/CommandCompletions.cpp   | 12 ++
 lldb/source/Commands/CommandObjectProcess.cpp | 23 ++-
 lldb/source/Commands/Options.td   |  3 ++-
 lldb/source/Core/PluginManager.cpp|  6 +
 lldb/source/Symbol/SaveCoreOptions.cpp| 13 +++
 8 files changed, 55 insertions(+), 13 deletions(-)

diff --git a/lldb/include/lldb/Interpreter/CommandCompletions.h 
b/lldb/include/lldb/Interpreter/CommandCompletions.h
index c7292b3b1471a..354debbc7d7bf 100644
--- a/lldb/include/lldb/Interpreter/CommandCompletions.h
+++ b/lldb/include/lldb/Interpreter/CommandCompletions.h
@@ -97,6 +97,10 @@ class CommandCompletions {
   static void ProcessNames(CommandInterpreter &interpreter,
CompletionRequest &request, SearchFilter *searcher);
 
+  static void ProcessSaveCorePluginNames(CommandInterpreter &interpreter,
+ CompletionRequest &request,
+ SearchFilter *searcher);
+
   static void DisassemblyFlavors(CommandInterpreter &interpreter,
  CompletionRequest &request,
  SearchFilter *searcher);
diff --git a/lldb/include/lldb/Interpreter/CommandOptionArgumentTable.h 
b/lldb/include/lldb/Interpreter/CommandOptionArgumentTable.h
index 1875ff6a048d4..d22e3842214dd 100644
--- a/lldb/include/lldb/Interpreter/CommandOptionArgumentTable.h
+++ b/lldb/include/lldb/Interpreter/CommandOptionArgumentTable.h
@@ -198,6 +198,8 @@ static constexpr OptionEnumValueElement g_completion_type[] 
= {
  "Completes to a ty

[Lldb-commits] [lldb] [lldb][AIX] Added XCOFF ParseSymtab handling (PR #141577)

2025-06-10 Thread Pavel Labath via lldb-commits


labath wrote:

The code is fine, but you should really add a test for it. You don't need to 
wait for lldb-test to grow symtab support. You can write a test that does 
something like:
```
# RUN: yaml2obj %s > %t
# RUN: %lldb %t -o "image dump symtab" -o exit | FileCheck %s
# CHECK: symtab contents
```

If you grep for "image dump symtab", you can find some existing tests to 
emulate.


I also feel I need to say something about comments. The most useful kind of 
comment is the one that answers the "why" question. Most of your comments try 
to answer the "what". Ideally the code should be clear enough that I can tell 
*what* it is doing without reading the comment. The part that's often not 
obvious is **why** is it doing that.

Taking this as an example:
```
// Remove the dot prefix from symbol names before adding to symtab. '.text'
// -> 'text'
```
The comment is not bad, but it's not that helpful as I can deduce that from the 
code. When reading this, the questions I have are:
- why are we doing that?
- who adds the "." and why?
- what would happen if we didn't do that?
- etc.

This isn't a hard requirement for the patch, but please keep this in mind.

https://github.com/llvm/llvm-project/pull/141577
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb/cmake] Use ADDITIONAL_HEADER(_DIR)?S (PR #142587)

2025-06-10 Thread Pavel Labath via lldb-commits


https://github.com/labath closed 
https://github.com/llvm/llvm-project/pull/142587
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] 7e471c1 - [lldb/cmake] Use ADDITIONAL_HEADER(_DIR)?S (#142587)

2025-06-10 Thread via lldb-commits


Author: Pavel Labath
Date: 2025-06-10T11:58:39+02:00
New Revision: 7e471c1fd0c4de4656cfaac39e247d207e987510

URL: 
https://github.com/llvm/llvm-project/commit/7e471c1fd0c4de4656cfaac39e247d207e987510
DIFF: 
https://github.com/llvm/llvm-project/commit/7e471c1fd0c4de4656cfaac39e247d207e987510.diff

LOG: [lldb/cmake] Use ADDITIONAL_HEADER(_DIR)?S (#142587)

Replace (questionable) header globs with an explicit argument supported
by llvm_add_library.

Added: 


Modified: 
lldb/CMakeLists.txt
lldb/cmake/modules/AddLLDB.cmake
lldb/source/API/CMakeLists.txt
lldb/source/Breakpoint/CMakeLists.txt
lldb/source/Core/CMakeLists.txt
lldb/source/DataFormatters/CMakeLists.txt
lldb/source/Expression/CMakeLists.txt
lldb/source/Host/CMakeLists.txt
lldb/source/Host/macosx/objcxx/CMakeLists.txt
lldb/source/Initialization/CMakeLists.txt
lldb/source/Interpreter/CMakeLists.txt
lldb/source/Interpreter/Interfaces/CMakeLists.txt
lldb/source/Symbol/CMakeLists.txt
lldb/source/Target/CMakeLists.txt
lldb/source/Utility/CMakeLists.txt
lldb/source/ValueObject/CMakeLists.txt
lldb/source/Version/CMakeLists.txt

Removed: 




diff  --git a/lldb/CMakeLists.txt b/lldb/CMakeLists.txt
index 85ba4fde17418..2aaf75dd87bc3 100644
--- a/lldb/CMakeLists.txt
+++ b/lldb/CMakeLists.txt
@@ -38,6 +38,8 @@ endif()
 include(LLDBConfig)
 include(AddLLDB)
 
+set(LLDB_INCLUDE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/include)
+
 # Define the LLDB_CONFIGURATION_xxx matching the build type.
 if(uppercase_CMAKE_BUILD_TYPE STREQUAL "DEBUG" )
   add_definitions(-DLLDB_CONFIGURATION_DEBUG)

diff  --git a/lldb/cmake/modules/AddLLDB.cmake 
b/lldb/cmake/modules/AddLLDB.cmake
index 8b986bf037aac..0108fb22e5a03 100644
--- a/lldb/cmake/modules/AddLLDB.cmake
+++ b/lldb/cmake/modules/AddLLDB.cmake
@@ -68,12 +68,6 @@ function(add_lldb_library name)
 set_property(GLOBAL APPEND PROPERTY LLDB_PLUGINS ${name})
   endif()
 
-  if (MSVC_IDE OR XCODE)
-string(REGEX MATCHALL "/[^/]+" split_path ${CMAKE_CURRENT_SOURCE_DIR})
-list(GET split_path -1 dir)
-file(GLOB_RECURSE headers
-  ../../include/lldb${dir}/*.h)
-  endif()
   if (PARAM_MODULE)
 set(libkind MODULE)
   elseif (PARAM_SHARED)
@@ -92,7 +86,7 @@ function(add_lldb_library name)
 set(pass_NO_INSTALL_RPATH NO_INSTALL_RPATH)
   endif()
 
-  llvm_add_library(${name} ${libkind} ${headers}
+  llvm_add_library(${name} ${libkind}
 ${PARAM_UNPARSED_ARGUMENTS}
 LINK_LIBS ${PARAM_LINK_LIBS}
 ${pass_NO_INSTALL_RPATH}

diff  --git a/lldb/source/API/CMakeLists.txt b/lldb/source/API/CMakeLists.txt
index cb5f1f831dac0..f5b25237d1edb 100644
--- a/lldb/source/API/CMakeLists.txt
+++ b/lldb/source/API/CMakeLists.txt
@@ -125,6 +125,8 @@ add_lldb_library(liblldb SHARED ${option_framework}
   ${lldb_python_wrapper}
   ${lldb_lua_wrapper}
 
+  ADDITIONAL_HEADER_DIRS
+${LLDB_INCLUDE_DIR}/lldb/API
   DEPENDS
 lldb-sbapi-dwarf-enums
 

diff  --git a/lldb/source/Breakpoint/CMakeLists.txt 
b/lldb/source/Breakpoint/CMakeLists.txt
index d8f8f8cbd055e..de23c8737b324 100644
--- a/lldb/source/Breakpoint/CMakeLists.txt
+++ b/lldb/source/Breakpoint/CMakeLists.txt
@@ -26,6 +26,8 @@ add_lldb_library(lldbBreakpoint NO_PLUGIN_DEPENDENCIES
   WatchpointOptions.cpp
   WatchpointResource.cpp
 
+  ADDITIONAL_HEADER_DIRS
+${LLDB_INCLUDE_DIR}/lldb/Breakpoint
   LINK_COMPONENTS
 Support
   LINK_LIBS

diff  --git a/lldb/source/Core/CMakeLists.txt b/lldb/source/Core/CMakeLists.txt
index 53dc031e90d11..d6b75bca7f2d6 100644
--- a/lldb/source/Core/CMakeLists.txt
+++ b/lldb/source/Core/CMakeLists.txt
@@ -57,10 +57,11 @@ add_lldb_library(lldbCore NO_PLUGIN_DEPENDENCIES
   ThreadedCommunication.cpp
   UserSettingsController.cpp
   Value.cpp
+
+  ADDITIONAL_HEADER_DIRS
+${LLDB_INCLUDE_DIR}/lldb/Core
   DEPENDS
 clang-tablegen-targets
-
-
   LINK_COMPONENTS
 Support
 Demangle

diff  --git a/lldb/source/DataFormatters/CMakeLists.txt 
b/lldb/source/DataFormatters/CMakeLists.txt
index 097cbdb4526bc..5f84e4ef43d6b 100644
--- a/lldb/source/DataFormatters/CMakeLists.txt
+++ b/lldb/source/DataFormatters/CMakeLists.txt
@@ -18,6 +18,8 @@ add_lldb_library(lldbDataFormatters NO_PLUGIN_DEPENDENCIES
   ValueObjectPrinter.cpp
   VectorType.cpp
 
+  ADDITIONAL_HEADER_DIRS
+${LLDB_INCLUDE_DIR}/lldb/DataFormatters
   LINK_COMPONENTS
 Support
   LINK_LIBS

diff  --git a/lldb/source/Expression/CMakeLists.txt 
b/lldb/source/Expression/CMakeLists.txt
index ac129ce49b5d3..08dc536781f9c 100644
--- a/lldb/source/Expression/CMakeLists.txt
+++ b/lldb/source/Expression/CMakeLists.txt
@@ -17,6 +17,8 @@ add_lldb_library(lldbExpression NO_PLUGIN_DEPENDENCIES
   UserExpression.cpp
   UtilityFunction.cpp
 
+  ADDITIONAL_HEADER_DIRS
+${LLDB_INCLUDE_DIR}/lldb/Expression
   DEPENDS
   intrinsics_gen
 

diff  --git a/lldb/source/Host/CMakeLists.txt b/lldb/source/Host/CMakeLists.txt
index 21f

[Lldb-commits] [lldb] [llvm] [lldb] Fix object format of some mach-o files by using vendor info in `getDefaultFormat()` (PR #143633)

2025-06-10 Thread via lldb-commits


https://github.com/royitaqi created 
https://github.com/llvm/llvm-project/pull/143633

**Context**: See previous attempt #142704

**TL;DR**: Some mach-o files (including some of those in lldb tests) are 
mistakenly reported as `ELF` (as in their `Triple`) by `ObjectFileMachO`. The 
reason is that those files don't have load commands like `LC_BUILD_VERSION` or 
`LC_VERSION_MIN_*` (which would cause the `Triple` code to set the correct 
`MachO` object format). Previously, #142704 tries to fix this by setting the 
correct object format `ObjectFileMachO::GetAllArchSpecs`. However, it seems 
such explicit assignment cause the `Triple` to report "-macho" in its string 
form, causing change in UI and a test failure which depends on the UI.

So we are dealing with the following constraints:
1. The UI cannot be changed. IIUC, this means the fix cannot set the object 
format explicitly. I.e. the fix has to be in `Triple`'s `getDefaultFormat()`, 
changing the returned default format based on the `Triple`'s other fields.
2. In `getDefaultFormat()`, at least in the case that I tested (see added unit 
test), the `OS` is not set.
3. The `Vendor` is set to `Apple. This is because 
`ObjectFileMachO::GetAllArchSpecs()` calls `ArchSpec::SetArchitecture()` 
([code](https://github.com/llvm/llvm-project/blob/1bf4702d2bbaad522886dfbab913a8dd6efe3b85/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp#L5059)),
 which sets the vendor 
([code](https://github.com/llvm/llvm-project/blob/1bf4702d2bbaad522886dfbab913a8dd6efe3b85/lldb/source/Utility/ArchSpec.cpp#L892)).
4. Since the above code will always set the arch type to `eArchTypeMachO`, 
which will always lead to the vendor to be set as `Apple`, it seems to be a 
consistent way to detect mach-o object format.

>From d01f75f4b8f75676ae15730f0035cca685dc5195 Mon Sep 17 00:00:00 2001
From: Roy Shi 
Date: Tue, 3 Jun 2025 17:04:29 -0700
Subject: [PATCH 1/4] Set default object format. Add test.

---
 .../ObjectFile/Mach-O/ObjectFileMachO.cpp |  1 +
 .../ObjectFile/MachO/TestObjectFileMachO.cpp  | 54 +++
 2 files changed, 55 insertions(+)

diff --git a/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp 
b/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
index 3950454b7c90e..0079672c5cbd0 100644
--- a/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
+++ b/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
@@ -5148,6 +5148,7 @@ void ObjectFileMachO::GetAllArchSpecs(const 
llvm::MachO::mach_header &header,
   llvm::Triple base_triple = base_arch.GetTriple();
   base_triple.setOS(llvm::Triple::UnknownOS);
   base_triple.setOSName(llvm::StringRef());
+  base_triple.setObjectFormat(llvm::Triple::MachO);
 
   if (header.filetype == MH_PRELOAD) {
 if (header.cputype == CPU_TYPE_ARM) {
diff --git a/lldb/unittests/ObjectFile/MachO/TestObjectFileMachO.cpp 
b/lldb/unittests/ObjectFile/MachO/TestObjectFileMachO.cpp
index 0ef2d0b85fd36..33aaba5d1055f 100644
--- a/lldb/unittests/ObjectFile/MachO/TestObjectFileMachO.cpp
+++ b/lldb/unittests/ObjectFile/MachO/TestObjectFileMachO.cpp
@@ -94,4 +94,58 @@ TEST_F(ObjectFileMachOTest, IndirectSymbolsInTheSharedCache) 
{
   for (size_t i = 0; i < 10; i++)
 OF->ParseSymtab(symtab);
 }
+
+TEST_F(ObjectFileMachOTest, ObjectFileFormatWithoutLoadCommand) {
+  // A Mach-O file without the load command LC_BUILD_VERSION.
+  const char *yamldata = R"(
+--- !mach-o
+FileHeader:
+  magic:   0xFEEDFACF
+  cputype: 0x010C
+  cpusubtype:  0x
+  filetype:0x0001
+  ncmds:   1
+  sizeofcmds:  152
+  flags:   0x2000
+  reserved:0x
+LoadCommands:
+  - cmd: LC_SEGMENT_64
+cmdsize: 152
+segname: __TEXT
+vmaddr:  0
+vmsize:  4
+fileoff: 184
+filesize:4
+maxprot: 7
+initprot:7
+nsects:  1
+flags:   0
+Sections:
+  - sectname:__text
+segname: __TEXT
+addr:0x
+content: 'AABBCCDD'
+size:4
+offset:  184
+align:   0
+reloff:  0x
+nreloc:  0
+flags:   0x8400
+reserved1:   0x
+reserved2:   0x
+reserved3:   0x
+...
+)";
+  
+  // Perform setup.
+  llvm::Expected file = TestFile::fromYaml(yamldata);
+  EXPECT_THAT_EXPECTED(file, llvm::Succeeded());
+  auto module_sp = std::make_shared(file->moduleSpec());
+  ASSERT_NE(module_sp, nullptr);
+  auto object_file = module_sp->GetObjectFile();
+  ASSERT_NE(object_file, nullptr);
+
+  // Verify that the object file is recognized as Mach-O.
+  ASSERT_EQ(object_file->GetArchitecture().GetTriple().getObjectFormat(), 
llvm::Triple::MachO);
+}
 #endif

>From 119833ef21bb21e580280811fcf16afcf4be4bb2 Mon Sep 17 00:00:00 2001
Fr

[Lldb-commits] [lldb] [llvm] [lldb] Fix object format of some mach-o files by using vendor info in `getDefaultFormat()` (PR #143633)

2025-06-10 Thread via lldb-commits


llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: None (royitaqi)


Changes

**Context**: See previous attempt #142704

**TL;DR**: Some mach-o files (including some of those in lldb tests) are 
mistakenly reported as `ELF` (as in their `Triple`) by `ObjectFileMachO`. The 
reason is that those files don't have load commands like `LC_BUILD_VERSION` or 
`LC_VERSION_MIN_*` (which would cause the `Triple` code to set the correct 
`MachO` object format). Previously, #142704 tries to fix this by 
setting the correct object format `ObjectFileMachO::GetAllArchSpecs`. However, 
it seems such explicit assignment cause the `Triple` to report "-macho" in its 
string form, causing change in UI and a test failure which depends on the UI.

So we are dealing with the following constraints:
1. The UI cannot be changed. IIUC, this means the fix cannot set the object 
format explicitly. I.e. the fix has to be in `Triple`'s `getDefaultFormat()`, 
changing the returned default format based on the `Triple`'s other fields.
2. In `getDefaultFormat()`, at least in the case that I tested (see added unit 
test), the `OS` is not set.
3. The `Vendor` is set to `Apple. This is because 
`ObjectFileMachO::GetAllArchSpecs()` calls `ArchSpec::SetArchitecture()` 
([code](https://github.com/llvm/llvm-project/blob/1bf4702d2bbaad522886dfbab913a8dd6efe3b85/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp#L5059)),
 which sets the vendor 
([code](https://github.com/llvm/llvm-project/blob/1bf4702d2bbaad522886dfbab913a8dd6efe3b85/lldb/source/Utility/ArchSpec.cpp#L892)).
4. Since the above code will always set the arch type to `eArchTypeMachO`, 
which will always lead to the vendor to be set as `Apple`, it seems to be a 
consistent way to detect mach-o object format.

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


2 Files Affected:

- (modified) lldb/unittests/ObjectFile/MachO/TestObjectFileMachO.cpp (+55) 
- (modified) llvm/lib/TargetParser/Triple.cpp (+3) 


``diff
diff --git a/lldb/unittests/ObjectFile/MachO/TestObjectFileMachO.cpp 
b/lldb/unittests/ObjectFile/MachO/TestObjectFileMachO.cpp
index 0ef2d0b85fd36..71ff866abb352 100644
--- a/lldb/unittests/ObjectFile/MachO/TestObjectFileMachO.cpp
+++ b/lldb/unittests/ObjectFile/MachO/TestObjectFileMachO.cpp
@@ -94,4 +94,59 @@ TEST_F(ObjectFileMachOTest, IndirectSymbolsInTheSharedCache) 
{
   for (size_t i = 0; i < 10; i++)
 OF->ParseSymtab(symtab);
 }
+
+TEST_F(ObjectFileMachOTest, ObjectFormatWithoutVersionLoadCommand) {
+  // A Mach-O file without the load command LC_BUILD_VERSION.
+  const char *yamldata = R"(
+--- !mach-o
+FileHeader:
+  magic:   0xFEEDFACF
+  cputype: 0x010C
+  cpusubtype:  0x
+  filetype:0x0001
+  ncmds:   1
+  sizeofcmds:  152
+  flags:   0x2000
+  reserved:0x
+LoadCommands:
+  - cmd: LC_SEGMENT_64
+cmdsize: 152
+segname: __TEXT
+vmaddr:  0
+vmsize:  4
+fileoff: 184
+filesize:4
+maxprot: 7
+initprot:7
+nsects:  1
+flags:   0
+Sections:
+  - sectname:__text
+segname: __TEXT
+addr:0x
+content: 'AABBCCDD'
+size:4
+offset:  184
+align:   0
+reloff:  0x
+nreloc:  0
+flags:   0x8400
+reserved1:   0x
+reserved2:   0x
+reserved3:   0x
+...
+)";
+
+  // Perform setup.
+  llvm::Expected file = TestFile::fromYaml(yamldata);
+  EXPECT_THAT_EXPECTED(file, llvm::Succeeded());
+  auto module_sp = std::make_shared(file->moduleSpec());
+  ASSERT_NE(module_sp, nullptr);
+  auto object_file = module_sp->GetObjectFile();
+  ASSERT_NE(object_file, nullptr);
+
+  // Verify that the object file is recognized as Mach-O.
+  ASSERT_EQ(object_file->GetArchitecture().GetTriple().getObjectFormat(),
+llvm::Triple::MachO);
+}
 #endif
diff --git a/llvm/lib/TargetParser/Triple.cpp b/llvm/lib/TargetParser/Triple.cpp
index 6a559ff023caa..19ccd44322314 100644
--- a/llvm/lib/TargetParser/Triple.cpp
+++ b/llvm/lib/TargetParser/Triple.cpp
@@ -933,6 +933,9 @@ static Triple::ObjectFormatType getDefaultFormat(const 
Triple &T) {
 case Triple::Win32:
 case Triple::UEFI:
   return Triple::COFF;
+case Triple::UnknownOS:
+  return T.getVendor() == Triple::Apple ? Triple::MachO : Triple::ELF;
+  // Intentional leak into the default case for additional logic.
 default:
   return T.isOSDarwin() ? Triple::MachO : Triple::ELF;
 }

``




https://github.com/llvm/llvm-project/pull/143633
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [llvm] [lldb] Fix object format of some mach-o files by using vendor info in `getDefaultFormat()` (PR #143633)

2025-06-10 Thread via lldb-commits


https://github.com/royitaqi edited 
https://github.com/llvm/llvm-project/pull/143633
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb][headers] Create Python script to fix up framework headers (PR #142051)

2025-06-10 Thread Chelsea Cassanova via lldb-commits


https://github.com/chelcassanova updated 
https://github.com/llvm/llvm-project/pull/142051

>From 2d63dfe6e4f9671d3c22c319e01782aacee303e4 Mon Sep 17 00:00:00 2001
From: Chelsea Cassanova 
Date: Wed, 28 May 2025 15:45:45 -0700
Subject: [PATCH] [lldb][headers] Create Python script to fix up framework
 headers

This commit replaces the shell script that fixes up includes for the
LLDB framework with a Python script. This script will also be used when
fixing up includes for the LLDBRPC.framework.
---
 lldb/cmake/modules/LLDBFramework.cmake|  46 ---
 lldb/scripts/framework-header-fix.py  | 126 ++
 .../Shell/Scripts/Inputs/Main/SBAddress.h |  13 ++
 .../Shell/Scripts/Inputs/RPC/RPCSBAddress.h   |   9 ++
 .../Shell/Scripts/TestFrameworkFixScript.test |  11 ++
 .../Scripts/TestFrameworkFixUnifdef.test  |  12 ++
 .../Scripts/TestRPCFrameworkFixScript.test|  14 ++
 7 files changed, 210 insertions(+), 21 deletions(-)
 create mode 100755 lldb/scripts/framework-header-fix.py
 create mode 100644 lldb/test/Shell/Scripts/Inputs/Main/SBAddress.h
 create mode 100644 lldb/test/Shell/Scripts/Inputs/RPC/RPCSBAddress.h
 create mode 100644 lldb/test/Shell/Scripts/TestFrameworkFixScript.test
 create mode 100644 lldb/test/Shell/Scripts/TestFrameworkFixUnifdef.test
 create mode 100644 lldb/test/Shell/Scripts/TestRPCFrameworkFixScript.test

diff --git a/lldb/cmake/modules/LLDBFramework.cmake 
b/lldb/cmake/modules/LLDBFramework.cmake
index 471aeaaad3c0d..f6dd9bb55fea1 100644
--- a/lldb/cmake/modules/LLDBFramework.cmake
+++ b/lldb/cmake/modules/LLDBFramework.cmake
@@ -68,24 +68,17 @@ if(NOT APPLE_EMBEDDED)
   )
 endif()
 
-# At configuration time, collect headers for the framework bundle and copy them
-# into a staging directory. Later we can copy over the entire folder.
-file(GLOB public_headers ${LLDB_SOURCE_DIR}/include/lldb/API/*.h)
-set(generated_public_headers ${LLDB_OBJ_DIR}/include/lldb/API/SBLanguages.h)
-file(GLOB root_public_headers ${LLDB_SOURCE_DIR}/include/lldb/lldb-*.h)
-file(GLOB root_private_headers ${LLDB_SOURCE_DIR}/include/lldb/lldb-private*.h)
-list(REMOVE_ITEM root_public_headers ${root_private_headers})
-
 find_program(unifdef_EXECUTABLE unifdef)
 
-set(lldb_header_staging ${CMAKE_CURRENT_BINARY_DIR}/FrameworkHeaders)
-foreach(header
-${public_headers}
-${generated_public_headers}
-${root_public_headers})
+# All necessary header files will be staged in the include directory in the 
build directory,
+# so just copy the files from there into the framework's staging directory.
+set(lldb_build_dir_header_staging "${CMAKE_BINARY_DIR}/include/lldb")
+set(lldb_framework_header_staging 
"${CMAKE_CURRENT_BINARY_DIR}/FrameworkHeaders")
+file(GLOB lldb_build_dir_header_staging_list 
${lldb_build_dir_header_staging}/*)
+foreach(header ${lldb_build_dir_header_staging_list})
 
   get_filename_component(basename ${header} NAME)
-  set(staged_header ${lldb_header_staging}/${basename})
+  set(staged_header ${lldb_framework_header_staging}/${basename})
 
   if(unifdef_EXECUTABLE)
 # unifdef returns 0 when the file is unchanged and 1 if something was 
changed.
@@ -107,15 +100,26 @@ endforeach()
 # Wrap output in a target, so lldb-framework can depend on it.
 add_custom_target(liblldb-resource-headers DEPENDS lldb-sbapi-dwarf-enums 
${lldb_staged_headers})
 set_target_properties(liblldb-resource-headers PROPERTIES FOLDER 
"LLDB/Resources")
+
+# We're taking the header files from where they've been staged in the build 
directory's include folder,
+# so create a dependency on the build step that creates that directory.
+add_dependencies(liblldb-resource-headers liblldb-header-staging)
 add_dependencies(liblldb liblldb-resource-headers)
 
-# At build time, copy the staged headers into the framework bundle (and do
-# some post-processing in-place).
-add_custom_command(TARGET liblldb POST_BUILD
-  COMMAND ${CMAKE_COMMAND} -E copy_directory ${lldb_header_staging} 
$/Headers
-  COMMAND ${LLDB_SOURCE_DIR}/scripts/framework-header-fix.sh 
$/Headers ${LLDB_VERSION}
-  COMMENT "LLDB.framework: copy framework headers"
-)
+# Take the headers from the staging directory and fix up their includes for 
the framework.
+# Then write them to the output directory.
+# Also, run unifdef to remove any specified guards from the header files.
+file(GLOB lldb_framework_header_staging_list 
${lldb_framework_header_staging}/*)
+foreach(header ${lldb_framework_header_staging_list})
+
+  set(input_header ${header})
+  set(output_header $/Headers/${input_header})
+
+  add_custom_command(TARGET liblldb POST_BUILD
+COMMAND ${LLDB_SOURCE_DIR}/scripts/framework-header-fix.py -f lldb_main -i 
${input_header} -o ${output_header} -p ${unifdef_EXECUTABLE} USWIG
+COMMENT "LLDB.framework: Fix up and copy framework headers"
+  )
+endforeach()
 
 # Copy vendor-specific headers from clang (without staging).
 if(NOT APPLE_EMBEDDED)
diff --git a/lldb/scripts/framework-header-fix.py 
b/lldb/scripts/framewor

[Lldb-commits] [lldb] [lldb] Add MCP support to LLDB (PoC) (PR #143628)

2025-06-10 Thread Jonas Devlieghere via lldb-commits


https://github.com/JDevlieghere updated 
https://github.com/llvm/llvm-project/pull/143628

>From 4b0e386016e3ee0d74a673e4f857b5537309614f Mon Sep 17 00:00:00 2001
From: Jonas Devlieghere 
Date: Wed, 4 Jun 2025 23:56:57 -0700
Subject: [PATCH] [lldb] Add MCP support to LLDB (PoC)

---
 lldb/include/lldb/MCP/MCPError.h  |  33 +++
 lldb/include/lldb/MCP/Protocol.h  | 131 +
 lldb/include/lldb/MCP/Server.h|  67 +
 lldb/include/lldb/MCP/Tool.h  |  45 
 lldb/include/lldb/MCP/Transport.h | 100 +++
 lldb/source/CMakeLists.txt|   1 +
 lldb/source/Commands/CMakeLists.txt   |   2 +
 lldb/source/Commands/CommandObjectMCP.cpp | 162 +++
 lldb/source/Commands/CommandObjectMCP.h   |  24 ++
 .../source/Interpreter/CommandInterpreter.cpp |   2 +
 lldb/source/MCP/CMakeLists.txt|  14 +
 lldb/source/MCP/MCPError.cpp  |  31 +++
 lldb/source/MCP/Protocol.cpp  | 180 +
 lldb/source/MCP/Server.cpp| 251 ++
 lldb/source/MCP/Tool.cpp  |  28 ++
 lldb/source/MCP/Transport.cpp | 109 
 16 files changed, 1180 insertions(+)
 create mode 100644 lldb/include/lldb/MCP/MCPError.h
 create mode 100644 lldb/include/lldb/MCP/Protocol.h
 create mode 100644 lldb/include/lldb/MCP/Server.h
 create mode 100644 lldb/include/lldb/MCP/Tool.h
 create mode 100644 lldb/include/lldb/MCP/Transport.h
 create mode 100644 lldb/source/Commands/CommandObjectMCP.cpp
 create mode 100644 lldb/source/Commands/CommandObjectMCP.h
 create mode 100644 lldb/source/MCP/CMakeLists.txt
 create mode 100644 lldb/source/MCP/MCPError.cpp
 create mode 100644 lldb/source/MCP/Protocol.cpp
 create mode 100644 lldb/source/MCP/Server.cpp
 create mode 100644 lldb/source/MCP/Tool.cpp
 create mode 100644 lldb/source/MCP/Transport.cpp

diff --git a/lldb/include/lldb/MCP/MCPError.h b/lldb/include/lldb/MCP/MCPError.h
new file mode 100644
index 0..2a76a7b087e20
--- /dev/null
+++ b/lldb/include/lldb/MCP/MCPError.h
@@ -0,0 +1,33 @@
+//===-- MCPError.h 
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "Protocol.h"
+#include "llvm/Support/Error.h"
+#include 
+
+namespace lldb_private::mcp {
+
+class MCPError : public llvm::ErrorInfo {
+public:
+  static char ID;
+
+  MCPError(std::string message, int64_t error_code);
+
+  void log(llvm::raw_ostream &OS) const override;
+  std::error_code convertToErrorCode() const override;
+
+  const std::string &getMessage() const { return m_message; }
+
+  protocol::Error toProtcolError() const;
+
+private:
+  std::string m_message;
+  int64_t m_error_code;
+};
+
+} // namespace lldb_private::mcp
diff --git a/lldb/include/lldb/MCP/Protocol.h b/lldb/include/lldb/MCP/Protocol.h
new file mode 100644
index 0..e661c3f7643af
--- /dev/null
+++ b/lldb/include/lldb/MCP/Protocol.h
@@ -0,0 +1,131 @@
+//===- Protocol.h 
-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef LLDB_TOOLS_LLDB_MCP_PROTOCOL_H
+#define LLDB_TOOLS_LLDB_MCP_PROTOCOL_H
+
+#include "llvm/Support/JSON.h"
+#include 
+#include 
+
+namespace lldb_private::mcp::protocol {
+
+static llvm::StringLiteral kProtocolVersion = "2025-03-26";
+
+struct Request {
+  uint64_t id = 0;
+  std::string method;
+  std::optional params;
+};
+
+llvm::json::Value toJSON(const Request &);
+bool fromJSON(const llvm::json::Value &, Request &, llvm::json::Path);
+
+struct Error {
+  int64_t code = 0;
+  std::string message;
+  std::optional data;
+};
+
+llvm::json::Value toJSON(const Error &);
+bool fromJSON(const llvm::json::Value &, Error &, llvm::json::Path);
+
+struct ProtocolError {
+  uint64_t id = 0;
+  Error error;
+};
+
+llvm::json::Value toJSON(const ProtocolError &);
+bool fromJSON(const llvm::json::Value &, ProtocolError &, llvm::json::Path);
+
+struct Response {
+  uint64_t id = 0;
+  std::optional result;
+  std::optional error;
+};
+
+llvm::json::Value toJSON(const Response &);
+bool fromJSON(const llvm::json::Value &, Response &, llvm::json::Path);
+
+struct Notification {
+  std::string method;
+  std::optional params;
+};
+
+llvm::json::Value toJSON(const Notification &);
+bool fromJSON(const llvm::json::Value &, Notification &, llvm::json::Path);
+
+struct ToolCapability {
+  bool listChanged = fal

[Lldb-commits] [clang] [lldb] [llvm] [debuginfo][coro] Fix linkage name for clones of coro functions (PR #141889)

2025-06-10 Thread Adrian Vogelsgesang via lldb-commits


vogelsgesang wrote:

@ChuanqiXu9 do you want to take another look? (given that this is a NFC for 
Swift, and primarily changes C++ behavior)
Alternatively, is it fine by you if I ship this based on @Michael137's approval?

https://github.com/llvm/llvm-project/pull/141889
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [clang] [lldb] [llvm] [debuginfo][coro] Fix linkage name for clones of coro functions (PR #141889)

2025-06-10 Thread Adrian Vogelsgesang via lldb-commits


vogelsgesang wrote:

> The LLDB test failure seems expected. The demangled frame name changed

Good catch. I updated the LLDB test expectations just now

https://github.com/llvm/llvm-project/pull/141889
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb][nfc] Factor out code checking if Variable is in scope (PR #143572)

2025-06-10 Thread Felipe de Azevedo Piovezan via lldb-commits



@@ -321,6 +302,27 @@ bool Variable::IsInScope(StackFrame *frame) {
   return false;
 }
 
+bool Variable::IsInScope(Block &block, Address addr) {

felipepiovezan wrote:

Just an oopsie on my part!

https://github.com/llvm/llvm-project/pull/143572
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [clang] [lldb] [llvm] [debuginfo][coro] Fix linkage name for clones of coro functions (PR #141889)

2025-06-10 Thread Chuanqi Xu via lldb-commits


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

Thanks. I feel good with it.

https://github.com/llvm/llvm-project/pull/141889
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [llvm] [lldb] Fix object format of some mach-o files by using vendor info in `getDefaultFormat()` (PR #143633)

2025-06-10 Thread via lldb-commits


https://github.com/royitaqi edited 
https://github.com/llvm/llvm-project/pull/143633
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [llvm] [lldb] Fix object format of some mach-o files by using vendor info in `getDefaultFormat()` (PR #143633)

2025-06-10 Thread via lldb-commits


https://github.com/royitaqi edited 
https://github.com/llvm/llvm-project/pull/143633
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [llvm] [lldb] Fix object format of some mach-o files by using vendor info in `getDefaultFormat()` (PR #143633)

2025-06-10 Thread via lldb-commits



@@ -933,6 +933,9 @@ static Triple::ObjectFormatType getDefaultFormat(const 
Triple &T) {
 case Triple::Win32:
 case Triple::UEFI:
   return Triple::COFF;
+case Triple::UnknownOS:
+  return T.getVendor() == Triple::Apple ? Triple::MachO : Triple::ELF;
+  // Intentional leak into the default case for additional logic.
 default:
   return T.isOSDarwin() ? Triple::MachO : Triple::ELF;

royitaqi wrote:

Off the top of my head: For the sake of future proof, e.g. say Apple ships 
their own Linux, I assume their Linux will use ELF format, and so for case 
where "vendor == Apple && os == Linux", we probably want to return ELF.

https://github.com/llvm/llvm-project/pull/143633
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] Revive TestSimulatorPlatform.py (PR #142244)

2025-06-10 Thread Jonas Devlieghere via lldb-commits


https://github.com/JDevlieghere closed 
https://github.com/llvm/llvm-project/pull/142244
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] a7f495f - [lldb] Revive TestSimulatorPlatform.py (#142244)

2025-06-10 Thread via lldb-commits


Author: Jonas Devlieghere
Date: 2025-06-10T13:30:31-07:00
New Revision: a7f495f170864e6bddc4bb29ae7fae293a7136aa

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

LOG: [lldb] Revive TestSimulatorPlatform.py (#142244)

This test was incorrectly disabled and bitrotted since then. This PR
fixes up the test and re-enables it.

 - Build against the system libc++ (which can target the simulator)
 - Bump the deployment target for iOS and tvOS on Apple Silicon
 - Skip backdeploying to pre-Apple Silicon OS on Apple Silicon.

Added: 


Modified: 
lldb/packages/Python/lldbsuite/test/decorators.py
lldb/test/API/macosx/simulator/TestSimulatorPlatform.py

Removed: 




diff  --git a/lldb/packages/Python/lldbsuite/test/decorators.py 
b/lldb/packages/Python/lldbsuite/test/decorators.py
index 868e9f7e5eca0..a391319ca9b0e 100644
--- a/lldb/packages/Python/lldbsuite/test/decorators.py
+++ b/lldb/packages/Python/lldbsuite/test/decorators.py
@@ -9,6 +9,7 @@
 import sys
 import tempfile
 import subprocess
+import json
 
 # Third-party modules
 import unittest
@@ -451,24 +452,67 @@ def apple_simulator_test(platform):
 """
 Decorate the test as a test requiring a simulator for a specific platform.
 
-Consider that a simulator is available if you have the corresponding SDK 
installed.
-The SDK identifiers for simulators are iphonesimulator, appletvsimulator, 
watchsimulator
+Consider that a simulator is available if you have the corresponding SDK
+and runtime installed.
+
+The SDK identifiers for simulators are iphonesimulator, appletvsimulator,
+watchsimulator
 """
 
 def should_skip_simulator_test():
 if lldbplatformutil.getHostPlatform() not in ["darwin", "macosx"]:
 return "simulator tests are run only on darwin hosts."
+
+# Make sure we recognize the platform.
+mapping = {
+"iphone": "ios",
+"appletv": "tvos",
+"watch": "watchos",
+}
+if platform not in mapping:
+return "unknown simulator platform: {}".format(platform)
+
+# Make sure we have an SDK.
 try:
 output = subprocess.check_output(
 ["xcodebuild", "-showsdks"], stderr=subprocess.DEVNULL
 ).decode("utf-8")
-if re.search("%ssimulator" % platform, output):
-return None
-else:
+if not re.search("%ssimulator" % platform, output):
 return "%s simulator is not supported on this system." % 
platform
 except subprocess.CalledProcessError:
 return "Simulators are unsupported on this system (xcodebuild 
failed)"
 
+# Make sure we a simulator runtime.
+try:
+sim_devices_str = subprocess.check_output(
+["xcrun", "simctl", "list", "-j", "devices"]
+).decode("utf-8")
+
+sim_devices = json.loads(sim_devices_str)["devices"]
+for simulator in sim_devices:
+if isinstance(simulator, dict):
+runtime = simulator["name"]
+devices = simulator["devices"]
+else:
+runtime = simulator
+devices = sim_devices[simulator]
+
+if not mapping[platform] in runtime.lower():
+continue
+
+for device in devices:
+if (
+"availability" in device
+and device["availability"] == "(available)"
+):
+return None
+if "isAvailable" in device and device["isAvailable"]:
+return None
+
+return "{} simulator is not supported on this 
system.".format(platform)
+except (subprocess.CalledProcessError, json.decoder.JSONDecodeError):
+return "Simulators are unsupported on this system (simctl failed)"
+
 return skipTestIfFn(should_skip_simulator_test)
 
 

diff  --git a/lldb/test/API/macosx/simulator/TestSimulatorPlatform.py 
b/lldb/test/API/macosx/simulator/TestSimulatorPlatform.py
index faf2256b03a0d..74ba0ee6c83bb 100644
--- a/lldb/test/API/macosx/simulator/TestSimulatorPlatform.py
+++ b/lldb/test/API/macosx/simulator/TestSimulatorPlatform.py
@@ -39,15 +39,15 @@ def check_debugserver(self, log, expected_platform, 
expected_version):
 if expected_version:
 self.assertEqual(aout_info["min_version_os_sdk"], expected_version)
 
-@skipIf(bugnumber="rdar://76995109")
 def run_with(self, arch, os, vers, env, expected_load_command):
 env_list = [env] if env else []
 triple = "-".join([arch, "apple", os + vers] + env_list)
 sdk = lldbutil.get_

[Lldb-commits] [lldb] [lldb][nfc] Factor out code checking if Variable is in scope (PR #143572)

2025-06-10 Thread Jonas Devlieghere via lldb-commits



@@ -321,6 +302,27 @@ bool Variable::IsInScope(StackFrame *frame) {
   return false;
 }
 
+bool Variable::IsInScope(Block &block, Address addr) {

JDevlieghere wrote:

Any reason to not pass this by const ref?

https://github.com/llvm/llvm-project/pull/143572
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [clang] [lldb] [llvm] [debuginfo][coro] Fix linkage name for clones of coro functions (PR #141889)

2025-06-10 Thread Adrian Vogelsgesang via lldb-commits


https://github.com/vogelsgesang updated 
https://github.com/llvm/llvm-project/pull/141889

>From 700c1c465ff7f29dc980356f36844a12d580 Mon Sep 17 00:00:00 2001
From: Adrian Vogelsgesang 
Date: Tue, 27 May 2025 23:50:18 +
Subject: [PATCH 1/3] [debuginfo][coro] Fix linkage name for clones of coro
 functions

So far, the `DW_AT_linkage_name` of the coroutine `resume`, `destroy`,
`cleanup` and `noalloc` functions were incorrectly set to the original
function name instead of the updated function names.

With this commit, we now update the `DW_AT_linkage_name` to the correct
name. This has multiple benefits:
1. it's easier for me (and other developers) to understand the output of
   `llvm-dwarf-dump` when coroutines are involved.
2. When hitting a breakpoint, both LLDB and GDB now tell you which clone
   of the function you are in. E.g., GDB now prints
   "Breakpoint 1.2, coro_func(int) [clone .resume] (v=43) at ..."
   instead of
   "Breakpoint 1.2, coro_func(int) (v=43) at ...".
3. GDB's `info line coro_func` command now allows you to distinguish the
   multiple different clones of the function.

In Swift, the linkage names of the clones were already updated. The
comment right above the relevant code in `CoroSplit.cpp` already hinted
that the linkage name should probably also be updated in C++. This
commit was added in commit 6ce76ff7eb7640, and back then the
corresponding `DW_AT_specification` (i.e., `SP->getDeclaration()`) was
not updated, yet, which led to problems for C++. In the meantime, commit
ca1a5b37c7236d added code to also update `SP->getDeclaration`, as such
there is no reason anymore to not update the linkage name for C++.

Note that most test cases used inconsistent function names for the LLVM
function vs. the DISubprogram linkage name. clang would never emit such
LLVM IR. This confused me initially, and hence I fixed it while updating
the test case.
---
 clang/lib/CodeGen/CGVTables.cpp   |  2 +-
 llvm/lib/Transforms/Coroutines/CoroSplit.cpp  | 31 +--
 ...coro-debug-dbg.values-not_used_in_frame.ll |  6 ++--
 .../Coroutines/coro-debug-dbg.values.ll   | 10 +++---
 .../Coroutines/coro-debug-frame-variable.ll   | 10 +++---
 llvm/test/Transforms/Coroutines/coro-debug.ll | 18 +--
 6 files changed, 31 insertions(+), 46 deletions(-)

diff --git a/clang/lib/CodeGen/CGVTables.cpp b/clang/lib/CodeGen/CGVTables.cpp
index c7447273a42fa..2897ccdf88660 100644
--- a/clang/lib/CodeGen/CGVTables.cpp
+++ b/clang/lib/CodeGen/CGVTables.cpp
@@ -124,7 +124,7 @@ static void resolveTopLevelMetadata(llvm::Function *Fn,
   auto *DIS = Fn->getSubprogram();
   if (!DIS)
 return;
-  auto *NewDIS = DIS->replaceWithDistinct(DIS->clone());
+  auto *NewDIS = llvm::MDNode::replaceWithDistinct(DIS->clone());
   VMap.MD()[DIS].reset(NewDIS);
 
   // Find all llvm.dbg.declare intrinsics and resolve the DILocalVariable nodes
diff --git a/llvm/lib/Transforms/Coroutines/CoroSplit.cpp 
b/llvm/lib/Transforms/Coroutines/CoroSplit.cpp
index f9a6c70fedc2d..07d888a10eb7f 100644
--- a/llvm/lib/Transforms/Coroutines/CoroSplit.cpp
+++ b/llvm/lib/Transforms/Coroutines/CoroSplit.cpp
@@ -912,29 +912,14 @@ void coro::BaseCloner::create() {
 assert(SP != OrigF.getSubprogram() && SP->isDistinct());
 updateScopeLine(ActiveSuspend, *SP);
 
-// Update the linkage name to reflect the modified symbol name. It
-// is necessary to update the linkage name in Swift, since the
-// mangling changes for resume functions. It might also be the
-// right thing to do in C++, but due to a limitation in LLVM's
-// AsmPrinter we can only do this if the function doesn't have an
-// abstract specification, since the DWARF backend expects the
-// abstract specification to contain the linkage name and asserts
-// that they are identical.
-if (SP->getUnit() &&
-SP->getUnit()->getSourceLanguage() == dwarf::DW_LANG_Swift) {
-  SP->replaceLinkageName(MDString::get(Context, NewF->getName()));
-  if (auto *Decl = SP->getDeclaration()) {
-auto *NewDecl = DISubprogram::get(
-Decl->getContext(), Decl->getScope(), Decl->getName(),
-NewF->getName(), Decl->getFile(), Decl->getLine(), Decl->getType(),
-Decl->getScopeLine(), Decl->getContainingType(),
-Decl->getVirtualIndex(), Decl->getThisAdjustment(),
-Decl->getFlags(), Decl->getSPFlags(), Decl->getUnit(),
-Decl->getTemplateParams(), nullptr, Decl->getRetainedNodes(),
-Decl->getThrownTypes(), Decl->getAnnotations(),
-Decl->getTargetFuncName());
-SP->replaceDeclaration(NewDecl);
-  }
+// Update the linkage name and the functaion name to reflect the modified
+// name.
+MDString *NewLinkageName = MDString::get(Context, NewF->getName());
+SP->replaceLinkageName(NewLinkageName);
+if (DISubprogram *Decl = SP->getDeclaration()) {
+  TempDISubprogram NewDecl = Decl->clone();
+  NewDecl->repla

[Lldb-commits] [lldb] [lldb][nfc] Factor out code checking if Variable is in scope (PR #143572)

2025-06-10 Thread Felipe de Azevedo Piovezan via lldb-commits


https://github.com/felipepiovezan updated 
https://github.com/llvm/llvm-project/pull/143572

>From 9821fd7c4530819f131271f4325123a400ecded4 Mon Sep 17 00:00:00 2001
From: Felipe de Azevedo Piovezan 
Date: Tue, 10 Jun 2025 10:26:52 -0700
Subject: [PATCH 1/3] [lldb][nfc] Factor out code checking if Variable is in
 scope

This is useful for checking whether a variable is in scope inside a
specific block.
---
 lldb/include/lldb/Symbol/Variable.h |  3 ++
 lldb/source/Symbol/Variable.cpp | 46 +++--
 2 files changed, 27 insertions(+), 22 deletions(-)

diff --git a/lldb/include/lldb/Symbol/Variable.h 
b/lldb/include/lldb/Symbol/Variable.h
index c437624d1ea6d..b867369576a41 100644
--- a/lldb/include/lldb/Symbol/Variable.h
+++ b/lldb/include/lldb/Symbol/Variable.h
@@ -89,6 +89,9 @@ class Variable : public UserID, public 
std::enable_shared_from_this {
 
   bool IsInScope(StackFrame *frame);
 
+  /// Returns true if this variable is in scope at `addr` inside `block`.
+  bool IsInScope(Block &block, Address addr);
+
   bool LocationIsValidForFrame(StackFrame *frame);
 
   bool LocationIsValidForAddress(const Address &address);
diff --git a/lldb/source/Symbol/Variable.cpp b/lldb/source/Symbol/Variable.cpp
index 8244725aba545..0415758dd268a 100644
--- a/lldb/source/Symbol/Variable.cpp
+++ b/lldb/source/Symbol/Variable.cpp
@@ -290,28 +290,9 @@ bool Variable::IsInScope(StackFrame *frame) {
   // this variable was defined in is currently
   Block *deepest_frame_block =
   frame->GetSymbolContext(eSymbolContextBlock).block;
-  if (deepest_frame_block) {
-SymbolContext variable_sc;
-CalculateSymbolContext(&variable_sc);
-
-// Check for static or global variable defined at the compile unit
-// level that wasn't defined in a block
-if (variable_sc.block == nullptr)
-  return true;
-
-// Check if the variable is valid in the current block
-if (variable_sc.block != deepest_frame_block &&
-!variable_sc.block->Contains(deepest_frame_block))
-  return false;
-
-// If no scope range is specified then it means that the scope is the
-// same as the scope of the enclosing lexical block.
-if (m_scope_range.IsEmpty())
-  return true;
-
-addr_t file_address = frame->GetFrameCodeAddress().GetFileAddress();
-return m_scope_range.FindEntryThatContains(file_address) != nullptr;
-  }
+  Address frame_addr = frame->GetFrameCodeAddress();
+  if (deepest_frame_block)
+return IsInScope(*deepest_frame_block, frame_addr);
 }
 break;
 
@@ -321,6 +302,27 @@ bool Variable::IsInScope(StackFrame *frame) {
   return false;
 }
 
+bool Variable::IsInScope(Block &block, Address addr) {
+  SymbolContext variable_sc;
+  CalculateSymbolContext(&variable_sc);
+
+  // Check for static or global variable defined at the compile unit
+  // level that wasn't defined in a block
+  if (variable_sc.block == nullptr)
+return true;
+
+  // Check if the variable is valid in the current block
+  if (variable_sc.block != &block && !variable_sc.block->Contains(&block))
+return false;
+
+  // If no scope range is specified then it means that the scope is the
+  // same as the scope of the enclosing lexical block.
+  if (m_scope_range.IsEmpty())
+return true;
+
+  return m_scope_range.FindEntryThatContains(addr.GetFileAddress()) != nullptr;
+}
+
 Status Variable::GetValuesForVariableExpressionPath(
 llvm::StringRef variable_expr_path, ExecutionContextScope *scope,
 GetVariableCallback callback, void *baton, VariableList &variable_list,

>From 2fe9bb4855d092bf77b8f6c6ba274c4d67860ea4 Mon Sep 17 00:00:00 2001
From: Felipe de Azevedo Piovezan 
Date: Tue, 10 Jun 2025 14:55:53 -0700
Subject: [PATCH 2/3] fixup! pass by const reference

---
 lldb/include/lldb/Symbol/Variable.h | 2 +-
 lldb/source/Symbol/Variable.cpp | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/lldb/include/lldb/Symbol/Variable.h 
b/lldb/include/lldb/Symbol/Variable.h
index b867369576a41..8229b38e4f32d 100644
--- a/lldb/include/lldb/Symbol/Variable.h
+++ b/lldb/include/lldb/Symbol/Variable.h
@@ -90,7 +90,7 @@ class Variable : public UserID, public 
std::enable_shared_from_this {
   bool IsInScope(StackFrame *frame);
 
   /// Returns true if this variable is in scope at `addr` inside `block`.
-  bool IsInScope(Block &block, Address addr);
+  bool IsInScope(const Block &block, Address addr);
 
   bool LocationIsValidForFrame(StackFrame *frame);
 
diff --git a/lldb/source/Symbol/Variable.cpp b/lldb/source/Symbol/Variable.cpp
index 0415758dd268a..5df89efc68007 100644
--- a/lldb/source/Symbol/Variable.cpp
+++ b/lldb/source/Symbol/Variable.cpp
@@ -302,7 +302,7 @@ bool Variable::IsInScope(StackFrame *frame) {
   return false;
 }
 
-bool Variable::IsInScope(Block &block, Address addr) {
+bool Variable::IsInScope(const Block &block, Address addr) {
   SymbolContext variable

[Lldb-commits] [lldb] [lldb][nfc] Factor out code checking if Variable is in scope (PR #143572)

2025-06-10 Thread Felipe de Azevedo Piovezan via lldb-commits



@@ -321,6 +302,27 @@ bool Variable::IsInScope(StackFrame *frame) {
   return false;
 }
 
+bool Variable::IsInScope(Block &block, Address addr) {

felipepiovezan wrote:

That's an interesting, given the current usage it makes sense to switch this to 
const reference.

Future changes aside, it's still worth pointing out that "by value" by default 
is usually the correct choice. An API that prescribes passing something by 
reference is also saying "it's a bad idea to copy this object", a warning to 
users of the API. Here, there is no such warning, so it is an API that makes a 
developer pause for nothing -- the warnings are usually "it's expensive", "you 
can't copy because of ownership semantics".

https://github.com/llvm/llvm-project/pull/143572
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb/aarch64] Fix PC register info augmentation (PR #143499)

2025-06-10 Thread Jason Molenda via lldb-commits


jasonmolenda wrote:

I thought we augmented the target.xml from the remote gdb stub via 
`ABI::AugmentRegisterInfo` -- adding eh_frame/dwarf register numbers that were 
not supplied by the stub, for instance -- but looking at AArch64 & x86, it 
looks like it's just adding the slice registers like w0 / x0 and eip / rip to 
the registers provided.  Ideally the remote stub should only tell us, like, "I 
have a register x1 and I will use number 1 to refer to it" and we should know 
everything else, the size, default format, ABI register numberings for x1 from 
internal knowledge.  In the beginning we had the model of "debugserver tells us 
everything about registers, lldb knows nothing built-in" but that was never 
going to work for wider interop and it didn't last long.

https://github.com/llvm/llvm-project/pull/143499
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] c706338 - [lldb] Fix `target stop-hook add` help output

2025-06-10 Thread Jonas Devlieghere via lldb-commits


Author: Jonas Devlieghere
Date: 2025-06-10T15:36:55-07:00
New Revision: c7063380205d8776e281f7a6603119aa8ea28c12

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

LOG: [lldb] Fix `target stop-hook add` help output

The help output for `target stop-hook add` references non-existing
option `--one-line-command`. The correct option is `--one-liner`:

```
-o  ( --one-liner  )
 Add a command for the stop hook.  Can be specified more than once,
 and commands will be run in the order they appear.
```

This commit fixes the help text.

rdar://152730660

Added: 


Modified: 
lldb/source/Commands/CommandObjectTarget.cpp

Removed: 




diff  --git a/lldb/source/Commands/CommandObjectTarget.cpp 
b/lldb/source/Commands/CommandObjectTarget.cpp
index 21b21954bbc90..a4ced37649ea0 100644
--- a/lldb/source/Commands/CommandObjectTarget.cpp
+++ b/lldb/source/Commands/CommandObjectTarget.cpp
@@ -4885,9 +4885,9 @@ class CommandObjectTargetStopHookAdd : public 
CommandObjectParsed,
 Command Based stop-hooks:
 -
   Stop hooks can run a list of lldb commands by providing one or more
-  --one-line-command options.  The commands will get run in the order they are
-  added.  Or you can provide no commands, in which case you will enter a
-  command editor where you can enter the commands to be run.
+  --one-liner options.  The commands will get run in the order they are added.
+  Or you can provide no commands, in which case you will enter a command editor
+  where you can enter the commands to be run.
 
 Python Based Stop Hooks:
 



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb][nfc] Factor out code checking if Variable is in scope (PR #143572)

2025-06-10 Thread Jonas Devlieghere via lldb-commits



@@ -321,6 +302,27 @@ bool Variable::IsInScope(StackFrame *frame) {
   return false;
 }
 
+bool Variable::IsInScope(Block &block, Address addr) {

JDevlieghere wrote:

What about `Address`? :D 

https://github.com/llvm/llvm-project/pull/143572
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb][nfc] Factor out code checking if Variable is in scope (PR #143572)

2025-06-10 Thread Felipe de Azevedo Piovezan via lldb-commits



@@ -321,6 +302,27 @@ bool Variable::IsInScope(StackFrame *frame) {
   return false;
 }
 
+bool Variable::IsInScope(Block &block, Address addr) {

felipepiovezan wrote:

>Like 
>[std::shared_ptr](https://en.cppreference.com/w/cpp/memory/shared_ptr.html), a 
>typical implementation of weak_ptr stores two pointers:
a pointer to the control block; and
the stored pointer of the shared_ptr it was constructed from.

Seems like it is cheap?

https://github.com/llvm/llvm-project/pull/143572
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb][nfc] Factor out code checking if Variable is in scope (PR #143572)

2025-06-10 Thread Felipe de Azevedo Piovezan via lldb-commits


https://github.com/felipepiovezan updated 
https://github.com/llvm/llvm-project/pull/143572

>From 9821fd7c4530819f131271f4325123a400ecded4 Mon Sep 17 00:00:00 2001
From: Felipe de Azevedo Piovezan 
Date: Tue, 10 Jun 2025 10:26:52 -0700
Subject: [PATCH 1/2] [lldb][nfc] Factor out code checking if Variable is in
 scope

This is useful for checking whether a variable is in scope inside a
specific block.
---
 lldb/include/lldb/Symbol/Variable.h |  3 ++
 lldb/source/Symbol/Variable.cpp | 46 +++--
 2 files changed, 27 insertions(+), 22 deletions(-)

diff --git a/lldb/include/lldb/Symbol/Variable.h 
b/lldb/include/lldb/Symbol/Variable.h
index c437624d1ea6d..b867369576a41 100644
--- a/lldb/include/lldb/Symbol/Variable.h
+++ b/lldb/include/lldb/Symbol/Variable.h
@@ -89,6 +89,9 @@ class Variable : public UserID, public 
std::enable_shared_from_this {
 
   bool IsInScope(StackFrame *frame);
 
+  /// Returns true if this variable is in scope at `addr` inside `block`.
+  bool IsInScope(Block &block, Address addr);
+
   bool LocationIsValidForFrame(StackFrame *frame);
 
   bool LocationIsValidForAddress(const Address &address);
diff --git a/lldb/source/Symbol/Variable.cpp b/lldb/source/Symbol/Variable.cpp
index 8244725aba545..0415758dd268a 100644
--- a/lldb/source/Symbol/Variable.cpp
+++ b/lldb/source/Symbol/Variable.cpp
@@ -290,28 +290,9 @@ bool Variable::IsInScope(StackFrame *frame) {
   // this variable was defined in is currently
   Block *deepest_frame_block =
   frame->GetSymbolContext(eSymbolContextBlock).block;
-  if (deepest_frame_block) {
-SymbolContext variable_sc;
-CalculateSymbolContext(&variable_sc);
-
-// Check for static or global variable defined at the compile unit
-// level that wasn't defined in a block
-if (variable_sc.block == nullptr)
-  return true;
-
-// Check if the variable is valid in the current block
-if (variable_sc.block != deepest_frame_block &&
-!variable_sc.block->Contains(deepest_frame_block))
-  return false;
-
-// If no scope range is specified then it means that the scope is the
-// same as the scope of the enclosing lexical block.
-if (m_scope_range.IsEmpty())
-  return true;
-
-addr_t file_address = frame->GetFrameCodeAddress().GetFileAddress();
-return m_scope_range.FindEntryThatContains(file_address) != nullptr;
-  }
+  Address frame_addr = frame->GetFrameCodeAddress();
+  if (deepest_frame_block)
+return IsInScope(*deepest_frame_block, frame_addr);
 }
 break;
 
@@ -321,6 +302,27 @@ bool Variable::IsInScope(StackFrame *frame) {
   return false;
 }
 
+bool Variable::IsInScope(Block &block, Address addr) {
+  SymbolContext variable_sc;
+  CalculateSymbolContext(&variable_sc);
+
+  // Check for static or global variable defined at the compile unit
+  // level that wasn't defined in a block
+  if (variable_sc.block == nullptr)
+return true;
+
+  // Check if the variable is valid in the current block
+  if (variable_sc.block != &block && !variable_sc.block->Contains(&block))
+return false;
+
+  // If no scope range is specified then it means that the scope is the
+  // same as the scope of the enclosing lexical block.
+  if (m_scope_range.IsEmpty())
+return true;
+
+  return m_scope_range.FindEntryThatContains(addr.GetFileAddress()) != nullptr;
+}
+
 Status Variable::GetValuesForVariableExpressionPath(
 llvm::StringRef variable_expr_path, ExecutionContextScope *scope,
 GetVariableCallback callback, void *baton, VariableList &variable_list,

>From 2fe9bb4855d092bf77b8f6c6ba274c4d67860ea4 Mon Sep 17 00:00:00 2001
From: Felipe de Azevedo Piovezan 
Date: Tue, 10 Jun 2025 14:55:53 -0700
Subject: [PATCH 2/2] fixup! pass by const reference

---
 lldb/include/lldb/Symbol/Variable.h | 2 +-
 lldb/source/Symbol/Variable.cpp | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/lldb/include/lldb/Symbol/Variable.h 
b/lldb/include/lldb/Symbol/Variable.h
index b867369576a41..8229b38e4f32d 100644
--- a/lldb/include/lldb/Symbol/Variable.h
+++ b/lldb/include/lldb/Symbol/Variable.h
@@ -90,7 +90,7 @@ class Variable : public UserID, public 
std::enable_shared_from_this {
   bool IsInScope(StackFrame *frame);
 
   /// Returns true if this variable is in scope at `addr` inside `block`.
-  bool IsInScope(Block &block, Address addr);
+  bool IsInScope(const Block &block, Address addr);
 
   bool LocationIsValidForFrame(StackFrame *frame);
 
diff --git a/lldb/source/Symbol/Variable.cpp b/lldb/source/Symbol/Variable.cpp
index 0415758dd268a..5df89efc68007 100644
--- a/lldb/source/Symbol/Variable.cpp
+++ b/lldb/source/Symbol/Variable.cpp
@@ -302,7 +302,7 @@ bool Variable::IsInScope(StackFrame *frame) {
   return false;
 }
 
-bool Variable::IsInScope(Block &block, Address addr) {
+bool Variable::IsInScope(const Block &block, Address addr) {
   SymbolContext variable

[Lldb-commits] [lldb] [lldb][nfc] Factor out code checking if Variable is in scope (PR #143572)

2025-06-10 Thread Felipe de Azevedo Piovezan via lldb-commits



@@ -321,6 +302,27 @@ bool Variable::IsInScope(StackFrame *frame) {
   return false;
 }
 
+bool Variable::IsInScope(Block &block, Address addr) {

felipepiovezan wrote:

That one is just a pointer + integer, my understanding is that it is supposed 
to be passed by value?

https://github.com/llvm/llvm-project/pull/143572
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb][nfc] Factor out code checking if Variable is in scope (PR #143572)

2025-06-10 Thread Felipe de Azevedo Piovezan via lldb-commits



@@ -321,6 +302,27 @@ bool Variable::IsInScope(StackFrame *frame) {
   return false;
 }
 
+bool Variable::IsInScope(Block &block, Address addr) {

felipepiovezan wrote:

Mmmm it is a weak pointer + integer. How cheap is it to copy a weak pointer?

https://github.com/llvm/llvm-project/pull/143572
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] Show coro_frame in `std::coroutine_handle` pretty printer (PR #141516)

2025-06-10 Thread Adrian Vogelsgesang via lldb-commits


https://github.com/vogelsgesang updated 
https://github.com/llvm/llvm-project/pull/141516

>From 82aa5d13eb9cc73c7e45cb3f4a9e32cd5639 Mon Sep 17 00:00:00 2001
From: Adrian Vogelsgesang 
Date: Fri, 23 May 2025 01:20:46 +
Subject: [PATCH] [lldb] Show coro_frame in `std::coroutine_handle` pretty
 printer

This commit adjusts the pretty printer for `std::corotoutine_handle`
based on recent personal experiences with debugging C++20 coroutines:

1. It adds the `coro_frame` member. This member exposes the complete
   coroutine frame contents, including the suspension point id and all
   internal variables which the compiler decided to persist into the
   coroutine frame. While this data is highly compiler-specific,
   inspecting it can help identify the internal state of suspended
   coroutines.
2. It includes the `promise` and `coro_frame` members, even if
   devirtualization failed and we could not infer the promise type / the
   coro_frame type. Having them available as `void*` pointers can still
   be useful to identify, e.g., which two coroutines have the same frame
   / promise pointers.
---
 .../lldb/DataFormatters/TypeSynthetic.h   |   2 +-
 lldb/source/DataFormatters/TypeSynthetic.cpp  |   6 +-
 .../Plugins/Language/CPlusPlus/Coroutines.cpp | 146 --
 .../Plugins/Language/CPlusPlus/Coroutines.h   |   4 +-
 .../coroutine_handle/TestCoroutineHandle.py   |  46 --
 5 files changed, 102 insertions(+), 102 deletions(-)

diff --git a/lldb/include/lldb/DataFormatters/TypeSynthetic.h 
b/lldb/include/lldb/DataFormatters/TypeSynthetic.h
index 37f02fb8f7ce5..11a4ca2cd8330 100644
--- a/lldb/include/lldb/DataFormatters/TypeSynthetic.h
+++ b/lldb/include/lldb/DataFormatters/TypeSynthetic.h
@@ -92,7 +92,7 @@ class SyntheticChildrenFrontEnd {
   lldb::ValueObjectSP
   CreateValueObjectFromAddress(llvm::StringRef name, uint64_t address,
const ExecutionContext &exe_ctx,
-   CompilerType type);
+   CompilerType type, bool do_deref = true);
 
   lldb::ValueObjectSP CreateValueObjectFromData(llvm::StringRef name,
 const DataExtractor &data,
diff --git a/lldb/source/DataFormatters/TypeSynthetic.cpp 
b/lldb/source/DataFormatters/TypeSynthetic.cpp
index 57009b07dc553..33af0ad63077f 100644
--- a/lldb/source/DataFormatters/TypeSynthetic.cpp
+++ b/lldb/source/DataFormatters/TypeSynthetic.cpp
@@ -138,9 +138,9 @@ lldb::ValueObjectSP 
SyntheticChildrenFrontEnd::CreateValueObjectFromExpression(
 
 lldb::ValueObjectSP SyntheticChildrenFrontEnd::CreateValueObjectFromAddress(
 llvm::StringRef name, uint64_t address, const ExecutionContext &exe_ctx,
-CompilerType type) {
-  ValueObjectSP valobj_sp(
-  ValueObject::CreateValueObjectFromAddress(name, address, exe_ctx, type));
+CompilerType type, bool do_deref) {
+  ValueObjectSP valobj_sp(ValueObject::CreateValueObjectFromAddress(
+  name, address, exe_ctx, type, do_deref));
   if (valobj_sp)
 valobj_sp->SetSyntheticChildrenGenerated(true);
   return valobj_sp;
diff --git a/lldb/source/Plugins/Language/CPlusPlus/Coroutines.cpp 
b/lldb/source/Plugins/Language/CPlusPlus/Coroutines.cpp
index 9d84af4a85384..69e420c60cbd8 100644
--- a/lldb/source/Plugins/Language/CPlusPlus/Coroutines.cpp
+++ b/lldb/source/Plugins/Language/CPlusPlus/Coroutines.cpp
@@ -11,8 +11,6 @@
 #include "Plugins/TypeSystem/Clang/TypeSystemClang.h"
 #include "lldb/Symbol/Function.h"
 #include "lldb/Symbol/VariableList.h"
-#include "lldb/Utility/LLDBLog.h"
-#include "lldb/Utility/Log.h"
 
 using namespace lldb;
 using namespace lldb_private;
@@ -61,19 +59,23 @@ static Function *ExtractDestroyFunction(lldb::TargetSP 
target_sp,
   return destroy_func_address.CalculateSymbolContextFunction();
 }
 
-static CompilerType InferPromiseType(Function &destroy_func) {
-  Block &block = destroy_func.GetBlock(true);
+// clang generates aritifical `__promise` and `__coro_frame` variables inside
+// the destroy function. Look for those variables and extract their type.
+static CompilerType InferArtificialCoroType(Function *destroy_func,
+ConstString var_name) {
+  if (!destroy_func)
+return {};
+
+  Block &block = destroy_func->GetBlock(true);
   auto variable_list = block.GetBlockVariableList(true);
 
-  // clang generates an artificial `__promise` variable inside the
-  // `destroy` function. Look for it.
-  auto promise_var = variable_list->FindVariable(ConstString("__promise"));
-  if (!promise_var)
+  auto var = variable_list->FindVariable(var_name);
+  if (!var)
 return {};
-  if (!promise_var->IsArtificial())
+  if (!var->IsArtificial())
 return {};
 
-  Type *promise_type = promise_var->GetType();
+  Type *promise_type = var->GetType();
   if (!promise_type)
 return {};
   return promise_type->GetForwardCompilerType();
@@ -107,30 +109,17 @@ 
lldb_private::formatters::StdlibCoroutineHand

[Lldb-commits] [lldb] [lldb][nfc] Factor out code checking if Variable is in scope (PR #143572)

2025-06-10 Thread Jonas Devlieghere via lldb-commits



@@ -321,6 +302,27 @@ bool Variable::IsInScope(StackFrame *frame) {
   return false;
 }
 
+bool Variable::IsInScope(Block &block, Address addr) {

JDevlieghere wrote:

A quick grep shows 223 instances of it being passed by const ref and the class 
itself seems to be taking other Addresses by const-ref too. There are 
definitely a bunch of instances of it being passed by value, but I would say 
"it's only slightly more expensive" isn't a strong argument unless there's a 
benefit to weigh that against such as needing a copy to modify or something. My 
final argument would be that if we ever do [address 
spaces](https://lists.llvm.org/pipermail/lldb-dev/2020-October/016517.html), 
the class will grow, which makes the case for the reference more compelling. 

https://github.com/llvm/llvm-project/pull/143572
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] Show coro_frame in `std::coroutine_handle` pretty printer (PR #141516)

2025-06-10 Thread Adrian Vogelsgesang via lldb-commits


vogelsgesang wrote:

@labath @adrian-prantl friendly ping 🙂 

https://github.com/llvm/llvm-project/pull/141516
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb/aarch64] Fix PC register info augmentation (PR #143499)

2025-06-10 Thread Jason Molenda via lldb-commits


jasonmolenda wrote:

Thanks for help, I didn't realize I regressed this with my NFC reorg.

https://github.com/llvm/llvm-project/pull/143499
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] add plugin names to process save-core error output. (PR #143126)

2025-06-10 Thread Ebuka Ezike via lldb-commits


https://github.com/da-viper updated 
https://github.com/llvm/llvm-project/pull/143126

>From 95c61d6a917060d7b3a2bc554575eb6a1086ed6e Mon Sep 17 00:00:00 2001
From: Ebuka Ezike 
Date: Fri, 6 Jun 2025 13:15:41 +0100
Subject: [PATCH 1/6] [lldb] add plugin names to process save-core error
 output.

---
 lldb/include/lldb/Core/PluginManager.h |  2 ++
 lldb/source/Core/PluginManager.cpp | 10 ++
 lldb/source/Symbol/SaveCoreOptions.cpp | 22 --
 3 files changed, 32 insertions(+), 2 deletions(-)

diff --git a/lldb/include/lldb/Core/PluginManager.h 
b/lldb/include/lldb/Core/PluginManager.h
index e2f709ecd2ff7..7996dc3fdf3f3 100644
--- a/lldb/include/lldb/Core/PluginManager.h
+++ b/lldb/include/lldb/Core/PluginManager.h
@@ -212,6 +212,8 @@ class PluginManager {
   static Status SaveCore(const lldb::ProcessSP &process_sp,
  lldb_private::SaveCoreOptions &core_options);
 
+  static llvm::SmallVector GetSaveCorePluginNames();
+
   // ObjectContainer
   static bool RegisterPlugin(
   llvm::StringRef name, llvm::StringRef description,
diff --git a/lldb/source/Core/PluginManager.cpp 
b/lldb/source/Core/PluginManager.cpp
index de815e6308838..d02e3030081dc 100644
--- a/lldb/source/Core/PluginManager.cpp
+++ b/lldb/source/Core/PluginManager.cpp
@@ -800,6 +800,16 @@ Status PluginManager::SaveCore(const lldb::ProcessSP 
&process_sp,
   return error;
 }
 
+llvm::SmallVector PluginManager::GetSaveCorePluginNames() {
+  llvm::SmallVector plugin_names;
+  auto instances = GetObjectFileInstances().GetSnapshot();
+  for (auto &instance : instances) {
+if (instance.save_core)
+  plugin_names.emplace_back(instance.name);
+  }
+  return plugin_names;
+}
+
 #pragma mark ObjectContainer
 
 struct ObjectContainerInstance
diff --git a/lldb/source/Symbol/SaveCoreOptions.cpp 
b/lldb/source/Symbol/SaveCoreOptions.cpp
index d884b00a47b00..c1c85571c8a78 100644
--- a/lldb/source/Symbol/SaveCoreOptions.cpp
+++ b/lldb/source/Symbol/SaveCoreOptions.cpp
@@ -22,8 +22,26 @@ Status SaveCoreOptions::SetPluginName(const char *name) {
   }
 
   if (!PluginManager::IsRegisteredObjectFilePluginName(name)) {
-return Status::FromErrorStringWithFormat(
-"plugin name '%s' is not a valid ObjectFile plugin name", name);
+StreamString stream;
+stream.Printf("plugin name '%s' is not a valid ObjectFile plugin name.",
+  name);
+
+llvm::SmallVector plugin_names =
+PluginManager::GetSaveCorePluginNames();
+if (!plugin_names.empty()) {
+  stream.PutCString(" valid values are: ");
+  bool is_first = true;
+  for (llvm::StringRef plugin_name : plugin_names) {
+llvm::StringRef delimiter = ", ";
+if (is_first) {
+  delimiter = "";
+  is_first = false;
+}
+stream.Printf("%s\"%s\"", delimiter.data(), plugin_name.data());
+  }
+  stream.PutChar('.');
+}
+return Status(stream.GetString().str());
   }
 
   m_plugin_name = name;

>From de106f4b8d350c8ffb8a2b40906a1ce72df3e9a1 Mon Sep 17 00:00:00 2001
From: Ebuka Ezike 
Date: Sun, 8 Jun 2025 19:33:01 +0100
Subject: [PATCH 2/6] add help and completion

---
 .../lldb/Interpreter/CommandCompletions.h |  4 
 .../Interpreter/CommandOptionArgumentTable.h  |  3 +++
 lldb/include/lldb/lldb-enumerations.h |  4 +++-
 lldb/source/Commands/CommandCompletions.cpp   | 12 ++
 lldb/source/Commands/CommandObjectProcess.cpp | 23 ++-
 lldb/source/Commands/Options.td   |  3 ++-
 lldb/source/Core/PluginManager.cpp|  6 +
 lldb/source/Symbol/SaveCoreOptions.cpp| 13 +++
 8 files changed, 55 insertions(+), 13 deletions(-)

diff --git a/lldb/include/lldb/Interpreter/CommandCompletions.h 
b/lldb/include/lldb/Interpreter/CommandCompletions.h
index c7292b3b1471a..354debbc7d7bf 100644
--- a/lldb/include/lldb/Interpreter/CommandCompletions.h
+++ b/lldb/include/lldb/Interpreter/CommandCompletions.h
@@ -97,6 +97,10 @@ class CommandCompletions {
   static void ProcessNames(CommandInterpreter &interpreter,
CompletionRequest &request, SearchFilter *searcher);
 
+  static void ProcessSaveCorePluginNames(CommandInterpreter &interpreter,
+ CompletionRequest &request,
+ SearchFilter *searcher);
+
   static void DisassemblyFlavors(CommandInterpreter &interpreter,
  CompletionRequest &request,
  SearchFilter *searcher);
diff --git a/lldb/include/lldb/Interpreter/CommandOptionArgumentTable.h 
b/lldb/include/lldb/Interpreter/CommandOptionArgumentTable.h
index 1875ff6a048d4..d22e3842214dd 100644
--- a/lldb/include/lldb/Interpreter/CommandOptionArgumentTable.h
+++ b/lldb/include/lldb/Interpreter/CommandOptionArgumentTable.h
@@ -198,6 +198,8 @@ static constexpr OptionEnumValueElement g_completion_type[] 
= {
  "Completes to a ty

[Lldb-commits] [lldb] eb76d83 - Reland "[lldb][headers] Create script to fix up versioning" (#142864)" (#142871)

2025-06-10 Thread via lldb-commits


Author: Chelsea Cassanova
Date: 2025-06-10T09:47:11-07:00
New Revision: eb76d8332e932dfda133fe95331e6910805a27c5

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

LOG: Reland "[lldb][headers] Create script to fix up versioning" (#142864)" 
(#142871)

This relands the original commit for the versioning script in LLDB. This
commit uses '>' for output from `unifdef` for platforms that have that
executable but do not have the `-o` option. It also fixes the Xcode
build by adding a dependency between the liblldb-header-staging target
in the source/API/CMakeLists.txt the `liblldb-resource-headers` target
in LLDBFramework.cmake.

Original patch: https://github.com/llvm/llvm-project/pull/141116

Added: 
lldb/scripts/version-header-fix.py
lldb/test/Shell/Scripts/Inputs/lldb-defines.h
lldb/test/Shell/Scripts/TestVersionFixScript.test

Modified: 
lldb/cmake/modules/LLDBFramework.cmake
lldb/scripts/framework-header-fix.sh
lldb/source/API/CMakeLists.txt

Removed: 




diff  --git a/lldb/cmake/modules/LLDBFramework.cmake 
b/lldb/cmake/modules/LLDBFramework.cmake
index 471aeaaad3c0d..8961b1afe93ad 100644
--- a/lldb/cmake/modules/LLDBFramework.cmake
+++ b/lldb/cmake/modules/LLDBFramework.cmake
@@ -107,6 +107,9 @@ endforeach()
 # Wrap output in a target, so lldb-framework can depend on it.
 add_custom_target(liblldb-resource-headers DEPENDS lldb-sbapi-dwarf-enums 
${lldb_staged_headers})
 set_target_properties(liblldb-resource-headers PROPERTIES FOLDER 
"LLDB/Resources")
+# We're taking the header files from where they've been staged in the build 
directory's include folder,
+# so create a dependency on the build step that creates that directory.
+add_dependencies(liblldb-resource-headers liblldb-header-staging)
 add_dependencies(liblldb liblldb-resource-headers)
 
 # At build time, copy the staged headers into the framework bundle (and do

diff  --git a/lldb/scripts/framework-header-fix.sh 
b/lldb/scripts/framework-header-fix.sh
index 3459dd91c9ec1..345579c80cdf5 100755
--- a/lldb/scripts/framework-header-fix.sh
+++ b/lldb/scripts/framework-header-fix.sh
@@ -7,11 +7,5 @@ for file in `find $1 -name "*.h"`
 do
   /usr/bin/sed -i.bak 's/\(#include\)[ ]*"lldb\/\(API\/\)\{0,1\}\(.*\)"/\1 
/1' "$file"
   /usr/bin/sed -i.bak 's|  LLDB_MAJOR_VERSION 
LLDB_MINOR_VERSION LLDB_PATCH_VERSION
+
+This script uncomments and populates the versioning information in 
lldb-defines.h
+"""
+
+import argparse
+import os
+import re
+
+LLDB_VERSION_REGEX = re.compile(r"//\s*#define LLDB_VERSION\s*$", re.M)
+LLDB_REVISION_REGEX = re.compile(r"//\s*#define LLDB_REVISION\s*$", re.M)
+LLDB_VERSION_STRING_REGEX = re.compile(r"//\s*#define 
LLDB_VERSION_STRING\s*$", re.M)
+
+
+def main():
+parser = argparse.ArgumentParser()
+parser.add_argument("input_path")
+parser.add_argument("output_path")
+parser.add_argument("lldb_version_major")
+parser.add_argument("lldb_version_minor")
+parser.add_argument("lldb_version_patch")
+args = parser.parse_args()
+input_path = str(args.input_path)
+output_path = str(args.output_path)
+lldb_version_major = args.lldb_version_major
+lldb_version_minor = args.lldb_version_minor
+lldb_version_patch = args.lldb_version_patch
+
+with open(input_path, "r") as input_file:
+lines = input_file.readlines()
+file_buffer = "".join(lines)
+
+with open(output_path, "w") as output_file:
+# For the defines in lldb-defines.h that define the major, minor and 
version string
+# uncomment each define and populate its value using the arguments 
passed in.
+# e.g. //#define LLDB_VERSION -> #define LLDB_VERSION 

+file_buffer = re.sub(
+LLDB_VERSION_REGEX,
+r"#define LLDB_VERSION " + lldb_version_major,
+file_buffer,
+)
+
+file_buffer = re.sub(
+LLDB_REVISION_REGEX,
+r"#define LLDB_REVISION " + lldb_version_patch,
+file_buffer,
+)
+file_buffer = re.sub(
+LLDB_VERSION_STRING_REGEX,
+r'#define LLDB_VERSION_STRING "{0}.{1}.{2}"'.format(
+lldb_version_major, lldb_version_minor, lldb_version_patch
+),
+file_buffer,
+)
+output_file.write(file_buffer)
+
+
+if __name__ == "__main__":
+main()

diff  --git a/lldb/source/API/CMakeLists.txt b/lldb/source/API/CMakeLists.txt
index f5b25237d1edb..2772aa920411f 100644
--- a/lldb/source/API/CMakeLists.txt
+++ b/lldb/source/API/CMakeLists.txt
@@ -292,6 +292,45 @@ else()
   endif()
 endif()
 
+# Stage all headers in the include directory in the build dir.
+file(GLOB public_headers ${LLDB_SOURCE_DIR}/include/lldb/API/*.h)
+set(lldb_header_staging_dir ${CMAKE_BINARY_DIR}/include/lld

[Lldb-commits] [lldb] Reland "[lldb][headers] Create script to fix up versioning" (#142864)" (PR #142871)

2025-06-10 Thread Chelsea Cassanova via lldb-commits


https://github.com/chelcassanova closed 
https://github.com/llvm/llvm-project/pull/142871
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] Add MCP support to LLDB (PoC) (PR #143628)

2025-06-10 Thread Jonas Devlieghere via lldb-commits


https://github.com/JDevlieghere created 
https://github.com/llvm/llvm-project/pull/143628

None

>From 621d239bf5221433a2fb0ebf6858a814f38b9241 Mon Sep 17 00:00:00 2001
From: Jonas Devlieghere 
Date: Wed, 4 Jun 2025 23:56:57 -0700
Subject: [PATCH] [lldb] Add MCP support to LLDB (PoC)

---
 lldb/include/lldb/MCP/MCPError.h  |  33 +++
 lldb/include/lldb/MCP/Protocol.h  | 131 +
 lldb/include/lldb/MCP/Server.h|  67 +
 lldb/include/lldb/MCP/Tool.h  |  45 
 lldb/include/lldb/MCP/Transport.h | 100 +++
 lldb/source/CMakeLists.txt|   1 +
 lldb/source/Commands/CMakeLists.txt   |   2 +
 lldb/source/Commands/CommandObjectMCP.cpp | 162 +++
 lldb/source/Commands/CommandObjectMCP.h   |  24 ++
 .../source/Interpreter/CommandInterpreter.cpp |   2 +
 lldb/source/MCP/CMakeLists.txt|  14 +
 lldb/source/MCP/MCPError.cpp  |  31 +++
 lldb/source/MCP/Protocol.cpp  | 180 +
 lldb/source/MCP/Server.cpp| 251 ++
 lldb/source/MCP/Tool.cpp  |  28 ++
 lldb/source/MCP/Transport.cpp | 109 
 lldb/tools/CMakeLists.txt |   1 +
 lldb/tools/lldb-mcp/CMakeLists.txt|  25 ++
 lldb/tools/lldb-mcp/OutputRedirector.cpp  | 111 
 lldb/tools/lldb-mcp/OutputRedirector.h|  57 
 lldb/tools/lldb-mcp/lldb-mcp.cpp  | 146 ++
 21 files changed, 1520 insertions(+)
 create mode 100644 lldb/include/lldb/MCP/MCPError.h
 create mode 100644 lldb/include/lldb/MCP/Protocol.h
 create mode 100644 lldb/include/lldb/MCP/Server.h
 create mode 100644 lldb/include/lldb/MCP/Tool.h
 create mode 100644 lldb/include/lldb/MCP/Transport.h
 create mode 100644 lldb/source/Commands/CommandObjectMCP.cpp
 create mode 100644 lldb/source/Commands/CommandObjectMCP.h
 create mode 100644 lldb/source/MCP/CMakeLists.txt
 create mode 100644 lldb/source/MCP/MCPError.cpp
 create mode 100644 lldb/source/MCP/Protocol.cpp
 create mode 100644 lldb/source/MCP/Server.cpp
 create mode 100644 lldb/source/MCP/Tool.cpp
 create mode 100644 lldb/source/MCP/Transport.cpp
 create mode 100644 lldb/tools/lldb-mcp/CMakeLists.txt
 create mode 100644 lldb/tools/lldb-mcp/OutputRedirector.cpp
 create mode 100644 lldb/tools/lldb-mcp/OutputRedirector.h
 create mode 100644 lldb/tools/lldb-mcp/lldb-mcp.cpp

diff --git a/lldb/include/lldb/MCP/MCPError.h b/lldb/include/lldb/MCP/MCPError.h
new file mode 100644
index 0..2e3bbb6766747
--- /dev/null
+++ b/lldb/include/lldb/MCP/MCPError.h
@@ -0,0 +1,33 @@
+//===-- DAPError.h 
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "Protocol.h"
+#include "llvm/Support/Error.h"
+#include 
+
+namespace lldb_private::mcp {
+
+class MCPError : public llvm::ErrorInfo {
+public:
+  static char ID;
+
+  MCPError(std::string message, int64_t error_code);
+
+  void log(llvm::raw_ostream &OS) const override;
+  std::error_code convertToErrorCode() const override;
+
+  const std::string &getMessage() const { return m_message; }
+
+  protocol::Error toProtcolError() const;
+
+private:
+  std::string m_message;
+  int64_t m_error_code;
+};
+
+} // namespace lldb_private::mcp
diff --git a/lldb/include/lldb/MCP/Protocol.h b/lldb/include/lldb/MCP/Protocol.h
new file mode 100644
index 0..e661c3f7643af
--- /dev/null
+++ b/lldb/include/lldb/MCP/Protocol.h
@@ -0,0 +1,131 @@
+//===- Protocol.h 
-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef LLDB_TOOLS_LLDB_MCP_PROTOCOL_H
+#define LLDB_TOOLS_LLDB_MCP_PROTOCOL_H
+
+#include "llvm/Support/JSON.h"
+#include 
+#include 
+
+namespace lldb_private::mcp::protocol {
+
+static llvm::StringLiteral kProtocolVersion = "2025-03-26";
+
+struct Request {
+  uint64_t id = 0;
+  std::string method;
+  std::optional params;
+};
+
+llvm::json::Value toJSON(const Request &);
+bool fromJSON(const llvm::json::Value &, Request &, llvm::json::Path);
+
+struct Error {
+  int64_t code = 0;
+  std::string message;
+  std::optional data;
+};
+
+llvm::json::Value toJSON(const Error &);
+bool fromJSON(const llvm::json::Value &, Error &, llvm::json::Path);
+
+struct ProtocolError {
+  uint64_t id = 0;
+  Error error;
+};
+
+llvm::json::Value toJSON(const ProtocolError &);
+bool fromJSON(const

[Lldb-commits] [lldb] [lldb] Add MCP support to LLDB (PoC) (PR #143628)

2025-06-10 Thread Jonas Devlieghere via lldb-commits


https://github.com/JDevlieghere edited 
https://github.com/llvm/llvm-project/pull/143628
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb/aarch64] Fix PC register info augmentation (PR #143499)

2025-06-10 Thread Pavel Labath via lldb-commits


https://github.com/labath created 
https://github.com/llvm/llvm-project/pull/143499

This fixes a regression caused by #139817, where we would fail to unwind (using 
eh_frame) when using debug stubs (like qemu) which do not provide eh_frame 
register numbers.

Unwinding fails because the unwinder tries to convert pc register number to the 
"eh_frame" scheme (and fails). Previously that worked because the code used a 
slightly different pattern which ended up comparing the number by converting it 
to the "generic" scheme (which we do provide).

I don't think that's a bug in the unwinder -- we just need to make sure we 
provide the register number all the time.

The associated test is not particularly useful, but I'm hoping it could be used 
to test other changes like this as well. Other register augmentation changes 
are tested in an end-to-end fashion (by injecting gdb-remote packets and then 
trying to read registers). That works well for testing the addition of 
subregisters, but it isn't particularly suitable for testing register numbers, 
as the only place (that I know of) where this manifests is during unwinding, 
and recreating an unwindable process in a test like this is fairly challenging.

Probably the best way to ensure coverage for this scenario would be to have 
lldb-server stop sending eh_frame register numbers (align it with other 
gdb-like stubs).

>From 71bbf816b98f957f3a24b27f2a8c04439c989cac Mon Sep 17 00:00:00 2001
From: Pavel Labath 
Date: Tue, 10 Jun 2025 11:46:07 +0200
Subject: [PATCH] [lldb/aarch64] Fix PC register info augmentation

This fixes a regression caused by #139817, where we would fail to unwind
(using eh_frame) when using debug stubs (like qemu) which do not provide
eh_frame register numbers.

Unwinding fails because the unwinder tries to convert pc register number
to the "eh_frame" scheme (and fails). Previously that worked because the
code used a slightly different pattern which ended up comparing the
number by converting it to the "generic" scheme (which we do provide).

I don't think that's a bug in the unwinder -- we just need to make sure
we provide the register number all the time.

The associated test is not particularly useful, but I'm hoping it could
be used to test other changes like this as well. Other register
augmentation changes are tested in an end-to-end fashion (by injecting
gdb-remote packets and then trying to read registers). That works well
for testing the addition of subregisters, but it isn't particularly
suitable for testing register numbers, as the only place (that I know
of) where this manifests is during unwinding, and recreating an
unwindable process in a test like this is fairly challenging.
---
 .../source/Plugins/ABI/AArch64/ABIAArch64.cpp |  5 +-
 lldb/unittests/ABI/AArch64/ABIAArch64Test.cpp | 68 +++
 lldb/unittests/ABI/AArch64/CMakeLists.txt |  9 +++
 lldb/unittests/ABI/CMakeLists.txt |  3 +
 lldb/unittests/CMakeLists.txt |  1 +
 5 files changed, 84 insertions(+), 2 deletions(-)
 create mode 100644 lldb/unittests/ABI/AArch64/ABIAArch64Test.cpp
 create mode 100644 lldb/unittests/ABI/AArch64/CMakeLists.txt
 create mode 100644 lldb/unittests/ABI/CMakeLists.txt

diff --git a/lldb/source/Plugins/ABI/AArch64/ABIAArch64.cpp 
b/lldb/source/Plugins/ABI/AArch64/ABIAArch64.cpp
index b9e7c698cdec0..e40d2c5fc121a 100644
--- a/lldb/source/Plugins/ABI/AArch64/ABIAArch64.cpp
+++ b/lldb/source/Plugins/ABI/AArch64/ABIAArch64.cpp
@@ -12,6 +12,7 @@
 #include "ABIMacOSX_arm64.h"
 #include "ABISysV_arm64.h"
 #include "Utility/ARM64_DWARF_Registers.h"
+#include "Utility/ARM64_ehframe_Registers.h"
 #include "lldb/Core/PluginManager.h"
 #include "lldb/Target/Process.h"
 
@@ -69,9 +70,9 @@ lldb::addr_t ABIAArch64::FixDataAddress(lldb::addr_t pc) {
 std::pair
 ABIAArch64::GetEHAndDWARFNums(llvm::StringRef name) {
   if (name == "pc")
-return {LLDB_INVALID_REGNUM, arm64_dwarf::pc};
+return {arm64_ehframe::pc, arm64_dwarf::pc};
   if (name == "cpsr")
-return {LLDB_INVALID_REGNUM, arm64_dwarf::cpsr};
+return {arm64_ehframe::cpsr, arm64_dwarf::cpsr};
   return MCBasedABI::GetEHAndDWARFNums(name);
 }
 
diff --git a/lldb/unittests/ABI/AArch64/ABIAArch64Test.cpp 
b/lldb/unittests/ABI/AArch64/ABIAArch64Test.cpp
new file mode 100644
index 0..7ae175a0d3a70
--- /dev/null
+++ b/lldb/unittests/ABI/AArch64/ABIAArch64Test.cpp
@@ -0,0 +1,68 @@
+//===-- ABIAArch64Test.cpp 
===//
+
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "Plugins/ABI/AArch64/ABIMacOSX_arm64.h"
+#include "Plugins/ABI/AArch64/ABISysV_arm64.h"
+#include "Utility/ARM64_DWARF_Registers.h"
+#include "Utility/ARM64_ehframe_Registers.h"
+#

[Lldb-commits] [lldb] [lldb/aarch64] Fix PC register info augmentation (PR #143499)

2025-06-10 Thread via lldb-commits


llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Pavel Labath (labath)


Changes

This fixes a regression caused by #139817, where we would fail to 
unwind (using eh_frame) when using debug stubs (like qemu) which do not provide 
eh_frame register numbers.

Unwinding fails because the unwinder tries to convert pc register number to the 
"eh_frame" scheme (and fails). Previously that worked because the code used a 
slightly different pattern which ended up comparing the number by converting it 
to the "generic" scheme (which we do provide).

I don't think that's a bug in the unwinder -- we just need to make sure we 
provide the register number all the time.

The associated test is not particularly useful, but I'm hoping it could be used 
to test other changes like this as well. Other register augmentation changes 
are tested in an end-to-end fashion (by injecting gdb-remote packets and then 
trying to read registers). That works well for testing the addition of 
subregisters, but it isn't particularly suitable for testing register numbers, 
as the only place (that I know of) where this manifests is during unwinding, 
and recreating an unwindable process in a test like this is fairly challenging.

Probably the best way to ensure coverage for this scenario would be to have 
lldb-server stop sending eh_frame register numbers (align it with other 
gdb-like stubs).

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


5 Files Affected:

- (modified) lldb/source/Plugins/ABI/AArch64/ABIAArch64.cpp (+3-2) 
- (added) lldb/unittests/ABI/AArch64/ABIAArch64Test.cpp (+68) 
- (added) lldb/unittests/ABI/AArch64/CMakeLists.txt (+9) 
- (added) lldb/unittests/ABI/CMakeLists.txt (+3) 
- (modified) lldb/unittests/CMakeLists.txt (+1) 


``diff
diff --git a/lldb/source/Plugins/ABI/AArch64/ABIAArch64.cpp 
b/lldb/source/Plugins/ABI/AArch64/ABIAArch64.cpp
index b9e7c698cdec0..e40d2c5fc121a 100644
--- a/lldb/source/Plugins/ABI/AArch64/ABIAArch64.cpp
+++ b/lldb/source/Plugins/ABI/AArch64/ABIAArch64.cpp
@@ -12,6 +12,7 @@
 #include "ABIMacOSX_arm64.h"
 #include "ABISysV_arm64.h"
 #include "Utility/ARM64_DWARF_Registers.h"
+#include "Utility/ARM64_ehframe_Registers.h"
 #include "lldb/Core/PluginManager.h"
 #include "lldb/Target/Process.h"
 
@@ -69,9 +70,9 @@ lldb::addr_t ABIAArch64::FixDataAddress(lldb::addr_t pc) {
 std::pair
 ABIAArch64::GetEHAndDWARFNums(llvm::StringRef name) {
   if (name == "pc")
-return {LLDB_INVALID_REGNUM, arm64_dwarf::pc};
+return {arm64_ehframe::pc, arm64_dwarf::pc};
   if (name == "cpsr")
-return {LLDB_INVALID_REGNUM, arm64_dwarf::cpsr};
+return {arm64_ehframe::cpsr, arm64_dwarf::cpsr};
   return MCBasedABI::GetEHAndDWARFNums(name);
 }
 
diff --git a/lldb/unittests/ABI/AArch64/ABIAArch64Test.cpp 
b/lldb/unittests/ABI/AArch64/ABIAArch64Test.cpp
new file mode 100644
index 0..7ae175a0d3a70
--- /dev/null
+++ b/lldb/unittests/ABI/AArch64/ABIAArch64Test.cpp
@@ -0,0 +1,68 @@
+//===-- ABIAArch64Test.cpp 
===//
+
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "Plugins/ABI/AArch64/ABIMacOSX_arm64.h"
+#include "Plugins/ABI/AArch64/ABISysV_arm64.h"
+#include "Utility/ARM64_DWARF_Registers.h"
+#include "Utility/ARM64_ehframe_Registers.h"
+#include "lldb/Target/DynamicRegisterInfo.h"
+#include "lldb/Utility/ArchSpec.h"
+#include "llvm/Support/ManagedStatic.h"
+#include "llvm/Support/TargetSelect.h"
+#include "gtest/gtest.h"
+#include 
+
+using namespace lldb_private;
+using namespace lldb;
+
+class ABIAArch64TestFixture : public testing::TestWithParam {
+public:
+  static void SetUpTestCase();
+  static void TearDownTestCase();
+
+  //  virtual void SetUp() override { }
+  //  virtual void TearDown() override { }
+
+protected:
+};
+
+void ABIAArch64TestFixture::SetUpTestCase() {
+  LLVMInitializeAArch64TargetInfo();
+  LLVMInitializeAArch64TargetMC();
+  ABISysV_arm64::Initialize();
+  ABIMacOSX_arm64::Initialize();
+}
+
+void ABIAArch64TestFixture::TearDownTestCase() {
+  ABISysV_arm64::Terminate();
+  ABIMacOSX_arm64::Terminate();
+  llvm::llvm_shutdown();
+}
+
+TEST_P(ABIAArch64TestFixture, AugmentRegisterInfo) {
+  ABISP abi_sp = ABI::FindPlugin(ProcessSP(), ArchSpec(GetParam()));
+  ASSERT_TRUE(abi_sp);
+  using Register = DynamicRegisterInfo::Register;
+
+  Register pc{ConstString("pc"), ConstString(), ConstString("GPR")};
+  std::vector regs{pc};
+
+  abi_sp->AugmentRegisterInfo(regs);
+
+  ASSERT_EQ(regs.size(), 1);
+  Register new_pc = regs[0];
+  EXPECT_EQ(new_pc.name, pc.name);
+  EXPECT_EQ(new_pc.set_name, pc.set_name);
+  EXPECT_EQ(new_pc.regnum_ehframe, arm64_ehframe::pc);
+  EXPECT_EQ(new_pc.regnum_dwarf, arm64_dwarf::pc);
+}
+
+INSTANTIATE_TEST_S

[Lldb-commits] [lldb] 95b5b68 - [lldb][test] Add test for handling conflicting Objective-C NS_OPTIONS typedefs

2025-06-10 Thread Michael Buch via lldb-commits


Author: Michael Buch
Date: 2025-06-10T10:58:16+01:00
New Revision: 95b5b6801ce4c08e1bc92616321cd4127e7c0957

URL: 
https://github.com/llvm/llvm-project/commit/95b5b6801ce4c08e1bc92616321cd4127e7c0957
DIFF: 
https://github.com/llvm/llvm-project/commit/95b5b6801ce4c08e1bc92616321cd4127e7c0957.diff

LOG: [lldb][test] Add test for handling conflicting Objective-C NS_OPTIONS 
typedefs

Add test that checks whether the expression evaluator can handle
the `NS_ENUM`/`NS_OPTIONS` typedefs from Objective-C `CoreFoundation`.
In the test, `module.h` mimicks the `NS_OPTIONS` typedef from `CoreFoundation`.

The `ClangModulesDeclVendor` currently compiles modules as
C++, so the `MyInt` Clang decl in the module will be a `TypedefType`,
while the DWARF AST parser will produce an `EnumType` (since that's what
the debug-info says). When the `ASTImporter` imports these decls into the
scratch AST, it will fail to re-use one or the other decl because they
aren't structurally equivalent (one is a typedef, the other an enum),
so we end up with two conflicting `MyInt` declarations in the scratch AST
and the expression fails to run due to ambiguity in name lookup.

rdar://151022173

Added: 
lldb/test/Shell/Expr/TestObjCxxEnumConflict.test

Modified: 


Removed: 




diff  --git a/lldb/test/Shell/Expr/TestObjCxxEnumConflict.test 
b/lldb/test/Shell/Expr/TestObjCxxEnumConflict.test
new file mode 100644
index 0..cf1f2c67e3880
--- /dev/null
+++ b/lldb/test/Shell/Expr/TestObjCxxEnumConflict.test
@@ -0,0 +1,54 @@
+# REQUIRES: system-darwin
+
+# Tests whether the expression evaluator can handle the `NS_ENUM`/`NS_OPTIONS`
+# typedefs from Objective-C `CoreFoundation`.
+# Here `module.h` mimicks the `NS_OPTIONS` typedef from `CoreFoundation`.
+# 
+# The `ClangModulesDeclVendor` currently compiles modules as
+# C++, so the `MyInt` Clang decl in the module will be a `TypedefType`,
+# while the DWARF AST parser will produce an `EnumType` (since that's what
+# the debug-info says). When the `ASTImporter` imports these decls into the
+# scratch AST, it will fail to re-use one or the other decl because they
+# aren't structurally equivalent (one is a typedef, the other an enum),
+# so we end up with two conflicting `MyInt` declarations in the scratch AST
+# and the expression fails to run due to ambiguity in name lookup.
+
+# RUN: split-file %s %t
+# RUN: %clang_host -g %t/main.m -fmodules -fcxx-modules -o %t.out
+# RUN: %lldb -x -b -s %t/commands.input %t.out -o exit 2>&1 \
+# RUN:   | FileCheck %s
+
+#--- main.m
+
+#import "module.h"
+
+int main() {
+MyInt i;
+return i;
+}
+
+#--- module.h
+
+#if (__cplusplus)
+typedef int MyInt;
+enum : MyInt { CASE };
+#else
+typedef enum MyInt : int MyInt;
+enum MyInt : int { CASE };
+#endif
+
+#--- module.modulemap
+module Int {
+header "module.h"
+}
+
+#--- commands.input
+
+break set -n main
+run
+expression -l objective-c -- (MyInt)5
+
+# CHECK: error: reference to 'MyInt' is ambiguous 
+# CHECK: error: reference to 'MyInt' is ambiguous 
+# CHECK: note: note: candidate found by name lookup is 'MyInt' 
+# CHECK: note: note: candidate found by name lookup is 'MyInt' 



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb-dap] Creating a 'capabilities' event helper. (PR #142831)

2025-06-10 Thread Jonas Devlieghere via lldb-commits


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


https://github.com/llvm/llvm-project/pull/142831
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] Add support for displaying `__float128` variables (PR #98369)

2025-06-10 Thread via lldb-commits


beetrees wrote:

Ping @JDevlieghere: I think this is ready to merge.

https://github.com/llvm/llvm-project/pull/98369
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] Reland "[lldb][headers] Create script to fix up versioning" (#142864)" (PR #142871)

2025-06-10 Thread Jonas Devlieghere via lldb-commits


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


https://github.com/llvm/llvm-project/pull/142871
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb-dap] Creating a 'capabilities' event helper. (PR #142831)

2025-06-10 Thread Jonas Devlieghere via lldb-commits


JDevlieghere wrote:

> I would go with either style2 or style 4 because of the default 
> initialisation needed in `fromJSON`

+1 on either 2 or 4.

https://github.com/llvm/llvm-project/pull/142831
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] 1cb906e - Minor fix to connect-url to support unix-connect sockets on localhost (#142875)

2025-06-10 Thread via lldb-commits


Author: satyajanga
Date: 2025-06-10T09:25:28-07:00
New Revision: 1cb906e8325d2b73054f2b4fa943b66377152f37

URL: 
https://github.com/llvm/llvm-project/commit/1cb906e8325d2b73054f2b4fa943b66377152f37
DIFF: 
https://github.com/llvm/llvm-project/commit/1cb906e8325d2b73054f2b4fa943b66377152f37.diff

LOG: Minor fix to connect-url to support unix-connect sockets on localhost 
(#142875)

**Summary:**

when the unix-socket connections on localhost are used to for platform
connect i.e.
`platform connect unix-connect:///path/to/socket.sock`
then `PlatformRemoteGDBServer.m_platform_hostname` is empty.

Based on the current logic, for the process attach, when the connection
param returned by platform server as qLaunchGDBServer is this
`socket_name:/path/to/processgdbserver.sock`
then the subsequent connect url for the process url looks like this
`unix-connect://[]/path/to/processgdbserver.sock` and the connection
fail.

This change is only adding the braces when the hostname is not empty.

**Test Plan:**

Added unittest and existing tests pass.
```
satyajanga@devvm21837:toolchain $ LLDB_COMMAND_TRACE=YES ./bin/llvm-lit 
--verbose  ~/llvm-sand/external/llvm-project/lldb/test/API/commands/platform
-- Testing: 9 tests, 9 workers --
UNSUPPORTED: lldb-api :: commands/platform/sdk/TestPlatformSDK.py (1 of 9)
PASS: lldb-api :: commands/platform/file/read/TestPlatformFileRead.py (2 of 9)
PASS: lldb-api :: commands/platform/file/close/TestPlatformFileClose.py (3 of 9)
PASS: lldb-api :: commands/platform/basic/TestPlatformPython.py (4 of 9)
PASS: lldb-api :: commands/platform/basic/TestPlatformCommand.py (5 of 9)
PASS: lldb-api :: commands/platform/process/launch/TestPlatformProcessLaunch.py 
(6 of 9)
PASS: lldb-api :: commands/platform/connect/TestPlatformConnect.py (7 of 9)
PASS: lldb-api :: 
commands/platform/launchgdbserver/TestPlatformLaunchGDBServer.py (8 of 9)
PASS: lldb-api :: commands/platform/process/list/TestProcessList.py (9 of 9)

Testing Time: 13.24s

Total Discovered Tests: 9
  Unsupported: 1 (11.11%)
  Passed : 8 (88.89%)
satyajanga@devvm21837:toolchain $ 

```


Reviewers:

@clayborg 
@Jlalond 

Subscribers:

Tasks:

Tags:

Added: 


Modified: 
lldb/source/Plugins/Platform/gdb-server/PlatformRemoteGDBServer.cpp
lldb/test/API/commands/platform/connect/TestPlatformConnect.py

Removed: 




diff  --git 
a/lldb/source/Plugins/Platform/gdb-server/PlatformRemoteGDBServer.cpp 
b/lldb/source/Plugins/Platform/gdb-server/PlatformRemoteGDBServer.cpp
index 26ca6ed128972..4a77423bac526 100644
--- a/lldb/source/Plugins/Platform/gdb-server/PlatformRemoteGDBServer.cpp
+++ b/lldb/source/Plugins/Platform/gdb-server/PlatformRemoteGDBServer.cpp
@@ -800,7 +800,10 @@ std::string PlatformRemoteGDBServer::MakeUrl(const char 
*scheme,
  const char *hostname,
  uint16_t port, const char *path) {
   StreamString result;
-  result.Printf("%s://[%s]", scheme, hostname);
+  result.Printf("%s://", scheme);
+  if (strlen(hostname) > 0)
+result.Printf("[%s]", hostname);
+
   if (port != 0)
 result.Printf(":%u", port);
   if (path)

diff  --git a/lldb/test/API/commands/platform/connect/TestPlatformConnect.py 
b/lldb/test/API/commands/platform/connect/TestPlatformConnect.py
index fc6c2ee98df44..5df0c16fbd1f7 100644
--- a/lldb/test/API/commands/platform/connect/TestPlatformConnect.py
+++ b/lldb/test/API/commands/platform/connect/TestPlatformConnect.py
@@ -57,3 +57,48 @@ def test_platform_process_connect(self):
 self.assertEqual(frame.GetFunction().GetName(), "main")
 self.assertEqual(frame.FindVariable("argc").GetValueAsSigned(), 2)
 process.Continue()
+
+@skipIfRemote
+@expectedFailureAll(hostoslist=["windows"], triple=".*-android")
+@skipIfDarwin  # lldb-server not found correctly
+@expectedFailureAll(oslist=["windows"])  # process modules not loaded
+# lldb-server platform times out waiting for the gdbserver port number to 
be
+# written to the pipe, yet it seems the gdbserver already has written it.
+@expectedFailureAll(
+archs=["aarch64"],
+oslist=["freebsd"],
+bugnumber="https://github.com/llvm/llvm-project/issues/84327";,
+)
+@add_test_categories(["lldb-server"])
+def test_platform_process_connect_with_unix_connect(self):
+self.build()
+lldb_temp_dir = 
lldb.SBHostOS.GetLLDBPath(lldb.ePathTypeLLDBTempSystemDir)
+named_pipe = "%s/platform_server.sock" % lldb_temp_dir
+port_file = self.getBuildArtifact("port")
+commandline_args = [
+"platform",
+"--listen",
+named_pipe,
+"--socket-file",
+port_file,
+"--",
+self.getBuildArtifact("a.out"),
+"foo",
+]
+self.spawnSubprocess(lldbgdbserverutils.get_lldb_server_exe(),

[Lldb-commits] [lldb] Minor fix to connect-url to support unix-connect sockets on localhost (PR #142875)

2025-06-10 Thread Jacob Lalonde via lldb-commits


https://github.com/Jlalond closed 
https://github.com/llvm/llvm-project/pull/142875
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb-dap] Reimplement `runInTerminal` with signals (PR #142374)

2025-06-10 Thread Pavel Labath via lldb-commits


labath wrote:

Sorry about the delay. I have very mixed feelings about this PR. I too found 
the existing method of synchronization extremely clunky, so I definitely 
wouldn't be sad to see it go. However, I also have some reservations about this 
implementation:
- you say you're assuming a single thread, but is that actually true. IIUC the 
signal receiving code runs inside the main lldb-dap process, which creates 
threads left and right. Your method of receiving a signal may not work reliably 
in a multithreaded process. We already have the MainLoop class, which knows how 
to wait for a signal in the presence of multiple threads. Unfortunately, it 
doesn't actually preserve the information about the sender. That should be 
relatively easy to fix though -- just have the signal handler save off the 
siginfo_t and then pass it to the callback. I would like to be able to 
reuse/extend that instead of building a new signal catching primitive.
- in the launcher process, I see that you're doing a fork -- and then exiting 
from the parent. This sounds like it could confuse some terminals, which may 
close the window once the process they launched exits. I think you're doing 
that because you want to be sure the child exits, but I don't think that's 
really necessary -- one can imagine synchronization protocols which don't 
require waiting in a third process. You just need to avoid SIGSTOPping the 
child process, which is another potential source of problems here.
- if the debugger attaches to the child process before it executes 
raise(SIGSTOP), the debugger will see one more stop by the child process than 
it might expect. Are you sure that's handled correctly here?

At the end of the day, I'm not really sure that signals are the best solution 
to this problem, as they interact strongly with the debugging APIs. The 
existing implementation was very.. baroque, but I think the choice of unix 
sockets was actually quite reasonable. With that in mind, let me propose an 
alternative protocol using (named) pipes:
- child gets the socket name, writes the pid to it, and waits for EOF, if EOF 
doesn't come, it exits
- parent listens on the socket, reads the pid, attaches to the process and then 
closes it

This doesn't require any signals, nor iostreams, and is mostly portable (we 
have a named pipe implementation for windows, and I believe we already use it 
in some situations).

https://github.com/llvm/llvm-project/pull/142374
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb][nfc] Factor out code checking if Variable is in scope (PR #143572)

2025-06-10 Thread Felipe de Azevedo Piovezan via lldb-commits


https://github.com/felipepiovezan created 
https://github.com/llvm/llvm-project/pull/143572

This is useful for checking whether a variable is in scope inside a specific 
block.

>From 9821fd7c4530819f131271f4325123a400ecded4 Mon Sep 17 00:00:00 2001
From: Felipe de Azevedo Piovezan 
Date: Tue, 10 Jun 2025 10:26:52 -0700
Subject: [PATCH] [lldb][nfc] Factor out code checking if Variable is in scope

This is useful for checking whether a variable is in scope inside a
specific block.
---
 lldb/include/lldb/Symbol/Variable.h |  3 ++
 lldb/source/Symbol/Variable.cpp | 46 +++--
 2 files changed, 27 insertions(+), 22 deletions(-)

diff --git a/lldb/include/lldb/Symbol/Variable.h 
b/lldb/include/lldb/Symbol/Variable.h
index c437624d1ea6d..b867369576a41 100644
--- a/lldb/include/lldb/Symbol/Variable.h
+++ b/lldb/include/lldb/Symbol/Variable.h
@@ -89,6 +89,9 @@ class Variable : public UserID, public 
std::enable_shared_from_this {
 
   bool IsInScope(StackFrame *frame);
 
+  /// Returns true if this variable is in scope at `addr` inside `block`.
+  bool IsInScope(Block &block, Address addr);
+
   bool LocationIsValidForFrame(StackFrame *frame);
 
   bool LocationIsValidForAddress(const Address &address);
diff --git a/lldb/source/Symbol/Variable.cpp b/lldb/source/Symbol/Variable.cpp
index 8244725aba545..0415758dd268a 100644
--- a/lldb/source/Symbol/Variable.cpp
+++ b/lldb/source/Symbol/Variable.cpp
@@ -290,28 +290,9 @@ bool Variable::IsInScope(StackFrame *frame) {
   // this variable was defined in is currently
   Block *deepest_frame_block =
   frame->GetSymbolContext(eSymbolContextBlock).block;
-  if (deepest_frame_block) {
-SymbolContext variable_sc;
-CalculateSymbolContext(&variable_sc);
-
-// Check for static or global variable defined at the compile unit
-// level that wasn't defined in a block
-if (variable_sc.block == nullptr)
-  return true;
-
-// Check if the variable is valid in the current block
-if (variable_sc.block != deepest_frame_block &&
-!variable_sc.block->Contains(deepest_frame_block))
-  return false;
-
-// If no scope range is specified then it means that the scope is the
-// same as the scope of the enclosing lexical block.
-if (m_scope_range.IsEmpty())
-  return true;
-
-addr_t file_address = frame->GetFrameCodeAddress().GetFileAddress();
-return m_scope_range.FindEntryThatContains(file_address) != nullptr;
-  }
+  Address frame_addr = frame->GetFrameCodeAddress();
+  if (deepest_frame_block)
+return IsInScope(*deepest_frame_block, frame_addr);
 }
 break;
 
@@ -321,6 +302,27 @@ bool Variable::IsInScope(StackFrame *frame) {
   return false;
 }
 
+bool Variable::IsInScope(Block &block, Address addr) {
+  SymbolContext variable_sc;
+  CalculateSymbolContext(&variable_sc);
+
+  // Check for static or global variable defined at the compile unit
+  // level that wasn't defined in a block
+  if (variable_sc.block == nullptr)
+return true;
+
+  // Check if the variable is valid in the current block
+  if (variable_sc.block != &block && !variable_sc.block->Contains(&block))
+return false;
+
+  // If no scope range is specified then it means that the scope is the
+  // same as the scope of the enclosing lexical block.
+  if (m_scope_range.IsEmpty())
+return true;
+
+  return m_scope_range.FindEntryThatContains(addr.GetFileAddress()) != nullptr;
+}
+
 Status Variable::GetValuesForVariableExpressionPath(
 llvm::StringRef variable_expr_path, ExecutionContextScope *scope,
 GetVariableCallback callback, void *baton, VariableList &variable_list,

___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] 74a012e - [lldb/aarch64] Fix PC register info augmentation (#143499)

2025-06-10 Thread via lldb-commits


Author: Pavel Labath
Date: 2025-06-10T19:50:33+02:00
New Revision: 74a012ed756f5280c71e281c0fd2dd50f83f38b7

URL: 
https://github.com/llvm/llvm-project/commit/74a012ed756f5280c71e281c0fd2dd50f83f38b7
DIFF: 
https://github.com/llvm/llvm-project/commit/74a012ed756f5280c71e281c0fd2dd50f83f38b7.diff

LOG: [lldb/aarch64] Fix PC register info augmentation (#143499)

This fixes a regression caused by #139817, where we would fail to unwind
(using eh_frame) when using debug stubs (like qemu) which do not provide
eh_frame register numbers.

Unwinding fails because the unwinder tries to convert pc register number
to the "eh_frame" scheme (and fails). Previously that worked because the
code used a slightly different pattern which ended up comparing the
number by converting it to the "generic" scheme (which we do provide).

I don't think that's a bug in the unwinder -- we just need to make sure
we provide the register number all the time.

The associated test is not particularly useful, but I'm hoping it could
be used to test other changes like this as well. Other register
augmentation changes are tested in an end-to-end fashion (by injecting
gdb-remote packets and then trying to read registers). That works well
for testing the addition of subregisters, but it isn't particularly
suitable for testing register numbers, as the only place (that I know
of) where this manifests is during unwinding, and recreating an
unwindable process in a test like this is fairly challenging.

Probably the best way to ensure coverage for this scenario would be to
have lldb-server stop sending eh_frame register numbers (align it with
other gdb-like stubs).

Added: 
lldb/unittests/ABI/AArch64/ABIAArch64Test.cpp
lldb/unittests/ABI/AArch64/CMakeLists.txt
lldb/unittests/ABI/CMakeLists.txt

Modified: 
lldb/source/Plugins/ABI/AArch64/ABIAArch64.cpp
lldb/unittests/CMakeLists.txt

Removed: 




diff  --git a/lldb/source/Plugins/ABI/AArch64/ABIAArch64.cpp 
b/lldb/source/Plugins/ABI/AArch64/ABIAArch64.cpp
index b9e7c698cdec0..e40d2c5fc121a 100644
--- a/lldb/source/Plugins/ABI/AArch64/ABIAArch64.cpp
+++ b/lldb/source/Plugins/ABI/AArch64/ABIAArch64.cpp
@@ -12,6 +12,7 @@
 #include "ABIMacOSX_arm64.h"
 #include "ABISysV_arm64.h"
 #include "Utility/ARM64_DWARF_Registers.h"
+#include "Utility/ARM64_ehframe_Registers.h"
 #include "lldb/Core/PluginManager.h"
 #include "lldb/Target/Process.h"
 
@@ -69,9 +70,9 @@ lldb::addr_t ABIAArch64::FixDataAddress(lldb::addr_t pc) {
 std::pair
 ABIAArch64::GetEHAndDWARFNums(llvm::StringRef name) {
   if (name == "pc")
-return {LLDB_INVALID_REGNUM, arm64_dwarf::pc};
+return {arm64_ehframe::pc, arm64_dwarf::pc};
   if (name == "cpsr")
-return {LLDB_INVALID_REGNUM, arm64_dwarf::cpsr};
+return {arm64_ehframe::cpsr, arm64_dwarf::cpsr};
   return MCBasedABI::GetEHAndDWARFNums(name);
 }
 

diff  --git a/lldb/unittests/ABI/AArch64/ABIAArch64Test.cpp 
b/lldb/unittests/ABI/AArch64/ABIAArch64Test.cpp
new file mode 100644
index 0..7ae175a0d3a70
--- /dev/null
+++ b/lldb/unittests/ABI/AArch64/ABIAArch64Test.cpp
@@ -0,0 +1,68 @@
+//===-- ABIAArch64Test.cpp 
===//
+
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "Plugins/ABI/AArch64/ABIMacOSX_arm64.h"
+#include "Plugins/ABI/AArch64/ABISysV_arm64.h"
+#include "Utility/ARM64_DWARF_Registers.h"
+#include "Utility/ARM64_ehframe_Registers.h"
+#include "lldb/Target/DynamicRegisterInfo.h"
+#include "lldb/Utility/ArchSpec.h"
+#include "llvm/Support/ManagedStatic.h"
+#include "llvm/Support/TargetSelect.h"
+#include "gtest/gtest.h"
+#include 
+
+using namespace lldb_private;
+using namespace lldb;
+
+class ABIAArch64TestFixture : public testing::TestWithParam {
+public:
+  static void SetUpTestCase();
+  static void TearDownTestCase();
+
+  //  virtual void SetUp() override { }
+  //  virtual void TearDown() override { }
+
+protected:
+};
+
+void ABIAArch64TestFixture::SetUpTestCase() {
+  LLVMInitializeAArch64TargetInfo();
+  LLVMInitializeAArch64TargetMC();
+  ABISysV_arm64::Initialize();
+  ABIMacOSX_arm64::Initialize();
+}
+
+void ABIAArch64TestFixture::TearDownTestCase() {
+  ABISysV_arm64::Terminate();
+  ABIMacOSX_arm64::Terminate();
+  llvm::llvm_shutdown();
+}
+
+TEST_P(ABIAArch64TestFixture, AugmentRegisterInfo) {
+  ABISP abi_sp = ABI::FindPlugin(ProcessSP(), ArchSpec(GetParam()));
+  ASSERT_TRUE(abi_sp);
+  using Register = DynamicRegisterInfo::Register;
+
+  Register pc{ConstString("pc"), ConstString(), ConstString("GPR")};
+  std::vector regs{pc};
+
+  abi_sp->AugmentRegisterInfo(regs);
+
+  ASSERT_EQ(regs.size(), 1);
+  Register new_pc = regs[0];
+  E

[Lldb-commits] [lldb] [lldb/aarch64] Fix PC register info augmentation (PR #143499)

2025-06-10 Thread Pavel Labath via lldb-commits


labath wrote:

Thanks.

https://github.com/llvm/llvm-project/pull/143499
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb/aarch64] Fix PC register info augmentation (PR #143499)

2025-06-10 Thread Pavel Labath via lldb-commits


https://github.com/labath closed 
https://github.com/llvm/llvm-project/pull/143499
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] Add a python JIT loader class. (PR #142514)

2025-06-10 Thread via lldb-commits


jimingham wrote:

It also seems architecturally wrong to try to guess and influence what 
BreakpointResolvers do behind their backs.  After all, the resolver might be 
just some Python Code you know nothing about.  How would you instrument that?  
If I set a regular expression name breakpoint, will you know to compare that 
regex against what the JIT produces?  What about source regular expression 
breakpoints?  Do you figure out what the containing source file is and observe 
that?

Having a system where "if you set these kinds of breakpoints we'll be able to 
intervene, but other breakpoint types just won't work" seems awkward.  If you 
are going to only support certain breakpoint types for JIT debugging, it seems 
much better to make that an explicit JIT breakpoint type writing a custom 
resolver that cooperates with your JIT engine to register interest and get 
called back when JIT events occur that are relevant to it.



https://github.com/llvm/llvm-project/pull/142514
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] 07a1d47 - [lldb-dap] Creating a 'capabilities' event helper. (#142831)

2025-06-10 Thread via lldb-commits


Author: John Harrison
Date: 2025-06-10T10:49:07-07:00
New Revision: 07a1d479cc4e2d529b04cecb2f97ff16f32ef197

URL: 
https://github.com/llvm/llvm-project/commit/07a1d479cc4e2d529b04cecb2f97ff16f32ef197
DIFF: 
https://github.com/llvm/llvm-project/commit/07a1d479cc4e2d529b04cecb2f97ff16f32ef197.diff

LOG: [lldb-dap] Creating a 'capabilities' event helper. (#142831)

This adds a new 'CapabilitiesEventBody' type for having a well
structured type for the event and updates the 'restart' request
to dynamically set their capabilities.

Added: 
lldb/tools/lldb-dap/Protocol/ProtocolEvents.cpp
lldb/tools/lldb-dap/Protocol/ProtocolEvents.h

Modified: 
lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
lldb/packages/Python/lldbsuite/test/tools/lldb-dap/lldbdap_testcase.py
lldb/test/API/tools/lldb-dap/launch/TestDAP_launch.py
lldb/tools/lldb-dap/CMakeLists.txt
lldb/tools/lldb-dap/EventHelper.cpp
lldb/tools/lldb-dap/EventHelper.h
lldb/tools/lldb-dap/Handler/ConfigurationDoneRequestHandler.cpp
lldb/tools/lldb-dap/Handler/RequestHandler.h
lldb/tools/lldb-dap/Handler/RestartRequestHandler.cpp
lldb/tools/lldb-dap/Protocol/ProtocolBase.h
lldb/unittests/DAP/ProtocolTypesTest.cpp

Removed: 




diff  --git a/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py 
b/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
index 71bae5c4ea035..9786678aa53f9 100644
--- a/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
+++ b/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
@@ -135,6 +135,10 @@ def as_dict(self):
 return source_dict
 
 
+class NotSupportedError(KeyError):
+"""Raised if a feature is not supported due to its capabilities."""
+
+
 class DebugCommunication(object):
 def __init__(
 self,
@@ -153,7 +157,7 @@ def __init__(
 self.recv_thread = threading.Thread(target=self._read_packet_thread)
 self.process_event_body = None
 self.exit_status: Optional[int] = None
-self.initialize_body = None
+self.capabilities: dict[str, Any] = {}
 self.progress_events: list[Event] = []
 self.reverse_requests = []
 self.sequence = 1
@@ -300,6 +304,9 @@ def _handle_recv_packet(self, packet: 
Optional[ProtocolMessage]) -> bool:
 elif event == "breakpoint":
 # Breakpoint events are sent when a breakpoint is resolved
 self._update_verified_breakpoints([body["breakpoint"]])
+elif event == "capabilities":
+# Update the capabilities with new ones from the event.
+self.capabilities.update(body["capabilities"])
 
 elif packet_type == "response":
 if packet["command"] == "disconnect":
@@ -487,13 +494,13 @@ def wait_for_terminated(self, timeout: Optional[float] = 
None):
 raise ValueError("didn't get terminated event")
 return event_dict
 
-def get_initialize_value(self, key):
+def get_capability(self, key):
 """Get a value for the given key if it there is a key/value pair in
-the "initialize" request response body.
+the capabilities reported by the adapter.
 """
-if self.initialize_body and key in self.initialize_body:
-return self.initialize_body[key]
-return None
+if key in self.capabilities:
+return self.capabilities[key]
+raise NotSupportedError(key)
 
 def get_threads(self):
 if self.threads is None:
@@ -759,6 +766,9 @@ def request_continue(self, threadId=None, 
singleThread=False):
 return response
 
 def request_restart(self, restartArguments=None):
+if self.exit_status is not None:
+raise ValueError("request_restart called after process exited")
+self.get_capability("supportsRestartRequest")
 command_dict = {
 "command": "restart",
 "type": "request",
@@ -866,7 +876,7 @@ def request_initialize(self, sourceInitFile=False):
 response = self.send_recv(command_dict)
 if response:
 if "body" in response:
-self.initialize_body = response["body"]
+self.capabilities = response["body"]
 return response
 
 def request_launch(
@@ -971,6 +981,7 @@ def request_stepIn(self, threadId, targetId, 
granularity="statement"):
 def request_stepInTargets(self, frameId):
 if self.exit_status is not None:
 raise ValueError("request_stepInTargets called after process 
exited")
+self.get_capability("supportsStepInTargetsRequest")
 args_dict = {"frameId": frameId}
 command_dict = {
 "command": "stepInTargets",

diff  --git 
a/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/lldbdap_testcase.py 
b/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/lldbd

[Lldb-commits] [lldb] [lldb-dap] Creating a 'capabilities' event helper. (PR #142831)

2025-06-10 Thread John Harrison via lldb-commits


https://github.com/ashgti closed 
https://github.com/llvm/llvm-project/pull/142831
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb-dap] Creating a 'capabilities' event helper. (PR #142831)

2025-06-10 Thread John Harrison via lldb-commits


ashgti wrote:

I think more of the tests I see are using style 4, so I went with that for my 
tests for consistency.

https://github.com/llvm/llvm-project/pull/142831
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb-dap] Creating a 'capabilities' event helper. (PR #142831)

2025-06-10 Thread John Harrison via lldb-commits


https://github.com/ashgti updated 
https://github.com/llvm/llvm-project/pull/142831

>From 0824e3c626ad5e8c2ce37f2fdfcf0c2fa47b7b1d Mon Sep 17 00:00:00 2001
From: John Harrison 
Date: Wed, 4 Jun 2025 11:03:37 -0700
Subject: [PATCH 1/8] [lldb-dap] Creating a 'capabilities' event helper.

This adds a new 'CapabilitiesEventBody' type for having a well structured type 
for the event and updates the 'stepInTargets' and 'restart' request to 
dynamically set their capabilities.

This also fixes the 'stepInTargets' test on non-x86 platforms.
---
 .../test/tools/lldb-dap/dap_server.py | 25 +++---
 .../tools/lldb-dap/launch/TestDAP_launch.py   |  2 +-
 .../stepInTargets/TestDAP_stepInTargets.py|  2 +
 lldb/tools/lldb-dap/CMakeLists.txt|  1 +
 lldb/tools/lldb-dap/EventHelper.cpp   | 18 
 lldb/tools/lldb-dap/EventHelper.h |  3 ++
 lldb/tools/lldb-dap/Handler/RequestHandler.h  |  3 --
 .../Handler/RestartRequestHandler.cpp | 17 ---
 lldb/tools/lldb-dap/Protocol/ProtocolBase.h   |  4 +-
 .../lldb-dap/Protocol/ProtocolEvents.cpp  | 21 +
 lldb/tools/lldb-dap/Protocol/ProtocolEvents.h | 46 +++
 11 files changed, 112 insertions(+), 30 deletions(-)
 create mode 100644 lldb/tools/lldb-dap/Protocol/ProtocolEvents.cpp
 create mode 100644 lldb/tools/lldb-dap/Protocol/ProtocolEvents.h

diff --git a/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py 
b/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
index 6b41aef2bb5b8..c3c8dbb12e9d0 100644
--- a/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
+++ b/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
@@ -135,6 +135,10 @@ def as_dict(self):
 return source_dict
 
 
+class NotSupportedError(Exception):
+"""Raised if a feature is not supported due to its capabilities."""
+
+
 class DebugCommunication(object):
 def __init__(
 self,
@@ -153,7 +157,7 @@ def __init__(
 self.recv_thread = threading.Thread(target=self._read_packet_thread)
 self.process_event_body = None
 self.exit_status: Optional[int] = None
-self.initialize_body = None
+self.capabilities: dict[str, Any] = {}
 self.progress_events: list[Event] = []
 self.reverse_requests = []
 self.sequence = 1
@@ -300,6 +304,9 @@ def _handle_recv_packet(self, packet: 
Optional[ProtocolMessage]) -> bool:
 elif event == "breakpoint":
 # Breakpoint events are sent when a breakpoint is resolved
 self._update_verified_breakpoints([body["breakpoint"]])
+elif event == "capabilities":
+# Update the capabilities with new ones from the event.
+self.capabilities.update(body["capabilities"])
 
 elif packet_type == "response":
 if packet["command"] == "disconnect":
@@ -488,13 +495,11 @@ def wait_for_terminated(self, timeout: Optional[float] = 
None):
 raise ValueError("didn't get terminated event")
 return event_dict
 
-def get_initialize_value(self, key):
+def get_capability(self, key, default=None):
 """Get a value for the given key if it there is a key/value pair in
-the "initialize" request response body.
+the capabilities reported by the adapter.
 """
-if self.initialize_body and key in self.initialize_body:
-return self.initialize_body[key]
-return None
+return self.capabilities.get(key, default)
 
 def get_threads(self):
 if self.threads is None:
@@ -760,6 +765,10 @@ def request_continue(self, threadId=None, 
singleThread=False):
 return response
 
 def request_restart(self, restartArguments=None):
+if self.exit_status is not None:
+raise ValueError("request_restart called after process exited")
+if not self.get_capability("supportsRestartRequest", False):
+raise NotSupportedError("supportsRestartRequest is not set")
 command_dict = {
 "command": "restart",
 "type": "request",
@@ -867,7 +876,7 @@ def request_initialize(self, sourceInitFile=False):
 response = self.send_recv(command_dict)
 if response:
 if "body" in response:
-self.initialize_body = response["body"]
+self.capabilities = response["body"]
 return response
 
 def request_launch(
@@ -972,6 +981,8 @@ def request_stepIn(self, threadId, targetId, 
granularity="statement"):
 def request_stepInTargets(self, frameId):
 if self.exit_status is not None:
 raise ValueError("request_stepInTargets called after process 
exited")
+if not self.get_capability("supportsStepInTargetsRequest", False):
+raise NotSupportedError("supportsStepInTargetsRequest is not set")
 args_dict = {"frameId": frameId}
 command_dict = {
 "com

[Lldb-commits] [lldb] [lldb/aarch64] Fix PC register info augmentation (PR #143499)

2025-06-10 Thread Kazu Hirata via lldb-commits


kazutakahirata wrote:

@labath I've landed 50313a5f556b9967e7d8eb53ee45f79f0fc5b2b8 to fix warnings 
from this PR.  Thanks!

https://github.com/llvm/llvm-project/pull/143499
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] 50313a5 - [lldb] Fix warnings

2025-06-10 Thread Kazu Hirata via lldb-commits


Author: Kazu Hirata
Date: 2025-06-10T11:27:30-07:00
New Revision: 50313a5f556b9967e7d8eb53ee45f79f0fc5b2b8

URL: 
https://github.com/llvm/llvm-project/commit/50313a5f556b9967e7d8eb53ee45f79f0fc5b2b8
DIFF: 
https://github.com/llvm/llvm-project/commit/50313a5f556b9967e7d8eb53ee45f79f0fc5b2b8.diff

LOG: [lldb] Fix warnings

This patch fixes:

  lldb/unittests/ABI/AArch64/ABIAArch64Test.cpp:53:67: error: missing
  field 'value_regs' initializer
  [-Werror,-Wmissing-field-initializers]

  third-party/unittest/googletest/include/gtest/gtest.h:1379:11:
  error: comparison of integers of different signs: 'const unsigned
  long' and 'const int' [-Werror,-Wsign-compare]

Added: 


Modified: 
lldb/unittests/ABI/AArch64/ABIAArch64Test.cpp

Removed: 




diff  --git a/lldb/unittests/ABI/AArch64/ABIAArch64Test.cpp 
b/lldb/unittests/ABI/AArch64/ABIAArch64Test.cpp
index 7ae175a0d3a70..5f9332e3e85bd 100644
--- a/lldb/unittests/ABI/AArch64/ABIAArch64Test.cpp
+++ b/lldb/unittests/ABI/AArch64/ABIAArch64Test.cpp
@@ -50,12 +50,15 @@ TEST_P(ABIAArch64TestFixture, AugmentRegisterInfo) {
   ASSERT_TRUE(abi_sp);
   using Register = DynamicRegisterInfo::Register;
 
-  Register pc{ConstString("pc"), ConstString(), ConstString("GPR")};
+  Register pc;
+  pc.name = ConstString("pc");
+  pc.alt_name = ConstString();
+  pc.set_name = ConstString("GPR");
   std::vector regs{pc};
 
   abi_sp->AugmentRegisterInfo(regs);
 
-  ASSERT_EQ(regs.size(), 1);
+  ASSERT_EQ(regs.size(), 1U);
   Register new_pc = regs[0];
   EXPECT_EQ(new_pc.name, pc.name);
   EXPECT_EQ(new_pc.set_name, pc.set_name);



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

63 matches

Mail list logo