date:20250609

[Lldb-commits] [lldb] e4447e1 - [lldb][test] Remove Windows xfail from forward declaration tests

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


Author: David Spickett
Date: 2025-06-09T10:14:54Z
New Revision: e4447e1273616a8732e332168a53a6ac5c8798e2

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

LOG: [lldb][test] Remove Windows xfail from forward declaration tests

Since https://github.com/llvm/llvm-project/pull/141344, they are
passing.

Added: 


Modified: 
lldb/test/API/lang/c/forward/TestForwardDeclaration.py
lldb/test/API/lang/cpp/forward/TestCPPForwardDeclaration.py

Removed: 




diff  --git a/lldb/test/API/lang/c/forward/TestForwardDeclaration.py 
b/lldb/test/API/lang/c/forward/TestForwardDeclaration.py
index 5d05f255623f4..b6b6f1d6b2613 100644
--- a/lldb/test/API/lang/c/forward/TestForwardDeclaration.py
+++ b/lldb/test/API/lang/c/forward/TestForwardDeclaration.py
@@ -53,7 +53,6 @@ def test(self):
 @skipIfDarwin
 @skipIf(compiler=no_match("clang"))
 @skipIf(compiler_version=["<", "8.0"])
-@expectedFailureAll(oslist=["windows"])
 def test_debug_names(self):
 """Test that we are able to find complete types when using DWARF v5
 accelerator tables"""

diff  --git a/lldb/test/API/lang/cpp/forward/TestCPPForwardDeclaration.py 
b/lldb/test/API/lang/cpp/forward/TestCPPForwardDeclaration.py
index 5e9dd9c2227dd..e66ab4fa71100 100644
--- a/lldb/test/API/lang/cpp/forward/TestCPPForwardDeclaration.py
+++ b/lldb/test/API/lang/cpp/forward/TestCPPForwardDeclaration.py
@@ -47,7 +47,6 @@ def test(self):
 @skipIfDarwin
 @skipIf(compiler=no_match("clang"))
 @skipIf(compiler_version=["<", "8.0"])
-@expectedFailureAll(oslist=["windows"])
 def test_debug_names(self):
 """Test that we are able to find complete types when using DWARF v5
 accelerator tables"""



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

[Lldb-commits] [lldb] [LLDB] Unify DWARF section name matching (PR #141344)

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


DavidSpickett wrote:

This fixed two tests on Windows - 
https://lab.llvm.org/buildbot/#/builders/141/builds/9338

Not often I see a unexpected passes! I've removed the xfails - 
https://github.com/llvm/llvm-project/commit/e4447e1273616a8732e332168a53a6ac5c8798e2.

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

[Lldb-commits] [lldb] c738308 - [lldb][test] Remove outdated rdar link in settings test

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


Author: David Spickett
Date: 2025-06-09T08:59:22Z
New Revision: c73830878463b6d383ca0e8c1dd50842ec4489b9

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

LOG: [lldb][test] Remove outdated rdar link in settings test

Added: 


Modified: 
lldb/test/API/commands/settings/TestSettings.py

Removed: 




diff  --git a/lldb/test/API/commands/settings/TestSettings.py 
b/lldb/test/API/commands/settings/TestSettings.py
index 4ac1239a0b4cd..bc864942055c0 100644
--- a/lldb/test/API/commands/settings/TestSettings.py
+++ b/lldb/test/API/commands/settings/TestSettings.py
@@ -168,7 +168,6 @@ def test_set_term_width(self):
 substrs=["term-width (unsigned) = 60"],
 )
 
-# rdar://problem/10712130
 def test_set_frame_format(self):
 """Test that 'set frame-format' with a backtick char in the format 
string works as well as fullpath."""
 self.build()



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

[Lldb-commits] [lldb] [lldb] Use llvm::find (NFC) (PR #143338)

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


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

[Lldb-commits] [compiler-rt] [lldb] [lldb] make lit use the same PYTHONHOME for building and testing (PR #143183)

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


Michael137 wrote:

Merging based on Jonas's approval (@charles-zablit doesn't have commit access 
yet)

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

[Lldb-commits] [lldb] b62488f - [lldb] make lit use the same PYTHONHOME for building and testing (#143183)

2025-06-09 Thread via lldb-commits


Author: Charles Zablit
Date: 2025-06-09T10:20:39+01:00
New Revision: b62488f8326c61fad05d4cd7c88e6e940d8929a4

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

LOG: [lldb] make lit use the same PYTHONHOME for building and testing (#143183)

When testing LLDB, we want to make sure to use the same Python as the
one we used to build it.

This patch used the CMake variable `Python3_ROOT_DIR` to set the
`PYTHONHOME` env variable in LLDB lit tests, in order to ensure of this.

Please see https://github.com/swiftlang/swift/pull/82063 for the
original issue.

Added: 


Modified: 
compiler-rt/test/lit.common.configured.in
lldb/test/Shell/lit.cfg.py
lldb/test/Shell/lit.site.cfg.py.in
lldb/test/Unit/lit.cfg.py
lldb/test/Unit/lit.site.cfg.py.in

Removed: 




diff  --git a/compiler-rt/test/lit.common.configured.in 
b/compiler-rt/test/lit.common.configured.in
index 04d1a4df5a54f..8ca47a8df5aed 100644
--- a/compiler-rt/test/lit.common.configured.in
+++ b/compiler-rt/test/lit.common.configured.in
@@ -25,6 +25,7 @@ set_default("gold_executable", "@GOLD_EXECUTABLE@")
 set_default("clang", "@COMPILER_RT_RESOLVED_TEST_COMPILER@")
 set_default("compiler_id", "@COMPILER_RT_TEST_COMPILER_ID@")
 set_default("python_executable", "@Python3_EXECUTABLE@")
+set_default("python_root_dir", "@Python3_ROOT_DIR@")
 set_default("compiler_rt_debug", @COMPILER_RT_DEBUG_PYBOOL@)
 set_default("compiler_rt_intercept_libdispatch", 
@COMPILER_RT_INTERCEPT_LIBDISPATCH_PYBOOL@)
 set_default("compiler_rt_output_dir", "@COMPILER_RT_RESOLVED_OUTPUT_DIR@")

diff  --git a/lldb/test/Shell/lit.cfg.py b/lldb/test/Shell/lit.cfg.py
index 193639667db5b..ab6113767187a 100644
--- a/lldb/test/Shell/lit.cfg.py
+++ b/lldb/test/Shell/lit.cfg.py
@@ -198,3 +198,8 @@ def calculate_arch_features(arch_string):
 config.available_features.add("ld_new-bug")
 except:
 pass
+
+# Some shell tests dynamically link with python.dll and need to know the
+# location of the Python libraries. This ensures that we use the same
+# version of Python that was used to build lldb to run our tests.
+config.environment["PYTHONHOME"] = config.python_root_dir

diff  --git a/lldb/test/Shell/lit.site.cfg.py.in 
b/lldb/test/Shell/lit.site.cfg.py.in
index 7e03938b12b23..5be5359217769 100644
--- a/lldb/test/Shell/lit.site.cfg.py.in
+++ b/lldb/test/Shell/lit.site.cfg.py.in
@@ -21,6 +21,7 @@ config.enable_remote = not @LLDB_TEST_SHELL_DISABLE_REMOTE@
 config.libcxx_libs_dir = "@LIBCXX_LIBRARY_DIR@"
 config.target_triple = "@LLVM_TARGET_TRIPLE@"
 config.python_executable = "@Python3_EXECUTABLE@"
+config.python_root_dir = "@Python3_ROOT_DIR@"
 config.have_zlib = @LLVM_ENABLE_ZLIB@
 config.objc_gnustep_dir = "@LLDB_TEST_OBJC_GNUSTEP_DIR@"
 config.lldb_enable_lzma = @LLDB_ENABLE_LZMA@

diff  --git a/lldb/test/Unit/lit.cfg.py b/lldb/test/Unit/lit.cfg.py
index 8d711f17d858e..681e3b19dce34 100644
--- a/lldb/test/Unit/lit.cfg.py
+++ b/lldb/test/Unit/lit.cfg.py
@@ -33,6 +33,7 @@
 ]
 )
 llvm_config.with_environment("PATH", os.path.dirname(sys.executable), 
append_path=True)
+config.environment["PYTHONHOME"] = config.python_root_dir
 
 # Enable sanitizer runtime flags.
 if config.llvm_use_sanitizer:

diff  --git a/lldb/test/Unit/lit.site.cfg.py.in 
b/lldb/test/Unit/lit.site.cfg.py.in
index 2748be229cf1c..fb94797bcd7de 100644
--- a/lldb/test/Unit/lit.site.cfg.py.in
+++ b/lldb/test/Unit/lit.site.cfg.py.in
@@ -11,6 +11,7 @@ config.lldb_src_root = "@LLDB_SOURCE_DIR@"
 config.target_triple = "@LLVM_TARGET_TRIPLE@"
 config.llvm_use_sanitizer = "@LLVM_USE_SANITIZER@"
 config.python_executable = "@Python3_EXECUTABLE@"
+config.python_root_dir = "@Python3_ROOT_DIR@"
 
 import lit.llvm
 lit.llvm.initialize(lit_config, config)



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

[Lldb-commits] [compiler-rt] [lldb] [lldb] make lit use the same PYTHONHOME for building and testing (PR #143183)

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


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

[Lldb-commits] [lldb] c6670fa - [LLDB] Unify DWARF section name matching (#141344)

2025-06-09 Thread via lldb-commits


Author: nerix
Date: 2025-06-09T09:46:50+01:00
New Revision: c6670fa20d434a85e167e88aa6a4f56bfc02af2f

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

LOG: [LLDB] Unify DWARF section name matching (#141344)

Different object file formats support DWARF sections (COFF, ELF, MachO,
PE/COFF, WASM). COFF and PE/COFF only matched a subset. This caused some
GCC executables produced on MinGW to have issue later on when debugging.
One example is that `.debug_rnglists` was not matched, which caused
range-extraction to fail when printing a backtrace.

This unifies the parsing of section names in
`ObjectFile::GetDWARFSectionTypeFromName`, so all file formats can use
the same naming convention. Since the prefixes are different,
`GetDWARFSectionTypeFromName` only matches the suffixes (i.e. `.debug_`
needs to be stripped before).

I added two tests to ensure the sections are correctly identified on
Windows executables.

Added: 
lldb/test/Shell/ObjectFile/PECOFF/dwarf-clang.yaml
lldb/test/Shell/ObjectFile/PECOFF/dwarf-gcc-mingw.yaml

Modified: 
lldb/include/lldb/Symbol/ObjectFile.h
lldb/source/Plugins/ObjectFile/COFF/ObjectFileCOFF.cpp
lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
lldb/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp
lldb/source/Plugins/ObjectFile/wasm/ObjectFileWasm.cpp
lldb/source/Symbol/ObjectFile.cpp

Removed: 




diff  --git a/lldb/include/lldb/Symbol/ObjectFile.h 
b/lldb/include/lldb/Symbol/ObjectFile.h
index 7fca6383fa9f3..43567592dd447 100644
--- a/lldb/include/lldb/Symbol/ObjectFile.h
+++ b/lldb/include/lldb/Symbol/ObjectFile.h
@@ -709,6 +709,13 @@ class ObjectFile : public 
std::enable_shared_from_this,
   llvm::StringRef name,
   lldb::SymbolType symbol_type_hint = lldb::eSymbolTypeUndefined);
 
+  /// Parses the section type from a section name for DWARF sections.
+  ///
+  /// The \a name must be stripped of the default prefix (e.g. ".debug_" or
+  /// "__debug_"). If there's no matching section type, \a eSectionTypeOther
+  /// will be returned.
+  static lldb::SectionType GetDWARFSectionTypeFromName(llvm::StringRef name);
+
   /// Loads this objfile to memory.
   ///
   /// Loads the bits needed to create an executable image to the memory. It is

diff  --git a/lldb/source/Plugins/ObjectFile/COFF/ObjectFileCOFF.cpp 
b/lldb/source/Plugins/ObjectFile/COFF/ObjectFileCOFF.cpp
index a7ad5d27b237f..1121f696637b6 100644
--- a/lldb/source/Plugins/ObjectFile/COFF/ObjectFileCOFF.cpp
+++ b/lldb/source/Plugins/ObjectFile/COFF/ObjectFileCOFF.cpp
@@ -191,19 +191,15 @@ void 
ObjectFileCOFF::CreateSections(lldb_private::SectionList §ions) {
 
   auto SectionType = [](StringRef Name,
 const coff_section *Section) -> lldb::SectionType {
-lldb::SectionType type =
-StringSwitch(Name)
-// DWARF Debug Sections
-.Case(".debug_abbrev", eSectionTypeDWARFDebugAbbrev)
-.Case(".debug_info", eSectionTypeDWARFDebugInfo)
-.Case(".debug_line", eSectionTypeDWARFDebugLine)
-.Case(".debug_pubnames", eSectionTypeDWARFDebugPubNames)
-.Case(".debug_pubtypes", eSectionTypeDWARFDebugPubTypes)
-.Case(".debug_str", eSectionTypeDWARFDebugStr)
-// CodeView Debug Sections: .debug$S, .debug$T
-.StartsWith(".debug$", eSectionTypeDebug)
-.Case("clangast", eSectionTypeOther)
-.Default(eSectionTypeInvalid);
+// DWARF Debug Sections
+if (Name.consume_front(".debug_"))
+  return GetDWARFSectionTypeFromName(Name);
+
+lldb::SectionType type = StringSwitch(Name)
+ // CodeView Debug Sections: .debug$S, .debug$T
+ .StartsWith(".debug$", eSectionTypeDebug)
+ .Case("clangast", eSectionTypeOther)
+ .Default(eSectionTypeInvalid);
 if (type != eSectionTypeInvalid)
   return type;
 

diff  --git a/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp 
b/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
index 13e1198516f78..f69358de6a288 100644
--- a/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
+++ b/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
@@ -1653,39 +1653,9 @@ lldb::user_id_t 
ObjectFileELF::GetSectionIndexByName(const char *name) {
 }
 
 static SectionType GetSectionTypeFromName(llvm::StringRef Name) {
-  if (Name.consume_front(".debug_")) {
-return llvm::StringSwitch(Name)
-.Case("abbrev", eSectionTypeDWARFDebugAbbrev)
-.Case("abbrev.dwo", eSectionTypeDWARFDebugAbbrevDwo)
-.Case("addr", eSectionTypeDWARFDebugAddr)
-.Case("aranges", eSectionTypeD

[Lldb-commits] [lldb] [LLDB] Unify DWARF section name matching (PR #141344)

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


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

[Lldb-commits] [lldb] df4b453 - [lldb] Use llvm::find (NFC) (#143338)

2025-06-09 Thread via lldb-commits


Author: Kazu Hirata
Date: 2025-06-09T09:56:27+01:00
New Revision: df4b453516ebf9aa03c48c17e81112dce1c80f41

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

LOG: [lldb] Use llvm::find (NFC) (#143338)

This patch should be mostly obvious, but in one place, this patch
changes:

  const auto &it = std::find(...)

to:

  auto it = llvm::find(...)

We do not need to bind to a temporary with const ref.

Added: 


Modified: 
lldb/source/Breakpoint/WatchpointResource.cpp
lldb/source/Expression/FunctionCaller.cpp
lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
lldb/source/Target/Process.cpp

Removed: 




diff  --git a/lldb/source/Breakpoint/WatchpointResource.cpp 
b/lldb/source/Breakpoint/WatchpointResource.cpp
index 49d9d12aadfc3..c2f510f03638f 100644
--- a/lldb/source/Breakpoint/WatchpointResource.cpp
+++ b/lldb/source/Breakpoint/WatchpointResource.cpp
@@ -56,8 +56,7 @@ void WatchpointResource::AddConstituent(const WatchpointSP 
&wp_sp) {
 
 void WatchpointResource::RemoveConstituent(WatchpointSP &wp_sp) {
   std::lock_guard guard(m_constituents_mutex);
-  const auto &it =
-  std::find(m_constituents.begin(), m_constituents.end(), wp_sp);
+  auto it = llvm::find(m_constituents, wp_sp);
   if (it != m_constituents.end())
 m_constituents.erase(it);
 }

diff  --git a/lldb/source/Expression/FunctionCaller.cpp 
b/lldb/source/Expression/FunctionCaller.cpp
index 83cac130ba728..6c93d94f691cb 100644
--- a/lldb/source/Expression/FunctionCaller.cpp
+++ b/lldb/source/Expression/FunctionCaller.cpp
@@ -323,8 +323,7 @@ bool FunctionCaller::FetchFunctionResults(ExecutionContext 
&exe_ctx,
 void FunctionCaller::DeallocateFunctionResults(ExecutionContext &exe_ctx,
lldb::addr_t args_addr) {
   std::list::iterator pos;
-  pos = std::find(m_wrapper_args_addrs.begin(), m_wrapper_args_addrs.end(),
-  args_addr);
+  pos = llvm::find(m_wrapper_args_addrs, args_addr);
   if (pos != m_wrapper_args_addrs.end())
 m_wrapper_args_addrs.erase(pos);
 

diff  --git a/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp 
b/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
index 420c84b496d15..f18bdd5175f2e 100644
--- a/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
+++ b/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
@@ -1728,7 +1728,7 @@ ThreadSP ProcessGDBRemote::SetThreadStopInfo(
 
   reg_ctx_sp->InvalidateIfNeeded(true);
 
-  auto iter = std::find(m_thread_ids.begin(), m_thread_ids.end(), tid);
+  auto iter = llvm::find(m_thread_ids, tid);
   if (iter != m_thread_ids.end())
 SetThreadPc(thread_sp, iter - m_thread_ids.begin());
 

diff  --git a/lldb/source/Target/Process.cpp b/lldb/source/Target/Process.cpp
index 58edf972ddbe7..61a3d05bc3746 100644
--- a/lldb/source/Target/Process.cpp
+++ b/lldb/source/Target/Process.cpp
@@ -5838,7 +5838,7 @@ void Process::ClearPreResumeActions() { 
m_pre_resume_actions.clear(); }
 void Process::ClearPreResumeAction(PreResumeActionCallback callback, void 
*baton)
 {
 PreResumeCallbackAndBaton element(callback, baton);
-auto found_iter = std::find(m_pre_resume_actions.begin(), 
m_pre_resume_actions.end(), element);
+auto found_iter = llvm::find(m_pre_resume_actions, element);
 if (found_iter != m_pre_resume_actions.end())
 {
 m_pre_resume_actions.erase(found_iter);



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

[Lldb-commits] [lldb] [lldb] Use llvm::find (NFC) (PR #143338)

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


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

LGTM

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

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

2025-06-09 Thread Dhruv Srivastava via lldb-commits


DhruvSrivastavaX wrote:

Hi @DavidSpickett , I have addressed all your comments as well. 

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] add plugin names to process save-core error output. (PR #143126)

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


da-viper wrote:

I overrode the `GetDefinitions` to add the missing options for the `plugin-name 
arg` it seems like the generic way to do it. 

https://github.com/llvm/llvm-project/pull/143126
___
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-09 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/2] [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/2] 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-09 Thread Dhruv Srivastava via lldb-commits


https://github.com/DhruvSrivastavaX updated 
https://github.com/llvm/llvm-project/pull/141577

>From a62cd7b510f3cf74ee356a95a26e0f9922f4b39c Mon Sep 17 00:00:00 2001
From: DhruvSrivastavaX 
Date: Tue, 27 May 2025 05:44:55 -0500
Subject: [PATCH 1/4] Added XCOFF ParseSymtab handling

---
 .../ObjectFile/XCOFF/ObjectFileXCOFF.cpp  | 66 ++-
 1 file changed, 65 insertions(+), 1 deletion(-)

diff --git a/lldb/source/Plugins/ObjectFile/XCOFF/ObjectFileXCOFF.cpp 
b/lldb/source/Plugins/ObjectFile/XCOFF/ObjectFileXCOFF.cpp
index e629355cd40b9..7dfe6c362add4 100644
--- a/lldb/source/Plugins/ObjectFile/XCOFF/ObjectFileXCOFF.cpp
+++ b/lldb/source/Plugins/ObjectFile/XCOFF/ObjectFileXCOFF.cpp
@@ -188,7 +188,71 @@ AddressClass ObjectFileXCOFF::GetAddressClass(addr_t 
file_addr) {
   return AddressClass::eUnknown;
 }
 
-void ObjectFileXCOFF::ParseSymtab(Symtab &lldb_symtab) {}
+lldb::SymbolType MapSymbolType(llvm::object::SymbolRef::Type sym_type) {
+  if (sym_type == llvm::object::SymbolRef::ST_Function)
+return lldb::eSymbolTypeCode;
+  else if (sym_type == llvm::object::SymbolRef::ST_Data)
+return lldb::eSymbolTypeData;
+  else if (sym_type == llvm::object::SymbolRef::ST_File)
+return lldb::eSymbolTypeSourceFile;
+  return lldb::eSymbolTypeInvalid;
+}
+
+void ObjectFileXCOFF::ParseSymtab(Symtab &lldb_symtab) {
+  SectionList *sectionList = GetSectionList();
+
+  for (const auto &symbol_ref : m_binary->symbols()) {
+llvm::object::XCOFFSymbolRef xcoff_sym_ref(symbol_ref);
+llvm::Expected name_or_err = xcoff_sym_ref.getName();
+if (!name_or_err) {
+  consumeError(name_or_err.takeError());
+  continue;
+}
+llvm::StringRef symbolName = name_or_err.get();
+// Remove the dot prefix for demangle
+llvm::StringRef symbol_name =
+symbolName.starts_with(".") ? symbolName.drop_front() : symbolName;
+auto storageClass = xcoff_sym_ref.getStorageClass();
+if (storageClass == XCOFF::C_HIDEXT && symbolName != "TOC") {
+  if (xcoff_sym_ref.getNumberOfAuxEntries() != 1)
+continue;
+  auto aux_csect_or_err = xcoff_sym_ref.getXCOFFCsectAuxRef();
+  if (!aux_csect_or_err) {
+consumeError(aux_csect_or_err.takeError());
+continue;
+  }
+  const llvm::object::XCOFFCsectAuxRef csect_aux = aux_csect_or_err.get();
+  if (csect_aux.getStorageMappingClass() != XCOFF::XMC_PR ||
+  (m_binary->is64Bit() ? (csect_aux.getAuxType64() != XCOFF::AUX_CSECT)
+   : false))
+continue;
+}
+
+Symbol symbol;
+symbol.GetMangled().SetValue(ConstString(symbol_name));
+
+int16_t sectionNumber = xcoff_sym_ref.getSectionNumber();
+size_t sectionIndex = static_cast(sectionNumber - 1);
+if (sectionNumber > 0 && sectionIndex < sectionList->GetSize()) {
+  lldb::SectionSP section_sp =
+  sectionList->GetSectionAtIndex(sectionNumber - 1);
+  if (!section_sp || section_sp->GetFileAddress() == LLDB_INVALID_ADDRESS)
+continue;
+  lldb::addr_t file_addr = section_sp->GetFileAddress();
+  lldb::addr_t symbolValue = xcoff_sym_ref.getValue();
+  if (symbolValue < file_addr)
+continue;
+  symbol.GetAddressRef() = Address(section_sp, symbolValue - file_addr);
+}
+
+Expected sym_type_or_err =
+symbol_ref.getType();
+symbol.SetType(MapSymbolType(sym_type_or_err.get()));
+printf("%s %d\n", symbol.GetName(), *sym_type_or_err);
+
+lldb_symtab.AddSymbol(symbol);
+  }
+}
 
 bool ObjectFileXCOFF::IsStripped() { return false; }
 

>From 21f5a39976457589e2ab9666820c08331aaf4542 Mon Sep 17 00:00:00 2001
From: Dhruv Srivastava 
Date: Tue, 27 May 2025 16:33:08 +0530
Subject: [PATCH 2/4] cleanup

---
 lldb/source/Plugins/ObjectFile/XCOFF/ObjectFileXCOFF.cpp | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/lldb/source/Plugins/ObjectFile/XCOFF/ObjectFileXCOFF.cpp 
b/lldb/source/Plugins/ObjectFile/XCOFF/ObjectFileXCOFF.cpp
index 7dfe6c362add4..1e84b86cd6f0a 100644
--- a/lldb/source/Plugins/ObjectFile/XCOFF/ObjectFileXCOFF.cpp
+++ b/lldb/source/Plugins/ObjectFile/XCOFF/ObjectFileXCOFF.cpp
@@ -247,8 +247,11 @@ void ObjectFileXCOFF::ParseSymtab(Symtab &lldb_symtab) {
 
 Expected sym_type_or_err =
 symbol_ref.getType();
+if (!sym_type_or_err) {
+  consumeError(sym_type_or_err.takeError());
+  continue;
+}
 symbol.SetType(MapSymbolType(sym_type_or_err.get()));
-printf("%s %d\n", symbol.GetName(), *sym_type_or_err);
 
 lldb_symtab.AddSymbol(symbol);
   }

>From 4d631899cd3ab96ea3819e1ece3ce2851d1f9f6c Mon Sep 17 00:00:00 2001
From: DhruvSrivastavaX 
Date: Thu, 29 May 2025 07:37:23 -0500
Subject: [PATCH 3/4] Addressed comments

---
 .../ObjectFile/XCOFF/ObjectFileXCOFF.cpp  | 27 ---
 1 file changed, 18 insertions(+), 9 deletions(-)

diff --git a/lldb/source/Plugins/ObjectFile/XCOFF/ObjectFileXCOFF.cpp 
b/lldb/source/Plugins/ObjectFile/XCOFF/ObjectFileXCO

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

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



@@ -736,6 +738,16 @@ void CommandCompletions::ProcessNames(CommandInterpreter 
&interpreter,
   for (const ProcessInstanceInfo &info : process_infos)
 request.TryCompleteCurrentArg(info.GetNameAsStringRef());
 }
+void CommandCompletions::ProcessSaveCorePluginNames(

DavidSpickett wrote:

Add a blank line between this and the function above.

https://github.com/llvm/llvm-project/pull/143126
___
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-09 Thread David Spickett via lldb-commits



@@ -1281,7 +1281,26 @@ class CommandObjectProcessSaveCore : public 
CommandObjectParsed {
 ~CommandOptions() override = default;
 
 llvm::ArrayRef GetDefinitions() override {
-  return llvm::ArrayRef(g_process_save_core_options);
+  if (m_opt_def.empty()) {

DavidSpickett wrote:

Early return this.

If opt def is not empty, return.
Otherwise do the rest.

https://github.com/llvm/llvm-project/pull/143126
___
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-09 Thread David Spickett via lldb-commits


https://github.com/DavidSpickett edited 
https://github.com/llvm/llvm-project/pull/143126
___
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-09 Thread David Spickett via lldb-commits



@@ -792,6 +792,12 @@ Status PluginManager::SaveCore(const lldb::ProcessSP 
&process_sp,
 }
   }
 
+  // report for one plugin if a name is specified.
+  if (error.Success() && !plugin_name.empty())

DavidSpickett wrote:

It's so strange that this code (and the one before the return) reads like:
if we did something good
say that something went wrong

I'm sure the logic works out somehow but it's not very clear.

Addressing that here will make it even more confusing, but keep it in mind when 
dealing with this code. It seems tricky.

https://github.com/llvm/llvm-project/pull/143126
___
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-09 Thread Jonas Devlieghere via lldb-commits


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

>From ff28c4be506dd762a4f8550a4a5a44578e34535d Mon Sep 17 00:00:00 2001
From: Jonas Devlieghere 
Date: Tue, 3 Jun 2025 16:03:36 -0700
Subject: [PATCH 1/2] [lldb] Revive TestSimulatorPlatform.py

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.
---
 .../Python/lldbsuite/test/decorators.py   | 55 +--
 .../macosx/simulator/TestSimulatorPlatform.py | 12 ++--
 2 files changed, 58 insertions(+), 9 deletions(-)

diff --git a/lldb/packages/Python/lldbsuite/test/decorators.py 
b/lldb/packages/Python/lldbsuite/test/decorators.py
index 868e9f7e5eca0..7e9a19028c38e 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,68 @@ 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_xcode_sdk(os, env)
 
-version_min = ""
 if not vers:
 vers = lldbutil.get_xcode_sdk_version(sdk)
+

[Lldb-commits] [lldb] 4855610 - [lldb][NFC] Split RegisterContextUnwind::SavedLocationForRegister (#139817)

2025-06-09 Thread via lldb-commits


Author: Jason Molenda
Date: 2025-06-09T18:36:35-07:00
New Revision: 48556108f25052a106bfbe83060775bebf9b43a4

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

LOG: [lldb][NFC] Split RegisterContextUnwind::SavedLocationForRegister (#139817)

RegisterContextUnwind::SavedLocationForRegister is around 450 lines that
first find an abstract register location (e.g. "CFA-8") for a register
by looking in the UnwindPlans. Then it evaluates the abstract register
location to create a concrete register location (e.g. "stored at address
0x...", "live in register at frame 0"). There are some complicated cases
in the first half of the method to handle return address register
architectures correctly, in particular.

Looking at the two halves, they're both exactly 226 lines long and
there's little involvement between them except for passing an abstract
register location along.

(there were some parts in the "abstract register location" code that
would set the concrete register location, unnecessarily)

It's also a complex enough method that there are some bits of code that
aren't actually doing anything at this point.

This patch adds a RegisterContextUnwind::GetAbstractRegisterLocation
method, which does the first half, and has a clearly defined return
values.

The code to convert an AbstractRegisterLocation into a
ConcreteRegisterLocation remains in SavedLocationForRegister.

It's a bit of a tricky patch to visually inspect, despite it not
changing functionality, the reorganizations and rewrites make the diff
unreadable. Nearly all the real changes are in the "find the abstract
register location" first half of the method. I think reading the new
code in its new form is the easiest way to inspect this PR. With a
defined interface between the two of what is expected, it's pretty easy
to look at the code and reason about whether it is written correctly.

(whereas before, that was very difficult, for me at least.)

-

Co-authored-by: Pavel Labath 

Added: 


Modified: 
lldb/include/lldb/Target/RegisterContextUnwind.h
lldb/source/Target/RegisterContextUnwind.cpp
lldb/source/Target/RegisterNumber.cpp

Removed: 




diff  --git a/lldb/include/lldb/Target/RegisterContextUnwind.h 
b/lldb/include/lldb/Target/RegisterContextUnwind.h
index 044a387fe5aa2..b10a364823b83 100644
--- a/lldb/include/lldb/Target/RegisterContextUnwind.h
+++ b/lldb/include/lldb/Target/RegisterContextUnwind.h
@@ -151,6 +151,9 @@ class RegisterContextUnwind : public 
lldb_private::RegisterContext {
   uint32_t lldb_regnum,
   lldb_private::UnwindLLDB::ConcreteRegisterLocation ®loc);
 
+  std::optional
+  GetAbstractRegisterLocation(uint32_t lldb_regnum, lldb::RegisterKind &kind);
+
   bool ReadRegisterValueFromRegisterLocation(
   lldb_private::UnwindLLDB::ConcreteRegisterLocation regloc,
   const lldb_private::RegisterInfo *reg_info,

diff  --git a/lldb/source/Target/RegisterContextUnwind.cpp 
b/lldb/source/Target/RegisterContextUnwind.cpp
index 32ed8e0384412..880300d0637fb 100644
--- a/lldb/source/Target/RegisterContextUnwind.cpp
+++ b/lldb/source/Target/RegisterContextUnwind.cpp
@@ -1233,247 +1233,201 @@ bool RegisterContextUnwind::IsTrapHandlerSymbol(
   return false;
 }
 
-// Answer the question: Where did THIS frame save the CALLER frame ("previous"
-// frame)'s register value?
-
-enum UnwindLLDB::RegisterSearchResult
-RegisterContextUnwind::SavedLocationForRegister(
-uint32_t lldb_regnum,
-lldb_private::UnwindLLDB::ConcreteRegisterLocation ®loc) {
+// Search this stack frame's UnwindPlans for the AbstractRegisterLocation
+// for this register.
+//
+// \param[in] lldb_regnum
+// The register number (in the eRegisterKindLLDB register numbering)
+// we are searching for.
+//
+// \param[out] kind
+// Set to the RegisterKind of the UnwindPlan which is the basis for
+// the returned AbstractRegisterLocation; if the location is in terms
+// of another register number, this Kind is needed to interpret it
+// correctly.
+//
+// \return
+// An empty optional indicaTes that there was an error in processing
+// the request.
+//
+// If there is no unwind rule for a volatile (caller-preserved) register,
+// the returned AbstractRegisterLocation will be IsUndefined,
+// indicating that we should stop searching.
+//
+// If there is no unwind rule for a non-volatile (callee-preserved)
+// register, the returned AbstractRegisterLocation will be IsSame.
+// In frame 0, IsSame means get the value from the live register context.
+// Else it means to continue descending down the stack to more-live frames
+// looking for a location/value.
+//
+// If an AbstractRegisterLocation is found in an UnwindPlan, that will
+// be returned, with no

[Lldb-commits] [lldb] [lldb][NFC] Split RegisterContextUnwind::SavedLocationForRegister (PR #139817)

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


https://github.com/jasonmolenda closed 
https://github.com/llvm/llvm-project/pull/139817
___
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-09 Thread Jonas Devlieghere via lldb-commits


https://github.com/JDevlieghere commented:

This needs a test.

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

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

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


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

Thanks!

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] [lldb] add plugin names to process save-core error output. (PR #143126)

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


https://github.com/JDevlieghere edited 
https://github.com/llvm/llvm-project/pull/143126
___
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-09 Thread Jonas Devlieghere via lldb-commits



@@ -212,6 +212,8 @@ class PluginManager {
   static Status SaveCore(const lldb::ProcessSP &process_sp,
  lldb_private::SaveCoreOptions &core_options);
 
+  static llvm::SmallVector GetSaveCorePluginNames();

JDevlieghere wrote:

It's rather uncommon to return a `SmallVector` by value. Usually, you return a 
`SmallVectorImpl` by reference (you can't by value because it's a polymorphic 
type) so that the caller can decide how many elements there are. Given that 
this isn't actually hot code, I would just return a plain `vector` (rather than 
giving this an output argument). 

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

[Lldb-commits] [lldb] [lldb][NFC] Split RegisterContextUnwind::SavedLocationForRegister (PR #139817)

2025-06-09 Thread LLVM Continuous Integration via lldb-commits


llvm-ci wrote:

LLVM Buildbot has detected a new failure on builder `lldb-arm-ubuntu` running 
on `linaro-lldb-arm-ubuntu` while building `lldb` at step 6 "test".

Full details are available at: 
https://lab.llvm.org/buildbot/#/builders/18/builds/17248


Here is the relevant piece of the build log for the reference

```
Step 6 (test) failure: build (failure)
...
PASS: lldb-api :: tools/lldb-dap/repl-mode/TestDAP_repl_mode_detection.py (1202 
of 3242)
UNSUPPORTED: lldb-api :: 
tools/lldb-dap/restart/TestDAP_restart_runInTerminal.py (1203 of 3242)
UNSUPPORTED: lldb-api :: tools/lldb-dap/save-core/TestDAP_save_core.py (1204 of 
3242)
UNSUPPORTED: lldb-api :: tools/lldb-dap/runInTerminal/TestDAP_runInTerminal.py 
(1205 of 3242)
PASS: lldb-api :: tools/lldb-dap/progress/TestDAP_Progress.py (1206 of 3242)
PASS: lldb-api :: tools/lldb-dap/restart/TestDAP_restart.py (1207 of 3242)
PASS: lldb-api :: tools/lldb-dap/send-event/TestDAP_sendEvent.py (1208 of 3242)
UNSUPPORTED: lldb-api :: tools/lldb-dap/stackTrace-x86/TestDAP_source_x86.py 
(1209 of 3242)
UNSUPPORTED: lldb-api :: 
tools/lldb-dap/stackTrace/subtleFrames/TestDAP_subtleFrames.py (1210 of 3242)
PASS: lldb-api :: tools/lldb-dap/source/TestDAP_source.py (1211 of 3242)
FAIL: lldb-api :: tools/lldb-dap/server/TestDAP_server.py (1212 of 3242)
 TEST 'lldb-api :: tools/lldb-dap/server/TestDAP_server.py' 
FAILED 
Script:
--
/usr/bin/python3.10 
/home/tcwg-buildbot/worker/lldb-arm-ubuntu/llvm-project/lldb/test/API/dotest.py 
-u CXXFLAGS -u CFLAGS --env 
LLVM_LIBS_DIR=/home/tcwg-buildbot/worker/lldb-arm-ubuntu/build/./lib --env 
LLVM_INCLUDE_DIR=/home/tcwg-buildbot/worker/lldb-arm-ubuntu/build/include --env 
LLVM_TOOLS_DIR=/home/tcwg-buildbot/worker/lldb-arm-ubuntu/build/./bin --arch 
armv8l --build-dir 
/home/tcwg-buildbot/worker/lldb-arm-ubuntu/build/lldb-test-build.noindex 
--lldb-module-cache-dir 
/home/tcwg-buildbot/worker/lldb-arm-ubuntu/build/lldb-test-build.noindex/module-cache-lldb/lldb-api
 --clang-module-cache-dir 
/home/tcwg-buildbot/worker/lldb-arm-ubuntu/build/lldb-test-build.noindex/module-cache-clang/lldb-api
 --executable /home/tcwg-buildbot/worker/lldb-arm-ubuntu/build/./bin/lldb 
--compiler /home/tcwg-buildbot/worker/lldb-arm-ubuntu/build/./bin/clang 
--dsymutil /home/tcwg-buildbot/worker/lldb-arm-ubuntu/build/./bin/dsymutil 
--make /usr/bin/gmake --llvm-tools-dir 
/home/tcwg-buildbot/worker/lldb-arm-ubuntu/build/./bin --lldb-obj-root 
/home/tcwg-buildbot/worker/lldb-arm-ubuntu/build/tools/lldb --lldb-libs-dir 
/home/tcwg-buildbot/worker/lldb-arm-ubuntu/build/./lib --cmake-build-type 
Release 
/home/tcwg-buildbot/worker/lldb-arm-ubuntu/llvm-project/lldb/test/API/tools/lldb-dap/server
 -p TestDAP_server.py
--
Exit Code: 1

Command Output (stdout):
--
lldb version 21.0.0git (https://github.com/llvm/llvm-project.git revision 
48556108f25052a106bfbe83060775bebf9b43a4)
  clang revision 48556108f25052a106bfbe83060775bebf9b43a4
  llvm revision 48556108f25052a106bfbe83060775bebf9b43a4
Skipping the following test categories: ['libc++', 'dsym', 'gmodules', 
'debugserver', 'objc']

--
Command Output (stderr):
--
= DEBUG ADAPTER PROTOCOL LOGS =
no log file available
= END =
DAP session (client_0) error: Bad file descriptor
FAIL: LLDB (/home/tcwg-buildbot/worker/lldb-arm-ubuntu/build/bin/clang-arm) :: 
test_server_interrupt (TestDAP_server.TestDAP_server)
= DEBUG ADAPTER PROTOCOL LOGS =
no log file available
= END =
= DEBUG ADAPTER PROTOCOL LOGS =
no log file available
= END =
PASS: LLDB (/home/tcwg-buildbot/worker/lldb-arm-ubuntu/build/bin/clang-arm) :: 
test_server_port (TestDAP_server.TestDAP_server)
DAP session (client_1) error: Bad file descriptor
= DEBUG ADAPTER PROTOCOL LOGS =
no log file available
= END =
= DEBUG ADAPTER PROTOCOL LOGS =
no log file available
= END =
PASS: LLDB (/home/tcwg-buildbot/worker/lldb-arm-ubuntu/build/bin/clang-arm) :: 
test_server_unix_socket (TestDAP_server.TestDAP_server)
==

```



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

[Lldb-commits] [lldb] [llvm] [NFC] Separate high-level-dependent portions of DWARFExpression (revised) (PR #143170)

2025-06-09 Thread via lldb-commits


https://github.com/Sterling-Augustine updated 
https://github.com/llvm/llvm-project/pull/143170

>From 1b2fcdccc6d7f35dc2f387259c70fe6c9825b8b0 Mon Sep 17 00:00:00 2001
From: Sterling Augustine 
Date: Wed, 4 Jun 2025 11:53:45 -0700
Subject: [PATCH 1/4] [NFC] Separate high-level-dependent portions of
 DWARFExpression

Move all expression verification into its only client: DWARFVerifier.
Move all printing code (which was a mix of static and member
functions) into a separate class.

Dwarf expressions are used in many contexts without Dwarf units and
other higher-level Dwarf concepts. The code currently includes
conditionals which fall back to defaults if some high-level construct
is not available. For example, prettyPrintBaseTypeRef checks U for
null.

These checks mean that a Dwarf expressions can be used without
high-level *run* time* dependencies on Dwarf unit. But as coded they
cannot be used without high level *build* time dependencies on Dwarf
unit.

One in a series of NFC DebugInfo/DWARF refactoring changes to layer it
more cleanly, so that binary CFI parsing can be used from low-level
code, (such as byte strings created via .cfi_escape) without circular
dependencies.
---
 .../llvm/DebugInfo/DWARF/DWARFExpression.h|  88 ---
 .../llvm/DebugInfo/DWARF/DWARFVerifier.h  |  18 +++
 llvm/lib/DebugInfo/DWARF/DWARFCFIProgram.cpp  |   2 +-
 llvm/lib/DebugInfo/DWARF/DWARFDebugFrame.cpp  |   4 +-
 llvm/lib/DebugInfo/DWARF/DWARFDebugLoc.cpp|   3 +-
 llvm/lib/DebugInfo/DWARF/DWARFDie.cpp |   4 +-
 llvm/lib/DebugInfo/DWARF/DWARFExpression.cpp  | 149 --
 llvm/lib/DebugInfo/DWARF/DWARFVerifier.cpp|  31 +++-
 .../LogicalView/Readers/LVDWARFReader.cpp |   4 +-
 llvm/tools/llvm-objdump/SourcePrinter.cpp |   2 +-
 .../DWARFExpressionCompactPrinterTest.cpp |   2 +-
 11 files changed, 187 insertions(+), 120 deletions(-)

diff --git a/llvm/include/llvm/DebugInfo/DWARF/DWARFExpression.h 
b/llvm/include/llvm/DebugInfo/DWARF/DWARFExpression.h
index 00228a32173f1..ecfb545c85798 100644
--- a/llvm/include/llvm/DebugInfo/DWARF/DWARFExpression.h
+++ b/llvm/include/llvm/DebugInfo/DWARF/DWARFExpression.h
@@ -76,6 +76,9 @@ class DWARFExpression {
 
   private:
 friend class DWARFExpression::iterator;
+friend class DWARFExpressionPrinter;
+friend class DWARFVerifier;
+
 uint8_t Opcode; ///< The Op Opcode, DW_OP_.
 Description Desc;
 bool Error = false;
@@ -98,11 +101,6 @@ class DWARFExpression {
 }
 uint64_t getEndOffset() const { return EndOffset; }
 bool isError() const { return Error; }
-bool print(raw_ostream &OS, DIDumpOptions DumpOpts,
-   const DWARFExpression *Expr, DWARFUnit *U) const;
-
-/// Verify \p Op. Does not affect the return of \a isError().
-static bool verify(const Operation &Op, DWARFUnit *U);
 
   private:
 bool extract(DataExtractor Data, uint8_t AddressSize, uint64_t Offset,
@@ -152,26 +150,12 @@ class DWARFExpression {
   iterator begin() const { return iterator(this, 0); }
   iterator end() const { return iterator(this, Data.getData().size()); }
 
-  void print(raw_ostream &OS, DIDumpOptions DumpOpts, DWARFUnit *U,
- bool IsEH = false) const;
-
-  /// Print the expression in a format intended to be compact and useful to a
-  /// user, but not perfectly unambiguous, or capable of representing every
-  /// valid DWARF expression. Returns true if the expression was sucessfully
-  /// printed.
-  bool printCompact(raw_ostream &OS,
-std::function
-GetNameForDWARFReg = nullptr);
-
-  bool verify(DWARFUnit *U);
-
   bool operator==(const DWARFExpression &RHS) const;
 
   StringRef getData() const { return Data.getData(); }
 
-  static bool prettyPrintRegisterOp(DWARFUnit *U, raw_ostream &OS,
-DIDumpOptions DumpOpts, uint8_t Opcode,
-const ArrayRef Operands);
+  friend class DWARFExpressionPrinter;
+  friend class DWARFVerifier;
 
 private:
   DataExtractor Data;
@@ -183,5 +167,63 @@ inline bool operator==(const DWARFExpression::iterator 
&LHS,
const DWARFExpression::iterator &RHS) {
   return LHS.Expr == RHS.Expr && LHS.Offset == RHS.Offset;
 }
-}
-#endif
+
+// This functionality is separated from the main data structure so that nothing
+// in DWARFExpression.cpp needs build-time dependencies on DWARFUnit or other
+// higher-level Dwarf structures. This approach creates better layering and
+// allows DWARFExpression to be used from code which can't have dependencies on
+// those higher-level structures.
+
+class DWARFUnit;
+struct DIDumpOptions;
+class raw_ostream;
+
+class DWARFExpressionPrinter {
+public:
+  /// Print a Dwarf expression/
+  /// \param E to be printed
+  /// \param OS to this stream
+  /// \param GetNameForDWARFReg callback to return dwarf register name
+  static void print(const DWARFExpression *E, raw_ostream &OS,
+

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

2025-06-09 Thread via lldb-commits


jimingham wrote:

> > This seems like a generic module loading observer. I don't see anything JIT 
> > specific about it. Not saying a generic module loading observer is not a 
> > good idea. But calling it a JITLoader seems pretty confusing to me.
> 
> true, in the current form. Check out the comments in my previous reply about 
> the motivations for this.
> 
> > One thing that's nicer about your approach here over independent callbacks 
> > for each of the hooks is that it allows you to group the three callbacks in 
> > the same class instance, so that you can more easily keep shared state.
> > But that's a general problem with these affordances. For instance, it's 
> > super inconvenient that the summary providers and synthetic child providers 
> > produce separate objects to handle the callbacks. You end up computing the 
> > sizes of container classes twice, once for the summary and once because you 
> > need it to present the type... If the summary & child provider could share 
> > state, you'd only need to do that once per stop.
> > And as we are adding more of these callbacks for "lifecycle events" it 
> > would be really convenient, as you have done here, to be able to get one 
> > object to manage multiple different types of callback hits.
> > For the case of hooks, I wonder if we could augment the -C options we 
> > currently use to add affordances backed by a Python class with a `__call__` 
> > method so you could say:
> > `target stop-hook add -C my_python_class --shared-instance 1 --call_method 
> > stop_hook_handler `
> > and then to finish off your design, we'd add:
> > `target module-hook add -C my_python_class --shared-instance 1 
> > --call_method module_hook_handler `
> > The --shared-instance that would tell lldb to make a single object instance 
> > and reuse if for any --shared-instance addition that uses this class (one 
> > for each target in this case). Allowing you to specify the method name 
> > means you don't have to do the discrimination in `__call__`...
> > That way as we add more of these callbacks (which I agree we really need to 
> > do) people could mix and match them as the wish, and we wouldn't have to 
> > figure out the right combination(s) for everybody's use cases.
> > Note for summary & synthetic child providers you wouldn't need to specify 
> > the methods as those are pre-determined. So the `--call-method` would not 
> > be necessary. In their case the shared instance would be held by a 
> > ValueObject, since we make formatter instances for each value object we 
> > format.
> > It might also be handy to be able to define several commands that share 
> > state, so you could do the same thing for command classes (though in that 
> > case the shared instance would be held by the debugger not the target...)
> 
> It would be great to create a generic version of this that allows users to 
> add methods to a python class and just have it be notified. That being said, 
> by motivation here is to augment the JITLoader plug-in API to do more things 
> as mentioned above. Now we can probably do this with a notification class 
> that we can install as long as we can find out about everything that is 
> needed. So one approach might be to allow a python class to get all of the 
> notifications I need for the JITLoader plug-in without calling it a JITLoader 
> as you wanted. The class could be something like:
> 
> ```
> class TargetObserver:
> def __init__(self, target):
> # Created as soon as a target is created
> self.target = target
>   
> # Module observing
> def module_added(self, module):
> # Called anytime a module is added to the target
> pass
> def module_removed(self, module):
> # Called anytime a module is removed from the target
> pass
> def module_loaded(self, module):
> # Called when the module is loaded or modified by the dynamic loader
> pass
> 
> # Launch/Attach observing
> def did_launch(self):
> # Called when the target is done being launched
> pass
> def did_attach(self):
> # Called when the target is done being attached
> pass
> 
> # Breakpoint observing
> def breakpoint_added(self, breakpoint):
> # Called when a breakpoint is added to the target
> pass
> def breakpoint_modified(self, breakpoint):
> # Called when a breakpoint is modified to the target
> pass
> def breakpoint_deleted(self, breakpoint):
> # Called when a breakpoint is added to the target
> pass
> 
> # Unresolved address resolving observation
> def resolve_load_address(self, load_addr):
> # Allow plug-ins to help resolve addresses that don't resolve in the 
> current target
> pass
> ```
> 
> We could remove the JITLoader class all together.

I think I'd come at if from the opposite direction.  We don't currently know 
what the full set of messages that we want to send are, so m

[Lldb-commits] [lldb] [llvm] [NFC] Separate high-level-dependent portions of DWARFExpression (revised) (PR #143170)

2025-06-09 Thread via lldb-commits



@@ -425,7 +425,7 @@ void CFIProgram::printOperand(raw_ostream &OS, 
DIDumpOptions DumpOpts,
   case OT_Expression:
 assert(Instr.Expression && "missing DWARFExpression object");
 OS << " ";
-Instr.Expression->print(OS, DumpOpts, nullptr);
+DWARFExpressionPrinter::print(&(*Instr.Expression), OS, DumpOpts, nullptr);

Sterling-Augustine wrote:

Thanks. Done.

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

[Lldb-commits] [lldb] [lldb][NFC] Split RegisterContextUnwind::SavedLocationForRegister (PR #139817)

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

https://github.com/jasonmolenda updated 
https://github.com/llvm/llvm-project/pull/139817

>From e63e53adc0909f481a165eca958a3ac2ca4374ee Mon Sep 17 00:00:00 2001
From: Jason Molenda 
Date: Tue, 13 May 2025 17:11:08 -0700
Subject: [PATCH 1/9] [lldb][NFC] Split
 RegisterContextUnwind::SavedLocationForRegister

RegisterContextUnwind::SavedLocationForRegister is around 450 lines
that first find an abstract register location (e.g. "CFA-8") for a
register by looking in the UnwindPlans.  Then it evaluates the
abstract register location to create a concrete register location
(e.g. "stored at address 0x...", "live in register at frame 0").
There are some complicated cases in the first half of the method
to handle return address register architectures correctly, in
particular.

Looking at the two halves, they're both exactly 226 lines long and
there's little involvement between them except for passing an
abstract register location along.

(there were some parts in the "abstract register location" code
that would set the concrete register location, unnecessarily)

It's also a complex enough method that there are some bits of code
that aren't actually doing anything at this point.

This patch adds a RegisterContextUnwind::GetAbstractRegisterLocation
method, which does the first half, and has a clearly defined return
values.

The code to convert an AbstractRegisterLocation into a
ConcreteRegisterLocation remains in SavedLocationForRegister.

It's a bit of a tricky patch to visually inspect, despite it not
changing functionality, the reorganizations and rewrites make the
diff unreadable.  Nearly all the real changes are in the
"find the abstract register location" first half of the method.
I think reading the new code in its new form is the easiest way
to inspect this PR.  With a defined interface between the two of
what is expected, it's pretty easy to look at the code and reason
about whether it is written correctly.

(whereas before, that was very difficult, for me at least.)
---
 .../lldb/Target/RegisterContextUnwind.h   |   3 +
 lldb/source/Target/RegisterContextUnwind.cpp  | 530 +-
 lldb/source/Target/RegisterNumber.cpp |   1 +
 3 files changed, 259 insertions(+), 275 deletions(-)

diff --git a/lldb/include/lldb/Target/RegisterContextUnwind.h 
b/lldb/include/lldb/Target/RegisterContextUnwind.h
index 044a387fe5aa2..b10a364823b83 100644
--- a/lldb/include/lldb/Target/RegisterContextUnwind.h
+++ b/lldb/include/lldb/Target/RegisterContextUnwind.h
@@ -151,6 +151,9 @@ class RegisterContextUnwind : public 
lldb_private::RegisterContext {
   uint32_t lldb_regnum,
   lldb_private::UnwindLLDB::ConcreteRegisterLocation ®loc);

+  std::optional
+  GetAbstractRegisterLocation(uint32_t lldb_regnum, lldb::RegisterKind &kind);
+
   bool ReadRegisterValueFromRegisterLocation(
   lldb_private::UnwindLLDB::ConcreteRegisterLocation regloc,
   const lldb_private::RegisterInfo *reg_info,
diff --git a/lldb/source/Target/RegisterContextUnwind.cpp 
b/lldb/source/Target/RegisterContextUnwind.cpp
index cf4b96c6eda9f..a3931abefb054 100644
--- a/lldb/source/Target/RegisterContextUnwind.cpp
+++ b/lldb/source/Target/RegisterContextUnwind.cpp
@@ -1243,247 +1243,194 @@ bool RegisterContextUnwind::IsTrapHandlerSymbol(
   return false;
 }

-// Answer the question: Where did THIS frame save the CALLER frame ("previous"
-// frame)'s register value?
-
-enum UnwindLLDB::RegisterSearchResult
-RegisterContextUnwind::SavedLocationForRegister(
-uint32_t lldb_regnum,
-lldb_private::UnwindLLDB::ConcreteRegisterLocation ®loc) {
+// Search this stack frame's UnwindPlans for the AbstractRegisterLocation
+// for this register.
+//
+// When an AbstractRegisterLocation is found in an UnwindPlan, that is
+// returned, regardless of the ABI rules for volatile/non-volatile registers
+// in effect.
+//
+// If there is no unwind rule for a volatile (caller-preserved) register
+// the returned AbstractRegisterLocation will be IsUndefined,
+// indicating that we should stop searching.
+//
+// If there is no unwind rule for a non-volatile (callee-preserved)
+// register, the returned AbstractRegisterLocation will be IsSame.
+// In frame 0, IsSame means get the  value from the live register context.
+// Else it means to continue descending down the stack to more-live frames
+// looking for a location/value.
+//
+// An empty optional indicates that there was an error in processing.
+std::optional
+RegisterContextUnwind::GetAbstractRegisterLocation(uint32_t lldb_regnum,
+   lldb::RegisterKind &kind) {
   RegisterNumber regnum(m_thread, eRegisterKindLLDB, lldb_regnum);
   Log *log = GetLog(LLDBLog::Unwind);

-  // Have we already found this register location?
-  if (!m_registers.empty()) {
-std::map::const_iterator
-iterator;
-iterator = m_registers.find(regnum.GetAsKind(eRegisterKindLLDB));
-if (iterator != m_registers.end()) {
-  regloc = iterator

[Lldb-commits] [lldb] f5733b0 - [lldb][Mach-O] Fix DWARF5 debugging regression for Mach-O

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


Author: Jason Molenda
Date: 2025-06-09T17:42:31-07:00
New Revision: f5733b0b859ada51ab4a1cc239ce901ea30b297f

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

LOG: [lldb][Mach-O] Fix DWARF5 debugging regression for Mach-O

A unification of the DWARF section names,
https://github.com/llvm/llvm-project/pull/141344
broke dwarf5 debugging with Mach-O files.  The str_offset and
str_offset.dwo names are different in Mach-O from other object
files.

Added: 


Modified: 
lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp

Removed: 




diff  --git a/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp 
b/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
index cbfebdbe913db..b1741926b74aa 100644
--- a/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
+++ b/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
@@ -1595,6 +1595,8 @@ static lldb::SectionType GetSectionType(uint32_t flags,
   static ConstString g_sect_name_objc_classlist("__objc_classlist");
   static ConstString g_sect_name_cfstring("__cfstring");
 
+  static ConstString g_sect_name_dwarf_debug_str_offs("__debug_str_offs");
+  static ConstString 
g_sect_name_dwarf_debug_str_offs_dwo("__debug_str_offs.dwo");
   static ConstString g_sect_name_dwarf_apple_names("__apple_names");
   static ConstString g_sect_name_dwarf_apple_types("__apple_types");
   static ConstString g_sect_name_dwarf_apple_namespaces("__apple_namespac");
@@ -1609,6 +1611,11 @@ static lldb::SectionType GetSectionType(uint32_t flags,
   static ConstString g_sect_name_lldb_formatters("__lldbformatters");
   static ConstString g_sect_name_swift_ast("__swift_ast");
 
+  if (section_name == g_sect_name_dwarf_debug_str_offs)
+return eSectionTypeDWARFDebugStrOffsets;
+  if (section_name == g_sect_name_dwarf_debug_str_offs_dwo)
+return eSectionTypeDWARFDebugStrOffsetsDwo;
+
   llvm::StringRef stripped_name = section_name.GetStringRef();
   if (stripped_name.consume_front("__debug_"))
 return ObjectFile::GetDWARFSectionTypeFromName(stripped_name);



___
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-09 Thread Ebuka Ezike via lldb-commits



@@ -797,7 +797,8 @@ let Command = "process save_core" in {
 EnumArg<"SaveCoreStyle">, Desc<"Request a specific style "
 "of corefile to be saved.">;
   def process_save_core_plugin_name : Option<"plugin-name", "p">,
-OptionalArg<"Plugin">, Desc<"Specify a plugin name to create the core 
file. "
+Arg<"Plugin">, Completion<"ProcessSaveCorePlugin">,

da-viper wrote:

I changed it to that because passing just the `--plugin` argument does not have 
change the change on how the core is saved.  as it always checks plugins. 

https://github.com/llvm/llvm-project/blob/4e6896244f4129a22e311f7f6290a595b6f03b75/lldb/source/Core/PluginManager.cpp#L825-L843

I reverted it back to optional because of it breaking user space. 

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

[Lldb-commits] [lldb] [lldb][NFC] Split RegisterContextUnwind::SavedLocationForRegister (PR #139817)

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

https://github.com/jasonmolenda updated 
https://github.com/llvm/llvm-project/pull/139817

>From e63e53adc0909f481a165eca958a3ac2ca4374ee Mon Sep 17 00:00:00 2001
From: Jason Molenda 
Date: Tue, 13 May 2025 17:11:08 -0700
Subject: [PATCH 1/9] [lldb][NFC] Split
 RegisterContextUnwind::SavedLocationForRegister

RegisterContextUnwind::SavedLocationForRegister is around 450 lines
that first find an abstract register location (e.g. "CFA-8") for a
register by looking in the UnwindPlans.  Then it evaluates the
abstract register location to create a concrete register location
(e.g. "stored at address 0x...", "live in register at frame 0").
There are some complicated cases in the first half of the method
to handle return address register architectures correctly, in
particular.

Looking at the two halves, they're both exactly 226 lines long and
there's little involvement between them except for passing an
abstract register location along.

(there were some parts in the "abstract register location" code
that would set the concrete register location, unnecessarily)

It's also a complex enough method that there are some bits of code
that aren't actually doing anything at this point.

This patch adds a RegisterContextUnwind::GetAbstractRegisterLocation
method, which does the first half, and has a clearly defined return
values.

The code to convert an AbstractRegisterLocation into a
ConcreteRegisterLocation remains in SavedLocationForRegister.

It's a bit of a tricky patch to visually inspect, despite it not
changing functionality, the reorganizations and rewrites make the
diff unreadable.  Nearly all the real changes are in the
"find the abstract register location" first half of the method.
I think reading the new code in its new form is the easiest way
to inspect this PR.  With a defined interface between the two of
what is expected, it's pretty easy to look at the code and reason
about whether it is written correctly.

(whereas before, that was very difficult, for me at least.)
---
 .../lldb/Target/RegisterContextUnwind.h   |   3 +
 lldb/source/Target/RegisterContextUnwind.cpp  | 530 +-
 lldb/source/Target/RegisterNumber.cpp |   1 +
 3 files changed, 259 insertions(+), 275 deletions(-)

diff --git a/lldb/include/lldb/Target/RegisterContextUnwind.h 
b/lldb/include/lldb/Target/RegisterContextUnwind.h
index 044a387fe5aa2..b10a364823b83 100644
--- a/lldb/include/lldb/Target/RegisterContextUnwind.h
+++ b/lldb/include/lldb/Target/RegisterContextUnwind.h
@@ -151,6 +151,9 @@ class RegisterContextUnwind : public 
lldb_private::RegisterContext {
   uint32_t lldb_regnum,
   lldb_private::UnwindLLDB::ConcreteRegisterLocation ®loc);

+  std::optional
+  GetAbstractRegisterLocation(uint32_t lldb_regnum, lldb::RegisterKind &kind);
+
   bool ReadRegisterValueFromRegisterLocation(
   lldb_private::UnwindLLDB::ConcreteRegisterLocation regloc,
   const lldb_private::RegisterInfo *reg_info,
diff --git a/lldb/source/Target/RegisterContextUnwind.cpp 
b/lldb/source/Target/RegisterContextUnwind.cpp
index cf4b96c6eda9f..a3931abefb054 100644
--- a/lldb/source/Target/RegisterContextUnwind.cpp
+++ b/lldb/source/Target/RegisterContextUnwind.cpp
@@ -1243,247 +1243,194 @@ bool RegisterContextUnwind::IsTrapHandlerSymbol(
   return false;
 }

-// Answer the question: Where did THIS frame save the CALLER frame ("previous"
-// frame)'s register value?
-
-enum UnwindLLDB::RegisterSearchResult
-RegisterContextUnwind::SavedLocationForRegister(
-uint32_t lldb_regnum,
-lldb_private::UnwindLLDB::ConcreteRegisterLocation ®loc) {
+// Search this stack frame's UnwindPlans for the AbstractRegisterLocation
+// for this register.
+//
+// When an AbstractRegisterLocation is found in an UnwindPlan, that is
+// returned, regardless of the ABI rules for volatile/non-volatile registers
+// in effect.
+//
+// If there is no unwind rule for a volatile (caller-preserved) register
+// the returned AbstractRegisterLocation will be IsUndefined,
+// indicating that we should stop searching.
+//
+// If there is no unwind rule for a non-volatile (callee-preserved)
+// register, the returned AbstractRegisterLocation will be IsSame.
+// In frame 0, IsSame means get the  value from the live register context.
+// Else it means to continue descending down the stack to more-live frames
+// looking for a location/value.
+//
+// An empty optional indicates that there was an error in processing.
+std::optional
+RegisterContextUnwind::GetAbstractRegisterLocation(uint32_t lldb_regnum,
+   lldb::RegisterKind &kind) {
   RegisterNumber regnum(m_thread, eRegisterKindLLDB, lldb_regnum);
   Log *log = GetLog(LLDBLog::Unwind);

-  // Have we already found this register location?
-  if (!m_registers.empty()) {
-std::map::const_iterator
-iterator;
-iterator = m_registers.find(regnum.GetAsKind(eRegisterKindLLDB));
-if (iterator != m_registers.end()) {
-  regloc = iterator

[Lldb-commits] [lldb] 474db6a - [NFC] Separate high-level-dependent portions of DWARFExpression (revised) (#143170)

2025-06-09 Thread via lldb-commits


Author: Sterling-Augustine
Date: 2025-06-09T16:32:40-07:00
New Revision: 474db6a85257612a2e878320d0bae51cb884d4f9

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

LOG: [NFC] Separate high-level-dependent portions of DWARFExpression (revised) 
(#143170)

(Revised version of a previous, unreviewed, PR.)

Move all expression verification into its only client: DWARFVerifier.
Move all printing code (which was a mix of static and member functions)
into a separate class.

This is one in a series of refactoring PRs to separate dwarf
functionality into lower-level pieces usable without object files and
sections at build time. The code is already written this way via various
"if (section == nullptr)" and similar conditionals. So the functionality
itself is needed and exists, but only as a runtime feature. The goal of
these refactors is to remove the build-time dependencies, which will
allow the existing functionality to be used from lower-level parts of
the compiler. Particularly from lib/MC/ More information at:


https://discourse.llvm.org/t/rfc-debuginfo-dwarf-refactor-into-to-lower-and-higher-level-libraries/86665

Added: 


Modified: 
lldb/source/Expression/DWARFExpression.cpp
lldb/source/Symbol/UnwindPlan.cpp
lldb/unittests/Symbol/PostfixExpressionTest.cpp
lldb/unittests/SymbolFile/NativePDB/PdbFPOProgramToDWARFExpressionTests.cpp
llvm/include/llvm/DebugInfo/DWARF/DWARFExpression.h
llvm/include/llvm/DebugInfo/DWARF/DWARFVerifier.h
llvm/lib/DebugInfo/DWARF/DWARFCFIProgram.cpp
llvm/lib/DebugInfo/DWARF/DWARFDebugFrame.cpp
llvm/lib/DebugInfo/DWARF/DWARFDebugLoc.cpp
llvm/lib/DebugInfo/DWARF/DWARFDie.cpp
llvm/lib/DebugInfo/DWARF/DWARFExpression.cpp
llvm/lib/DebugInfo/DWARF/DWARFVerifier.cpp
llvm/lib/DebugInfo/LogicalView/Readers/LVDWARFReader.cpp
llvm/tools/llvm-objdump/SourcePrinter.cpp
llvm/unittests/DebugInfo/DWARF/DWARFExpressionCompactPrinterTest.cpp

Removed: 




diff  --git a/lldb/source/Expression/DWARFExpression.cpp 
b/lldb/source/Expression/DWARFExpression.cpp
index 5ae3c9ef7c7dd..661324338e801 100644
--- a/lldb/source/Expression/DWARFExpression.cpp
+++ b/lldb/source/Expression/DWARFExpression.cpp
@@ -80,8 +80,8 @@ void DWARFExpression::DumpLocation(Stream *s, 
lldb::DescriptionLevel level,
   };
   llvm::DIDumpOptions DumpOpts;
   DumpOpts.GetNameForDWARFReg = GetRegName;
-  llvm::DWARFExpression(m_data.GetAsLLVM(), m_data.GetAddressByteSize())
-  .print(s->AsRawOstream(), DumpOpts, nullptr);
+  llvm::DWARFExpression E(m_data.GetAsLLVM(), m_data.GetAddressByteSize());
+  llvm::DWARFExpressionPrinter::print(&E, s->AsRawOstream(), DumpOpts, 
nullptr);
 }
 
 RegisterKind DWARFExpression::GetRegisterKind() const { return m_reg_kind; }

diff  --git a/lldb/source/Symbol/UnwindPlan.cpp 
b/lldb/source/Symbol/UnwindPlan.cpp
index b1a96b5e26840..e9ac6b6cde295 100644
--- a/lldb/source/Symbol/UnwindPlan.cpp
+++ b/lldb/source/Symbol/UnwindPlan.cpp
@@ -87,8 +87,10 @@ static void DumpDWARFExpr(Stream &s, llvm::ArrayRef 
expr, Thread *threa
   if (auto order_and_width = GetByteOrderAndAddrSize(thread)) {
 llvm::DataExtractor data(expr, order_and_width->first == eByteOrderLittle,
  order_and_width->second);
-llvm::DWARFExpression(data, order_and_width->second, llvm::dwarf::DWARF32)
-.print(s.AsRawOstream(), llvm::DIDumpOptions(), nullptr);
+llvm::DWARFExpression E(data, order_and_width->second,
+llvm::dwarf::DWARF32);
+llvm::DWARFExpressionPrinter::print(&E, s.AsRawOstream(),
+llvm::DIDumpOptions(), nullptr);
   } else
 s.PutCString("dwarf-expr");
 }

diff  --git a/lldb/unittests/Symbol/PostfixExpressionTest.cpp 
b/lldb/unittests/Symbol/PostfixExpressionTest.cpp
index d56df476ebaab..1e437da5133d9 100644
--- a/lldb/unittests/Symbol/PostfixExpressionTest.cpp
+++ b/lldb/unittests/Symbol/PostfixExpressionTest.cpp
@@ -159,8 +159,8 @@ static std::string ParseAndGenerateDWARF(llvm::StringRef 
expr) {
 
   std::string result;
   llvm::raw_string_ostream os(result);
-  llvm::DWARFExpression(extractor, addr_size, llvm::dwarf::DWARF32)
-  .print(os, llvm::DIDumpOptions(), nullptr);
+  llvm::DWARFExpression E(extractor, addr_size, llvm::dwarf::DWARF32);
+  llvm::DWARFExpressionPrinter::print(&E, os, llvm::DIDumpOptions(), nullptr);
   return result;
 }
 

diff  --git 
a/lldb/unittests/SymbolFile/NativePDB/PdbFPOProgramToDWARFExpressionTests.cpp 
b/lldb/unittests/SymbolFile/NativePDB/PdbFPOProgramToDWARFExpressionTests.cpp
index efb8f720b56e1..d746e04f8a9fc 100644
--- 
a/lldb/unittests/SymbolFile/NativePDB/PdbFPOProgramToDWARFExpressionTests.cpp
+++ 
b/lldb/unittests/SymbolFile/NativePDB/PdbFPOProgramToDWARFExpressi

[Lldb-commits] [lldb] [llvm] [NFC] Separate high-level-dependent portions of DWARFExpression (revised) (PR #143170)

2025-06-09 Thread via lldb-commits


https://github.com/Sterling-Augustine closed 
https://github.com/llvm/llvm-project/pull/143170
___
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-09 Thread David Spickett via lldb-commits



@@ -198,6 +198,8 @@ static constexpr OptionEnumValueElement g_completion_type[] 
= {
  "Completes to a type category name."},
 {lldb::eCustomCompletion, "custom", "Custom completion."},
 {lldb::eThreadIDCompletion, "thread-id", "Completes to a thread ID."},
+{lldb::eProcessSaveCorePluginCompletion, "plugin-name",
+ "Completes to a process save-core plugin"},

DavidSpickett wrote:

"Completes to an ObjectFile plugin that can save core files."

More specific without having to go read the command sources. We can find out 
what command uses it by searching for the enumerator if we need to.

https://github.com/llvm/llvm-project/pull/143126
___
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-09 Thread David Spickett via lldb-commits



@@ -22,8 +22,19 @@ 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: ");

DavidSpickett wrote:

Either refer to the names as names, or as values, not a mix of the two. I 
suggest using "name" in all cases.

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

[Lldb-commits] [lldb] Add commands to list/enable/disable plugins (PR #134418)

2025-06-09 Thread Greg Clayton via lldb-commits


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


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

[Lldb-commits] [lldb] [lldb] Fix the incorrect reporting of dwarf5 .debug_names index time during partial indexing (PR #134133)

2025-06-09 Thread Greg Clayton via lldb-commits


https://github.com/clayborg requested changes to this pull request.

Just add a quick test for this and it is ready to go.

https://github.com/llvm/llvm-project/pull/134133
___
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-09 Thread Greg Clayton via lldb-commits


clayborg wrote:

> This seems like a generic module loading observer. I don't see anything JIT 
> specific about it. Not saying a generic module loading observer is not a good 
> idea. But calling it a JITLoader seems pretty confusing to me.

true, in the current form. Check out the comments in my previous reply about 
the motivations for this.



> One thing that's nicer about your approach here over independent callbacks 
> for each of the hooks is that it allows you to group the three callbacks in 
> the same class instance, so that you can more easily keep shared state.
> 
> But that's a general problem with these affordances. For instance, it's super 
> inconvenient that the summary providers and synthetic child providers produce 
> separate objects to handle the callbacks. You end up computing the sizes of 
> container classes twice, once for the summary and once because you need it to 
> present the type... If the summary & child provider could share state, you'd 
> only need to do that once per stop.
> 
> And as we are adding more of these callbacks for "lifecycle events" it would 
> be really convenient, as you have done here, to be able to get one object to 
> manage multiple different types of callback hits.
> 
> For the case of hooks, I wonder if we could augment the -C options we 
> currently use to add affordances backed by a Python class with a `__call__` 
> method so you could say:
> 
> `target stop-hook add -C my_python_class --shared-instance 1 --call_method 
> stop_hook_handler `
> 
> and then to finish off your design, we'd add:
> 
> `target module-hook add -C my_python_class --shared-instance 1 --call_method 
> module_hook_handler `
> 
> The --shared-instance that would tell lldb to make a single object instance 
> and reuse if for any --shared-instance addition that uses this class (one for 
> each target in this case). Allowing you to specify the method name means you 
> don't have to do the discrimination in `__call__`...
> 
> That way as we add more of these callbacks (which I agree we really need to 
> do) people could mix and match them as the wish, and we wouldn't have to 
> figure out the right combination(s) for everybody's use cases.
> 
> Note for summary & synthetic child providers you wouldn't need to specify the 
> methods as those are pre-determined. So the `--call-method` would not be 
> necessary. In their case the shared instance would be held by a ValueObject, 
> since we make formatter instances for each value object we format.
> 
> It might also be handy to be able to define several commands that share 
> state, so you could do the same thing for command classes (though in that 
> case the shared instance would be held by the debugger not the target...)

It would be great to create a generic version of this that allows users to add 
methods to a python class and just have it be notified. That being said, by 
motivation here is to augment the JITLoader plug-in API to do more things as 
mentioned above. Now we can probably do this with a notification class that we 
can install as long as we can find out about everything that is needed. So one 
approach might be to allow a python class to get all of the notifications I 
need for the JITLoader plug-in without calling it a JITLoader as you wanted. 
The class could be something like:
```
class TargetObserver:
def __init__(self, target):
# Created as soon as a target is created
self.target = target
  
# Module observing
def module_added(self, module):
# Called anytime a module is added to the target
pass
def module_removed(self, module):
# Called anytime a module is removed from the target
pass
def module_loaded(self, module):
# Called when the module is loaded or modified by the dynamic loader
pass

# Launch/Attach observing
def did_launch(self):
# Called when the target is done being launched
pass
def did_attach(self):
# Called when the target is done being attached
pass

# Breakpoint observing
def breakpoint_added(self, breakpoint):
# Called when a breakpoint is added to the target
pass
def breakpoint_modified(self, breakpoint):
# Called when a breakpoint is modified to the target
pass
def breakpoint_deleted(self, breakpoint):
# Called when a breakpoint is added to the target
pass

# Unresolved address resolving observation
def resolve_load_address(self, load_addr):
# Allow plug-ins to help resolve addresses that don't resolve in the 
current target
pass


We could remove the JITLoader class all together.

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] [clang] [lldb] [Clang][PowerPC] Add __dmr type and DMF integer calculation builtins (PR #142480)

2025-06-09 Thread Maryam Moghadas via lldb-commits


https://github.com/maryammo updated 
https://github.com/llvm/llvm-project/pull/142480

>From 5ef7a4ca7c2a838a6b2100968d5023e0797b2848 Mon Sep 17 00:00:00 2001
From: Maryam Moghadas 
Date: Mon, 2 Jun 2025 19:54:57 +
Subject: [PATCH 1/2] [Clang][PowerPC] Add __dmr type and DMF integer
 calculation builtins

Define the __dmr type used to manipulate the new DMR registers introduced by
the Dense Math Facility (DMF) on PowerPC, and add six Clang builtins that
correspond to the integer outer-product accumulate to ACC instructions:
__builtin_mma_dmxvi8gerx4, __builtin_mma_pmdmxvi8gerx4,
__builtin_mma_dmxvi8gerx4pp, __builtin_mma_pmdmxvi8gerx4pp,
__builtin_mma_dmxvi8gerx4spp, and __builtin_mma_pmdmxvi8gerx4spp.
---
 clang/include/clang/Basic/BuiltinsPPC.def |  12 ++
 clang/include/clang/Basic/PPCTypes.def|   1 +
 clang/lib/AST/ASTContext.cpp  |   1 +
 clang/test/AST/ast-dump-ppc-types.c   |  13 +-
 .../CodeGen/PowerPC/builtins-ppc-mmaplus.c|  94 +
 .../PowerPC/ppc-future-mma-builtin-err.c  |  21 ++
 ...ppc-future-paired-vec-memops-builtin-err.c |  20 ++
 .../test/CodeGen/PowerPC/ppc-mmaplus-types.c  | 184 ++
 .../test/CodeGenCXX/ppc-mangle-mma-types.cpp  |   5 +
 clang/test/Sema/ppc-pair-mma-types.c  |  98 ++
 .../TypeSystem/Clang/TypeSystemClang.cpp  |   1 +
 11 files changed, 447 insertions(+), 3 deletions(-)
 create mode 100644 clang/test/CodeGen/PowerPC/builtins-ppc-mmaplus.c
 create mode 100644 clang/test/CodeGen/PowerPC/ppc-future-mma-builtin-err.c
 create mode 100644 
clang/test/CodeGen/PowerPC/ppc-future-paired-vec-memops-builtin-err.c
 create mode 100644 clang/test/CodeGen/PowerPC/ppc-mmaplus-types.c

diff --git a/clang/include/clang/Basic/BuiltinsPPC.def 
b/clang/include/clang/Basic/BuiltinsPPC.def
index bb7d54bbb793e..099500754a0e0 100644
--- a/clang/include/clang/Basic/BuiltinsPPC.def
+++ b/clang/include/clang/Basic/BuiltinsPPC.def
@@ -1134,6 +1134,18 @@ UNALIASED_CUSTOM_BUILTIN(mma_pmxvbf16ger2np, 
"vW512*VVi15i15i3", true,
  "mma,paired-vector-memops")
 UNALIASED_CUSTOM_BUILTIN(mma_pmxvbf16ger2nn, "vW512*VVi15i15i3", true,
  "mma,paired-vector-memops")
+UNALIASED_CUSTOM_BUILTIN(mma_dmxvi8gerx4, "vW1024*W256V", false,
+ "mma,paired-vector-memops")
+UNALIASED_CUSTOM_BUILTIN(mma_pmdmxvi8gerx4, "vW1024*W256Vi255i15i15", false,
+ "mma,paired-vector-memops")
+UNALIASED_CUSTOM_BUILTIN(mma_dmxvi8gerx4pp, "vW1024*W256V", true,
+ "mma,paired-vector-memops")
+UNALIASED_CUSTOM_BUILTIN(mma_pmdmxvi8gerx4pp, "vW1024*W256Vi255i15i15", true,
+ "mma,paired-vector-memops")
+UNALIASED_CUSTOM_BUILTIN(mma_dmxvi8gerx4spp,  "vW1024*W256V", true,
+ "mma,paired-vector-memops")
+UNALIASED_CUSTOM_BUILTIN(mma_pmdmxvi8gerx4spp, "vW1024*W256Vi255i15i15", true,
+ "mma,paired-vector-memops")
 
 // FIXME: Obviously incomplete.
 
diff --git a/clang/include/clang/Basic/PPCTypes.def 
b/clang/include/clang/Basic/PPCTypes.def
index 9e2cb2aedc9fc..cfc9de3a473d4 100644
--- a/clang/include/clang/Basic/PPCTypes.def
+++ b/clang/include/clang/Basic/PPCTypes.def
@@ -30,6 +30,7 @@
 #endif
 
 
+PPC_VECTOR_MMA_TYPE(__dmr, VectorDmr, 1024)
 PPC_VECTOR_MMA_TYPE(__vector_quad, VectorQuad, 512)
 PPC_VECTOR_VSX_TYPE(__vector_pair, VectorPair, 256)
 
diff --git a/clang/lib/AST/ASTContext.cpp b/clang/lib/AST/ASTContext.cpp
index 45f9602856840..ffb4ca61b00c4 100644
--- a/clang/lib/AST/ASTContext.cpp
+++ b/clang/lib/AST/ASTContext.cpp
@@ -3455,6 +3455,7 @@ static void encodeTypeForFunctionPointerAuth(const 
ASTContext &Ctx,
 case BuiltinType::BFloat16:
 case BuiltinType::VectorQuad:
 case BuiltinType::VectorPair:
+case BuiltinType::VectorDmr:
   OS << "?";
   return;
 
diff --git a/clang/test/AST/ast-dump-ppc-types.c 
b/clang/test/AST/ast-dump-ppc-types.c
index 26ae5441f20d7..a430268284413 100644
--- a/clang/test/AST/ast-dump-ppc-types.c
+++ b/clang/test/AST/ast-dump-ppc-types.c
@@ -1,9 +1,11 @@
+// RUN: %clang_cc1 -triple powerpc64le-unknown-unknown -target-cpu future \
+// RUN:   -ast-dump  %s | FileCheck %s
 // RUN: %clang_cc1 -triple powerpc64le-unknown-unknown -target-cpu pwr10 \
-// RUN:   -ast-dump -ast-dump-filter __vector %s | FileCheck %s
+// RUN:   -ast-dump  %s | FileCheck %s
 // RUN: %clang_cc1 -triple powerpc64le-unknown-unknown -target-cpu pwr9 \
-// RUN:   -ast-dump -ast-dump-filter __vector %s | FileCheck %s
+// RUN:   -ast-dump  %s | FileCheck %s
 // RUN: %clang_cc1 -triple powerpc64le-unknown-unknown -target-cpu pwr8 \
-// RUN:   -ast-dump -ast-dump-filter __vector %s | FileCheck %s
+// RUN:   -ast-dump  %s | FileCheck %s
 // RUN: %clang_cc1 -triple x86_64-unknown-unknown -ast-dump %s | FileCheck %s \
 // RUN:   --check-prefix=CHECK-X86_64
 // RUN: %clang_cc1 -triple arm-unknown-unknown -ast-dump %s | FileCheck %s \
@@ -15,16 +17,21 @@

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

2025-06-09 Thread via lldb-commits


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

>From 05d118b35936d0ed02c627ed094a5cd5b48451f4 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   |  37 
 .../msvcstl/u8string/Makefile |   4 +
 .../u8string/TestDataFormatterStdU8String.py  |  31 
 .../msvcstl/u8string/main.cpp |  15 ++
 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..7717f1945968a 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 "windows" in platform:
+return False, f"Don't know how to build with MSVC's STL on {platform}"
+return True, "MSVC STL is present on Windows"
+
+
+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 a

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

2025-06-09 Thread via lldb-commits


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

>From e7c1973cb18636174d4f6cab90643cbb04e96262 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..7717f1945968a 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 "windows" in platform:
+return False, f"Don't know how to build with MSVC's STL on {platform}"
+return True, "MSVC STL is present on Windows"
+
+
+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] d4fe522 - Add commands to list/enable/disable plugins (#134418)

2025-06-09 Thread via lldb-commits


Author: David Peixotto
Date: 2025-06-09T13:30:13-07:00
New Revision: d4fe522eb4ae710e90107a682911fc75f2388a87

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

LOG: Add commands to list/enable/disable plugins (#134418)

This commit adds three new commands for managing plugins. The `list`
command will show which plugins are currently registered and their
enabled state. The `enable` and `disable` commands can be used to enable
or disable plugins.

A disabled plugin will not show up to the PluginManager when it iterates
over available plugins of a particular type.

The purpose of these commands is to provide more visibility into
registered plugins and allow users to disable plugins for experimental
perf reasons.

There are a few limitations to the current implementation

1. Only SystemRuntime and InstrumentationRuntime plugins are currently
supported. We can easily extend the existing implementation to support
more types. The scope was limited to these plugins to keep the PR size
manageable.

2. Only "statically" know plugin types are supported (i.e. those managed
by the PluginManager and not from `plugin load`). It is possibly we
could support dynamic plugins as well, but I have not looked into it
yet.

Added: 
lldb/test/Shell/Commands/command-plugin-enable+disable.test
lldb/test/Shell/Commands/command-plugin-list.test

Modified: 
lldb/include/lldb/Core/PluginManager.h
lldb/include/lldb/Interpreter/CommandOptionArgumentTable.h
lldb/include/lldb/Target/Statistics.h
lldb/include/lldb/lldb-enumerations.h
lldb/source/Commands/CommandObjectPlugin.cpp
lldb/source/Commands/CommandObjectStats.cpp
lldb/source/Commands/Options.td
lldb/source/Core/PluginManager.cpp
lldb/source/Target/Statistics.cpp
lldb/test/API/commands/statistics/basic/TestStats.py
lldb/unittests/Core/PluginManagerTest.cpp

Removed: 




diff  --git a/lldb/include/lldb/Core/PluginManager.h 
b/lldb/include/lldb/Core/PluginManager.h
index e2f709ecd2ff7..e7b169103 100644
--- a/lldb/include/lldb/Core/PluginManager.h
+++ b/lldb/include/lldb/Core/PluginManager.h
@@ -19,10 +19,13 @@
 #include "lldb/lldb-enumerations.h"
 #include "lldb/lldb-forward.h"
 #include "lldb/lldb-private-interfaces.h"
+#include "llvm/ADT/ArrayRef.h"
 #include "llvm/ADT/StringRef.h"
+#include "llvm/Support/JSON.h"
 
 #include 
 #include 
+#include 
 #include 
 
 #define LLDB_PLUGIN_DEFINE_ADV(ClassName, PluginName)  
\
@@ -55,12 +58,67 @@ struct RegisteredPluginInfo {
   bool enabled = false;
 };
 
+// Define some data structures to describe known plugin "namespaces".
+// The PluginManager is organized into a series of static functions
+// that operate on 
diff erent types of plugins. For example SystemRuntime
+// and ObjectFile plugins.
+//
+// The namespace name is used a prefix when matching plugin names. For example,
+// if we have an "macosx" plugin in the "system-runtime" namespace then we will
+// match a plugin name pattern against the "system-runtime.macosx" name.
+//
+// The plugin namespace here is used so we can operate on all the plugins
+// of a given type so it is easy to enable or disable them as a group.
+using GetPluginInfo = std::function()>;
+using SetPluginEnabled = std::function;
+struct PluginNamespace {
+  llvm::StringRef name;
+  GetPluginInfo get_info;
+  SetPluginEnabled set_enabled;
+};
+
 class PluginManager {
 public:
   static void Initialize();
 
   static void Terminate();
 
+  // Support for enabling and disabling plugins.
+
+  // Return the plugins that can be enabled or disabled by the user.
+  static llvm::ArrayRef GetPluginNamespaces();
+
+  // Generate a json object that describes the plugins that are available.
+  // This is a json representation of the plugin info returned by
+  // GetPluginNamespaces().
+  //
+  //{
+  //   : [
+  //   {
+  //   "enabled": ,
+  //   "name": ,
+  //   },
+  //   ...
+  //   ],
+  //   ...
+  //}
+  //
+  // If pattern is given it will be used to filter the plugins that are
+  // are returned. The pattern filters the plugin names using the
+  // PluginManager::MatchPluginName() function.
+  static llvm::json::Object GetJSON(llvm::StringRef pattern = "");
+
+  // Return true if the pattern matches the plugin name.
+  //
+  // The pattern matches the name if it is exactly equal to the namespace name
+  // or if it is equal to the qualified name, which is the namespace name
+  // followed by a dot and the plugin name (e.g. "system-runtime.foo").
+  //
+  // An empty pattern matches all plugins.
+  static bool MatchPluginName(llvm::StringRef pattern,
+  const PluginNamespace &plugin_ns,
+  cons

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

2025-06-09 Thread via lldb-commits


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

[Lldb-commits] [lldb] Add commands to list/enable/disable plugins (PR #134418)

2025-06-09 Thread David Peixotto via lldb-commits


https://github.com/dmpots closed 
https://github.com/llvm/llvm-project/pull/134418
___
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-09 Thread David Spickett via lldb-commits



@@ -198,6 +198,8 @@ static constexpr OptionEnumValueElement g_completion_type[] 
= {
  "Completes to a type category name."},
 {lldb::eCustomCompletion, "custom", "Custom completion."},
 {lldb::eThreadIDCompletion, "thread-id", "Completes to a thread ID."},
+{lldb::eProcessSaveCorePluginCompletion, "plugin-name",

DavidSpickett wrote:

It's not like this gets into the API, but I think the name should be more 
specific than "plugin-name". How about "save-core-plugin-name"?

There are other commands that have plugin options for different types of 
plugins. So unless we pramaterise this one completion later, they'll have their 
own specific filters to apply.

https://github.com/llvm/llvm-project/pull/143126
___
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-09 Thread David Spickett via lldb-commits



@@ -198,6 +198,8 @@ static constexpr OptionEnumValueElement g_completion_type[] 
= {
  "Completes to a type category name."},
 {lldb::eCustomCompletion, "custom", "Custom completion."},
 {lldb::eThreadIDCompletion, "thread-id", "Completes to a thread ID."},
+{lldb::eProcessSaveCorePluginCompletion, "plugin-name",
+ "Completes to a process save-core plugin"},

DavidSpickett wrote:

Basically phrase it more like:
```
{lldb::ePlatformPluginCompletion, "platform-plugin",
 "Completes to a platform plugin."},
```

https://github.com/llvm/llvm-project/pull/143126
___
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-09 Thread David Spickett via lldb-commits



@@ -1281,7 +1281,26 @@ class CommandObjectProcessSaveCore : public 
CommandObjectParsed {
 ~CommandOptions() override = default;
 
 llvm::ArrayRef GetDefinitions() override {
-  return llvm::ArrayRef(g_process_save_core_options);
+  if (m_opt_def.empty()) {

DavidSpickett wrote:

Actually now I see you are modifying opt_def, but still, I think having 2 
return points is easier to read.

https://github.com/llvm/llvm-project/pull/143126
___
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-09 Thread David Spickett via lldb-commits



@@ -22,8 +22,26 @@ Status SaveCoreOptions::SetPluginName(const char *name) {
   }
 
   if (!PluginManager::IsRegisteredObjectFilePluginName(name)) {

DavidSpickett wrote:

In other words:
if (!PluginManager::IsRegisteredObjectFilePluginName(name)) {

Is checking a different list of names than:
PluginManager::GetSaveCorePluginNames();

Will print.

So a user could use a valid plugin name, for a plugin that doesn't happen to 
support core files. Then read the error message later and see that name doesn't 
even appear even though the command accepted it.

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

[Lldb-commits] [lldb] [llvm] [NFC] Separate high-level-dependent portions of DWARFExpression (revised) (PR #143170)

2025-06-09 Thread David Blaikie via lldb-commits



@@ -425,7 +425,7 @@ void CFIProgram::printOperand(raw_ostream &OS, 
DIDumpOptions DumpOpts,
   case OT_Expression:
 assert(Instr.Expression && "missing DWARFExpression object");
 OS << " ";
-Instr.Expression->print(OS, DumpOpts, nullptr);
+DWARFExpressionPrinter::print(&(*Instr.Expression), OS, DumpOpts, nullptr);

dwblaikie wrote:

No need for the parents here? Could use .get instead of &* , and wouldn't need 
the null check in the next case

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

[Lldb-commits] [lldb] [llvm] [NFC] Separate high-level-dependent portions of DWARFExpression (revised) (PR #143170)

2025-06-09 Thread David Blaikie via lldb-commits


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

[Lldb-commits] [lldb] [llvm] [NFC] Separate high-level-dependent portions of DWARFExpression (revised) (PR #143170)

2025-06-09 Thread David Blaikie via lldb-commits


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


https://github.com/llvm/llvm-project/pull/143170
___
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-09 Thread Jacob Lalonde via lldb-commits


https://github.com/Jlalond commented:

Commented on my own real concern. David can approve the land, but please don't 
break the current default behavior :)

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

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

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


https://github.com/DavidSpickett created 
https://github.com/llvm/llvm-project/pull/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.

>From 7316a626d2934737a0b4a6a284357882e221e0b6 Mon Sep 17 00:00:00 2001
From: David Spickett 
Date: Mon, 9 Jun 2025 14:50:29 +
Subject: [PATCH] [lldb] Use 1 based row and column for statusline

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.

>From what I read, some terminals correct 0 back to 1
and some treat 0 as a missing argument, which also
defaults to 1.
---
 lldb/source/Core/Statusline.cpp | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

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"
 

___
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-09 Thread Jacob Lalonde via lldb-commits



@@ -797,7 +797,8 @@ let Command = "process save_core" in {
 EnumArg<"SaveCoreStyle">, Desc<"Request a specific style "
 "of corefile to be saved.">;
   def process_save_core_plugin_name : Option<"plugin-name", "p">,
-OptionalArg<"Plugin">, Desc<"Specify a plugin name to create the core 
file. "
+Arg<"Plugin">, Completion<"ProcessSaveCorePlugin">,

Jlalond wrote:

I think almost all the tests specify a plugin, so this shouldn't affect us that 
much. I think we should keep the default behavior. Imagine if someone is using 
LLDB right now to capture Minidumps in an automated fashion and isn't 
specifying the plugin? We have accidentally created a user space contract and 
we shouldn't break that without communicating it.

https://github.com/llvm/llvm-project/pull/143126
___
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-09 Thread Jacob Lalonde via lldb-commits



@@ -198,6 +198,8 @@ static constexpr OptionEnumValueElement g_completion_type[] 
= {
  "Completes to a type category name."},
 {lldb::eCustomCompletion, "custom", "Custom completion."},
 {lldb::eThreadIDCompletion, "thread-id", "Completes to a thread ID."},
+{lldb::eProcessSaveCorePluginCompletion, "plugin-name",

Jlalond wrote:

I agree with Spickett here, `save-core` is the overall phrase for all of this 
behavior and it makes it very greppable

https://github.com/llvm/llvm-project/pull/143126
___
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-09 Thread Jacob Lalonde via lldb-commits


https://github.com/Jlalond edited 
https://github.com/llvm/llvm-project/pull/143126
___
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-09 Thread Jacob Lalonde via lldb-commits


https://github.com/Jlalond edited 
https://github.com/llvm/llvm-project/pull/143126
___
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-09 Thread David Spickett via lldb-commits



@@ -797,7 +797,8 @@ let Command = "process save_core" in {
 EnumArg<"SaveCoreStyle">, Desc<"Request a specific style "
 "of corefile to be saved.">;
   def process_save_core_plugin_name : Option<"plugin-name", "p">,
-OptionalArg<"Plugin">, Desc<"Specify a plugin name to create the core 
file. "
+Arg<"Plugin">, Completion<"ProcessSaveCorePlugin">,

DavidSpickett wrote:

This is a change in behaviour. Are we not defaulting to a plugin due to this?

I'm not against it necessarily, but it might surprise current users aka 
@Jlalond .

https://github.com/llvm/llvm-project/pull/143126
___
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-09 Thread David Spickett via lldb-commits



@@ -792,6 +792,12 @@ Status PluginManager::SaveCore(const lldb::ProcessSP 
&process_sp,
 }
   }
 
+  // report for one plugin if a name is specified.
+  if (error.Success() && !plugin_name.empty())
+error = Status::FromErrorStringWithFormatv(

DavidSpickett wrote:

Won't this error be overwritten by the one set on line 804?

if (error.Success() && whatever)
  some error
if (error.Success())
  some other error

return the error

https://github.com/llvm/llvm-project/pull/143126
___
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-09 Thread David Spickett via lldb-commits


https://github.com/DavidSpickett commented:

Trying not to bog you down in nitpicks, honest :)

There are completion test cases 
(`lldb/test/API/functionalities/completion/TestCompletion.py` at least). See if 
you can add to those.

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

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

2025-06-09 Thread via lldb-commits

llvmbot wrote:

@llvm/pr-subscribers-lldb

Author: David Spickett (DavidSpickett)

Changes

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.

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

1 Files Affected:

- (modified) lldb/source/Core/Statusline.cpp (+2-2) 

``diff
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"

``

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] [lldb] Use 1 based row and column for statusline (PR #143385)

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


https://github.com/DavidSpickett edited 
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] Add a python JIT loader class. (PR #142514)

2025-06-09 Thread Greg Clayton via lldb-commits

clayborg wrote:

> > This seems like a generic module loading observer. I don't see anything JIT 
> > specific about it. Not saying a generic module loading observer is not a 
> > good idea. But calling it a JITLoader seems pretty confusing to me.
> 
> +1 on the name. The design seems very general, so maybe calling it something 
> like ModuleObserver or something would make more sense.
> 
> Your PR summary describes what users can do, but why might they want to do 
> it? Do you have a motivation for this change?

I do, and I should have mentioned this in the description: I want to extend the 
JITLoader API to be able to lazily resolve addresses. Right now JIT loaders are 
inefficient and expensive to use as they must stop anytime something has been 
JIT'ed  and if a program JITs a million functions, we will stop a million times 
due to it setting a breakpoint in the process. I changed it so that any "load 
address -> lldb_private::Address" resolving goes though 
`Target::ResolveLoadAddress()` with:
```
commit c4fb7180cbbe977f1ab1ce945a691550f8fdd1fb
Author: Greg Clayton 
Date:   Tue Jan 14 20:12:46 2025 -0800

[lldb][NFC] Make the target's SectionLoadList private. (#113278)

Lots of code around LLDB was directly accessing the target's section
load list. This NFC patch makes the section load list private so the
Target class can access it, but everyone else now uses accessor
functions. This allows us to control the resolving of addresses and will
allow for functionality in LLDB which can lazily resolve addresses in
JIT plug-ins with a future patch.
```

With this in, we can modify the `Target::ResolveLoadAddress` function like:
```
bool Target::ResolveLoadAddress(addr_t load_addr, Address &so_addr,
uint32_t stop_id, bool allow_section_end) {
  bool result = m_section_load_history.ResolveLoadAddress(stop_id, load_addr, 
so_addr, allow_section_end);
  if (!result) {
// Check with JITLoader plug-ins and ask if they can resolve this address 
lazily.
...
  }
  return result;
}
```

This allows JIT loaders to be loaded with little or no cost until we do a 
backtrace. Any frames that go through JIT'ed functions that are not resolved 
allows the JIT loaded to load only what is needed.

Another future patch will notify the JITLoader plug-ins about breakpoints as 
they are created and allow the JIT loader to intelligently implement 
functionality to set breakpoints. We have an internal JIT solution that already 
does this. When a user sets a file and line breakpoint, or a breakpoint by 
name, the JIT loader will mark up its metadata and stop in the debugger when 
the code for this file and line breakpoint or breakpoint by name gets JIT'ed. 
Again, this helps us debug processes that JIT without the huge overhead that 
the current model imposes.

This patch lays the groundwork for current JITLoader plug-ins in python, and 
will allow me to modify the JITLoader API and test the new changes in python. 
It will allow me to break up the new changes piece by piece:
- JITLoader being able to lazily resolve functions as needed when a backtrace 
happens without needing to have a breakpoint set all the time
- JITLoader getting knowledge of breakpoint creation to allow breakpoints to be 
intelligently implemented by the JIT loader plug-in

@jimingham Hopefully this explains why this patch exists. I will read your 
comments above and comment if needed.

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] [lldb] add plugin names to process save-core error output. (PR #143126)

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



@@ -198,6 +198,8 @@ static constexpr OptionEnumValueElement g_completion_type[] 
= {
  "Completes to a type category name."},
 {lldb::eCustomCompletion, "custom", "Custom completion."},
 {lldb::eThreadIDCompletion, "thread-id", "Completes to a thread ID."},
+{lldb::eProcessSaveCorePluginCompletion, "plugin-name",

da-viper wrote:

I assumed the name here should match the argument name, will update. 

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

67 matches

Mail list logo