[Lldb-commits] [lldb] [lldb] Set return status to Failed when Python command raises uncaught exception (PR #113996)

[via lldb-commits]

@@ -621,6 +623,9 @@ bool 
lldb_private::python::SWIGBridge::LLDBSwigPythonCallCommand(
 pfunc(debugger_arg, PythonString(args),
   SWIGBridge::ToSWIGWrapper(std::move(exe_ctx_ref_sp)), 
cmd_retobj_arg.obj(), dict);
 
+  if (PyErr_Occurred())

jimingham wrote:

Might be nice here to check if the CommandReturnObject's ErrorString is empty, 
and if it is, add a boiler-plate error message like "Scripted command threw an 
uncaught exception".

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

[Lldb-commits] [lldb] [lldb-dap] Always pass disableASLR to the DAP executable (PR #113891)

[Michael Buch via lldb-commits]

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

[Lldb-commits] [lldb] b4e1af0 - [lldb-dap] Always pass disableASLR to the DAP executable (#113891)

[via lldb-commits]

Author: Michael Buch
Date: 2024-10-29T18:40:06Z
New Revision: b4e1af0096fd05ed4bddf11b48b604d75a7103d0

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

LOG: [lldb-dap] Always pass disableASLR to the DAP executable (#113891)

More context can be found in
https://github.com/llvm/llvm-project/pull/110303

For DAP tests running in constrained environments (e.g., Docker
containers), disabling ASLR isn't allowed. So we set `disableASLR=False`
(since https://github.com/llvm/llvm-project/pull/113593).

However, the `dap_server.py` will currently only forward the value
of `disableASLR` to the DAP executable if it's set to `True`. If the
DAP executable wasn't provided a `disableASLR` field it defaults to
`true` too:
https://github.com/llvm/llvm-project/blob/f14743794587db102c6d1b20f9c87a1ac20decfd/lldb/tools/lldb-dap/lldb-dap.cpp#L2103-L2104

This means that passing `disableASLR=False` from the tests is currently
not possible.

This is also true for many of the other boolean arguments of
`request_launch`. But this patch only addresses `disableASLR` for now
since it's blocking a libc++ patch.

Added: 


Modified: 
lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py

Removed: 




diff  --git a/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py 
b/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
index 63748a71f1122d..c29992ce9c7848 100644
--- a/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
+++ b/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
@@ -793,8 +793,6 @@ def request_launch(
 args_dict["env"] = env
 if stopOnEntry:
 args_dict["stopOnEntry"] = stopOnEntry
-if disableASLR:
-args_dict["disableASLR"] = disableASLR
 if disableSTDIO:
 args_dict["disableSTDIO"] = disableSTDIO
 if shellExpandArguments:
@@ -829,6 +827,7 @@ def request_launch(
 if customThreadFormat:
 args_dict["customThreadFormat"] = customThreadFormat
 
+args_dict["disableASLR"] = disableASLR
 args_dict["enableAutoVariableSummaries"] = enableAutoVariableSummaries
 args_dict["enableSyntheticChildDebugging"] = 
enableSyntheticChildDebugging
 args_dict["displayExtendedBacktrace"] = displayExtendedBacktrace



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

[Lldb-commits] [lldb] [lldb] Use Py_InitializeFromConfig with Python >= 3.8 (NFC) (PR #114112)

[Med Ismail Bennani via lldb-commits]

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

LGTM

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

[Lldb-commits] [lldb] [lldb] Use Py_InitializeFromConfig with Python >= 3.8 (NFC) (PR #114112)

[Jonas Devlieghere via lldb-commits]

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

>From c58438160c016841c6a72e53cd5c4985ebd1e521 Mon Sep 17 00:00:00 2001
From: Jonas Devlieghere 
Date: Tue, 29 Oct 2024 11:19:33 -0700
Subject: [PATCH 1/2] [lldb] Use Py_InitializeFromConfig with Python >= 3.8
 (NFC)

This fixes the deprecation warning for Py_SetPythonHome, which was
deprecated in Python 3.11. With this patch, when building against Python
3.8 or later, we now use Py_InitializeFromConfig instead.

Fixes #113475
---
 .../Python/ScriptInterpreterPython.cpp| 67 +++
 1 file changed, 40 insertions(+), 27 deletions(-)

diff --git 
a/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp 
b/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
index 7cc38da6a6a94b..d7734c5e199058 100644
--- a/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
+++ b/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
@@ -92,7 +92,38 @@ namespace {
 struct InitializePythonRAII {
 public:
   InitializePythonRAII() {
-InitializePythonHome();
+#if (PY_MAJOR_VERSION == 3 && PY_MINOR_VERSION >= 8) || (PY_MAJOR_VERSION > 3)
+PyConfig config;
+PyConfig_InitPythonConfig(&config);
+#endif
+
+#if LLDB_EMBED_PYTHON_HOME
+typedef wchar_t *str_type;
+static str_type g_python_home = []() -> str_type {
+  const char *lldb_python_home = LLDB_PYTHON_HOME;
+  const char *absolute_python_home = nullptr;
+  llvm::SmallString<64> path;
+  if (llvm::sys::path::is_absolute(lldb_python_home)) {
+absolute_python_home = lldb_python_home;
+  } else {
+FileSpec spec = HostInfo::GetShlibDir();
+if (!spec)
+  return nullptr;
+spec.GetPath(path);
+llvm::sys::path::append(path, lldb_python_home);
+absolute_python_home = path.c_str();
+  }
+  size_t size = 0;
+  return Py_DecodeLocale(absolute_python_home, &size);
+}();
+if (g_python_home != nullptr) {
+#if (PY_MAJOR_VERSION == 3 && PY_MINOR_VERSION >= 8)
+  PyConfig_SetBytesString(&config, &config.home, g_python_home);
+#else
+  Py_SetPythonHome(g_python_home);
+#endif
+}
+#endif
 
 // The table of built-in modules can only be extended before Python is
 // initialized.
@@ -117,15 +148,22 @@ struct InitializePythonRAII {
   PyImport_AppendInittab("_lldb", LLDBSwigPyInit);
 }
 
+#if (PY_MAJOR_VERSION == 3 && PY_MINOR_VERSION >= 8) || (PY_MAJOR_VERSION > 3)
+  config.install_signal_handlers = 0;
+  Py_InitializeFromConfig(&config);
+  PyConfig_Clear(&config);
+  InitializeThreadsPrivate();
+#else
 // Python < 3.2 and Python >= 3.2 reversed the ordering requirements for
 // calling `Py_Initialize` and `PyEval_InitThreads`.  < 3.2 requires that you
 // call `PyEval_InitThreads` first, and >= 3.2 requires that you call it last.
-#if (PY_MAJOR_VERSION == 3 && PY_MINOR_VERSION >= 2) || (PY_MAJOR_VERSION > 3)
+#if (PY_MAJOR_VERSION == 3 && PY_MINOR_VERSION >= 2)
 Py_InitializeEx(0);
 InitializeThreadsPrivate();
 #else
 InitializeThreadsPrivate();
 Py_InitializeEx(0);
+#endif
 #endif
   }
 
@@ -142,31 +180,6 @@ struct InitializePythonRAII {
   }
 
 private:
-  void InitializePythonHome() {
-#if LLDB_EMBED_PYTHON_HOME
-typedef wchar_t *str_type;
-static str_type g_python_home = []() -> str_type {
-  const char *lldb_python_home = LLDB_PYTHON_HOME;
-  const char *absolute_python_home = nullptr;
-  llvm::SmallString<64> path;
-  if (llvm::sys::path::is_absolute(lldb_python_home)) {
-absolute_python_home = lldb_python_home;
-  } else {
-FileSpec spec = HostInfo::GetShlibDir();
-if (!spec)
-  return nullptr;
-spec.GetPath(path);
-llvm::sys::path::append(path, lldb_python_home);
-absolute_python_home = path.c_str();
-  }
-  size_t size = 0;
-  return Py_DecodeLocale(absolute_python_home, &size);
-}();
-if (g_python_home != nullptr) {
-  Py_SetPythonHome(g_python_home);
-}
-#endif
-  }
 
   void InitializeThreadsPrivate() {
 // Since Python 3.7 `Py_Initialize` calls `PyEval_InitThreads` inside itself,

>From 35d76ac118a4b900e28b33c1d958d44c7b22c21c Mon Sep 17 00:00:00 2001
From: Jonas Devlieghere 
Date: Tue, 29 Oct 2024 11:36:42 -0700
Subject: [PATCH 2/2] Fix formatting

---
 .../ScriptInterpreter/Python/ScriptInterpreterPython.cpp | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git 
a/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp 
b/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
index d7734c5e199058..cde1e707cd1cec 100644
--- a/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
+++ b/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
@@ -149,10 +149,10 @@ struct InitializePythonRAII {
 }
 
 #if (PY_MAJOR_VERSION == 3 && PY_MINOR_VER

[Lldb-commits] [lldb] [lldb] Fix API test for file redirection to existing files (PR #114119)

[Jacob Lalonde via lldb-commits]

@@ -99,31 +99,45 @@ def test_stdout_stderr_redirection(self):
 @expectedFlakeyLinux(bugnumber="llvm.org/pr26437")
 @skipIfDarwinEmbedded  # debugserver can't create/write files on the device
 def test_stdout_stderr_redirection_to_existing_files(self):
-"""Exercise SBLaunchInfo::AddOpenFileAction() for STDOUT and STDERR 
without redirecting STDIN to output files already exist."""
+"""Exercise SBLaunchInfo::AddOpenFileAction() for STDOUT and STDERR 
redirect to output files already exist."""
 self.setup_test()
 self.build()
 self.create_target()
-self.write_file_with_placeholder(self.output_file)
-self.write_file_with_placeholder(self.error_file)
-self.redirect_stdout()
-self.redirect_stderr()
-self.run_process(True)
-output = self.read_output_file_and_delete()
-error = self.read_error_file_and_delete()
-self.check_process_output(output, error)
 
-def write_file_with_placeholder(self, target_file):
+# Create the output and error files with placeholder

Jlalond wrote:

Can you expand in comments or the description what this test is for and why it 
neds to change @kusmour?

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

[Lldb-commits] [lldb] [lldb] Fix API test for file redirection to existing files (PR #114119)

[Jacob Lalonde via lldb-commits]

@@ -99,31 +99,45 @@ def test_stdout_stderr_redirection(self):
 @expectedFlakeyLinux(bugnumber="llvm.org/pr26437")
 @skipIfDarwinEmbedded  # debugserver can't create/write files on the device
 def test_stdout_stderr_redirection_to_existing_files(self):
-"""Exercise SBLaunchInfo::AddOpenFileAction() for STDOUT and STDERR 
without redirecting STDIN to output files already exist."""
+"""Exercise SBLaunchInfo::AddOpenFileAction() for STDOUT and STDERR 
redirect to output files already exist."""
 self.setup_test()
 self.build()
 self.create_target()
-self.write_file_with_placeholder(self.output_file)
-self.write_file_with_placeholder(self.error_file)
-self.redirect_stdout()
-self.redirect_stderr()
-self.run_process(True)
-output = self.read_output_file_and_delete()
-error = self.read_error_file_and_delete()
-self.check_process_output(output, error)
 
-def write_file_with_placeholder(self, target_file):
+# Create the output and error files with placeholder
 placeholder = "This content should be overwritten."
 if lldb.remote_platform:
+f = open(self.local_output_file, "w")

Jlalond wrote:

If we are going to make local files the [Save core tests put them in the build 
directory](https://github.com/llvm/llvm-project/blob/8a0cb9ac869334fd6c6bd6aad8408623a7ccd7f6/lldb/test/API/functionalities/process_save_core_minidump/TestProcessSaveCoreMinidump.py#L414)
 as an example.

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

[Lldb-commits] [lldb] [lldb] Fix API test for file redirection to existing files (PR #114119)

[Jacob Lalonde via lldb-commits]

@@ -99,31 +99,45 @@ def test_stdout_stderr_redirection(self):
 @expectedFlakeyLinux(bugnumber="llvm.org/pr26437")
 @skipIfDarwinEmbedded  # debugserver can't create/write files on the device
 def test_stdout_stderr_redirection_to_existing_files(self):
-"""Exercise SBLaunchInfo::AddOpenFileAction() for STDOUT and STDERR 
without redirecting STDIN to output files already exist."""
+"""Exercise SBLaunchInfo::AddOpenFileAction() for STDOUT and STDERR 
redirect to output files already exist."""
 self.setup_test()
 self.build()
 self.create_target()
-self.write_file_with_placeholder(self.output_file)
-self.write_file_with_placeholder(self.error_file)
-self.redirect_stdout()
-self.redirect_stderr()
-self.run_process(True)
-output = self.read_output_file_and_delete()
-error = self.read_error_file_and_delete()
-self.check_process_output(output, error)
 
-def write_file_with_placeholder(self, target_file):
+# Create the output and error files with placeholder
 placeholder = "This content should be overwritten."
 if lldb.remote_platform:
+f = open(self.local_output_file, "w")
+f.write(placeholder)
+f.close()
+
+f = open(self.local_error_file, "w")
+f.write(placeholder)
+f.close()
+self.runCmd(
+'platform put-file "{local}" "{remote}"'.format(
+local=self.local_output_file, remote=self.output_file
+)
+)
 self.runCmd(
-'platform file write "{target}" -d "{data}"'.format(
-target=target_file, data=placeholder
+'platform put-file "{local}" "{remote}"'.format(
+local=self.local_error_file, remote=self.error_file
 )
 )
 else:
-f = open(target_file, "w")
+f = open(self.output_file, "w")
+f.write(placeholder)
+f.close()
+f = open(self.error_file, "w")
 f.write(placeholder)
 f.close()
+
+self.redirect_stdout()

Jlalond wrote:

Should we have a finally block to clean up files?

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

[Lldb-commits] [lldb] [lldb] Fix API test for file redirection to existing files (PR #114119)

[via lldb-commits]

@@ -99,31 +99,45 @@ def test_stdout_stderr_redirection(self):
 @expectedFlakeyLinux(bugnumber="llvm.org/pr26437")
 @skipIfDarwinEmbedded  # debugserver can't create/write files on the device
 def test_stdout_stderr_redirection_to_existing_files(self):
-"""Exercise SBLaunchInfo::AddOpenFileAction() for STDOUT and STDERR 
without redirecting STDIN to output files already exist."""
+"""Exercise SBLaunchInfo::AddOpenFileAction() for STDOUT and STDERR 
redirect to output files already exist."""
 self.setup_test()
 self.build()
 self.create_target()
-self.write_file_with_placeholder(self.output_file)
-self.write_file_with_placeholder(self.error_file)
-self.redirect_stdout()
-self.redirect_stderr()
-self.run_process(True)
-output = self.read_output_file_and_delete()
-error = self.read_error_file_and_delete()
-self.check_process_output(output, error)
 
-def write_file_with_placeholder(self, target_file):
+# Create the output and error files with placeholder
 placeholder = "This content should be overwritten."
 if lldb.remote_platform:
+f = open(self.local_output_file, "w")

kusmour wrote:

So I double checked the `platform file write` it will require `platform file 
open` first and obtain the file descriptor so that we can write. 

The put method however won't require extra steps and is used in the same test 
already.

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

[Lldb-commits] [lldb] Fix return value of 'PluginManager::RegisterPlugin()'. (PR #114120)

[Miro Bucko via lldb-commits]

https://github.com/mbucko created 
https://github.com/llvm/llvm-project/pull/114120

None

>From 3c831942c752004a6e46c1f5ddd5e783ee2176e0 Mon Sep 17 00:00:00 2001
From: Miro Bucko 
Date: Tue, 29 Oct 2024 13:02:21 -0700
Subject: [PATCH] Fix return value of 'PluginManager::RegisterPlugin()'.

---
 lldb/source/Core/PluginManager.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lldb/source/Core/PluginManager.cpp 
b/lldb/source/Core/PluginManager.cpp
index a5219025495a91..50bbfba33ee512 100644
--- a/lldb/source/Core/PluginManager.cpp
+++ b/lldb/source/Core/PluginManager.cpp
@@ -209,7 +209,7 @@ template  class PluginInstances {
 Instance instance =
 Instance(name, description, callback, std::forward(args)...);
 m_instances.push_back(instance);
-return false;
+return true;
   }
 
   bool UnregisterPlugin(typename Instance::CallbackType callback) {

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

[Lldb-commits] [lldb] Fix return value of 'PluginManager::RegisterPlugin()'. (PR #114120)

[via lldb-commits]

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Miro Bucko (mbucko)


Changes



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


1 Files Affected:

- (modified) lldb/source/Core/PluginManager.cpp (+1-1) 


``diff
diff --git a/lldb/source/Core/PluginManager.cpp 
b/lldb/source/Core/PluginManager.cpp
index a5219025495a91..50bbfba33ee512 100644
--- a/lldb/source/Core/PluginManager.cpp
+++ b/lldb/source/Core/PluginManager.cpp
@@ -209,7 +209,7 @@ template  class PluginInstances {
 Instance instance =
 Instance(name, description, callback, std::forward(args)...);
 m_instances.push_back(instance);
-return false;
+return true;
   }
 
   bool UnregisterPlugin(typename Instance::CallbackType callback) {

``




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

[Lldb-commits] [lldb] [lldb][test] Skip `LibCxxInternalsRecognizerTestCase` on clang <= 17 (PR #114122)

[Adrian Vogelsgesang via lldb-commits]

https://github.com/vogelsgesang created 
https://github.com/llvm/llvm-project/pull/114122

Because of a build failure with libc++17.
See 
https://green.lab.llvm.org/job/llvm.org/view/LLDB/job/lldb-cmake-matrix/912/execution/node/107/log/

>From 00d136ed33cdc4362f7f23804ee184ddb1fb2539 Mon Sep 17 00:00:00 2001
From: Adrian Vogelsgesang 
Date: Tue, 29 Oct 2024 20:23:13 +
Subject: [PATCH] [lldb][test] Skip `LibCxxInternalsRecognizerTestCase` on
 clang <= 17

Because of a build failure with libc++17.
See 
https://green.lab.llvm.org/job/llvm.org/view/LLDB/job/lldb-cmake-matrix/912/execution/node/107/log/
---
 .../libcxx-internals-recognizer/TestLibcxxInternalsRecognizer.py | 1 +
 1 file changed, 1 insertion(+)

diff --git 
a/lldb/test/API/lang/cpp/libcxx-internals-recognizer/TestLibcxxInternalsRecognizer.py
 
b/lldb/test/API/lang/cpp/libcxx-internals-recognizer/TestLibcxxInternalsRecognizer.py
index ad48208f21e502..0270e78808c646 100644
--- 
a/lldb/test/API/lang/cpp/libcxx-internals-recognizer/TestLibcxxInternalsRecognizer.py
+++ 
b/lldb/test/API/lang/cpp/libcxx-internals-recognizer/TestLibcxxInternalsRecognizer.py
@@ -8,6 +8,7 @@ class LibCxxInternalsRecognizerTestCase(TestBase):
 NO_DEBUG_INFO_TESTCASE = True
 
 @add_test_categories(["libc++"])
+@skipIf(compiler="clang", compiler_version=["<", "18.0"])
 def test_frame_recognizer(self):
 """Test that implementation details of libc++ are hidden"""
 self.build()

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

[Lldb-commits] [libcxx] [lldb] [lldb][libc++] Hide all libc++ implementation details from stacktraces (PR #108870)

[Adrian Vogelsgesang via lldb-commits]

vogelsgesang wrote:

see #114122

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

[Lldb-commits] [lldb] 8193832 - [lldb] Search main function with lldb::eFunctionNameTypeFull when getting default file and line. (#113980)

[via lldb-commits]

Author: Zequan Wu
Date: 2024-10-29T16:23:33-04:00
New Revision: 8193832fb988e3df1e8e726634783805dca8d9b6

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

LOG: [lldb] Search main function with lldb::eFunctionNameTypeFull when getting 
default file and line. (#113980)

This is to work around the fact that
`SymbolFileNativePDB::FindFunctions` only support
`lldb::eFunctionNameTypeFull` and `lldb::eFunctionNameTypeMethod` now.
Since `main`'s full name is the same as base name (`main`), it's okay to
search with `lldb::eFunctionNameTypeFull` when trying to get the default
file and line. With this, `lldb/test/Shell/Driver/TestSingleQuote.test`
passes on Windows with NativePDB plugin.

Added: 


Modified: 
lldb/source/Core/SourceManager.cpp

Removed: 




diff  --git a/lldb/source/Core/SourceManager.cpp 
b/lldb/source/Core/SourceManager.cpp
index fd5b49946c6a92..27a9edeef4249e 100644
--- a/lldb/source/Core/SourceManager.cpp
+++ b/lldb/source/Core/SourceManager.cpp
@@ -430,7 +430,7 @@ SourceManager::GetDefaultFileAndLine() {
 false; // Force it to be a debug symbol.
 function_options.include_inlines = true;
 executable_ptr->FindFunctions(main_name, CompilerDeclContext(),
-  lldb::eFunctionNameTypeBase,
+  lldb::eFunctionNameTypeFull,
   function_options, sc_list);
 for (const SymbolContext &sc : sc_list) {
   if (sc.function) {



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

[Lldb-commits] [lldb] [lldb] Fix API test for file redirection to existing files (PR #114119)

[via lldb-commits]

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

[Lldb-commits] [lldb] [lldb] Add a compiler/interpreter of LLDB data formatter bytecode to lldb/examples (PR #113398)

[Adrian Prantl via lldb-commits]

https://github.com/adrian-prantl updated 
https://github.com/llvm/llvm-project/pull/113398

>From 0b88de8fe7f5e4ea7f4089be403b271cd7b086d0 Mon Sep 17 00:00:00 2001
From: Adrian Prantl 
Date: Tue, 22 Oct 2024 16:29:50 -0700
Subject: [PATCH 1/2] Add a compiler/interpreter of LLDB data formatter
 bytecode to examples

---
 lldb/docs/index.rst   |   1 +
 lldb/docs/resources/formatterbytecode.rst | 221 
 lldb/examples/formatter-bytecode/Makefile |   8 +
 lldb/examples/formatter-bytecode/compiler.py  | 486 ++
 .../formatter-bytecode/test/MyOptional.cpp|  23 +
 .../formatter-bytecode/test/formatter.py  | 131 +
 6 files changed, 870 insertions(+)
 create mode 100644 lldb/docs/resources/formatterbytecode.rst
 create mode 100644 lldb/examples/formatter-bytecode/Makefile
 create mode 100644 lldb/examples/formatter-bytecode/compiler.py
 create mode 100644 lldb/examples/formatter-bytecode/test/MyOptional.cpp
 create mode 100644 lldb/examples/formatter-bytecode/test/formatter.py

diff --git a/lldb/docs/index.rst b/lldb/docs/index.rst
index e2c15d872b4be2..c3c2fb36eb541a 100644
--- a/lldb/docs/index.rst
+++ b/lldb/docs/index.rst
@@ -164,6 +164,7 @@ interesting areas to contribute to lldb.
resources/fuzzing
resources/sbapi
resources/dataformatters
+   resources/formatterbytecode
resources/extensions
resources/lldbgdbremote
resources/lldbplatformpackets
diff --git a/lldb/docs/resources/formatterbytecode.rst 
b/lldb/docs/resources/formatterbytecode.rst
new file mode 100644
index 00..e6a52a2bdddcdb
--- /dev/null
+++ b/lldb/docs/resources/formatterbytecode.rst
@@ -0,0 +1,221 @@
+Formatter Bytecode
+==
+
+Background
+--
+
+LLDB provides very rich customization options to display data types (see 
:doc:`/use/variable/`). To use custom data formatters, developers need to edit 
the global `~/.lldbinit` file to make sure they are found and loaded. In 
addition to this rather manual workflow, developers or library authors can ship 
ship data formatters with their code in a format that allows LLDB automatically 
find them and run them securely.
+
+An end-to-end example of such a workflow is the Swift `DebugDescription` macro 
(see https://www.swift.org/blog/announcing-swift-6/#debugging ) that translates 
Swift string interpolation into LLDB summary strings, and puts them into a 
`.lldbsummaries` section, where LLDB can find them.
+
+This document describes a minimal bytecode tailored to running LLDB 
formatters. It defines a human-readable assembler representation for the 
language, an efficient binary encoding, a virtual machine for evaluating it, 
and format for embedding formatters into binary containers.
+
+Goals
+~
+
+Provide an efficient and secure encoding for data formatters that can be used 
as a compilation target from user-friendly representations (such as DIL, Swift 
DebugDescription, or NatVis).
+
+Non-goals
+~
+
+While humans could write the assembler syntax, making it user-friendly is not 
a goal.
+
+Design of the virtual machine
+-
+
+The LLDB formatter virtual machine uses a stack-based bytecode, comparable 
with DWARF expressions, but with higher-level data types and functions.
+
+The virtual machine has two stacks, a data and a control stack. The control 
stack is kept separate to make it easier to reason about the security aspects 
of the virtual machine.
+
+Data types
+~~
+
+All objects on the data stack must have one of the following data types. These 
data types are "host" data types, in LLDB parlance.
+
+* *String* (UTF-8)
+* *Int* (64 bit)
+* *UInt* (64 bit)
+* *Object* (Basically an `SBValue`)
+* *Type* (Basically an `SBType`)
+* *Selector* (One of the predefine functions)
+
+*Object* and *Type* are opaque, they can only be used as a parameters of 
`call`.
+
+Instruction set
+---
+
+Stack operations
+
+
+These instructions manipulate the data stack directly.
+
+  ==  ===
+ OpcodeMnemonicStack effect  
+  --  ---
+ 0x00  `dup`   `(x -> x x)`  
+ 0x01  `drop`  `(x y -> x)`   
+ 0x02  `pick`  `(x ... UInt -> x ... x)`  
+ 0x03  `over`  `(x y -> x y x)`   
+ 0x04  `swap`  `(x y -> y x)` 
+ 0x05  `rot`   `(x y z -> z x y)` 
+===  ==  ===
+
+Control flow
+
+
+These manipulate the control stack and program counter.
+
+  ==  

+ OpcodeMnemonicDescription  
+  --  

+ 0x10   `{`push a code block address onto the control stack
+  --`}`(technically not an opcode) syntax for end

[Lldb-commits] [lldb] [lldb] Add a compiler/interpreter of LLDB data formatter bytecode to lldb/examples (PR #113398)

[Adrian Prantl via lldb-commits]

https://github.com/adrian-prantl updated 
https://github.com/llvm/llvm-project/pull/113398

>From 0b88de8fe7f5e4ea7f4089be403b271cd7b086d0 Mon Sep 17 00:00:00 2001
From: Adrian Prantl 
Date: Tue, 22 Oct 2024 16:29:50 -0700
Subject: [PATCH 1/2] Add a compiler/interpreter of LLDB data formatter
 bytecode to examples

---
 lldb/docs/index.rst   |   1 +
 lldb/docs/resources/formatterbytecode.rst | 221 
 lldb/examples/formatter-bytecode/Makefile |   8 +
 lldb/examples/formatter-bytecode/compiler.py  | 486 ++
 .../formatter-bytecode/test/MyOptional.cpp|  23 +
 .../formatter-bytecode/test/formatter.py  | 131 +
 6 files changed, 870 insertions(+)
 create mode 100644 lldb/docs/resources/formatterbytecode.rst
 create mode 100644 lldb/examples/formatter-bytecode/Makefile
 create mode 100644 lldb/examples/formatter-bytecode/compiler.py
 create mode 100644 lldb/examples/formatter-bytecode/test/MyOptional.cpp
 create mode 100644 lldb/examples/formatter-bytecode/test/formatter.py

diff --git a/lldb/docs/index.rst b/lldb/docs/index.rst
index e2c15d872b4be2..c3c2fb36eb541a 100644
--- a/lldb/docs/index.rst
+++ b/lldb/docs/index.rst
@@ -164,6 +164,7 @@ interesting areas to contribute to lldb.
resources/fuzzing
resources/sbapi
resources/dataformatters
+   resources/formatterbytecode
resources/extensions
resources/lldbgdbremote
resources/lldbplatformpackets
diff --git a/lldb/docs/resources/formatterbytecode.rst 
b/lldb/docs/resources/formatterbytecode.rst
new file mode 100644
index 00..e6a52a2bdddcdb
--- /dev/null
+++ b/lldb/docs/resources/formatterbytecode.rst
@@ -0,0 +1,221 @@
+Formatter Bytecode
+==
+
+Background
+--
+
+LLDB provides very rich customization options to display data types (see 
:doc:`/use/variable/`). To use custom data formatters, developers need to edit 
the global `~/.lldbinit` file to make sure they are found and loaded. In 
addition to this rather manual workflow, developers or library authors can ship 
ship data formatters with their code in a format that allows LLDB automatically 
find them and run them securely.
+
+An end-to-end example of such a workflow is the Swift `DebugDescription` macro 
(see https://www.swift.org/blog/announcing-swift-6/#debugging ) that translates 
Swift string interpolation into LLDB summary strings, and puts them into a 
`.lldbsummaries` section, where LLDB can find them.
+
+This document describes a minimal bytecode tailored to running LLDB 
formatters. It defines a human-readable assembler representation for the 
language, an efficient binary encoding, a virtual machine for evaluating it, 
and format for embedding formatters into binary containers.
+
+Goals
+~
+
+Provide an efficient and secure encoding for data formatters that can be used 
as a compilation target from user-friendly representations (such as DIL, Swift 
DebugDescription, or NatVis).
+
+Non-goals
+~
+
+While humans could write the assembler syntax, making it user-friendly is not 
a goal.
+
+Design of the virtual machine
+-
+
+The LLDB formatter virtual machine uses a stack-based bytecode, comparable 
with DWARF expressions, but with higher-level data types and functions.
+
+The virtual machine has two stacks, a data and a control stack. The control 
stack is kept separate to make it easier to reason about the security aspects 
of the virtual machine.
+
+Data types
+~~
+
+All objects on the data stack must have one of the following data types. These 
data types are "host" data types, in LLDB parlance.
+
+* *String* (UTF-8)
+* *Int* (64 bit)
+* *UInt* (64 bit)
+* *Object* (Basically an `SBValue`)
+* *Type* (Basically an `SBType`)
+* *Selector* (One of the predefine functions)
+
+*Object* and *Type* are opaque, they can only be used as a parameters of 
`call`.
+
+Instruction set
+---
+
+Stack operations
+
+
+These instructions manipulate the data stack directly.
+
+  ==  ===
+ OpcodeMnemonicStack effect  
+  --  ---
+ 0x00  `dup`   `(x -> x x)`  
+ 0x01  `drop`  `(x y -> x)`   
+ 0x02  `pick`  `(x ... UInt -> x ... x)`  
+ 0x03  `over`  `(x y -> x y x)`   
+ 0x04  `swap`  `(x y -> y x)` 
+ 0x05  `rot`   `(x y z -> z x y)` 
+===  ==  ===
+
+Control flow
+
+
+These manipulate the control stack and program counter.
+
+  ==  

+ OpcodeMnemonicDescription  
+  --  

+ 0x10   `{`push a code block address onto the control stack
+  --`}`(technically not an opcode) syntax for end

[Lldb-commits] [lldb] [llvm] [DWARF] Fix arity of DW_OP_bra (PR #114136)

[Jonas Devlieghere via lldb-commits]

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

[Lldb-commits] [lldb] [lldb] Fix API test for file redirection to existing files (PR #114119)

[Alex Langford via lldb-commits]

@@ -99,31 +99,45 @@ def test_stdout_stderr_redirection(self):
 @expectedFlakeyLinux(bugnumber="llvm.org/pr26437")
 @skipIfDarwinEmbedded  # debugserver can't create/write files on the device
 def test_stdout_stderr_redirection_to_existing_files(self):
-"""Exercise SBLaunchInfo::AddOpenFileAction() for STDOUT and STDERR 
without redirecting STDIN to output files already exist."""
+"""Exercise SBLaunchInfo::AddOpenFileAction() for STDOUT and STDERR 
redirect to output files already exist."""
 self.setup_test()
 self.build()
 self.create_target()
-self.write_file_with_placeholder(self.output_file)
-self.write_file_with_placeholder(self.error_file)
-self.redirect_stdout()
-self.redirect_stderr()
-self.run_process(True)
-output = self.read_output_file_and_delete()
-error = self.read_error_file_and_delete()
-self.check_process_output(output, error)
 
-def write_file_with_placeholder(self, target_file):
+# Create the output and error files with placeholder
 placeholder = "This content should be overwritten."
 if lldb.remote_platform:
+f = open(self.local_output_file, "w")

bulbazord wrote:

Why does this create files on your local filesystem now instead of doing the 
previous `platform file write` commands? Was there something wrong with the 
previous approach?

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

[Lldb-commits] [lldb] [lldb] Fix API test for file redirection to existing files (PR #114119)

[via lldb-commits]

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Wanyi (kusmour)


Changes

API test failed for remote debugging in [#112657](https://github.com/llvm/llvm-project/pull/112657)

Fixing it properly

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


1 Files Affected:

- (modified) lldb/test/API/python_api/process/io/TestProcessIO.py (+27-13) 


``diff
diff --git a/lldb/test/API/python_api/process/io/TestProcessIO.py 
b/lldb/test/API/python_api/process/io/TestProcessIO.py
index 3b5c7c48c51f4d..24cd845904cc2c 100644
--- a/lldb/test/API/python_api/process/io/TestProcessIO.py
+++ b/lldb/test/API/python_api/process/io/TestProcessIO.py
@@ -99,31 +99,45 @@ def test_stdout_stderr_redirection(self):
 @expectedFlakeyLinux(bugnumber="llvm.org/pr26437")
 @skipIfDarwinEmbedded  # debugserver can't create/write files on the device
 def test_stdout_stderr_redirection_to_existing_files(self):
-"""Exercise SBLaunchInfo::AddOpenFileAction() for STDOUT and STDERR 
without redirecting STDIN to output files already exist."""
+"""Exercise SBLaunchInfo::AddOpenFileAction() for STDOUT and STDERR 
redirect to output files already exist."""
 self.setup_test()
 self.build()
 self.create_target()
-self.write_file_with_placeholder(self.output_file)
-self.write_file_with_placeholder(self.error_file)
-self.redirect_stdout()
-self.redirect_stderr()
-self.run_process(True)
-output = self.read_output_file_and_delete()
-error = self.read_error_file_and_delete()
-self.check_process_output(output, error)
 
-def write_file_with_placeholder(self, target_file):
+# Create the output and error files with placeholder
 placeholder = "This content should be overwritten."
 if lldb.remote_platform:
+f = open(self.local_output_file, "w")
+f.write(placeholder)
+f.close()
+
+f = open(self.local_error_file, "w")
+f.write(placeholder)
+f.close()
+self.runCmd(
+'platform put-file "{local}" "{remote}"'.format(
+local=self.local_output_file, remote=self.output_file
+)
+)
 self.runCmd(
-'platform file write "{target}" -d "{data}"'.format(
-target=target_file, data=placeholder
+'platform put-file "{local}" "{remote}"'.format(
+local=self.local_error_file, remote=self.error_file
 )
 )
 else:
-f = open(target_file, "w")
+f = open(self.output_file, "w")
+f.write(placeholder)
+f.close()
+f = open(self.error_file, "w")
 f.write(placeholder)
 f.close()
+
+self.redirect_stdout()
+self.redirect_stderr()
+self.run_process(True)
+output = self.read_output_file_and_delete()
+error = self.read_error_file_and_delete()
+self.check_process_output(output, error)
 
 # target_file - path on local file system or remote file system if running 
remote
 # local_file - path on local system

``




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

[Lldb-commits] [lldb] Fix return value of 'PluginManager::RegisterPlugin()'. (PR #114120)

[Jonas Devlieghere via lldb-commits]

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


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

[Lldb-commits] [lldb] [lldb][test] Skip `LibCxxInternalsRecognizerTestCase` on clang <= 17 (PR #114122)

[Felipe de Azevedo Piovezan via lldb-commits]

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

Thanks!

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

[Lldb-commits] [lldb] [lldb] Fix API test for file redirection to existing files (PR #114119)

[via lldb-commits]

@@ -99,31 +99,45 @@ def test_stdout_stderr_redirection(self):
 @expectedFlakeyLinux(bugnumber="llvm.org/pr26437")
 @skipIfDarwinEmbedded  # debugserver can't create/write files on the device
 def test_stdout_stderr_redirection_to_existing_files(self):
-"""Exercise SBLaunchInfo::AddOpenFileAction() for STDOUT and STDERR 
without redirecting STDIN to output files already exist."""
+"""Exercise SBLaunchInfo::AddOpenFileAction() for STDOUT and STDERR 
redirect to output files already exist."""
 self.setup_test()
 self.build()
 self.create_target()
-self.write_file_with_placeholder(self.output_file)
-self.write_file_with_placeholder(self.error_file)
-self.redirect_stdout()
-self.redirect_stderr()
-self.run_process(True)
-output = self.read_output_file_and_delete()
-error = self.read_error_file_and_delete()
-self.check_process_output(output, error)
 
-def write_file_with_placeholder(self, target_file):
+# Create the output and error files with placeholder
 placeholder = "This content should be overwritten."
 if lldb.remote_platform:
+f = open(self.local_output_file, "w")
+f.write(placeholder)
+f.close()
+
+f = open(self.local_error_file, "w")
+f.write(placeholder)
+f.close()
+self.runCmd(
+'platform put-file "{local}" "{remote}"'.format(
+local=self.local_output_file, remote=self.output_file
+)
+)
 self.runCmd(
-'platform file write "{target}" -d "{data}"'.format(
-target=target_file, data=placeholder
+'platform put-file "{local}" "{remote}"'.format(
+local=self.local_error_file, remote=self.error_file
 )
 )
 else:
-f = open(target_file, "w")
+f = open(self.output_file, "w")
+f.write(placeholder)
+f.close()
+f = open(self.error_file, "w")
 f.write(placeholder)
 f.close()
+
+self.redirect_stdout()

kusmour wrote:

Nope, for remote platform there's no `platform file remove` (you can see a 
comment below from `redirect_stdin`. For local file, the function 
`read_output_file_and_delete` will do the clean up already :)

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

[Lldb-commits] [lldb] [lldb] Extend FindTypes to optionally search by mangled type name (PR #113007)

[Augusto Noronha via lldb-commits]

https://github.com/augusto2112 updated 
https://github.com/llvm/llvm-project/pull/113007

>From eab35bd50d89a16494d8f08421a12aef77356c43 Mon Sep 17 00:00:00 2001
From: Augusto Noronha 
Date: Tue, 22 Oct 2024 14:34:44 -0700
Subject: [PATCH 1/2] [lldb] Extend FindTypes to optionally search by mangled
 type name

Swift types have mangled type names. This adds functionality to look
up those types through the FindTypes API by searching for the mangled
type name instead of the regular name.
---
 lldb/include/lldb/Symbol/Type.h  |  9 +
 .../Plugins/SymbolFile/CTF/SymbolFileCTF.cpp | 16 +++-
 .../Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp |  9 +
 .../SymbolFile/NativePDB/SymbolFileNativePDB.cpp |  5 -
 .../Plugins/SymbolFile/PDB/SymbolFilePDB.cpp |  5 -
 5 files changed, 37 insertions(+), 7 deletions(-)

diff --git a/lldb/include/lldb/Symbol/Type.h b/lldb/include/lldb/Symbol/Type.h
index 03d9f927997476..a8e5b81585e169 100644
--- a/lldb/include/lldb/Symbol/Type.h
+++ b/lldb/include/lldb/Symbol/Type.h
@@ -84,6 +84,9 @@ FLAGS_ENUM(TypeQueryOptions){
 /// matching type is found. When false, the type query should find all
 /// matching types.
 e_find_one = (1u << 4),
+// If set, treat TypeQuery::m_name as a mangled name that should be
+// searched.
+e_search_by_mangled_name = (1u << 5),
 };
 LLDB_MARK_AS_BITMASK_ENUM(TypeQueryOptions)
 
@@ -300,6 +303,12 @@ class TypeQuery {
   m_options &= ~e_find_one;
   }
 
+  /// Returns true if the type query is supposed to treat the name to be
+  /// searched as a mangled name.
+  bool GetSearchByMangledName() const {
+return (m_options & e_search_by_mangled_name) != 0;
+  }
+
   /// Access the internal compiler context array.
   ///
   /// Clients can use this to populate the context manually.
diff --git a/lldb/source/Plugins/SymbolFile/CTF/SymbolFileCTF.cpp 
b/lldb/source/Plugins/SymbolFile/CTF/SymbolFileCTF.cpp
index bb738c3dcc54a0..4d08c53f752098 100644
--- a/lldb/source/Plugins/SymbolFile/CTF/SymbolFileCTF.cpp
+++ b/lldb/source/Plugins/SymbolFile/CTF/SymbolFileCTF.cpp
@@ -1032,11 +1032,17 @@ void SymbolFileCTF::FindTypes(const 
lldb_private::TypeQuery &match,
 
   ConstString name = match.GetTypeBasename();
   for (TypeSP type_sp : GetTypeList().Types()) {
-if (type_sp && type_sp->GetName() == name) {
-  results.InsertUnique(type_sp);
-  if (results.Done(match))
-return;
-}
+if (!type_sp)
+  continue;
+auto type_name =
+match.GetSearchByMangledName()
+? type_sp->GetForwardCompilerType().GetMangledTypeName()
+: type_sp->GetName();
+if (type_name != name)
+  continue;
+results.InsertUnique(type_sp);
+if (results.Done(match))
+  return;
   }
 }
 
diff --git a/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
index e5b8eee8d08c24..704c8d64dbfb2f 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
@@ -2758,6 +2758,15 @@ void SymbolFileDWARF::FindTypes(const TypeQuery &query, 
TypeResults &results) {
 return true; // Keep iterating over index types, language mismatch.
 }
 
+// Since mangled names are unique, we only need to check if the names are
+// the same.
+if (query.GetSearchByMangledName()) {
+  if (die.GetMangledName() == query.GetTypeBasename().GetStringRef())
+if (Type *matching_type = ResolveType(die, true, true))
+  results.InsertUnique(matching_type->shared_from_this());
+  return !results.Done(query); // Keep iterating if we aren't done.
+}
+
 // Check the context matches
 std::vector die_context;
 if (query.GetModuleSearch())
diff --git a/lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp 
b/lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp
index 7fded6a31a3af5..b55518a136c997 100644
--- a/lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp
+++ b/lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp
@@ -1735,7 +1735,10 @@ void SymbolFileNativePDB::FindTypes(const 
lldb_private::TypeQuery &query,
   continue;
 
 // We resolved a type. Get the fully qualified name to ensure it matches.
-ConstString name = type_sp->GetQualifiedName();
+ConstString name =
+query.GetSearchByMangledName()
+? type_sp->GetForwardCompilerType().GetMangledTypeName()
+: type_sp->GetQualifiedName();
 TypeQuery type_match(name.GetStringRef(), TypeQueryOptions::e_exact_match);
 if (query.ContextMatches(type_match.GetContextRef())) {
   results.InsertUnique(type_sp);
diff --git a/lldb/source/Plugins/SymbolFile/PDB/SymbolFilePDB.cpp 
b/lldb/source/Plugins/SymbolFile/PDB/SymbolFilePDB.cpp
index 4fc48b4d133382..0ea18d8f74baa3 100644
--- a/lldb/source/Plugins/SymbolFile/PDB/SymbolFilePDB.cpp
+++ b/lldb/s

[Lldb-commits] [lldb] [llvm] [DWARF] Fix arity of DW_OP_bra (PR #114136)

[Alex Langford via lldb-commits]

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


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

[Lldb-commits] [lldb] Fix a couple of tests that were incorrectly using configuration.dwarf_version (PR #114161)

[Jonas Devlieghere via lldb-commits]

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


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

[Lldb-commits] [lldb] Fix call site breakpoint patch (PR #114158)

[via lldb-commits]

https://github.com/jimingham created 
https://github.com/llvm/llvm-project/pull/114158

This fixes the two test suite failures that I missed in the PR:

https://github.com/llvm/llvm-project/pull/112939

One was a poorly written test case - it assumed that on connect to a gdb-remote 
with a running process, lldb MUST have fetched all the frame 0 registers.  In 
fact, there's no need for it to do so (as the CallSite patch showed...) and if 
we don't need to we shouldn't.  So I fixed the test to only expect a `g` packet 
AFTER calling read_registers.

The other was a place where some code had used 0 when it meant 
LLDB_INVALID_LINE_NUMBER, which I had fixed but missed one place where it was 
still compared to 0.

>From 0695a7b57597fd08a802dbe4af06291ceb75d9f1 Mon Sep 17 00:00:00 2001
From: Jim Ingham 
Date: Mon, 28 Oct 2024 17:58:43 -0700
Subject: [PATCH 1/3] =?UTF-8?q?Revert=20"Revert=20"Add=20the=20ability=20t?=
 =?UTF-8?q?o=20break=20on=20call-site=20locations,=20improve=20inli?=
 =?UTF-8?q?=E2=80=A6=20(#113947)"?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

This reverts commit b54bc104ea87e301816b450ee117d2d864c7d82d.
---
 .../lldb/Breakpoint/BreakpointLocation.h  |  36 
 lldb/include/lldb/Breakpoint/BreakpointSite.h |   5 +
 lldb/include/lldb/Core/Declaration.h  |   6 +-
 lldb/include/lldb/Target/StopInfo.h   |  12 ++
 .../lldb/Target/ThreadPlanStepInRange.h   |   4 +-
 lldb/source/Breakpoint/BreakpointLocation.cpp |  63 ++-
 lldb/source/Breakpoint/BreakpointResolver.cpp |  15 ++
 lldb/source/Breakpoint/BreakpointSite.cpp |  17 ++
 lldb/source/Core/Declaration.cpp  |   5 +-
 lldb/source/Symbol/Block.cpp  |   2 +-
 lldb/source/Symbol/CompileUnit.cpp| 111 +++-
 lldb/source/Target/StackFrameList.cpp | 171 ++
 lldb/source/Target/StopInfo.cpp   |  55 ++
 lldb/source/Target/Thread.cpp |   8 +
 lldb/source/Target/ThreadPlanStepInRange.cpp  |  24 ++-
 .../source/Target/ThreadPlanStepOverRange.cpp |   2 +-
 .../inline-stepping/TestInlineStepping.py |  63 +++
 .../inline-stepping/calling.cpp   |  25 +++
 18 files changed, 493 insertions(+), 131 deletions(-)

diff --git a/lldb/include/lldb/Breakpoint/BreakpointLocation.h 
b/lldb/include/lldb/Breakpoint/BreakpointLocation.h
index cca00335bc3c67..3592291bb2d06e 100644
--- a/lldb/include/lldb/Breakpoint/BreakpointLocation.h
+++ b/lldb/include/lldb/Breakpoint/BreakpointLocation.h
@@ -11,10 +11,12 @@
 
 #include 
 #include 
+#include 
 
 #include "lldb/Breakpoint/BreakpointOptions.h"
 #include "lldb/Breakpoint/StoppointHitCounter.h"
 #include "lldb/Core/Address.h"
+#include "lldb/Symbol/LineEntry.h"
 #include "lldb/Utility/UserID.h"
 #include "lldb/lldb-private.h"
 
@@ -282,6 +284,25 @@ class BreakpointLocation
   /// Returns the breakpoint location ID.
   lldb::break_id_t GetID() const { return m_loc_id; }
 
+  /// Set the line entry that should be shown to users for this location.
+  /// It is up to the caller to verify that this is a valid entry to show.
+  /// The current use of this is to distinguish among line entries from a
+  /// virtual inlined call stack that all share the same address.
+  /// The line entry must have the same start address as the address for this
+  /// location.
+  bool SetPreferredLineEntry(const LineEntry &line_entry) {
+if (m_address == line_entry.range.GetBaseAddress()) {
+  m_preferred_line_entry = line_entry;
+  return true;
+}
+assert(0 && "Tried to set a preferred line entry with a different 
address");
+return false;
+  }
+
+  const std::optional GetPreferredLineEntry() {
+return m_preferred_line_entry;
+  }
+
 protected:
   friend class BreakpointSite;
   friend class BreakpointLocationList;
@@ -306,6 +327,16 @@ class BreakpointLocation
   /// If it returns false we should continue, otherwise stop.
   bool IgnoreCountShouldStop();
 
+  /// If this location knows that the virtual stack frame it represents is
+  /// not frame 0, return the suggested stack frame instead.  This will happen
+  /// when the location's address contains a "virtual inlined call stack" and
+  /// the breakpoint was set on a file & line that are not at the bottom of 
that
+  /// stack.  For now we key off the "preferred line entry" - looking for that
+  /// in the blocks that start with the stop PC.
+  /// This version of the API doesn't take an "inlined" parameter because it
+  /// only changes frames in the inline stack.
+  std::optional GetSuggestedStackFrameIndex();
+
 private:
   void SwapLocation(lldb::BreakpointLocationSP swap_from);
 
@@ -369,6 +400,11 @@ class BreakpointLocation
   lldb::break_id_t m_loc_id; ///< Breakpoint location ID.
   StoppointHitCounter m_hit_counter; ///< Number of times this breakpoint
  /// location has been hit.
+  /// If this exists, use it to print the st

[Lldb-commits] [lldb] Fix the sort function for languages to have "strict weak ordering". (PR #114160)

[via lldb-commits]

https://github.com/jimingham updated 
https://github.com/llvm/llvm-project/pull/114160

>From 237cb04100fd35df22b4e743c575681f31b54970 Mon Sep 17 00:00:00 2001
From: Jim Ingham 
Date: Tue, 29 Oct 2024 17:11:43 -0700
Subject: [PATCH 1/2] Fix the sort function for languages to have "strict weak
 ordering".

If you build libstdc++ with "debug" strictness, the test TestTypeLookup.py
will assert.  That's because we're calling llvm::sort (which redirects to
std::sort) with a function that doesn't obey strict weak ordering.

The error was that when the two languages were equal, we're sometimes
returning `true` but strict weak ordering requires that always be false.

This patch just makes the function behave properly.
---
 lldb/source/Commands/CommandObjectType.cpp | 1 +
 1 file changed, 1 insertion(+)

diff --git a/lldb/source/Commands/CommandObjectType.cpp 
b/lldb/source/Commands/CommandObjectType.cpp
index f9786529bcdb1c..b5230216bb221a 100644
--- a/lldb/source/Commands/CommandObjectType.cpp
+++ b/lldb/source/Commands/CommandObjectType.cpp
@@ -2649,6 +2649,7 @@ class CommandObjectTypeLookup : public CommandObjectRaw {
 return false;
   LanguageType lt1 = lang1->GetLanguageType();
   LanguageType lt2 = lang2->GetLanguageType();
+  if (lt1 == lt2) return false;
   if (lt1 == guessed_language)
 return true; // make the selected frame's language come first
   if (lt2 == guessed_language)

>From a29750070153ad858140ce0dba13357b5d998044 Mon Sep 17 00:00:00 2001
From: Jim Ingham 
Date: Tue, 29 Oct 2024 17:22:31 -0700
Subject: [PATCH 2/2] clang-format

---
 lldb/source/Commands/CommandObjectType.cpp | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/lldb/source/Commands/CommandObjectType.cpp 
b/lldb/source/Commands/CommandObjectType.cpp
index b5230216bb221a..e4c6e374446e82 100644
--- a/lldb/source/Commands/CommandObjectType.cpp
+++ b/lldb/source/Commands/CommandObjectType.cpp
@@ -2649,7 +2649,8 @@ class CommandObjectTypeLookup : public CommandObjectRaw {
 return false;
   LanguageType lt1 = lang1->GetLanguageType();
   LanguageType lt2 = lang2->GetLanguageType();
-  if (lt1 == lt2) return false;
+  if (lt1 == lt2)
+return false;
   if (lt1 == guessed_language)
 return true; // make the selected frame's language come first
   if (lt2 == guessed_language)

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

[Lldb-commits] [lldb] [lldb] Search main function with lldb::eFunctionNameTypeFull when getting default file and line. (PR #113980)

[Zequan Wu via lldb-commits]

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

[Lldb-commits] [lldb] [lldb] Fix API test for file redirection to existing files (PR #114119)

[via lldb-commits]

github-actions[bot] wrote:




:warning: Python code formatter, darker found issues in your code. :warning:



You can test this locally with the following command:


``bash
darker --check --diff -r 
8a0cb9ac869334fd6c6bd6aad8408623a7ccd7f6...dfa32524d1e6cac75471975de1e2a28225efce83
 lldb/test/API/python_api/process/io/TestProcessIO.py
``





View the diff from darker here.


``diff
--- TestProcessIO.py2024-10-29 19:50:36.00 +
+++ TestProcessIO.py2024-10-29 19:57:49.554558 +
@@ -129,11 +129,11 @@
 f.write(placeholder)
 f.close()
 f = open(self.error_file, "w")
 f.write(placeholder)
 f.close()
-
+
 self.redirect_stdout()
 self.redirect_stderr()
 self.run_process(True)
 output = self.read_output_file_and_delete()
 error = self.read_error_file_and_delete()

``




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

[Lldb-commits] [lldb] [llvm] [DWARF] Fix arity of DW_OP_bra (PR #114136)

[Jonas Devlieghere via lldb-commits]

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

Found by my POC DWARF expression evaluation fuzzer. 

>From b4f93c43634ac4a20693da560522f3b13a516ac7 Mon Sep 17 00:00:00 2001
From: Jonas Devlieghere 
Date: Tue, 29 Oct 2024 15:13:19 -0700
Subject: [PATCH] [DWARF] Fix arity of DW_OP_bra

---
 lldb/unittests/Expression/DWARFExpressionTest.cpp | 3 +++
 llvm/include/llvm/BinaryFormat/Dwarf.def  | 2 +-
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/lldb/unittests/Expression/DWARFExpressionTest.cpp 
b/lldb/unittests/Expression/DWARFExpressionTest.cpp
index f9e0605fce29d6..fdc9bfae1876c5 100644
--- a/lldb/unittests/Expression/DWARFExpressionTest.cpp
+++ b/lldb/unittests/Expression/DWARFExpressionTest.cpp
@@ -181,6 +181,9 @@ TEST(DWARFExpression, DW_OP_bra) {
   }),
   // clang-format on
   llvm::HasValue(0x42));
+
+  EXPECT_THAT_ERROR(Evaluate({DW_OP_bra, 0x01, 0x00}).takeError(),
+llvm::Failed());
 }
 
 TEST(DWARFExpression, DW_OP_convert) {
diff --git a/llvm/include/llvm/BinaryFormat/Dwarf.def 
b/llvm/include/llvm/BinaryFormat/Dwarf.def
index 9336f2a454ae47..0cbbbe823c06b5 100644
--- a/llvm/include/llvm/BinaryFormat/Dwarf.def
+++ b/llvm/include/llvm/BinaryFormat/Dwarf.def
@@ -728,7 +728,7 @@ HANDLE_DW_OP(0x24, shl, 0, 2, 2, DWARF)
 HANDLE_DW_OP(0x25, shr, 0, 2, 2, DWARF)
 HANDLE_DW_OP(0x26, shra, 0, 2, 2, DWARF)
 HANDLE_DW_OP(0x27, xor, 0, 2, 2, DWARF)
-HANDLE_DW_OP(0x28, bra, 1, 0, 2, DWARF)
+HANDLE_DW_OP(0x28, bra, 1, 1, 2, DWARF)
 HANDLE_DW_OP(0x29, eq, 0, 2, 2, DWARF)
 HANDLE_DW_OP(0x2a, ge, 0, 2, 2, DWARF)
 HANDLE_DW_OP(0x2b, gt, 0, 2, 2, DWARF)

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

[Lldb-commits] [lldb] [llvm] [DWARF] Fix arity of DW_OP_bra (PR #114136)

[via lldb-commits]

llvmbot wrote:



@llvm/pr-subscribers-debuginfo

@llvm/pr-subscribers-lldb

Author: Jonas Devlieghere (JDevlieghere)


Changes

Found by my POC DWARF expression evaluation fuzzer. 

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


2 Files Affected:

- (modified) lldb/unittests/Expression/DWARFExpressionTest.cpp (+3) 
- (modified) llvm/include/llvm/BinaryFormat/Dwarf.def (+1-1) 


``diff
diff --git a/lldb/unittests/Expression/DWARFExpressionTest.cpp 
b/lldb/unittests/Expression/DWARFExpressionTest.cpp
index f9e0605fce29d6..fdc9bfae1876c5 100644
--- a/lldb/unittests/Expression/DWARFExpressionTest.cpp
+++ b/lldb/unittests/Expression/DWARFExpressionTest.cpp
@@ -181,6 +181,9 @@ TEST(DWARFExpression, DW_OP_bra) {
   }),
   // clang-format on
   llvm::HasValue(0x42));
+
+  EXPECT_THAT_ERROR(Evaluate({DW_OP_bra, 0x01, 0x00}).takeError(),
+llvm::Failed());
 }
 
 TEST(DWARFExpression, DW_OP_convert) {
diff --git a/llvm/include/llvm/BinaryFormat/Dwarf.def 
b/llvm/include/llvm/BinaryFormat/Dwarf.def
index 9336f2a454ae47..0cbbbe823c06b5 100644
--- a/llvm/include/llvm/BinaryFormat/Dwarf.def
+++ b/llvm/include/llvm/BinaryFormat/Dwarf.def
@@ -728,7 +728,7 @@ HANDLE_DW_OP(0x24, shl, 0, 2, 2, DWARF)
 HANDLE_DW_OP(0x25, shr, 0, 2, 2, DWARF)
 HANDLE_DW_OP(0x26, shra, 0, 2, 2, DWARF)
 HANDLE_DW_OP(0x27, xor, 0, 2, 2, DWARF)
-HANDLE_DW_OP(0x28, bra, 1, 0, 2, DWARF)
+HANDLE_DW_OP(0x28, bra, 1, 1, 2, DWARF)
 HANDLE_DW_OP(0x29, eq, 0, 2, 2, DWARF)
 HANDLE_DW_OP(0x2a, ge, 0, 2, 2, DWARF)
 HANDLE_DW_OP(0x2b, gt, 0, 2, 2, DWARF)

``




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

[Lldb-commits] [lldb] [lldb] Add a compiler/interpreter of LLDB data formatter bytecode to lldb/examples (PR #113398)

[Adrian Prantl via lldb-commits]

https://github.com/adrian-prantl updated 
https://github.com/llvm/llvm-project/pull/113398

>From 0b88de8fe7f5e4ea7f4089be403b271cd7b086d0 Mon Sep 17 00:00:00 2001
From: Adrian Prantl 
Date: Tue, 22 Oct 2024 16:29:50 -0700
Subject: [PATCH 1/2] Add a compiler/interpreter of LLDB data formatter
 bytecode to examples

---
 lldb/docs/index.rst   |   1 +
 lldb/docs/resources/formatterbytecode.rst | 221 
 lldb/examples/formatter-bytecode/Makefile |   8 +
 lldb/examples/formatter-bytecode/compiler.py  | 486 ++
 .../formatter-bytecode/test/MyOptional.cpp|  23 +
 .../formatter-bytecode/test/formatter.py  | 131 +
 6 files changed, 870 insertions(+)
 create mode 100644 lldb/docs/resources/formatterbytecode.rst
 create mode 100644 lldb/examples/formatter-bytecode/Makefile
 create mode 100644 lldb/examples/formatter-bytecode/compiler.py
 create mode 100644 lldb/examples/formatter-bytecode/test/MyOptional.cpp
 create mode 100644 lldb/examples/formatter-bytecode/test/formatter.py

diff --git a/lldb/docs/index.rst b/lldb/docs/index.rst
index e2c15d872b4be2..c3c2fb36eb541a 100644
--- a/lldb/docs/index.rst
+++ b/lldb/docs/index.rst
@@ -164,6 +164,7 @@ interesting areas to contribute to lldb.
resources/fuzzing
resources/sbapi
resources/dataformatters
+   resources/formatterbytecode
resources/extensions
resources/lldbgdbremote
resources/lldbplatformpackets
diff --git a/lldb/docs/resources/formatterbytecode.rst 
b/lldb/docs/resources/formatterbytecode.rst
new file mode 100644
index 00..e6a52a2bdddcdb
--- /dev/null
+++ b/lldb/docs/resources/formatterbytecode.rst
@@ -0,0 +1,221 @@
+Formatter Bytecode
+==
+
+Background
+--
+
+LLDB provides very rich customization options to display data types (see 
:doc:`/use/variable/`). To use custom data formatters, developers need to edit 
the global `~/.lldbinit` file to make sure they are found and loaded. In 
addition to this rather manual workflow, developers or library authors can ship 
ship data formatters with their code in a format that allows LLDB automatically 
find them and run them securely.
+
+An end-to-end example of such a workflow is the Swift `DebugDescription` macro 
(see https://www.swift.org/blog/announcing-swift-6/#debugging ) that translates 
Swift string interpolation into LLDB summary strings, and puts them into a 
`.lldbsummaries` section, where LLDB can find them.
+
+This document describes a minimal bytecode tailored to running LLDB 
formatters. It defines a human-readable assembler representation for the 
language, an efficient binary encoding, a virtual machine for evaluating it, 
and format for embedding formatters into binary containers.
+
+Goals
+~
+
+Provide an efficient and secure encoding for data formatters that can be used 
as a compilation target from user-friendly representations (such as DIL, Swift 
DebugDescription, or NatVis).
+
+Non-goals
+~
+
+While humans could write the assembler syntax, making it user-friendly is not 
a goal.
+
+Design of the virtual machine
+-
+
+The LLDB formatter virtual machine uses a stack-based bytecode, comparable 
with DWARF expressions, but with higher-level data types and functions.
+
+The virtual machine has two stacks, a data and a control stack. The control 
stack is kept separate to make it easier to reason about the security aspects 
of the virtual machine.
+
+Data types
+~~
+
+All objects on the data stack must have one of the following data types. These 
data types are "host" data types, in LLDB parlance.
+
+* *String* (UTF-8)
+* *Int* (64 bit)
+* *UInt* (64 bit)
+* *Object* (Basically an `SBValue`)
+* *Type* (Basically an `SBType`)
+* *Selector* (One of the predefine functions)
+
+*Object* and *Type* are opaque, they can only be used as a parameters of 
`call`.
+
+Instruction set
+---
+
+Stack operations
+
+
+These instructions manipulate the data stack directly.
+
+  ==  ===
+ OpcodeMnemonicStack effect  
+  --  ---
+ 0x00  `dup`   `(x -> x x)`  
+ 0x01  `drop`  `(x y -> x)`   
+ 0x02  `pick`  `(x ... UInt -> x ... x)`  
+ 0x03  `over`  `(x y -> x y x)`   
+ 0x04  `swap`  `(x y -> y x)` 
+ 0x05  `rot`   `(x y z -> z x y)` 
+===  ==  ===
+
+Control flow
+
+
+These manipulate the control stack and program counter.
+
+  ==  

+ OpcodeMnemonicDescription  
+  --  

+ 0x10   `{`push a code block address onto the control stack
+  --`}`(technically not an opcode) syntax for end

[Lldb-commits] [lldb] [lldb] Extend FindTypes to optionally search by mangled type name (PR #113007)

[Augusto Noronha via lldb-commits]

augusto2112 wrote:

@Michael137 I wasn't able to run `yaml2obj` to convert back an object file that 
contains debug info, I'm not sure if the issue is that `yaml2obj` doesn't 
support something that's encoded in the debug info, or some bug with MachO.

This is the error:

```
error: wrote too much data somewhere, section offsets in section 
__debug_str_offs__DWARF for segment __DWARF don't line up: [cursor=0x41d1e0], 
[fileStart=0x41ccdc], [sectionOffset=0x4f2]
```

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

[Lldb-commits] [lldb] [lldb] Use Py_InitializeFromConfig with Python >= 3.8 (NFC) (PR #114112)

[via lldb-commits]

R-Goc wrote:

Looks good. 

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

[Lldb-commits] [lldb] [lldb] Extend FindTypes to optionally search by mangled type name (PR #113007)

[Augusto Noronha via lldb-commits]

https://github.com/augusto2112 updated 
https://github.com/llvm/llvm-project/pull/113007

>From eab35bd50d89a16494d8f08421a12aef77356c43 Mon Sep 17 00:00:00 2001
From: Augusto Noronha 
Date: Tue, 22 Oct 2024 14:34:44 -0700
Subject: [PATCH 1/3] [lldb] Extend FindTypes to optionally search by mangled
 type name

Swift types have mangled type names. This adds functionality to look
up those types through the FindTypes API by searching for the mangled
type name instead of the regular name.
---
 lldb/include/lldb/Symbol/Type.h  |  9 +
 .../Plugins/SymbolFile/CTF/SymbolFileCTF.cpp | 16 +++-
 .../Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp |  9 +
 .../SymbolFile/NativePDB/SymbolFileNativePDB.cpp |  5 -
 .../Plugins/SymbolFile/PDB/SymbolFilePDB.cpp |  5 -
 5 files changed, 37 insertions(+), 7 deletions(-)

diff --git a/lldb/include/lldb/Symbol/Type.h b/lldb/include/lldb/Symbol/Type.h
index 03d9f927997476..a8e5b81585e169 100644
--- a/lldb/include/lldb/Symbol/Type.h
+++ b/lldb/include/lldb/Symbol/Type.h
@@ -84,6 +84,9 @@ FLAGS_ENUM(TypeQueryOptions){
 /// matching type is found. When false, the type query should find all
 /// matching types.
 e_find_one = (1u << 4),
+// If set, treat TypeQuery::m_name as a mangled name that should be
+// searched.
+e_search_by_mangled_name = (1u << 5),
 };
 LLDB_MARK_AS_BITMASK_ENUM(TypeQueryOptions)
 
@@ -300,6 +303,12 @@ class TypeQuery {
   m_options &= ~e_find_one;
   }
 
+  /// Returns true if the type query is supposed to treat the name to be
+  /// searched as a mangled name.
+  bool GetSearchByMangledName() const {
+return (m_options & e_search_by_mangled_name) != 0;
+  }
+
   /// Access the internal compiler context array.
   ///
   /// Clients can use this to populate the context manually.
diff --git a/lldb/source/Plugins/SymbolFile/CTF/SymbolFileCTF.cpp 
b/lldb/source/Plugins/SymbolFile/CTF/SymbolFileCTF.cpp
index bb738c3dcc54a0..4d08c53f752098 100644
--- a/lldb/source/Plugins/SymbolFile/CTF/SymbolFileCTF.cpp
+++ b/lldb/source/Plugins/SymbolFile/CTF/SymbolFileCTF.cpp
@@ -1032,11 +1032,17 @@ void SymbolFileCTF::FindTypes(const 
lldb_private::TypeQuery &match,
 
   ConstString name = match.GetTypeBasename();
   for (TypeSP type_sp : GetTypeList().Types()) {
-if (type_sp && type_sp->GetName() == name) {
-  results.InsertUnique(type_sp);
-  if (results.Done(match))
-return;
-}
+if (!type_sp)
+  continue;
+auto type_name =
+match.GetSearchByMangledName()
+? type_sp->GetForwardCompilerType().GetMangledTypeName()
+: type_sp->GetName();
+if (type_name != name)
+  continue;
+results.InsertUnique(type_sp);
+if (results.Done(match))
+  return;
   }
 }
 
diff --git a/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
index e5b8eee8d08c24..704c8d64dbfb2f 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
@@ -2758,6 +2758,15 @@ void SymbolFileDWARF::FindTypes(const TypeQuery &query, 
TypeResults &results) {
 return true; // Keep iterating over index types, language mismatch.
 }
 
+// Since mangled names are unique, we only need to check if the names are
+// the same.
+if (query.GetSearchByMangledName()) {
+  if (die.GetMangledName() == query.GetTypeBasename().GetStringRef())
+if (Type *matching_type = ResolveType(die, true, true))
+  results.InsertUnique(matching_type->shared_from_this());
+  return !results.Done(query); // Keep iterating if we aren't done.
+}
+
 // Check the context matches
 std::vector die_context;
 if (query.GetModuleSearch())
diff --git a/lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp 
b/lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp
index 7fded6a31a3af5..b55518a136c997 100644
--- a/lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp
+++ b/lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp
@@ -1735,7 +1735,10 @@ void SymbolFileNativePDB::FindTypes(const 
lldb_private::TypeQuery &query,
   continue;
 
 // We resolved a type. Get the fully qualified name to ensure it matches.
-ConstString name = type_sp->GetQualifiedName();
+ConstString name =
+query.GetSearchByMangledName()
+? type_sp->GetForwardCompilerType().GetMangledTypeName()
+: type_sp->GetQualifiedName();
 TypeQuery type_match(name.GetStringRef(), TypeQueryOptions::e_exact_match);
 if (query.ContextMatches(type_match.GetContextRef())) {
   results.InsertUnique(type_sp);
diff --git a/lldb/source/Plugins/SymbolFile/PDB/SymbolFilePDB.cpp 
b/lldb/source/Plugins/SymbolFile/PDB/SymbolFilePDB.cpp
index 4fc48b4d133382..0ea18d8f74baa3 100644
--- a/lldb/source/Plugins/SymbolFile/PDB/SymbolFilePDB.cpp
+++ b/lldb/s

[Lldb-commits] [lldb] [lldb] Fix API test for file redirection to existing files (PR #114119)

[via lldb-commits]

https://github.com/kusmour updated 
https://github.com/llvm/llvm-project/pull/114119

>From a1b19dfcce99cfbfea5a3e7004e1a04e0b13a3e2 Mon Sep 17 00:00:00 2001
From: Wanyi Ye 
Date: Tue, 29 Oct 2024 12:50:28 -0700
Subject: [PATCH] [lldb] Fix API test for file redirection to existing files

---
 .../python_api/process/io/TestProcessIO.py| 39 +++
 1 file changed, 23 insertions(+), 16 deletions(-)

diff --git a/lldb/test/API/python_api/process/io/TestProcessIO.py 
b/lldb/test/API/python_api/process/io/TestProcessIO.py
index 3b5c7c48c51f4d..5d9727add399b5 100644
--- a/lldb/test/API/python_api/process/io/TestProcessIO.py
+++ b/lldb/test/API/python_api/process/io/TestProcessIO.py
@@ -99,31 +99,38 @@ def test_stdout_stderr_redirection(self):
 @expectedFlakeyLinux(bugnumber="llvm.org/pr26437")
 @skipIfDarwinEmbedded  # debugserver can't create/write files on the device
 def test_stdout_stderr_redirection_to_existing_files(self):
-"""Exercise SBLaunchInfo::AddOpenFileAction() for STDOUT and STDERR 
without redirecting STDIN to output files already exist."""
+"""Exercise SBLaunchInfo::AddOpenFileAction() for STDOUT and STDERR 
redirect to output files already exist."""
 self.setup_test()
 self.build()
 self.create_target()
-self.write_file_with_placeholder(self.output_file)
-self.write_file_with_placeholder(self.error_file)
-self.redirect_stdout()
-self.redirect_stderr()
-self.run_process(True)
-output = self.read_output_file_and_delete()
-error = self.read_error_file_and_delete()
-self.check_process_output(output, error)
 
-def write_file_with_placeholder(self, target_file):
+# Create the output and error files with placeholder
 placeholder = "This content should be overwritten."
+# Local file directory and working directory are the same for local 
debugging
+f = open(self.local_output_file, "w")
+f.write(placeholder)
+f.close()
+f = open(self.local_error_file, "w")
+f.write(placeholder)
+f.close()
 if lldb.remote_platform:
 self.runCmd(
-'platform file write "{target}" -d "{data}"'.format(
-target=target_file, data=placeholder
+'platform put-file "{local}" "{remote}"'.format(
+local=self.local_output_file, remote=self.output_file
+)
+)
+self.runCmd(
+'platform put-file "{local}" "{remote}"'.format(
+local=self.local_error_file, remote=self.error_file
 )
 )
-else:
-f = open(target_file, "w")
-f.write(placeholder)
-f.close()
+
+self.redirect_stdout()
+self.redirect_stderr()
+self.run_process(True)
+output = self.read_output_file_and_delete()
+error = self.read_error_file_and_delete()
+self.check_process_output(output, error)
 
 # target_file - path on local file system or remote file system if running 
remote
 # local_file - path on local system

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

[Lldb-commits] [lldb] Fix the sort function for languages to have "strict weak ordering". (PR #114160)

[via lldb-commits]

https://github.com/jimingham created 
https://github.com/llvm/llvm-project/pull/114160

If you build libstdc++ with "debug" strictness, the test TestTypeLookup.py will 
assert.  That's because we're calling llvm::sort (which redirects to std::sort) 
with a function that doesn't obey strict weak ordering.

The error was that when the two languages were equal, we're sometimes returning 
`true` but strict weak ordering requires that always be false.

This patch just makes the function behave properly.

>From 237cb04100fd35df22b4e743c575681f31b54970 Mon Sep 17 00:00:00 2001
From: Jim Ingham 
Date: Tue, 29 Oct 2024 17:11:43 -0700
Subject: [PATCH] Fix the sort function for languages to have "strict weak
 ordering".

If you build libstdc++ with "debug" strictness, the test TestTypeLookup.py
will assert.  That's because we're calling llvm::sort (which redirects to
std::sort) with a function that doesn't obey strict weak ordering.

The error was that when the two languages were equal, we're sometimes
returning `true` but strict weak ordering requires that always be false.

This patch just makes the function behave properly.
---
 lldb/source/Commands/CommandObjectType.cpp | 1 +
 1 file changed, 1 insertion(+)

diff --git a/lldb/source/Commands/CommandObjectType.cpp 
b/lldb/source/Commands/CommandObjectType.cpp
index f9786529bcdb1c..b5230216bb221a 100644
--- a/lldb/source/Commands/CommandObjectType.cpp
+++ b/lldb/source/Commands/CommandObjectType.cpp
@@ -2649,6 +2649,7 @@ class CommandObjectTypeLookup : public CommandObjectRaw {
 return false;
   LanguageType lt1 = lang1->GetLanguageType();
   LanguageType lt2 = lang2->GetLanguageType();
+  if (lt1 == lt2) return false;
   if (lt1 == guessed_language)
 return true; // make the selected frame's language come first
   if (lt2 == guessed_language)

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

[Lldb-commits] [lldb] Fix the sort function for languages to have "strict weak ordering". (PR #114160)

[via lldb-commits]

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: None (jimingham)


Changes

If you build libstdc++ with "debug" strictness, the test TestTypeLookup.py will 
assert.  That's because we're calling llvm::sort (which redirects to std::sort) 
with a function that doesn't obey strict weak ordering.

The error was that when the two languages were equal, we're sometimes returning 
`true` but strict weak ordering requires that always be false.

This patch just makes the function behave properly.

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


1 Files Affected:

- (modified) lldb/source/Commands/CommandObjectType.cpp (+1) 


``diff
diff --git a/lldb/source/Commands/CommandObjectType.cpp 
b/lldb/source/Commands/CommandObjectType.cpp
index f9786529bcdb1c..b5230216bb221a 100644
--- a/lldb/source/Commands/CommandObjectType.cpp
+++ b/lldb/source/Commands/CommandObjectType.cpp
@@ -2649,6 +2649,7 @@ class CommandObjectTypeLookup : public CommandObjectRaw {
 return false;
   LanguageType lt1 = lang1->GetLanguageType();
   LanguageType lt2 = lang2->GetLanguageType();
+  if (lt1 == lt2) return false;
   if (lt1 == guessed_language)
 return true; // make the selected frame's language come first
   if (lt2 == guessed_language)

``




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

[Lldb-commits] [lldb] Fix call site breakpoint patch (PR #114158)

[via lldb-commits]

github-actions[bot] wrote:




:warning: Python code formatter, darker found issues in your code. :warning:



You can test this locally with the following command:


``bash
darker --check --diff -r 
39303e24b6f628f3c080f1b54bd12383a55b9b3a...dfcd21afd11b6e384ece06f128636dde2c075ac6
 lldb/test/API/functionalities/gdb_remote_client/TestGDBRemoteClient.py 
lldb/test/API/functionalities/inline-stepping/TestInlineStepping.py
``





View the diff from darker here.


``diff
--- gdb_remote_client/TestGDBRemoteClient.py2024-10-29 23:35:22.00 +
+++ gdb_remote_client/TestGDBRemoteClient.py2024-10-30 00:13:12.020549 +
@@ -138,11 +138,11 @@
 # test.
 # Also, even with the use-g-packet-for-reading lldb will sometimes 
send p0
 # early on to see if the packet is supported.  So we can't say that 
there
 # will be NO p packets.
 # But there certainly should be no p packets after the g packet.
-
+
 self.read_registers(process)
 print(f"\nPACKET LOG:\n{self.server.responder.packetLog}\n")
 g_pos = 0
 try:
 g_pos = self.server.responder.packetLog.index("g")
@@ -155,11 +155,18 @@
 except:
 pass
 
 # Make sure there aren't any `p` packets after the `g` packet:
 self.assertEqual(
-0, len([p for p in self.server.responder.packetLog[g_pos:] if 
p.startswith("p")])
+0,
+len(
+[
+p
+for p in self.server.responder.packetLog[g_pos:]
+if p.startswith("p")
+]
+),
 )
 
 def test_read_registers_using_p_packets(self):
 """Test reading registers using 'p' packets"""
 self.dbg.HandleCommand(

``




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

[Lldb-commits] [lldb] Fix the sort function for languages to have "strict weak ordering". (PR #114160)

[via lldb-commits]

github-actions[bot] wrote:




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



You can test this locally with the following command:


``bash
git-clang-format --diff 39303e24b6f628f3c080f1b54bd12383a55b9b3a 
237cb04100fd35df22b4e743c575681f31b54970 --extensions cpp -- 
lldb/source/Commands/CommandObjectType.cpp
``





View the diff from clang-format here.


``diff
diff --git a/lldb/source/Commands/CommandObjectType.cpp 
b/lldb/source/Commands/CommandObjectType.cpp
index b5230216bb..e4c6e37444 100644
--- a/lldb/source/Commands/CommandObjectType.cpp
+++ b/lldb/source/Commands/CommandObjectType.cpp
@@ -2649,7 +2649,8 @@ public:
 return false;
   LanguageType lt1 = lang1->GetLanguageType();
   LanguageType lt2 = lang2->GetLanguageType();
-  if (lt1 == lt2) return false;
+  if (lt1 == lt2)
+return false;
   if (lt1 == guessed_language)
 return true; // make the selected frame's language come first
   if (lt2 == guessed_language)

``




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

[Lldb-commits] [lldb] [lldb] Fix API test for file redirection to existing files (PR #114119)

[via lldb-commits]

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

[Lldb-commits] [lldb] Fix a couple of tests that were incorrectly using configuration.dwarf_version (PR #114161)

[via lldb-commits]

https://github.com/jimingham created 
https://github.com/llvm/llvm-project/pull/114161

The tests were using the variable directly to get the dwarf version used for 
the test.  That's only the overridden value, and won't be set if we're using 
the compiler default.  I also put a comment by the variable to make sure people 
don't make the same mistake in the future.

>From 7fe3b6ac2e32dcb3660affa422ae8909b11670e2 Mon Sep 17 00:00:00 2001
From: Jim Ingham 
Date: Tue, 29 Oct 2024 17:39:36 -0700
Subject: [PATCH] Fix a couple of tests that were incorrectly using

configuration.dwarf_version

directly to get the dwarf version used for the test.  That's
only the overridden value, and won't be set if we're using the
compiler default.  I also put a comment by the variable to make
sure people don't make the same mistake in the future.
---
 lldb/packages/Python/lldbsuite/test/configuration.py| 4 
 lldb/test/API/lang/cpp/namespace/TestNamespaceLookup.py | 4 ++--
 lldb/test/API/python_api/type/TestTypeList.py   | 4 ++--
 3 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/lldb/packages/Python/lldbsuite/test/configuration.py 
b/lldb/packages/Python/lldbsuite/test/configuration.py
index 1bacd74a968c31..bcc179346836d1 100644
--- a/lldb/packages/Python/lldbsuite/test/configuration.py
+++ b/lldb/packages/Python/lldbsuite/test/configuration.py
@@ -46,6 +46,10 @@
 make_path = None
 
 # The overriden dwarf verison.
+# Don't use this to test the current compiler's
+# DWARF version, as this won't be set if the
+# version isn't overridden.
+# Use lldbplatformutils.getDwarfVersion() instead.
 dwarf_version = 0
 
 # Any overridden settings.
diff --git a/lldb/test/API/lang/cpp/namespace/TestNamespaceLookup.py 
b/lldb/test/API/lang/cpp/namespace/TestNamespaceLookup.py
index b5e8115160d209..fbc8884a927fee 100644
--- a/lldb/test/API/lang/cpp/namespace/TestNamespaceLookup.py
+++ b/lldb/test/API/lang/cpp/namespace/TestNamespaceLookup.py
@@ -8,7 +8,7 @@
 from lldbsuite.test.decorators import *
 from lldbsuite.test.lldbtest import *
 from lldbsuite.test import lldbutil
-
+from lldbsuite.test import lldbplatformutil
 
 class NamespaceLookupTestCase(TestBase):
 def setUp(self):
@@ -167,7 +167,7 @@ def test_scope_lookup_with_run_command(self):
 self.runToBkpt("continue")
 # FIXME: In DWARF 5 with dsyms, the ordering of functions is slightly
 # different, which also hits the same issues mentioned previously.
-if configuration.dwarf_version <= 4 or self.getDebugInfo() == "dwarf":
+if int(lldbplatformutil.getDwarfVersion()) <= 4 or self.getDebugInfo() 
== "dwarf":
 self.expect_expr("func()", result_type="int", result_value="2")
 
 # Continue to BP_ns_scope at ns scope
diff --git a/lldb/test/API/python_api/type/TestTypeList.py 
b/lldb/test/API/python_api/type/TestTypeList.py
index bc4d00c17c5551..09879276b44aa3 100644
--- a/lldb/test/API/python_api/type/TestTypeList.py
+++ b/lldb/test/API/python_api/type/TestTypeList.py
@@ -6,7 +6,7 @@
 from lldbsuite.test.decorators import *
 from lldbsuite.test.lldbtest import *
 from lldbsuite.test import lldbutil
-
+from lldbsuite.test import lldbplatformutil
 
 class TypeAndTypeListTestCase(TestBase):
 def setUp(self):
@@ -248,7 +248,7 @@ def test(self):
 self.assertEqual(myint_arr_element_type, myint_type)
 
 # Test enum methods. Requires DW_AT_enum_class which was added in 
Dwarf 4.
-if configuration.dwarf_version >= 4:
+if int(lldbplatformutil.getDwarfVersion()) >= 4:
 enum_type = target.FindFirstType("EnumType")
 self.assertTrue(enum_type)
 self.DebugSBType(enum_type)

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

[Lldb-commits] [lldb] Fix a couple of tests that were incorrectly using configuration.dwarf_version (PR #114161)

[via lldb-commits]

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: None (jimingham)


Changes

The tests were using the variable directly to get the dwarf version used for 
the test.  That's only the overridden value, and won't be set if we're using 
the compiler default.  I also put a comment by the variable to make sure people 
don't make the same mistake in the future.

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


3 Files Affected:

- (modified) lldb/packages/Python/lldbsuite/test/configuration.py (+4) 
- (modified) lldb/test/API/lang/cpp/namespace/TestNamespaceLookup.py (+2-2) 
- (modified) lldb/test/API/python_api/type/TestTypeList.py (+2-2) 


``diff
diff --git a/lldb/packages/Python/lldbsuite/test/configuration.py 
b/lldb/packages/Python/lldbsuite/test/configuration.py
index 1bacd74a968c31..bcc179346836d1 100644
--- a/lldb/packages/Python/lldbsuite/test/configuration.py
+++ b/lldb/packages/Python/lldbsuite/test/configuration.py
@@ -46,6 +46,10 @@
 make_path = None
 
 # The overriden dwarf verison.
+# Don't use this to test the current compiler's
+# DWARF version, as this won't be set if the
+# version isn't overridden.
+# Use lldbplatformutils.getDwarfVersion() instead.
 dwarf_version = 0
 
 # Any overridden settings.
diff --git a/lldb/test/API/lang/cpp/namespace/TestNamespaceLookup.py 
b/lldb/test/API/lang/cpp/namespace/TestNamespaceLookup.py
index b5e8115160d209..fbc8884a927fee 100644
--- a/lldb/test/API/lang/cpp/namespace/TestNamespaceLookup.py
+++ b/lldb/test/API/lang/cpp/namespace/TestNamespaceLookup.py
@@ -8,7 +8,7 @@
 from lldbsuite.test.decorators import *
 from lldbsuite.test.lldbtest import *
 from lldbsuite.test import lldbutil
-
+from lldbsuite.test import lldbplatformutil
 
 class NamespaceLookupTestCase(TestBase):
 def setUp(self):
@@ -167,7 +167,7 @@ def test_scope_lookup_with_run_command(self):
 self.runToBkpt("continue")
 # FIXME: In DWARF 5 with dsyms, the ordering of functions is slightly
 # different, which also hits the same issues mentioned previously.
-if configuration.dwarf_version <= 4 or self.getDebugInfo() == "dwarf":
+if int(lldbplatformutil.getDwarfVersion()) <= 4 or self.getDebugInfo() 
== "dwarf":
 self.expect_expr("func()", result_type="int", result_value="2")
 
 # Continue to BP_ns_scope at ns scope
diff --git a/lldb/test/API/python_api/type/TestTypeList.py 
b/lldb/test/API/python_api/type/TestTypeList.py
index bc4d00c17c5551..09879276b44aa3 100644
--- a/lldb/test/API/python_api/type/TestTypeList.py
+++ b/lldb/test/API/python_api/type/TestTypeList.py
@@ -6,7 +6,7 @@
 from lldbsuite.test.decorators import *
 from lldbsuite.test.lldbtest import *
 from lldbsuite.test import lldbutil
-
+from lldbsuite.test import lldbplatformutil
 
 class TypeAndTypeListTestCase(TestBase):
 def setUp(self):
@@ -248,7 +248,7 @@ def test(self):
 self.assertEqual(myint_arr_element_type, myint_type)
 
 # Test enum methods. Requires DW_AT_enum_class which was added in 
Dwarf 4.
-if configuration.dwarf_version >= 4:
+if int(lldbplatformutil.getDwarfVersion()) >= 4:
 enum_type = target.FindFirstType("EnumType")
 self.assertTrue(enum_type)
 self.DebugSBType(enum_type)

``




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

[Lldb-commits] [lldb] Fix a couple of tests that were incorrectly using configuration.dwarf_version (PR #114161)

[via lldb-commits]

github-actions[bot] wrote:




:warning: Python code formatter, darker found issues in your code. :warning:



You can test this locally with the following command:


``bash
darker --check --diff -r 
39303e24b6f628f3c080f1b54bd12383a55b9b3a...7fe3b6ac2e32dcb3660affa422ae8909b11670e2
 lldb/packages/Python/lldbsuite/test/configuration.py 
lldb/test/API/lang/cpp/namespace/TestNamespaceLookup.py 
lldb/test/API/python_api/type/TestTypeList.py
``





View the diff from darker here.


``diff
--- test/API/lang/cpp/namespace/TestNamespaceLookup.py  2024-10-30 
00:39:36.00 +
+++ test/API/lang/cpp/namespace/TestNamespaceLookup.py  2024-10-30 
00:46:35.813998 +
@@ -165,11 +165,14 @@
 
 # Continue to BP_file_scope at file scope
 self.runToBkpt("continue")
 # FIXME: In DWARF 5 with dsyms, the ordering of functions is slightly
 # different, which also hits the same issues mentioned previously.
-if int(lldbplatformutil.getDwarfVersion()) <= 4 or self.getDebugInfo() 
== "dwarf":
+if (
+int(lldbplatformutil.getDwarfVersion()) <= 4
+or self.getDebugInfo() == "dwarf"
+):
 self.expect_expr("func()", result_type="int", result_value="2")
 
 # Continue to BP_ns_scope at ns scope
 self.runToBkpt("continue")
 # Evaluate func(10) - should call A::func(int)

``




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

[Lldb-commits] [lldb] Fix return value of 'PluginManager::RegisterPlugin()'. (PR #114120)

[via lldb-commits]

jimingham wrote:

We obviously aren't checking this return anywhere.  The only way it can return 
false that I can see is if you call RegisterPlugin with no callback pointer - 
which seems more like a programming error than a run-time check.  Do we 
actually need this bool return?

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

[Lldb-commits] [lldb] [lldb] Extend FindTypes to optionally search by mangled type name (PR #113007)

[Augusto Noronha via lldb-commits]

@@ -2758,6 +2758,15 @@ void SymbolFileDWARF::FindTypes(const TypeQuery &query, 
TypeResults &results) {
 return true; // Keep iterating over index types, language mismatch.
 }
 
+// Since mangled names are unique, we only need to check if the names are
+// the same.
+if (query.GetSearchByMangledName()) {
+  if (die.GetMangledName() == query.GetTypeBasename().GetStringRef())
+if (Type *matching_type = ResolveType(die, true, true))
+  results.InsertUnique(matching_type->shared_from_this());
+  return !results.Done(query); // Keep iterating if we aren't done.
+}

augusto2112 wrote:

Good catch! Thanks!

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

[Lldb-commits] [lldb] a325c53 - [lldb] Fix lldb windows build breakage from https://github.com/llvm/llvm-project/pull/112657.

[Zequan Wu via lldb-commits]

Author: Zequan Wu
Date: 2024-10-29T14:38:02-07:00
New Revision: a325c5359310316e393e7e446373fca645002ecb

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

LOG: [lldb] Fix lldb windows build breakage from 
https://github.com/llvm/llvm-project/pull/112657.

LLDB windows build failure: 
https://lab.llvm.org/buildbot/#/builders/141/builds/3462

Added: 


Modified: 
lldb/unittests/Host/FileActionTest.cpp

Removed: 




diff  --git a/lldb/unittests/Host/FileActionTest.cpp 
b/lldb/unittests/Host/FileActionTest.cpp
index 3d2c722552c9c2..56227cd587e5bb 100644
--- a/lldb/unittests/Host/FileActionTest.cpp
+++ b/lldb/unittests/Host/FileActionTest.cpp
@@ -10,6 +10,9 @@
 
 #include "lldb/Host/FileAction.h"
 #include "gtest/gtest.h"
+#if defined(_WIN32)
+#include "lldb/Host/windows/PosixApi.h"
+#endif
 
 using namespace lldb_private;
 



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

[Lldb-commits] [lldb] Fix return value of 'PluginManager::RegisterPlugin()'. (PR #114120)

[Jonas Devlieghere via lldb-commits]

@@ -209,7 +209,7 @@ template  class PluginInstances {
 Instance instance =
 Instance(name, description, callback, std::forward(args)...);
 m_instances.push_back(instance);

JDevlieghere wrote:

While you're here... :-) Should this use `emplace_back` to create the instance 
object in place?

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

[Lldb-commits] [lldb] [lldb][test] Skip `LibCxxInternalsRecognizerTestCase` on clang <= 17 (PR #114122)

[Michael Buch via lldb-commits]

Michael137 wrote:

Sorry to clarify. I think based on @felipepiovezan comment here: 
https://github.com/llvm/llvm-project/pull/108870#issuecomment-281588

On Clang 17 we compile fine, just the assertion fails to find the expected 
function name (because of the `std::__1` inline namespace):
```
FAIL: test_frame_recognizer 
(TestLibcxxInternalsRecognizer.LibCxxInternalsRecognizerTestCase)
   Test that implementation details of libc++ are hidden
--
Traceback (most recent call last):
  File 
"/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/test/API/lang/cpp/libcxx-internals-recognizer/TestLibcxxInternalsRecognizer.py",
 line 60, in test_frame_recognizer
self.assertIn(
AssertionError: 'ranges::__sort::operator()' not found in 
'std::__1::__wrap_iter 
std::__1::ranges::__sort::__fn::operator()[abi:ue170006],
 std::__1::__wrap_iter, bool (*)(int, int), 
std::__1::identity>(std::__1::__wrap_iter, std::__1::__wrap_iter, 
bool (*)(int, int), std::__1::identity) const'
Config=x86_64-/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/clang_1706_build/bin/clang
```

So really we should skip for <= 15. And fix the assertion for 17+

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

[Lldb-commits] [lldb] [lldb] Extend FindTypes to optionally search by mangled type name (PR #113007)

[Augusto Noronha via lldb-commits]

@@ -1032,11 +1032,17 @@ void SymbolFileCTF::FindTypes(const 
lldb_private::TypeQuery &match,
 
   ConstString name = match.GetTypeBasename();
   for (TypeSP type_sp : GetTypeList().Types()) {
-if (type_sp && type_sp->GetName() == name) {
-  results.InsertUnique(type_sp);
-  if (results.Done(match))
-return;
-}
+if (!type_sp)
+  continue;
+auto type_name =
+match.GetSearchByMangledName()
+? type_sp->GetForwardCompilerType().GetMangledTypeName()
+: type_sp->GetName();
+if (type_name != name)
+  continue;
+results.InsertUnique(type_sp);
+if (results.Done(match))
+  return;

augusto2112 wrote:

Sure, I implemented there for completeness.

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

[Lldb-commits] [lldb] [lldb] Set return status to Failed when Python command raises uncaught exception (PR #113996)

[via lldb-commits]

@@ -621,6 +623,9 @@ bool 
lldb_private::python::SWIGBridge::LLDBSwigPythonCallCommand(
 pfunc(debugger_arg, PythonString(args),
   SWIGBridge::ToSWIGWrapper(std::move(exe_ctx_ref_sp)), 
cmd_retobj_arg.obj(), dict);
 
+  if (PyErr_Occurred())

jimingham wrote:

Yes, appending a command-centered message to the error stream sounds right to 
me.  

A raw dump of a python expression - especially if you don't really know that 
lldb has python implemented commands - will just be confusing.  But if we have 
the exception dump followed by a line attributing it to this lldb command, that 
would clearer.

It doesn't look like you know the actual command name at this point, but even 
saying the python function or class name might help people figure it out. 

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

[Lldb-commits] [lldb] [lldb][test] Skip `LibCxxInternalsRecognizerTestCase` on clang <= 17 (PR #114122)

[via lldb-commits]

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Adrian Vogelsgesang (vogelsgesang)


Changes

Because of a build failure with libc++17.
See 
https://green.lab.llvm.org/job/llvm.org/view/LLDB/job/lldb-cmake-matrix/912/execution/node/107/log/

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


1 Files Affected:

- (modified) 
lldb/test/API/lang/cpp/libcxx-internals-recognizer/TestLibcxxInternalsRecognizer.py
 (+1) 


``diff
diff --git 
a/lldb/test/API/lang/cpp/libcxx-internals-recognizer/TestLibcxxInternalsRecognizer.py
 
b/lldb/test/API/lang/cpp/libcxx-internals-recognizer/TestLibcxxInternalsRecognizer.py
index ad48208f21e502..0270e78808c646 100644
--- 
a/lldb/test/API/lang/cpp/libcxx-internals-recognizer/TestLibcxxInternalsRecognizer.py
+++ 
b/lldb/test/API/lang/cpp/libcxx-internals-recognizer/TestLibcxxInternalsRecognizer.py
@@ -8,6 +8,7 @@ class LibCxxInternalsRecognizerTestCase(TestBase):
 NO_DEBUG_INFO_TESTCASE = True
 
 @add_test_categories(["libc++"])
+@skipIf(compiler="clang", compiler_version=["<", "18.0"])
 def test_frame_recognizer(self):
 """Test that implementation details of libc++ are hidden"""
 self.build()

``




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

[Lldb-commits] [lldb] 2ab98df - [lldb] Update link to GreenDragon in the docs

[Jonas Devlieghere via lldb-commits]

Author: Jonas Devlieghere
Date: 2024-10-29T09:45:29-07:00
New Revision: 2ab98dfe19ac384f0cfac1a1fafc56b9dd7ad9b7

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

LOG: [lldb] Update link to GreenDragon in the docs

Added: 


Modified: 
lldb/docs/resources/test.rst

Removed: 




diff  --git a/lldb/docs/resources/test.rst b/lldb/docs/resources/test.rst
index 715d3772fe2787..5f1bd0d5738305 100644
--- a/lldb/docs/resources/test.rst
+++ b/lldb/docs/resources/test.rst
@@ -418,8 +418,8 @@ An overview of all LLDB builders can be found here:
 `https://lab.llvm.org/buildbot/#/builders?tags=lldb 
`_
 
 Building and testing for macOS uses a 
diff erent platform called GreenDragon. It
-has a dedicated tab for LLDB: `https://green.lab.llvm.org/green/view/LLDB/
-`_
+has a dedicated tab for LLDB: 
`https://green.lab.llvm.org/job/llvm.org/view/LLDB/
+`_
 
 
 Running The Tests



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

[Lldb-commits] [lldb] [lldb-dap] Always pass disableASLR to the DAP executable (PR #113891)

[Augusto Noronha via lldb-commits]

augusto2112 wrote:

> If we don't always want forward `disableASLR` we could instead flip the 
> condition to:
> 
> ```
> if not disableASLR:
> args_dict["disableASLR"] = disableASLR
> ```
> 
> Any thoughts?

I think "if not" would make it more confusing. The way it is in this patch 
seems fine to me

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

[Lldb-commits] [lldb] [lldb] Set return status to Failed when Python command raises uncaught exception (PR #113996)

[Dave Lee via lldb-commits]

@@ -621,6 +623,9 @@ bool 
lldb_private::python::SWIGBridge::LLDBSwigPythonCallCommand(
 pfunc(debugger_arg, PythonString(args),
   SWIGBridge::ToSWIGWrapper(std::move(exe_ctx_ref_sp)), 
cmd_retobj_arg.obj(), dict);
 
+  if (PyErr_Occurred())

kastiglione wrote:

Maybe the answer is as simple as calling `AppendError`, that way we get both 
messages.

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

[Lldb-commits] [lldb] [lldb] Lookup static const members in FindGlobalVariables (PR #111859)

[Ilia Kuklin via lldb-commits]

https://github.com/kuilpd updated 
https://github.com/llvm/llvm-project/pull/111859

>From 4c394ec162b58b3cde3af924a5e9be1de8250a07 Mon Sep 17 00:00:00 2001
From: Ilia Kuklin 
Date: Tue, 30 Jul 2024 17:02:10 +0500
Subject: [PATCH 1/3] [lldb] Lookup static const members in FindGlobalVariables

Static const members initialized inside a class definition might not have a 
corresponding DW_TAG_variable (DWARF 4 and earlier), so they're not indexed by 
ManualDWARFIndex.

Add an additional lookup in FindGlobalVariables. Try looking up the enclosing 
type (e.g. foo::bar for foo::bar::A) and then searching for a static const 
member (A) within this type.
---
 .../SymbolFile/DWARF/SymbolFileDWARF.cpp  | 130 ++
 .../SymbolFile/DWARF/SymbolFileDWARF.h|   3 +
 .../API/python_api/frame/globals/Makefile |   4 +
 .../frame/globals/TestTargetGlobals.py|  43 ++
 .../API/python_api/frame/globals/main.cpp |  12 ++
 5 files changed, 192 insertions(+)
 create mode 100644 lldb/test/API/python_api/frame/globals/Makefile
 create mode 100644 lldb/test/API/python_api/frame/globals/TestTargetGlobals.py
 create mode 100644 lldb/test/API/python_api/frame/globals/main.cpp

diff --git a/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
index 9287d4baf19e9c..d53da79c1efcee 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
@@ -2439,6 +2439,48 @@ void SymbolFileDWARF::FindGlobalVariables(
 return variables.GetSize() - original_size < max_matches;
   });
 
+  // If we don't have enough matches and the variable context is not empty, try
+  // to resolve the context as a type and look for static const members.
+  if (variables.GetSize() - original_size < max_matches && !context.empty()) {
+llvm::StringRef type_name;
+if (std::optional parsed_name =
+Type::GetTypeScopeAndBasename(context))
+  type_name = parsed_name->basename;
+else
+  type_name = context;
+
+m_index->GetTypes(ConstString(type_name), [&](DWARFDIE parent) {
+  llvm::StringRef parent_type_name = parent.GetDWARFDeclContext()
+ .GetQualifiedNameAsConstString()
+ .GetStringRef();
+
+  // This type is from another scope, skip it.
+  if (!parent_type_name.ends_with(context))
+return true;
+
+  auto *dwarf_cu = llvm::dyn_cast(parent.GetCU());
+  if (!dwarf_cu)
+return true;
+
+  sc.comp_unit = GetCompUnitForDWARFCompUnit(*dwarf_cu);
+
+  for (DWARFDIE die = parent.GetFirstChild(); die.IsValid();
+   die = die.GetSibling()) {
+// Try parsing the entry as a static const member.
+if (auto var_sp = ParseStaticConstMemberDIE(sc, die)) {
+  if (var_sp->GetUnqualifiedName().GetStringRef() != basename)
+continue;
+
+  // There can be only one member with a given name.
+  variables.AddVariableIfUnique(var_sp);
+  break;
+}
+  }
+
+  return variables.GetSize() - original_size < max_matches;
+});
+  }
+
   // Return the number of variable that were appended to the list
   const uint32_t num_matches = variables.GetSize() - original_size;
   if (log && num_matches > 0) {
@@ -3371,6 +3413,94 @@ size_t SymbolFileDWARF::ParseVariablesForContext(const 
SymbolContext &sc) {
   return 0;
 }
 
+VariableSP SymbolFileDWARF::ParseStaticConstMemberDIE(
+const lldb_private::SymbolContext &sc, const DWARFDIE &die) {
+  if (die.GetDWARF() != this)
+return die.GetDWARF()->ParseStaticConstMemberDIE(sc, die);
+
+  // Look only for members, ignore all other types of entries.
+  if (die.Tag() != DW_TAG_member)
+return nullptr;
+
+  if (VariableSP var_sp = GetDIEToVariable()[die.GetDIE()])
+return var_sp; // Already been parsed!
+
+  const char *name = nullptr;
+  const char *mangled = nullptr;
+  Declaration decl;
+  DWARFExpression location;
+  DWARFFormValue type_die_form;
+  DWARFFormValue const_value_form;
+
+  DWARFAttributes attributes = die.GetAttributes();
+  const size_t num_attributes = attributes.Size();
+
+  for (size_t i = 0; i < num_attributes; ++i) {
+dw_attr_t attr = attributes.AttributeAtIndex(i);
+DWARFFormValue form_value;
+
+if (!attributes.ExtractFormValueAtIndex(i, form_value))
+  continue;
+
+switch (attr) {
+case DW_AT_decl_file:
+  decl.SetFile(sc.comp_unit->GetSupportFiles().GetFileSpecAtIndex(
+  form_value.Unsigned()));
+  break;
+case DW_AT_decl_line:
+  decl.SetLine(form_value.Unsigned());
+  break;
+case DW_AT_decl_column:
+  decl.SetColumn(form_value.Unsigned());
+  break;
+case DW_AT_name:
+  name = form_value.AsCString();
+  break;
+case DW_AT_type:
+  type_die_form = form_value;
+  break;
+case DW_AT_const_value:
+  const_

[Lldb-commits] [lldb] [lldb] Add a compiler/interpreter of LLDB data formatter bytecode to lldb/examples (PR #113398)

[Adrian Prantl via lldb-commits]

https://github.com/adrian-prantl updated 
https://github.com/llvm/llvm-project/pull/113398

>From 0b88de8fe7f5e4ea7f4089be403b271cd7b086d0 Mon Sep 17 00:00:00 2001
From: Adrian Prantl 
Date: Tue, 22 Oct 2024 16:29:50 -0700
Subject: [PATCH 1/2] Add a compiler/interpreter of LLDB data formatter
 bytecode to examples

---
 lldb/docs/index.rst   |   1 +
 lldb/docs/resources/formatterbytecode.rst | 221 
 lldb/examples/formatter-bytecode/Makefile |   8 +
 lldb/examples/formatter-bytecode/compiler.py  | 486 ++
 .../formatter-bytecode/test/MyOptional.cpp|  23 +
 .../formatter-bytecode/test/formatter.py  | 131 +
 6 files changed, 870 insertions(+)
 create mode 100644 lldb/docs/resources/formatterbytecode.rst
 create mode 100644 lldb/examples/formatter-bytecode/Makefile
 create mode 100644 lldb/examples/formatter-bytecode/compiler.py
 create mode 100644 lldb/examples/formatter-bytecode/test/MyOptional.cpp
 create mode 100644 lldb/examples/formatter-bytecode/test/formatter.py

diff --git a/lldb/docs/index.rst b/lldb/docs/index.rst
index e2c15d872b4be2..c3c2fb36eb541a 100644
--- a/lldb/docs/index.rst
+++ b/lldb/docs/index.rst
@@ -164,6 +164,7 @@ interesting areas to contribute to lldb.
resources/fuzzing
resources/sbapi
resources/dataformatters
+   resources/formatterbytecode
resources/extensions
resources/lldbgdbremote
resources/lldbplatformpackets
diff --git a/lldb/docs/resources/formatterbytecode.rst 
b/lldb/docs/resources/formatterbytecode.rst
new file mode 100644
index 00..e6a52a2bdddcdb
--- /dev/null
+++ b/lldb/docs/resources/formatterbytecode.rst
@@ -0,0 +1,221 @@
+Formatter Bytecode
+==
+
+Background
+--
+
+LLDB provides very rich customization options to display data types (see 
:doc:`/use/variable/`). To use custom data formatters, developers need to edit 
the global `~/.lldbinit` file to make sure they are found and loaded. In 
addition to this rather manual workflow, developers or library authors can ship 
ship data formatters with their code in a format that allows LLDB automatically 
find them and run them securely.
+
+An end-to-end example of such a workflow is the Swift `DebugDescription` macro 
(see https://www.swift.org/blog/announcing-swift-6/#debugging ) that translates 
Swift string interpolation into LLDB summary strings, and puts them into a 
`.lldbsummaries` section, where LLDB can find them.
+
+This document describes a minimal bytecode tailored to running LLDB 
formatters. It defines a human-readable assembler representation for the 
language, an efficient binary encoding, a virtual machine for evaluating it, 
and format for embedding formatters into binary containers.
+
+Goals
+~
+
+Provide an efficient and secure encoding for data formatters that can be used 
as a compilation target from user-friendly representations (such as DIL, Swift 
DebugDescription, or NatVis).
+
+Non-goals
+~
+
+While humans could write the assembler syntax, making it user-friendly is not 
a goal.
+
+Design of the virtual machine
+-
+
+The LLDB formatter virtual machine uses a stack-based bytecode, comparable 
with DWARF expressions, but with higher-level data types and functions.
+
+The virtual machine has two stacks, a data and a control stack. The control 
stack is kept separate to make it easier to reason about the security aspects 
of the virtual machine.
+
+Data types
+~~
+
+All objects on the data stack must have one of the following data types. These 
data types are "host" data types, in LLDB parlance.
+
+* *String* (UTF-8)
+* *Int* (64 bit)
+* *UInt* (64 bit)
+* *Object* (Basically an `SBValue`)
+* *Type* (Basically an `SBType`)
+* *Selector* (One of the predefine functions)
+
+*Object* and *Type* are opaque, they can only be used as a parameters of 
`call`.
+
+Instruction set
+---
+
+Stack operations
+
+
+These instructions manipulate the data stack directly.
+
+  ==  ===
+ OpcodeMnemonicStack effect  
+  --  ---
+ 0x00  `dup`   `(x -> x x)`  
+ 0x01  `drop`  `(x y -> x)`   
+ 0x02  `pick`  `(x ... UInt -> x ... x)`  
+ 0x03  `over`  `(x y -> x y x)`   
+ 0x04  `swap`  `(x y -> y x)` 
+ 0x05  `rot`   `(x y z -> z x y)` 
+===  ==  ===
+
+Control flow
+
+
+These manipulate the control stack and program counter.
+
+  ==  

+ OpcodeMnemonicDescription  
+  --  

+ 0x10   `{`push a code block address onto the control stack
+  --`}`(technically not an opcode) syntax for end

[Lldb-commits] [lldb] [lldb-dap] Fix for missing 'raw_string_ostream::flush' removal in ProgressEvent.cpp; addressing #108745 (PR #114087)

[Jonas Devlieghere via lldb-commits]

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


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

[Lldb-commits] [lldb] [lldb-dap] Always pass disableASLR to the DAP executable (PR #113891)

[Augusto Noronha via lldb-commits]

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


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

[Lldb-commits] [lldb] [lldb] Set return status to Failed when Python command raises uncaught exception (PR #113996)

[Dave Lee via lldb-commits]

@@ -621,6 +623,9 @@ bool 
lldb_private::python::SWIGBridge::LLDBSwigPythonCallCommand(
 pfunc(debugger_arg, PythonString(args),
   SWIGBridge::ToSWIGWrapper(std::move(exe_ctx_ref_sp)), 
cmd_retobj_arg.obj(), dict);
 
+  if (PyErr_Occurred())

kastiglione wrote:

Since warnings are also written to the error stream, should different logic be 
used? For example, set an error message if the status is not Failed?

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

[Lldb-commits] [lldb] [lldb] Set return status to Failed when Python command raises uncaught exception (PR #113996)

[Dave Lee via lldb-commits]

https://github.com/kastiglione updated 
https://github.com/llvm/llvm-project/pull/113996

>From 75f96b84c9bd2b3211edb5fa8806092711133251 Mon Sep 17 00:00:00 2001
From: Dave Lee 
Date: Mon, 28 Oct 2024 15:49:50 -0700
Subject: [PATCH 1/3] [lldb] Set return status to Failed when Python command
 raises uncaught exception

---
 lldb/bindings/python/python-wrapper.swig  | 13 +++--
 .../script/exception/TestCommandException.py  | 27 +++
 .../command/script/exception/throw_command.py |  6 +
 3 files changed, 44 insertions(+), 2 deletions(-)
 create mode 100644 
lldb/test/API/commands/command/script/exception/TestCommandException.py
 create mode 100644 
lldb/test/API/commands/command/script/exception/throw_command.py

diff --git a/lldb/bindings/python/python-wrapper.swig 
b/lldb/bindings/python/python-wrapper.swig
index b72a462d04643b..dfe762e026788a 100644
--- a/lldb/bindings/python/python-wrapper.swig
+++ b/lldb/bindings/python/python-wrapper.swig
@@ -592,6 +592,8 @@ void 
*lldb_private::python::LLDBSWIGPython_CastPyObjectToSBExecutionContext(PyOb
   return sb_ptr;
 }
 
+#include "lldb/Interpreter/CommandReturnObject.h"
+
 bool lldb_private::python::SWIGBridge::LLDBSwigPythonCallCommand(
 const char *python_function_name, const char *session_dictionary_name,
 lldb::DebuggerSP debugger, const char *args,
@@ -621,6 +623,9 @@ bool 
lldb_private::python::SWIGBridge::LLDBSwigPythonCallCommand(
 pfunc(debugger_arg, PythonString(args),
   SWIGBridge::ToSWIGWrapper(std::move(exe_ctx_ref_sp)), 
cmd_retobj_arg.obj(), dict);
 
+  if (PyErr_Occurred())
+cmd_retobj.SetStatus(eReturnStatusFailed);
+
   return true;
 }
 
@@ -642,6 +647,9 @@ bool 
lldb_private::python::SWIGBridge::LLDBSwigPythonCallCommandObject(
   pfunc(SWIGBridge::ToSWIGWrapper(std::move(debugger)), PythonString(args),
 SWIGBridge::ToSWIGWrapper(exe_ctx_ref_sp), cmd_retobj_arg.obj());
 
+  if (PyErr_Occurred())
+cmd_retobj.SetStatus(eReturnStatusFailed);
+
   return true;
 }
 
@@ -740,8 +748,6 @@ 
lldb_private::python::SWIGBridge::LLDBSwigPythonHandleOptionArgumentCompletionFo
   return dict_sp;
 }
 
-#include "lldb/Interpreter/CommandReturnObject.h"
-
 bool lldb_private::python::SWIGBridge::LLDBSwigPythonCallParsedCommandObject(
 PyObject *implementor, lldb::DebuggerSP debugger, 
lldb_private::StructuredDataImpl &args_impl,
 lldb_private::CommandReturnObject &cmd_retobj,
@@ -760,6 +766,9 @@ bool 
lldb_private::python::SWIGBridge::LLDBSwigPythonCallParsedCommandObject(
   pfunc(SWIGBridge::ToSWIGWrapper(std::move(debugger)), 
SWIGBridge::ToSWIGWrapper(args_impl),
 SWIGBridge::ToSWIGWrapper(exe_ctx_ref_sp), 
SWIGBridge::ToSWIGWrapper(cmd_retobj).obj());
 
+  if (PyErr_Occurred())
+cmd_retobj.SetStatus(eReturnStatusFailed);
+
   return true;
 }
 
diff --git 
a/lldb/test/API/commands/command/script/exception/TestCommandException.py 
b/lldb/test/API/commands/command/script/exception/TestCommandException.py
new file mode 100644
index 00..73484137d82b3e
--- /dev/null
+++ b/lldb/test/API/commands/command/script/exception/TestCommandException.py
@@ -0,0 +1,27 @@
+import os
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+
+
+class TestCase(TestBase):
+NO_DEBUG_INFO_TESTCASE = True
+
+def test(self):
+"""
+Check that a Python command, which raises an unhandled exception, has
+its status set to failed.
+"""
+command_path = os.path.join(self.getSourceDir(), "throw_command.py")
+self.runCmd(f"command script import {command_path}")
+
+with open(os.devnull, "w") as devnull:
+self.dbg.SetErrorFileHandle(devnull, False)
+result = lldb.SBCommandReturnObject()
+self.ci.HandleCommand("throw", result)
+
+self.assertEqual(
+result.GetStatus(),
+lldb.eReturnStatusFailed,
+"command unexpectedly succeeded",
+)
diff --git a/lldb/test/API/commands/command/script/exception/throw_command.py 
b/lldb/test/API/commands/command/script/exception/throw_command.py
new file mode 100644
index 00..7c4989850cb19a
--- /dev/null
+++ b/lldb/test/API/commands/command/script/exception/throw_command.py
@@ -0,0 +1,6 @@
+import lldb
+
+
+@lldb.command()
+def throw(debugger, cmd, ctx, result, _):
+raise Exception("command failed")

>From b64f5ac38b31a1098ca31183f2bfdae4a6069306 Mon Sep 17 00:00:00 2001
From: Dave Lee 
Date: Tue, 29 Oct 2024 09:37:32 -0700
Subject: [PATCH 2/3] Reset error file handle

---
 .../commands/command/script/exception/TestCommandException.py| 1 +
 1 file changed, 1 insertion(+)

diff --git 
a/lldb/test/API/commands/command/script/exception/TestCommandException.py 
b/lldb/test/API/commands/command/script/exception/TestCommandException.py
index 73484137d82b3e..6a673b7589d87e 100644
--- a/lldb/test/API/commands/command/script/exception/TestCommandException.py
+++ b/lldb/test/A

[Lldb-commits] [lldb] [lldb] Set return status to Failed when Python command raises uncaught exception (PR #113996)

[Dave Lee via lldb-commits]

https://github.com/kastiglione updated 
https://github.com/llvm/llvm-project/pull/113996

>From 75f96b84c9bd2b3211edb5fa8806092711133251 Mon Sep 17 00:00:00 2001
From: Dave Lee 
Date: Mon, 28 Oct 2024 15:49:50 -0700
Subject: [PATCH 1/4] [lldb] Set return status to Failed when Python command
 raises uncaught exception

---
 lldb/bindings/python/python-wrapper.swig  | 13 +++--
 .../script/exception/TestCommandException.py  | 27 +++
 .../command/script/exception/throw_command.py |  6 +
 3 files changed, 44 insertions(+), 2 deletions(-)
 create mode 100644 
lldb/test/API/commands/command/script/exception/TestCommandException.py
 create mode 100644 
lldb/test/API/commands/command/script/exception/throw_command.py

diff --git a/lldb/bindings/python/python-wrapper.swig 
b/lldb/bindings/python/python-wrapper.swig
index b72a462d04643b..dfe762e026788a 100644
--- a/lldb/bindings/python/python-wrapper.swig
+++ b/lldb/bindings/python/python-wrapper.swig
@@ -592,6 +592,8 @@ void 
*lldb_private::python::LLDBSWIGPython_CastPyObjectToSBExecutionContext(PyOb
   return sb_ptr;
 }
 
+#include "lldb/Interpreter/CommandReturnObject.h"
+
 bool lldb_private::python::SWIGBridge::LLDBSwigPythonCallCommand(
 const char *python_function_name, const char *session_dictionary_name,
 lldb::DebuggerSP debugger, const char *args,
@@ -621,6 +623,9 @@ bool 
lldb_private::python::SWIGBridge::LLDBSwigPythonCallCommand(
 pfunc(debugger_arg, PythonString(args),
   SWIGBridge::ToSWIGWrapper(std::move(exe_ctx_ref_sp)), 
cmd_retobj_arg.obj(), dict);
 
+  if (PyErr_Occurred())
+cmd_retobj.SetStatus(eReturnStatusFailed);
+
   return true;
 }
 
@@ -642,6 +647,9 @@ bool 
lldb_private::python::SWIGBridge::LLDBSwigPythonCallCommandObject(
   pfunc(SWIGBridge::ToSWIGWrapper(std::move(debugger)), PythonString(args),
 SWIGBridge::ToSWIGWrapper(exe_ctx_ref_sp), cmd_retobj_arg.obj());
 
+  if (PyErr_Occurred())
+cmd_retobj.SetStatus(eReturnStatusFailed);
+
   return true;
 }
 
@@ -740,8 +748,6 @@ 
lldb_private::python::SWIGBridge::LLDBSwigPythonHandleOptionArgumentCompletionFo
   return dict_sp;
 }
 
-#include "lldb/Interpreter/CommandReturnObject.h"
-
 bool lldb_private::python::SWIGBridge::LLDBSwigPythonCallParsedCommandObject(
 PyObject *implementor, lldb::DebuggerSP debugger, 
lldb_private::StructuredDataImpl &args_impl,
 lldb_private::CommandReturnObject &cmd_retobj,
@@ -760,6 +766,9 @@ bool 
lldb_private::python::SWIGBridge::LLDBSwigPythonCallParsedCommandObject(
   pfunc(SWIGBridge::ToSWIGWrapper(std::move(debugger)), 
SWIGBridge::ToSWIGWrapper(args_impl),
 SWIGBridge::ToSWIGWrapper(exe_ctx_ref_sp), 
SWIGBridge::ToSWIGWrapper(cmd_retobj).obj());
 
+  if (PyErr_Occurred())
+cmd_retobj.SetStatus(eReturnStatusFailed);
+
   return true;
 }
 
diff --git 
a/lldb/test/API/commands/command/script/exception/TestCommandException.py 
b/lldb/test/API/commands/command/script/exception/TestCommandException.py
new file mode 100644
index 00..73484137d82b3e
--- /dev/null
+++ b/lldb/test/API/commands/command/script/exception/TestCommandException.py
@@ -0,0 +1,27 @@
+import os
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+
+
+class TestCase(TestBase):
+NO_DEBUG_INFO_TESTCASE = True
+
+def test(self):
+"""
+Check that a Python command, which raises an unhandled exception, has
+its status set to failed.
+"""
+command_path = os.path.join(self.getSourceDir(), "throw_command.py")
+self.runCmd(f"command script import {command_path}")
+
+with open(os.devnull, "w") as devnull:
+self.dbg.SetErrorFileHandle(devnull, False)
+result = lldb.SBCommandReturnObject()
+self.ci.HandleCommand("throw", result)
+
+self.assertEqual(
+result.GetStatus(),
+lldb.eReturnStatusFailed,
+"command unexpectedly succeeded",
+)
diff --git a/lldb/test/API/commands/command/script/exception/throw_command.py 
b/lldb/test/API/commands/command/script/exception/throw_command.py
new file mode 100644
index 00..7c4989850cb19a
--- /dev/null
+++ b/lldb/test/API/commands/command/script/exception/throw_command.py
@@ -0,0 +1,6 @@
+import lldb
+
+
+@lldb.command()
+def throw(debugger, cmd, ctx, result, _):
+raise Exception("command failed")

>From b64f5ac38b31a1098ca31183f2bfdae4a6069306 Mon Sep 17 00:00:00 2001
From: Dave Lee 
Date: Tue, 29 Oct 2024 09:37:32 -0700
Subject: [PATCH 2/4] Reset error file handle

---
 .../commands/command/script/exception/TestCommandException.py| 1 +
 1 file changed, 1 insertion(+)

diff --git 
a/lldb/test/API/commands/command/script/exception/TestCommandException.py 
b/lldb/test/API/commands/command/script/exception/TestCommandException.py
index 73484137d82b3e..6a673b7589d87e 100644
--- a/lldb/test/API/commands/command/script/exception/TestCommandException.py
+++ b/lldb/test/A

[Lldb-commits] [lldb] [llvm] [lldb] Fix write only file action to truncate the file (PR #112657)

[Jacob Lalonde via lldb-commits]

@@ -6,6 +6,8 @@
 //
 
//===--===//
 
+#include 

Jlalond wrote:

It's also passing the Windows CI. @bulbazord I can help @kusmour validate if 
you want, but I personally think CI is good enough

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

[Lldb-commits] [lldb] [lldb] Set return status to Failed when Python command raises uncaught exception (PR #113996)

[Dave Lee via lldb-commits]

@@ -0,0 +1,27 @@
+import os
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+
+
+class TestCase(TestBase):
+NO_DEBUG_INFO_TESTCASE = True
+
+def test(self):
+"""
+Check that a Python command, which raises an unhandled exception, has
+its status set to failed.
+"""
+command_path = os.path.join(self.getSourceDir(), "throw_command.py")
+self.runCmd(f"command script import {command_path}")
+
+with open(os.devnull, "w") as devnull:
+self.dbg.SetErrorFileHandle(devnull, False)

kastiglione wrote:

A few tests do reset do reset the file handle (however some tests do not). I'll 
add a reset here too.

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

[Lldb-commits] [lldb] [lldb] Set return status to Failed when Python command raises uncaught exception (PR #113996)

[Dave Lee via lldb-commits]

https://github.com/kastiglione updated 
https://github.com/llvm/llvm-project/pull/113996

>From 75f96b84c9bd2b3211edb5fa8806092711133251 Mon Sep 17 00:00:00 2001
From: Dave Lee 
Date: Mon, 28 Oct 2024 15:49:50 -0700
Subject: [PATCH 1/2] [lldb] Set return status to Failed when Python command
 raises uncaught exception

---
 lldb/bindings/python/python-wrapper.swig  | 13 +++--
 .../script/exception/TestCommandException.py  | 27 +++
 .../command/script/exception/throw_command.py |  6 +
 3 files changed, 44 insertions(+), 2 deletions(-)
 create mode 100644 
lldb/test/API/commands/command/script/exception/TestCommandException.py
 create mode 100644 
lldb/test/API/commands/command/script/exception/throw_command.py

diff --git a/lldb/bindings/python/python-wrapper.swig 
b/lldb/bindings/python/python-wrapper.swig
index b72a462d04643b..dfe762e026788a 100644
--- a/lldb/bindings/python/python-wrapper.swig
+++ b/lldb/bindings/python/python-wrapper.swig
@@ -592,6 +592,8 @@ void 
*lldb_private::python::LLDBSWIGPython_CastPyObjectToSBExecutionContext(PyOb
   return sb_ptr;
 }
 
+#include "lldb/Interpreter/CommandReturnObject.h"
+
 bool lldb_private::python::SWIGBridge::LLDBSwigPythonCallCommand(
 const char *python_function_name, const char *session_dictionary_name,
 lldb::DebuggerSP debugger, const char *args,
@@ -621,6 +623,9 @@ bool 
lldb_private::python::SWIGBridge::LLDBSwigPythonCallCommand(
 pfunc(debugger_arg, PythonString(args),
   SWIGBridge::ToSWIGWrapper(std::move(exe_ctx_ref_sp)), 
cmd_retobj_arg.obj(), dict);
 
+  if (PyErr_Occurred())
+cmd_retobj.SetStatus(eReturnStatusFailed);
+
   return true;
 }
 
@@ -642,6 +647,9 @@ bool 
lldb_private::python::SWIGBridge::LLDBSwigPythonCallCommandObject(
   pfunc(SWIGBridge::ToSWIGWrapper(std::move(debugger)), PythonString(args),
 SWIGBridge::ToSWIGWrapper(exe_ctx_ref_sp), cmd_retobj_arg.obj());
 
+  if (PyErr_Occurred())
+cmd_retobj.SetStatus(eReturnStatusFailed);
+
   return true;
 }
 
@@ -740,8 +748,6 @@ 
lldb_private::python::SWIGBridge::LLDBSwigPythonHandleOptionArgumentCompletionFo
   return dict_sp;
 }
 
-#include "lldb/Interpreter/CommandReturnObject.h"
-
 bool lldb_private::python::SWIGBridge::LLDBSwigPythonCallParsedCommandObject(
 PyObject *implementor, lldb::DebuggerSP debugger, 
lldb_private::StructuredDataImpl &args_impl,
 lldb_private::CommandReturnObject &cmd_retobj,
@@ -760,6 +766,9 @@ bool 
lldb_private::python::SWIGBridge::LLDBSwigPythonCallParsedCommandObject(
   pfunc(SWIGBridge::ToSWIGWrapper(std::move(debugger)), 
SWIGBridge::ToSWIGWrapper(args_impl),
 SWIGBridge::ToSWIGWrapper(exe_ctx_ref_sp), 
SWIGBridge::ToSWIGWrapper(cmd_retobj).obj());
 
+  if (PyErr_Occurred())
+cmd_retobj.SetStatus(eReturnStatusFailed);
+
   return true;
 }
 
diff --git 
a/lldb/test/API/commands/command/script/exception/TestCommandException.py 
b/lldb/test/API/commands/command/script/exception/TestCommandException.py
new file mode 100644
index 00..73484137d82b3e
--- /dev/null
+++ b/lldb/test/API/commands/command/script/exception/TestCommandException.py
@@ -0,0 +1,27 @@
+import os
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+
+
+class TestCase(TestBase):
+NO_DEBUG_INFO_TESTCASE = True
+
+def test(self):
+"""
+Check that a Python command, which raises an unhandled exception, has
+its status set to failed.
+"""
+command_path = os.path.join(self.getSourceDir(), "throw_command.py")
+self.runCmd(f"command script import {command_path}")
+
+with open(os.devnull, "w") as devnull:
+self.dbg.SetErrorFileHandle(devnull, False)
+result = lldb.SBCommandReturnObject()
+self.ci.HandleCommand("throw", result)
+
+self.assertEqual(
+result.GetStatus(),
+lldb.eReturnStatusFailed,
+"command unexpectedly succeeded",
+)
diff --git a/lldb/test/API/commands/command/script/exception/throw_command.py 
b/lldb/test/API/commands/command/script/exception/throw_command.py
new file mode 100644
index 00..7c4989850cb19a
--- /dev/null
+++ b/lldb/test/API/commands/command/script/exception/throw_command.py
@@ -0,0 +1,6 @@
+import lldb
+
+
+@lldb.command()
+def throw(debugger, cmd, ctx, result, _):
+raise Exception("command failed")

>From b64f5ac38b31a1098ca31183f2bfdae4a6069306 Mon Sep 17 00:00:00 2001
From: Dave Lee 
Date: Tue, 29 Oct 2024 09:37:32 -0700
Subject: [PATCH 2/2] Reset error file handle

---
 .../commands/command/script/exception/TestCommandException.py| 1 +
 1 file changed, 1 insertion(+)

diff --git 
a/lldb/test/API/commands/command/script/exception/TestCommandException.py 
b/lldb/test/API/commands/command/script/exception/TestCommandException.py
index 73484137d82b3e..6a673b7589d87e 100644
--- a/lldb/test/API/commands/command/script/exception/TestCommandException.py
+++ b/lldb/test/A

[Lldb-commits] [lldb] [lldb] Set return status to Failed when Python command raises uncaught exception (PR #113996)

[Dave Lee via lldb-commits]

@@ -0,0 +1,27 @@
+import os

kastiglione wrote:

What are the issues with a new file?

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

[Lldb-commits] [lldb] [lldb] Use Py_InitializeFromConfig with Python >= 3.8 (NFC) (PR #114112)

[via lldb-commits]

github-actions[bot] wrote:




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



You can test this locally with the following command:


``bash
git-clang-format --diff 2ab98dfe19ac384f0cfac1a1fafc56b9dd7ad9b7 
c58438160c016841c6a72e53cd5c4985ebd1e521 --extensions cpp -- 
lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
``





View the diff from clang-format here.


``diff
diff --git 
a/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp 
b/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
index d7734c5e19..cde1e707cd 100644
--- a/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
+++ b/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
@@ -149,10 +149,10 @@ public:
 }
 
 #if (PY_MAJOR_VERSION == 3 && PY_MINOR_VERSION >= 8) || (PY_MAJOR_VERSION > 3)
-  config.install_signal_handlers = 0;
-  Py_InitializeFromConfig(&config);
-  PyConfig_Clear(&config);
-  InitializeThreadsPrivate();
+config.install_signal_handlers = 0;
+Py_InitializeFromConfig(&config);
+PyConfig_Clear(&config);
+InitializeThreadsPrivate();
 #else
 // Python < 3.2 and Python >= 3.2 reversed the ordering requirements for
 // calling `Py_Initialize` and `PyEval_InitThreads`.  < 3.2 requires that you
@@ -180,7 +180,6 @@ public:
   }
 
 private:
-
   void InitializeThreadsPrivate() {
 // Since Python 3.7 `Py_Initialize` calls `PyEval_InitThreads` inside itself,
 // so there is no way to determine whether the embedded interpreter

``




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

[Lldb-commits] [lldb] [lldb] Use Py_InitializeFromConfig with Python >= 3.8 (NFC) (PR #114112)

[via lldb-commits]

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Jonas Devlieghere (JDevlieghere)


Changes

This fixes the deprecation warning for Py_SetPythonHome, which was deprecated 
in Python 3.11. With this patch, when building against Python 3.8 or later, we 
now use Py_InitializeFromConfig instead.

Fixes #113475

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


1 Files Affected:

- (modified) 
lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp 
(+40-27) 


``diff
diff --git 
a/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp 
b/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
index 7cc38da6a6a94b..d7734c5e199058 100644
--- a/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
+++ b/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
@@ -92,7 +92,38 @@ namespace {
 struct InitializePythonRAII {
 public:
   InitializePythonRAII() {
-InitializePythonHome();
+#if (PY_MAJOR_VERSION == 3 && PY_MINOR_VERSION >= 8) || (PY_MAJOR_VERSION > 3)
+PyConfig config;
+PyConfig_InitPythonConfig(&config);
+#endif
+
+#if LLDB_EMBED_PYTHON_HOME
+typedef wchar_t *str_type;
+static str_type g_python_home = []() -> str_type {
+  const char *lldb_python_home = LLDB_PYTHON_HOME;
+  const char *absolute_python_home = nullptr;
+  llvm::SmallString<64> path;
+  if (llvm::sys::path::is_absolute(lldb_python_home)) {
+absolute_python_home = lldb_python_home;
+  } else {
+FileSpec spec = HostInfo::GetShlibDir();
+if (!spec)
+  return nullptr;
+spec.GetPath(path);
+llvm::sys::path::append(path, lldb_python_home);
+absolute_python_home = path.c_str();
+  }
+  size_t size = 0;
+  return Py_DecodeLocale(absolute_python_home, &size);
+}();
+if (g_python_home != nullptr) {
+#if (PY_MAJOR_VERSION == 3 && PY_MINOR_VERSION >= 8)
+  PyConfig_SetBytesString(&config, &config.home, g_python_home);
+#else
+  Py_SetPythonHome(g_python_home);
+#endif
+}
+#endif
 
 // The table of built-in modules can only be extended before Python is
 // initialized.
@@ -117,15 +148,22 @@ struct InitializePythonRAII {
   PyImport_AppendInittab("_lldb", LLDBSwigPyInit);
 }
 
+#if (PY_MAJOR_VERSION == 3 && PY_MINOR_VERSION >= 8) || (PY_MAJOR_VERSION > 3)
+  config.install_signal_handlers = 0;
+  Py_InitializeFromConfig(&config);
+  PyConfig_Clear(&config);
+  InitializeThreadsPrivate();
+#else
 // Python < 3.2 and Python >= 3.2 reversed the ordering requirements for
 // calling `Py_Initialize` and `PyEval_InitThreads`.  < 3.2 requires that you
 // call `PyEval_InitThreads` first, and >= 3.2 requires that you call it last.
-#if (PY_MAJOR_VERSION == 3 && PY_MINOR_VERSION >= 2) || (PY_MAJOR_VERSION > 3)
+#if (PY_MAJOR_VERSION == 3 && PY_MINOR_VERSION >= 2)
 Py_InitializeEx(0);
 InitializeThreadsPrivate();
 #else
 InitializeThreadsPrivate();
 Py_InitializeEx(0);
+#endif
 #endif
   }
 
@@ -142,31 +180,6 @@ struct InitializePythonRAII {
   }
 
 private:
-  void InitializePythonHome() {
-#if LLDB_EMBED_PYTHON_HOME
-typedef wchar_t *str_type;
-static str_type g_python_home = []() -> str_type {
-  const char *lldb_python_home = LLDB_PYTHON_HOME;
-  const char *absolute_python_home = nullptr;
-  llvm::SmallString<64> path;
-  if (llvm::sys::path::is_absolute(lldb_python_home)) {
-absolute_python_home = lldb_python_home;
-  } else {
-FileSpec spec = HostInfo::GetShlibDir();
-if (!spec)
-  return nullptr;
-spec.GetPath(path);
-llvm::sys::path::append(path, lldb_python_home);
-absolute_python_home = path.c_str();
-  }
-  size_t size = 0;
-  return Py_DecodeLocale(absolute_python_home, &size);
-}();
-if (g_python_home != nullptr) {
-  Py_SetPythonHome(g_python_home);
-}
-#endif
-  }
 
   void InitializeThreadsPrivate() {
 // Since Python 3.7 `Py_Initialize` calls `PyEval_InitThreads` inside itself,

``




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

[Lldb-commits] [lldb] [lldb] Use Py_InitializeFromConfig with Python >= 3.8 (NFC) (PR #114112)

[Jonas Devlieghere via lldb-commits]

JDevlieghere wrote:

CC @R-Goc

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

[Lldb-commits] [lldb] [llvm] [lldb] Fix write only file action to truncate the file (PR #112657)

[Alex Langford via lldb-commits]

@@ -6,6 +6,8 @@
 //
 
//===--===//
 
+#include 

bulbazord wrote:

CI is good enough for me here. I've approved the PR.

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

[Lldb-commits] [lldb] [llvm] [lldb] Fix write only file action to truncate the file (PR #112657)

[Alex Langford via lldb-commits]

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


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

[Lldb-commits] [lldb] efc6d33 - [lldb] Fix write only file action to truncate the file (#112657)

[via lldb-commits]

Author: Wanyi
Date: 2024-10-29T14:22:51-04:00
New Revision: efc6d33be9f4b4d0f0e8d3d5f198f2616b75792b

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

LOG: [lldb] Fix write only file action to truncate the file (#112657)

When `FileAction` opens file with write access, it doesn't clear the
file nor append to the end of the file if it already exists. Instead, it
writes from cursor index 0.

For example, by using the settings `target.output-path` and
`target.error-path`, lldb will redirect process stdout/stderr to files.
It then calls this function to write to the files which the above
symptoms appear.

## Test
- Added unit test checking the file flags
- Added 2 api tests checking
  - File content overwritten if the file path already exists
- Stdout and stderr redirection to the same file doesn't change its
behavior

Added: 


Modified: 
lldb/source/Host/common/FileAction.cpp
lldb/test/API/commands/settings/TestSettings.py
lldb/test/API/python_api/process/io/TestProcessIO.py
lldb/unittests/Host/FileActionTest.cpp
llvm/docs/ReleaseNotes.md

Removed: 




diff  --git a/lldb/source/Host/common/FileAction.cpp 
b/lldb/source/Host/common/FileAction.cpp
index f980d3224640e0..e1c3e14a165ea9 100644
--- a/lldb/source/Host/common/FileAction.cpp
+++ b/lldb/source/Host/common/FileAction.cpp
@@ -41,7 +41,7 @@ bool FileAction::Open(int fd, const FileSpec &file_spec, bool 
read,
 else if (read)
   m_arg = O_NOCTTY | O_RDONLY;
 else
-  m_arg = O_NOCTTY | O_CREAT | O_WRONLY;
+  m_arg = O_NOCTTY | O_CREAT | O_WRONLY | O_TRUNC;
 m_file_spec = file_spec;
 return true;
   } else {

diff  --git a/lldb/test/API/commands/settings/TestSettings.py 
b/lldb/test/API/commands/settings/TestSettings.py
index 385acceb7a8b5c..2dd813f6b155b3 100644
--- a/lldb/test/API/commands/settings/TestSettings.py
+++ b/lldb/test/API/commands/settings/TestSettings.py
@@ -528,6 +528,59 @@ def test_set_error_output_path(self):
 output, exe=False, startstr="This message should go to standard 
out."
 )
 
+@skipIfDarwinEmbedded  #  debugserver on ios etc 
can't write files
+def test_same_error_output_path(self):
+"""Test that setting target.error and output-path to the same file 
path for the launched process works."""
+self.build()
+
+exe = self.getBuildArtifact("a.out")
+self.runCmd("file " + exe, CURRENT_EXECUTABLE_SET)
+
+# Set the error-path and output-path and verify both are set.
+self.runCmd(
+"settings set target.error-path '{0}'".format(
+lldbutil.append_to_process_working_directory(self, 
"output.txt")
+)
+)
+self.runCmd(
+"settings set target.output-path '{0}".format(
+lldbutil.append_to_process_working_directory(self, 
"output.txt")
+)
+)
+# And add hooks to restore the original settings during tearDown().
+self.addTearDownHook(lambda: self.runCmd("settings clear 
target.output-path"))
+self.addTearDownHook(lambda: self.runCmd("settings clear 
target.error-path"))
+
+self.expect(
+"settings show target.error-path",
+SETTING_MSG("target.error-path"),
+substrs=["target.error-path (file)", 'output.txt"'],
+)
+
+self.expect(
+"settings show target.output-path",
+SETTING_MSG("target.output-path"),
+substrs=["target.output-path (file)", 'output.txt"'],
+)
+
+self.runCmd(
+"process launch --working-dir '{0}'".format(
+self.get_process_working_directory()
+),
+RUN_SUCCEEDED,
+)
+
+output = lldbutil.read_file_from_process_wd(self, "output.txt")
+err_message = "This message should go to standard error."
+out_message = "This message should go to standard out."
+# Error msg should get flushed by the output msg
+self.expect(output, exe=False, substrs=[out_message])
+self.assertNotIn(
+err_message,
+output,
+"Race condition when both stderr/stdout redirects to the same 
file",
+)
+
 def test_print_dictionary_setting(self):
 self.runCmd("settings clear target.env-vars")
 self.runCmd('settings set target.env-vars ["MY_VAR"]=some-value')

diff  --git a/lldb/test/API/python_api/process/io/TestProcessIO.py 
b/lldb/test/API/python_api/process/io/TestProcessIO.py
index 5bb91d2758312d..3b5c7c48c51f4d 100644
--- a/lldb/test/API/python_api/process/io/TestProcessIO.py
+++ b/lldb/test/API/python_api/process/io/TestProcessIO.py
@@ -95,6 +95,36 @@ def test_stdout_stderr_redirection(self):
 error = self.read_error_fil

[Lldb-commits] [lldb] [llvm] [lldb] Fix write only file action to truncate the file (PR #112657)

[via lldb-commits]

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

[Lldb-commits] [lldb] [lldb] Use Py_InitializeFromConfig with Python >= 3.8 (NFC) (PR #114112)

[Jonas Devlieghere via lldb-commits]

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

This fixes the deprecation warning for Py_SetPythonHome, which was deprecated 
in Python 3.11. With this patch, when building against Python 3.8 or later, we 
now use Py_InitializeFromConfig instead.

Fixes #113475

>From c58438160c016841c6a72e53cd5c4985ebd1e521 Mon Sep 17 00:00:00 2001
From: Jonas Devlieghere 
Date: Tue, 29 Oct 2024 11:19:33 -0700
Subject: [PATCH] [lldb] Use Py_InitializeFromConfig with Python >= 3.8 (NFC)

This fixes the deprecation warning for Py_SetPythonHome, which was
deprecated in Python 3.11. With this patch, when building against Python
3.8 or later, we now use Py_InitializeFromConfig instead.

Fixes #113475
---
 .../Python/ScriptInterpreterPython.cpp| 67 +++
 1 file changed, 40 insertions(+), 27 deletions(-)

diff --git 
a/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp 
b/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
index 7cc38da6a6a94b..d7734c5e199058 100644
--- a/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
+++ b/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
@@ -92,7 +92,38 @@ namespace {
 struct InitializePythonRAII {
 public:
   InitializePythonRAII() {
-InitializePythonHome();
+#if (PY_MAJOR_VERSION == 3 && PY_MINOR_VERSION >= 8) || (PY_MAJOR_VERSION > 3)
+PyConfig config;
+PyConfig_InitPythonConfig(&config);
+#endif
+
+#if LLDB_EMBED_PYTHON_HOME
+typedef wchar_t *str_type;
+static str_type g_python_home = []() -> str_type {
+  const char *lldb_python_home = LLDB_PYTHON_HOME;
+  const char *absolute_python_home = nullptr;
+  llvm::SmallString<64> path;
+  if (llvm::sys::path::is_absolute(lldb_python_home)) {
+absolute_python_home = lldb_python_home;
+  } else {
+FileSpec spec = HostInfo::GetShlibDir();
+if (!spec)
+  return nullptr;
+spec.GetPath(path);
+llvm::sys::path::append(path, lldb_python_home);
+absolute_python_home = path.c_str();
+  }
+  size_t size = 0;
+  return Py_DecodeLocale(absolute_python_home, &size);
+}();
+if (g_python_home != nullptr) {
+#if (PY_MAJOR_VERSION == 3 && PY_MINOR_VERSION >= 8)
+  PyConfig_SetBytesString(&config, &config.home, g_python_home);
+#else
+  Py_SetPythonHome(g_python_home);
+#endif
+}
+#endif
 
 // The table of built-in modules can only be extended before Python is
 // initialized.
@@ -117,15 +148,22 @@ struct InitializePythonRAII {
   PyImport_AppendInittab("_lldb", LLDBSwigPyInit);
 }
 
+#if (PY_MAJOR_VERSION == 3 && PY_MINOR_VERSION >= 8) || (PY_MAJOR_VERSION > 3)
+  config.install_signal_handlers = 0;
+  Py_InitializeFromConfig(&config);
+  PyConfig_Clear(&config);
+  InitializeThreadsPrivate();
+#else
 // Python < 3.2 and Python >= 3.2 reversed the ordering requirements for
 // calling `Py_Initialize` and `PyEval_InitThreads`.  < 3.2 requires that you
 // call `PyEval_InitThreads` first, and >= 3.2 requires that you call it last.
-#if (PY_MAJOR_VERSION == 3 && PY_MINOR_VERSION >= 2) || (PY_MAJOR_VERSION > 3)
+#if (PY_MAJOR_VERSION == 3 && PY_MINOR_VERSION >= 2)
 Py_InitializeEx(0);
 InitializeThreadsPrivate();
 #else
 InitializeThreadsPrivate();
 Py_InitializeEx(0);
+#endif
 #endif
   }
 
@@ -142,31 +180,6 @@ struct InitializePythonRAII {
   }
 
 private:
-  void InitializePythonHome() {
-#if LLDB_EMBED_PYTHON_HOME
-typedef wchar_t *str_type;
-static str_type g_python_home = []() -> str_type {
-  const char *lldb_python_home = LLDB_PYTHON_HOME;
-  const char *absolute_python_home = nullptr;
-  llvm::SmallString<64> path;
-  if (llvm::sys::path::is_absolute(lldb_python_home)) {
-absolute_python_home = lldb_python_home;
-  } else {
-FileSpec spec = HostInfo::GetShlibDir();
-if (!spec)
-  return nullptr;
-spec.GetPath(path);
-llvm::sys::path::append(path, lldb_python_home);
-absolute_python_home = path.c_str();
-  }
-  size_t size = 0;
-  return Py_DecodeLocale(absolute_python_home, &size);
-}();
-if (g_python_home != nullptr) {
-  Py_SetPythonHome(g_python_home);
-}
-#endif
-  }
 
   void InitializeThreadsPrivate() {
 // Since Python 3.7 `Py_Initialize` calls `PyEval_InitThreads` inside itself,

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

[Lldb-commits] [lldb] [lldb] Lookup static const members in FindGlobalVariables (PR #111859)

[Ilia Kuklin via lldb-commits]

@@ -3490,7 +3490,7 @@ VariableSP SymbolFileDWARF::ParseVariableDIE(const 
SymbolContext &sc,
   ModuleSP module = GetObjectFile()->GetModule();
 
   if (tag != DW_TAG_variable && tag != DW_TAG_constant &&
-  (tag != DW_TAG_formal_parameter || !sc.function))
+  tag != DW_TAG_member && (tag != DW_TAG_formal_parameter || !sc.function))

kuilpd wrote:

Added an assert, but maybe I should just add that as a condition for detecting 
a `static const` member to begin with?

https://github.com/llvm/llvm-project/pull/111859
___
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's helper for Unicode conversion (NFC) (PR #112582)

[Jonas Devlieghere via lldb-commits]

JDevlieghere wrote:

Friendly ping

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

[Lldb-commits] [lldb] [lldb] Search main function with lldb::eFunctionNameTypeFull when getting default file and line. (PR #113980)

[Jonas Devlieghere via lldb-commits]

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

🥳

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

[Lldb-commits] [libcxx] [lldb] [lldb][libc++] Hide all libc++ implementation details from stacktraces (PR #108870)

[Felipe de Azevedo Piovezan via lldb-commits]

felipepiovezan wrote:

Hi @vogelsgesang , the test you added on this PR breaks the LLDB matrix bot, in 
particular it breaks the 15 & 17 clang tests. Could you add a `skipIf` 
annotation if this test is only supposed to pass when working with newer 
versions of libcxx/clang? 
https://green.lab.llvm.org/job/llvm.org/view/LLDB/job/lldb-cmake-matrix/912/execution/node/107/log/

15 error:
```
/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/test/API/lang/cpp/libcxx-internals-recognizer/main.cpp:29:3:
 error: no member named 'sort' in namespace 'std::ranges'; did you mean 
'std::sort'?
  std::ranges::sort(vec.begin(), vec.end(), ranges_sort_less);
  ^
  std::sort
/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/clang_1501_build/include/c++/v1/__algorithm/sort.h:693:6:
 note: 'std::sort' declared here
void sort(_RandomAccessIterator __first, _RandomAccessIterator __last, _Comp 
__comp) {
 ^
/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/test/API/lang/cpp/libcxx-internals-recognizer/main.cpp:32:36:
 error: no member named 'views' in namespace 'std::ranges'
  for (auto x : vec | std::ranges::views::transform(view_transform)) {
  ~^
2 errors generated.
make: *** [main.o] Error 1

```

17 error:

```
FAIL: test_frame_recognizer 
(TestLibcxxInternalsRecognizer.LibCxxInternalsRecognizerTestCase)
   Test that implementation details of libc++ are hidden
--
Traceback (most recent call last):
  File 
"/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/test/API/lang/cpp/libcxx-internals-recognizer/TestLibcxxInternalsRecognizer.py",
 line 60, in test_frame_recognizer
self.assertIn(
AssertionError: 'ranges::__sort::operator()' not found in 
'std::__1::__wrap_iter 
std::__1::ranges::__sort::__fn::operator()[abi:ue170006],
 std::__1::__wrap_iter, bool (*)(int, int), 
std::__1::identity>(std::__1::__wrap_iter, std::__1::__wrap_iter, 
bool (*)(int, int), std::__1::identity) const'
Config=x86_64-/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/clang_1706_build/bin/clang
```


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

[Lldb-commits] [lldb] [lldb] Lookup static const members in FindGlobalVariables (PR #111859)

[Ilia Kuklin via lldb-commits]

https://github.com/kuilpd updated 
https://github.com/llvm/llvm-project/pull/111859

>From 4c394ec162b58b3cde3af924a5e9be1de8250a07 Mon Sep 17 00:00:00 2001
From: Ilia Kuklin 
Date: Tue, 30 Jul 2024 17:02:10 +0500
Subject: [PATCH 1/4] [lldb] Lookup static const members in FindGlobalVariables

Static const members initialized inside a class definition might not have a 
corresponding DW_TAG_variable (DWARF 4 and earlier), so they're not indexed by 
ManualDWARFIndex.

Add an additional lookup in FindGlobalVariables. Try looking up the enclosing 
type (e.g. foo::bar for foo::bar::A) and then searching for a static const 
member (A) within this type.
---
 .../SymbolFile/DWARF/SymbolFileDWARF.cpp  | 130 ++
 .../SymbolFile/DWARF/SymbolFileDWARF.h|   3 +
 .../API/python_api/frame/globals/Makefile |   4 +
 .../frame/globals/TestTargetGlobals.py|  43 ++
 .../API/python_api/frame/globals/main.cpp |  12 ++
 5 files changed, 192 insertions(+)
 create mode 100644 lldb/test/API/python_api/frame/globals/Makefile
 create mode 100644 lldb/test/API/python_api/frame/globals/TestTargetGlobals.py
 create mode 100644 lldb/test/API/python_api/frame/globals/main.cpp

diff --git a/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
index 9287d4baf19e9c..d53da79c1efcee 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
@@ -2439,6 +2439,48 @@ void SymbolFileDWARF::FindGlobalVariables(
 return variables.GetSize() - original_size < max_matches;
   });
 
+  // If we don't have enough matches and the variable context is not empty, try
+  // to resolve the context as a type and look for static const members.
+  if (variables.GetSize() - original_size < max_matches && !context.empty()) {
+llvm::StringRef type_name;
+if (std::optional parsed_name =
+Type::GetTypeScopeAndBasename(context))
+  type_name = parsed_name->basename;
+else
+  type_name = context;
+
+m_index->GetTypes(ConstString(type_name), [&](DWARFDIE parent) {
+  llvm::StringRef parent_type_name = parent.GetDWARFDeclContext()
+ .GetQualifiedNameAsConstString()
+ .GetStringRef();
+
+  // This type is from another scope, skip it.
+  if (!parent_type_name.ends_with(context))
+return true;
+
+  auto *dwarf_cu = llvm::dyn_cast(parent.GetCU());
+  if (!dwarf_cu)
+return true;
+
+  sc.comp_unit = GetCompUnitForDWARFCompUnit(*dwarf_cu);
+
+  for (DWARFDIE die = parent.GetFirstChild(); die.IsValid();
+   die = die.GetSibling()) {
+// Try parsing the entry as a static const member.
+if (auto var_sp = ParseStaticConstMemberDIE(sc, die)) {
+  if (var_sp->GetUnqualifiedName().GetStringRef() != basename)
+continue;
+
+  // There can be only one member with a given name.
+  variables.AddVariableIfUnique(var_sp);
+  break;
+}
+  }
+
+  return variables.GetSize() - original_size < max_matches;
+});
+  }
+
   // Return the number of variable that were appended to the list
   const uint32_t num_matches = variables.GetSize() - original_size;
   if (log && num_matches > 0) {
@@ -3371,6 +3413,94 @@ size_t SymbolFileDWARF::ParseVariablesForContext(const 
SymbolContext &sc) {
   return 0;
 }
 
+VariableSP SymbolFileDWARF::ParseStaticConstMemberDIE(
+const lldb_private::SymbolContext &sc, const DWARFDIE &die) {
+  if (die.GetDWARF() != this)
+return die.GetDWARF()->ParseStaticConstMemberDIE(sc, die);
+
+  // Look only for members, ignore all other types of entries.
+  if (die.Tag() != DW_TAG_member)
+return nullptr;
+
+  if (VariableSP var_sp = GetDIEToVariable()[die.GetDIE()])
+return var_sp; // Already been parsed!
+
+  const char *name = nullptr;
+  const char *mangled = nullptr;
+  Declaration decl;
+  DWARFExpression location;
+  DWARFFormValue type_die_form;
+  DWARFFormValue const_value_form;
+
+  DWARFAttributes attributes = die.GetAttributes();
+  const size_t num_attributes = attributes.Size();
+
+  for (size_t i = 0; i < num_attributes; ++i) {
+dw_attr_t attr = attributes.AttributeAtIndex(i);
+DWARFFormValue form_value;
+
+if (!attributes.ExtractFormValueAtIndex(i, form_value))
+  continue;
+
+switch (attr) {
+case DW_AT_decl_file:
+  decl.SetFile(sc.comp_unit->GetSupportFiles().GetFileSpecAtIndex(
+  form_value.Unsigned()));
+  break;
+case DW_AT_decl_line:
+  decl.SetLine(form_value.Unsigned());
+  break;
+case DW_AT_decl_column:
+  decl.SetColumn(form_value.Unsigned());
+  break;
+case DW_AT_name:
+  name = form_value.AsCString();
+  break;
+case DW_AT_type:
+  type_die_form = form_value;
+  break;
+case DW_AT_const_value:
+  const_

[Lldb-commits] [lldb] [lldb] Add a compiler/interpreter of LLDB data formatter bytecode to lldb/examples (PR #113398)

[Adrian Prantl via lldb-commits]

https://github.com/adrian-prantl updated 
https://github.com/llvm/llvm-project/pull/113398

>From 0b88de8fe7f5e4ea7f4089be403b271cd7b086d0 Mon Sep 17 00:00:00 2001
From: Adrian Prantl 
Date: Tue, 22 Oct 2024 16:29:50 -0700
Subject: [PATCH 1/2] Add a compiler/interpreter of LLDB data formatter
 bytecode to examples

---
 lldb/docs/index.rst   |   1 +
 lldb/docs/resources/formatterbytecode.rst | 221 
 lldb/examples/formatter-bytecode/Makefile |   8 +
 lldb/examples/formatter-bytecode/compiler.py  | 486 ++
 .../formatter-bytecode/test/MyOptional.cpp|  23 +
 .../formatter-bytecode/test/formatter.py  | 131 +
 6 files changed, 870 insertions(+)
 create mode 100644 lldb/docs/resources/formatterbytecode.rst
 create mode 100644 lldb/examples/formatter-bytecode/Makefile
 create mode 100644 lldb/examples/formatter-bytecode/compiler.py
 create mode 100644 lldb/examples/formatter-bytecode/test/MyOptional.cpp
 create mode 100644 lldb/examples/formatter-bytecode/test/formatter.py

diff --git a/lldb/docs/index.rst b/lldb/docs/index.rst
index e2c15d872b4be2..c3c2fb36eb541a 100644
--- a/lldb/docs/index.rst
+++ b/lldb/docs/index.rst
@@ -164,6 +164,7 @@ interesting areas to contribute to lldb.
resources/fuzzing
resources/sbapi
resources/dataformatters
+   resources/formatterbytecode
resources/extensions
resources/lldbgdbremote
resources/lldbplatformpackets
diff --git a/lldb/docs/resources/formatterbytecode.rst 
b/lldb/docs/resources/formatterbytecode.rst
new file mode 100644
index 00..e6a52a2bdddcdb
--- /dev/null
+++ b/lldb/docs/resources/formatterbytecode.rst
@@ -0,0 +1,221 @@
+Formatter Bytecode
+==
+
+Background
+--
+
+LLDB provides very rich customization options to display data types (see 
:doc:`/use/variable/`). To use custom data formatters, developers need to edit 
the global `~/.lldbinit` file to make sure they are found and loaded. In 
addition to this rather manual workflow, developers or library authors can ship 
ship data formatters with their code in a format that allows LLDB automatically 
find them and run them securely.
+
+An end-to-end example of such a workflow is the Swift `DebugDescription` macro 
(see https://www.swift.org/blog/announcing-swift-6/#debugging ) that translates 
Swift string interpolation into LLDB summary strings, and puts them into a 
`.lldbsummaries` section, where LLDB can find them.
+
+This document describes a minimal bytecode tailored to running LLDB 
formatters. It defines a human-readable assembler representation for the 
language, an efficient binary encoding, a virtual machine for evaluating it, 
and format for embedding formatters into binary containers.
+
+Goals
+~
+
+Provide an efficient and secure encoding for data formatters that can be used 
as a compilation target from user-friendly representations (such as DIL, Swift 
DebugDescription, or NatVis).
+
+Non-goals
+~
+
+While humans could write the assembler syntax, making it user-friendly is not 
a goal.
+
+Design of the virtual machine
+-
+
+The LLDB formatter virtual machine uses a stack-based bytecode, comparable 
with DWARF expressions, but with higher-level data types and functions.
+
+The virtual machine has two stacks, a data and a control stack. The control 
stack is kept separate to make it easier to reason about the security aspects 
of the virtual machine.
+
+Data types
+~~
+
+All objects on the data stack must have one of the following data types. These 
data types are "host" data types, in LLDB parlance.
+
+* *String* (UTF-8)
+* *Int* (64 bit)
+* *UInt* (64 bit)
+* *Object* (Basically an `SBValue`)
+* *Type* (Basically an `SBType`)
+* *Selector* (One of the predefine functions)
+
+*Object* and *Type* are opaque, they can only be used as a parameters of 
`call`.
+
+Instruction set
+---
+
+Stack operations
+
+
+These instructions manipulate the data stack directly.
+
+  ==  ===
+ OpcodeMnemonicStack effect  
+  --  ---
+ 0x00  `dup`   `(x -> x x)`  
+ 0x01  `drop`  `(x y -> x)`   
+ 0x02  `pick`  `(x ... UInt -> x ... x)`  
+ 0x03  `over`  `(x y -> x y x)`   
+ 0x04  `swap`  `(x y -> y x)` 
+ 0x05  `rot`   `(x y z -> z x y)` 
+===  ==  ===
+
+Control flow
+
+
+These manipulate the control stack and program counter.
+
+  ==  

+ OpcodeMnemonicDescription  
+  --  

+ 0x10   `{`push a code block address onto the control stack
+  --`}`(technically not an opcode) syntax for end

[Lldb-commits] [lldb] Improve namespace lookup using .debug_names parent chain (PR #110062)

[Greg Clayton via lldb-commits]

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


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

[Lldb-commits] [lldb] [lldb] Fix API test for file redirection to existing files (PR #114119)

[via lldb-commits]

https://github.com/kusmour created 
https://github.com/llvm/llvm-project/pull/114119

API test failed for remote debugging in 
[#112657](https://github.com/llvm/llvm-project/pull/112657)

Fixing it properly

>From dfa32524d1e6cac75471975de1e2a28225efce83 Mon Sep 17 00:00:00 2001
From: Wanyi Ye 
Date: Tue, 29 Oct 2024 12:50:28 -0700
Subject: [PATCH] [lldb] Fix API test for file redirection to existing files

---
 .../python_api/process/io/TestProcessIO.py| 40 +--
 1 file changed, 27 insertions(+), 13 deletions(-)

diff --git a/lldb/test/API/python_api/process/io/TestProcessIO.py 
b/lldb/test/API/python_api/process/io/TestProcessIO.py
index 3b5c7c48c51f4d..24cd845904cc2c 100644
--- a/lldb/test/API/python_api/process/io/TestProcessIO.py
+++ b/lldb/test/API/python_api/process/io/TestProcessIO.py
@@ -99,31 +99,45 @@ def test_stdout_stderr_redirection(self):
 @expectedFlakeyLinux(bugnumber="llvm.org/pr26437")
 @skipIfDarwinEmbedded  # debugserver can't create/write files on the device
 def test_stdout_stderr_redirection_to_existing_files(self):
-"""Exercise SBLaunchInfo::AddOpenFileAction() for STDOUT and STDERR 
without redirecting STDIN to output files already exist."""
+"""Exercise SBLaunchInfo::AddOpenFileAction() for STDOUT and STDERR 
redirect to output files already exist."""
 self.setup_test()
 self.build()
 self.create_target()
-self.write_file_with_placeholder(self.output_file)
-self.write_file_with_placeholder(self.error_file)
-self.redirect_stdout()
-self.redirect_stderr()
-self.run_process(True)
-output = self.read_output_file_and_delete()
-error = self.read_error_file_and_delete()
-self.check_process_output(output, error)
 
-def write_file_with_placeholder(self, target_file):
+# Create the output and error files with placeholder
 placeholder = "This content should be overwritten."
 if lldb.remote_platform:
+f = open(self.local_output_file, "w")
+f.write(placeholder)
+f.close()
+
+f = open(self.local_error_file, "w")
+f.write(placeholder)
+f.close()
+self.runCmd(
+'platform put-file "{local}" "{remote}"'.format(
+local=self.local_output_file, remote=self.output_file
+)
+)
 self.runCmd(
-'platform file write "{target}" -d "{data}"'.format(
-target=target_file, data=placeholder
+'platform put-file "{local}" "{remote}"'.format(
+local=self.local_error_file, remote=self.error_file
 )
 )
 else:
-f = open(target_file, "w")
+f = open(self.output_file, "w")
+f.write(placeholder)
+f.close()
+f = open(self.error_file, "w")
 f.write(placeholder)
 f.close()
+
+self.redirect_stdout()
+self.redirect_stderr()
+self.run_process(True)
+output = self.read_output_file_and_delete()
+error = self.read_error_file_and_delete()
+self.check_process_output(output, error)
 
 # target_file - path on local file system or remote file system if running 
remote
 # local_file - path on local system

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

[Lldb-commits] [lldb] [lldb] Set return status to Failed when Python command raises uncaught exception (PR #113996)

[Dave Lee via lldb-commits]

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

[Lldb-commits] [lldb] [lldb-dap] Always pass disableASLR to the DAP executable (PR #113891)

[Michael Buch via lldb-commits]

Michael137 wrote:

If we don't always want forward `disableASLR` we could instead flip the 
condition to:
```
if not disableASLR:
args_dict["disableASLR"] = disableASLR
```

Any thoughts?

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

[Lldb-commits] [lldb] [lldb] Set return status to Failed when Python command raises uncaught exception (PR #113996)

[David Spickett via lldb-commits]

@@ -0,0 +1,27 @@
+import os

DavidSpickett wrote:

A bit surprised we don't have a scripted commands test that this could be added 
to instead of making a new file.

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

[Lldb-commits] [lldb] [lldb] Set return status to Failed when Python command raises uncaught exception (PR #113996)

[David Spickett via lldb-commits]

@@ -0,0 +1,27 @@
+import os
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+
+
+class TestCase(TestBase):
+NO_DEBUG_INFO_TESTCASE = True
+
+def test(self):
+"""
+Check that a Python command, which raises an unhandled exception, has
+its status set to failed.
+"""
+command_path = os.path.join(self.getSourceDir(), "throw_command.py")
+self.runCmd(f"command script import {command_path}")
+
+with open(os.devnull, "w") as devnull:
+self.dbg.SetErrorFileHandle(devnull, False)

DavidSpickett wrote:

Should the context manager reset `self.dbg`'s error file handle after this or 
is `self.dbg` remade for every test?

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

[Lldb-commits] [lldb] Fix a couple of tests that were incorrectly using configuration.dwarf_version (PR #114161)

[via lldb-commits]

https://github.com/jimingham updated 
https://github.com/llvm/llvm-project/pull/114161

>From 7fe3b6ac2e32dcb3660affa422ae8909b11670e2 Mon Sep 17 00:00:00 2001
From: Jim Ingham 
Date: Tue, 29 Oct 2024 17:39:36 -0700
Subject: [PATCH 1/2] Fix a couple of tests that were incorrectly using

configuration.dwarf_version

directly to get the dwarf version used for the test.  That's
only the overridden value, and won't be set if we're using the
compiler default.  I also put a comment by the variable to make
sure people don't make the same mistake in the future.
---
 lldb/packages/Python/lldbsuite/test/configuration.py| 4 
 lldb/test/API/lang/cpp/namespace/TestNamespaceLookup.py | 4 ++--
 lldb/test/API/python_api/type/TestTypeList.py   | 4 ++--
 3 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/lldb/packages/Python/lldbsuite/test/configuration.py 
b/lldb/packages/Python/lldbsuite/test/configuration.py
index 1bacd74a968c31..bcc179346836d1 100644
--- a/lldb/packages/Python/lldbsuite/test/configuration.py
+++ b/lldb/packages/Python/lldbsuite/test/configuration.py
@@ -46,6 +46,10 @@
 make_path = None
 
 # The overriden dwarf verison.
+# Don't use this to test the current compiler's
+# DWARF version, as this won't be set if the
+# version isn't overridden.
+# Use lldbplatformutils.getDwarfVersion() instead.
 dwarf_version = 0
 
 # Any overridden settings.
diff --git a/lldb/test/API/lang/cpp/namespace/TestNamespaceLookup.py 
b/lldb/test/API/lang/cpp/namespace/TestNamespaceLookup.py
index b5e8115160d209..fbc8884a927fee 100644
--- a/lldb/test/API/lang/cpp/namespace/TestNamespaceLookup.py
+++ b/lldb/test/API/lang/cpp/namespace/TestNamespaceLookup.py
@@ -8,7 +8,7 @@
 from lldbsuite.test.decorators import *
 from lldbsuite.test.lldbtest import *
 from lldbsuite.test import lldbutil
-
+from lldbsuite.test import lldbplatformutil
 
 class NamespaceLookupTestCase(TestBase):
 def setUp(self):
@@ -167,7 +167,7 @@ def test_scope_lookup_with_run_command(self):
 self.runToBkpt("continue")
 # FIXME: In DWARF 5 with dsyms, the ordering of functions is slightly
 # different, which also hits the same issues mentioned previously.
-if configuration.dwarf_version <= 4 or self.getDebugInfo() == "dwarf":
+if int(lldbplatformutil.getDwarfVersion()) <= 4 or self.getDebugInfo() 
== "dwarf":
 self.expect_expr("func()", result_type="int", result_value="2")
 
 # Continue to BP_ns_scope at ns scope
diff --git a/lldb/test/API/python_api/type/TestTypeList.py 
b/lldb/test/API/python_api/type/TestTypeList.py
index bc4d00c17c5551..09879276b44aa3 100644
--- a/lldb/test/API/python_api/type/TestTypeList.py
+++ b/lldb/test/API/python_api/type/TestTypeList.py
@@ -6,7 +6,7 @@
 from lldbsuite.test.decorators import *
 from lldbsuite.test.lldbtest import *
 from lldbsuite.test import lldbutil
-
+from lldbsuite.test import lldbplatformutil
 
 class TypeAndTypeListTestCase(TestBase):
 def setUp(self):
@@ -248,7 +248,7 @@ def test(self):
 self.assertEqual(myint_arr_element_type, myint_type)
 
 # Test enum methods. Requires DW_AT_enum_class which was added in 
Dwarf 4.
-if configuration.dwarf_version >= 4:
+if int(lldbplatformutil.getDwarfVersion()) >= 4:
 enum_type = target.FindFirstType("EnumType")
 self.assertTrue(enum_type)
 self.DebugSBType(enum_type)

>From 2350fbcf70ac1fece3babf7ef1578f7cdc79c151 Mon Sep 17 00:00:00 2001
From: Jim Ingham 
Date: Tue, 29 Oct 2024 17:50:23 -0700
Subject: [PATCH 2/2] uglification

---
 lldb/test/API/lang/cpp/namespace/TestNamespaceLookup.py | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/lldb/test/API/lang/cpp/namespace/TestNamespaceLookup.py 
b/lldb/test/API/lang/cpp/namespace/TestNamespaceLookup.py
index fbc8884a927fee..41141164769ec2 100644
--- a/lldb/test/API/lang/cpp/namespace/TestNamespaceLookup.py
+++ b/lldb/test/API/lang/cpp/namespace/TestNamespaceLookup.py
@@ -167,7 +167,10 @@ def test_scope_lookup_with_run_command(self):
 self.runToBkpt("continue")
 # FIXME: In DWARF 5 with dsyms, the ordering of functions is slightly
 # different, which also hits the same issues mentioned previously.
-if int(lldbplatformutil.getDwarfVersion()) <= 4 or self.getDebugInfo() 
== "dwarf":
+if (
+int(lldbplatformutil.getDwarfVersion()) <= 4
+or self.getDebugInfo() == "dwarf"
+):
 self.expect_expr("func()", result_type="int", result_value="2")
 
 # Continue to BP_ns_scope at ns scope

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

[Lldb-commits] [lldb] [lldb][test] Skip `LibCxxInternalsRecognizerTestCase` on clang <= 17 (PR #114122)

[Michael Buch via lldb-commits]

Michael137 wrote:

Note that for the clang-15 failure you'll have to make sure we account for 
inline namespaces in the test assertion

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

[Lldb-commits] [lldb] Fix call site breakpoint patch (PR #114158)

[via lldb-commits]

https://github.com/jimingham updated 
https://github.com/llvm/llvm-project/pull/114158

>From 0695a7b57597fd08a802dbe4af06291ceb75d9f1 Mon Sep 17 00:00:00 2001
From: Jim Ingham 
Date: Mon, 28 Oct 2024 17:58:43 -0700
Subject: [PATCH 1/4] =?UTF-8?q?Revert=20"Revert=20"Add=20the=20ability=20t?=
 =?UTF-8?q?o=20break=20on=20call-site=20locations,=20improve=20inli?=
 =?UTF-8?q?=E2=80=A6=20(#113947)"?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

This reverts commit b54bc104ea87e301816b450ee117d2d864c7d82d.
---
 .../lldb/Breakpoint/BreakpointLocation.h  |  36 
 lldb/include/lldb/Breakpoint/BreakpointSite.h |   5 +
 lldb/include/lldb/Core/Declaration.h  |   6 +-
 lldb/include/lldb/Target/StopInfo.h   |  12 ++
 .../lldb/Target/ThreadPlanStepInRange.h   |   4 +-
 lldb/source/Breakpoint/BreakpointLocation.cpp |  63 ++-
 lldb/source/Breakpoint/BreakpointResolver.cpp |  15 ++
 lldb/source/Breakpoint/BreakpointSite.cpp |  17 ++
 lldb/source/Core/Declaration.cpp  |   5 +-
 lldb/source/Symbol/Block.cpp  |   2 +-
 lldb/source/Symbol/CompileUnit.cpp| 111 +++-
 lldb/source/Target/StackFrameList.cpp | 171 ++
 lldb/source/Target/StopInfo.cpp   |  55 ++
 lldb/source/Target/Thread.cpp |   8 +
 lldb/source/Target/ThreadPlanStepInRange.cpp  |  24 ++-
 .../source/Target/ThreadPlanStepOverRange.cpp |   2 +-
 .../inline-stepping/TestInlineStepping.py |  63 +++
 .../inline-stepping/calling.cpp   |  25 +++
 18 files changed, 493 insertions(+), 131 deletions(-)

diff --git a/lldb/include/lldb/Breakpoint/BreakpointLocation.h 
b/lldb/include/lldb/Breakpoint/BreakpointLocation.h
index cca00335bc3c67..3592291bb2d06e 100644
--- a/lldb/include/lldb/Breakpoint/BreakpointLocation.h
+++ b/lldb/include/lldb/Breakpoint/BreakpointLocation.h
@@ -11,10 +11,12 @@
 
 #include 
 #include 
+#include 
 
 #include "lldb/Breakpoint/BreakpointOptions.h"
 #include "lldb/Breakpoint/StoppointHitCounter.h"
 #include "lldb/Core/Address.h"
+#include "lldb/Symbol/LineEntry.h"
 #include "lldb/Utility/UserID.h"
 #include "lldb/lldb-private.h"
 
@@ -282,6 +284,25 @@ class BreakpointLocation
   /// Returns the breakpoint location ID.
   lldb::break_id_t GetID() const { return m_loc_id; }
 
+  /// Set the line entry that should be shown to users for this location.
+  /// It is up to the caller to verify that this is a valid entry to show.
+  /// The current use of this is to distinguish among line entries from a
+  /// virtual inlined call stack that all share the same address.
+  /// The line entry must have the same start address as the address for this
+  /// location.
+  bool SetPreferredLineEntry(const LineEntry &line_entry) {
+if (m_address == line_entry.range.GetBaseAddress()) {
+  m_preferred_line_entry = line_entry;
+  return true;
+}
+assert(0 && "Tried to set a preferred line entry with a different 
address");
+return false;
+  }
+
+  const std::optional GetPreferredLineEntry() {
+return m_preferred_line_entry;
+  }
+
 protected:
   friend class BreakpointSite;
   friend class BreakpointLocationList;
@@ -306,6 +327,16 @@ class BreakpointLocation
   /// If it returns false we should continue, otherwise stop.
   bool IgnoreCountShouldStop();
 
+  /// If this location knows that the virtual stack frame it represents is
+  /// not frame 0, return the suggested stack frame instead.  This will happen
+  /// when the location's address contains a "virtual inlined call stack" and
+  /// the breakpoint was set on a file & line that are not at the bottom of 
that
+  /// stack.  For now we key off the "preferred line entry" - looking for that
+  /// in the blocks that start with the stop PC.
+  /// This version of the API doesn't take an "inlined" parameter because it
+  /// only changes frames in the inline stack.
+  std::optional GetSuggestedStackFrameIndex();
+
 private:
   void SwapLocation(lldb::BreakpointLocationSP swap_from);
 
@@ -369,6 +400,11 @@ class BreakpointLocation
   lldb::break_id_t m_loc_id; ///< Breakpoint location ID.
   StoppointHitCounter m_hit_counter; ///< Number of times this breakpoint
  /// location has been hit.
+  /// If this exists, use it to print the stop description rather than the
+  /// LineEntry m_address resolves to directly.  Use this for instance when the
+  /// location was given somewhere in the virtual inlined call stack since the
+  /// Address always resolves to the lowest entry in the stack.
+  std::optional m_preferred_line_entry;
 
   void SetShouldResolveIndirectFunctions(bool do_resolve) {
 m_should_resolve_indirect_functions = do_resolve;
diff --git a/lldb/include/lldb/Breakpoint/BreakpointSite.h 
b/lldb/include/lldb/Breakpoint/BreakpointSite.h
index 17b76d51c1ae53..7b3f7be23639f2 100644
--- a/lldb/include/lldb/Breakpoint/BreakpointSite.h
+++ b/lldb/i

[Lldb-commits] [lldb] [LLDB] Finish implementing support for DW_FORM_data16 (PR #113508)

[Walter Erquinigo via lldb-commits]

walter-erquinigo wrote:

Friendly ping, otherwise I'll merge it in a couple of days

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

[Lldb-commits] [lldb] Fix call site breakpoint patch (PR #114158)

[via lldb-commits]

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: None (jimingham)


Changes

This fixes the two test suite failures that I missed in the PR:

https://github.com/llvm/llvm-project/pull/112939

One was a poorly written test case - it assumed that on connect to a gdb-remote 
with a running process, lldb MUST have fetched all the frame 0 registers.  In 
fact, there's no need for it to do so (as the CallSite patch showed...) and if 
we don't need to we shouldn't.  So I fixed the test to only expect a `g` packet 
AFTER calling read_registers.

The other was a place where some code had used 0 when it meant 
LLDB_INVALID_LINE_NUMBER, which I had fixed but missed one place where it was 
still compared to 0.

---

Patch is 43.37 KiB, truncated to 20.00 KiB below, full version: 
https://github.com/llvm/llvm-project/pull/114158.diff


19 Files Affected:

- (modified) lldb/include/lldb/Breakpoint/BreakpointLocation.h (+36) 
- (modified) lldb/include/lldb/Breakpoint/BreakpointSite.h (+5) 
- (modified) lldb/include/lldb/Core/Declaration.h (+5-1) 
- (modified) lldb/include/lldb/Target/StopInfo.h (+12) 
- (modified) lldb/include/lldb/Target/ThreadPlanStepInRange.h (+2-2) 
- (modified) lldb/source/Breakpoint/BreakpointLocation.cpp (+61-2) 
- (modified) lldb/source/Breakpoint/BreakpointResolver.cpp (+15) 
- (modified) lldb/source/Breakpoint/BreakpointSite.cpp (+17) 
- (modified) lldb/source/Core/Declaration.cpp (+3-2) 
- (modified) lldb/source/Symbol/Block.cpp (+1-1) 
- (modified) lldb/source/Symbol/CompileUnit.cpp (+111-2) 
- (modified) lldb/source/Target/StackFrameList.cpp (+56-115) 
- (modified) lldb/source/Target/StopInfo.cpp (+55) 
- (modified) lldb/source/Target/Thread.cpp (+8) 
- (modified) lldb/source/Target/ThreadPlanStepInRange.cpp (+18-6) 
- (modified) lldb/source/Target/ThreadPlanStepOverRange.cpp (+1-1) 
- (modified) 
lldb/test/API/functionalities/gdb_remote_client/TestGDBRemoteClient.py (+24-4) 
- (modified) 
lldb/test/API/functionalities/inline-stepping/TestInlineStepping.py (+63) 
- (modified) lldb/test/API/functionalities/inline-stepping/calling.cpp (+25) 


``diff
diff --git a/lldb/include/lldb/Breakpoint/BreakpointLocation.h 
b/lldb/include/lldb/Breakpoint/BreakpointLocation.h
index cca00335bc3c67..3592291bb2d06e 100644
--- a/lldb/include/lldb/Breakpoint/BreakpointLocation.h
+++ b/lldb/include/lldb/Breakpoint/BreakpointLocation.h
@@ -11,10 +11,12 @@
 
 #include 
 #include 
+#include 
 
 #include "lldb/Breakpoint/BreakpointOptions.h"
 #include "lldb/Breakpoint/StoppointHitCounter.h"
 #include "lldb/Core/Address.h"
+#include "lldb/Symbol/LineEntry.h"
 #include "lldb/Utility/UserID.h"
 #include "lldb/lldb-private.h"
 
@@ -282,6 +284,25 @@ class BreakpointLocation
   /// Returns the breakpoint location ID.
   lldb::break_id_t GetID() const { return m_loc_id; }
 
+  /// Set the line entry that should be shown to users for this location.
+  /// It is up to the caller to verify that this is a valid entry to show.
+  /// The current use of this is to distinguish among line entries from a
+  /// virtual inlined call stack that all share the same address.
+  /// The line entry must have the same start address as the address for this
+  /// location.
+  bool SetPreferredLineEntry(const LineEntry &line_entry) {
+if (m_address == line_entry.range.GetBaseAddress()) {
+  m_preferred_line_entry = line_entry;
+  return true;
+}
+assert(0 && "Tried to set a preferred line entry with a different 
address");
+return false;
+  }
+
+  const std::optional GetPreferredLineEntry() {
+return m_preferred_line_entry;
+  }
+
 protected:
   friend class BreakpointSite;
   friend class BreakpointLocationList;
@@ -306,6 +327,16 @@ class BreakpointLocation
   /// If it returns false we should continue, otherwise stop.
   bool IgnoreCountShouldStop();
 
+  /// If this location knows that the virtual stack frame it represents is
+  /// not frame 0, return the suggested stack frame instead.  This will happen
+  /// when the location's address contains a "virtual inlined call stack" and
+  /// the breakpoint was set on a file & line that are not at the bottom of 
that
+  /// stack.  For now we key off the "preferred line entry" - looking for that
+  /// in the blocks that start with the stop PC.
+  /// This version of the API doesn't take an "inlined" parameter because it
+  /// only changes frames in the inline stack.
+  std::optional GetSuggestedStackFrameIndex();
+
 private:
   void SwapLocation(lldb::BreakpointLocationSP swap_from);
 
@@ -369,6 +400,11 @@ class BreakpointLocation
   lldb::break_id_t m_loc_id; ///< Breakpoint location ID.
   StoppointHitCounter m_hit_counter; ///< Number of times this breakpoint
  /// location has been hit.
+  /// If this exists, use it to print the stop description rather than the
+  /// LineEntry m_address resolves to directly.  Use this for instance when the
+  /// location was given somewhere in the virtual inlined call stack

[Lldb-commits] [lldb] 75b37c3 - [DWARF] Fix arity of DW_OP_bra (#114136)

[via lldb-commits]

Author: Jonas Devlieghere
Date: 2024-10-29T16:41:01-07:00
New Revision: 75b37c3191254d0c418058cb94c3a7922b7ba71e

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

LOG: [DWARF] Fix arity of DW_OP_bra (#114136)

Found by my proof-of-concept DWARF expression evaluator fuzzer.

Added: 


Modified: 
lldb/unittests/Expression/DWARFExpressionTest.cpp
llvm/include/llvm/BinaryFormat/Dwarf.def

Removed: 




diff  --git a/lldb/unittests/Expression/DWARFExpressionTest.cpp 
b/lldb/unittests/Expression/DWARFExpressionTest.cpp
index f9e0605fce29d6..fdc9bfae1876c5 100644
--- a/lldb/unittests/Expression/DWARFExpressionTest.cpp
+++ b/lldb/unittests/Expression/DWARFExpressionTest.cpp
@@ -181,6 +181,9 @@ TEST(DWARFExpression, DW_OP_bra) {
   }),
   // clang-format on
   llvm::HasValue(0x42));
+
+  EXPECT_THAT_ERROR(Evaluate({DW_OP_bra, 0x01, 0x00}).takeError(),
+llvm::Failed());
 }
 
 TEST(DWARFExpression, DW_OP_convert) {

diff  --git a/llvm/include/llvm/BinaryFormat/Dwarf.def 
b/llvm/include/llvm/BinaryFormat/Dwarf.def
index 9336f2a454ae47..0cbbbe823c06b5 100644
--- a/llvm/include/llvm/BinaryFormat/Dwarf.def
+++ b/llvm/include/llvm/BinaryFormat/Dwarf.def
@@ -728,7 +728,7 @@ HANDLE_DW_OP(0x24, shl, 0, 2, 2, DWARF)
 HANDLE_DW_OP(0x25, shr, 0, 2, 2, DWARF)
 HANDLE_DW_OP(0x26, shra, 0, 2, 2, DWARF)
 HANDLE_DW_OP(0x27, xor, 0, 2, 2, DWARF)
-HANDLE_DW_OP(0x28, bra, 1, 0, 2, DWARF)
+HANDLE_DW_OP(0x28, bra, 1, 1, 2, DWARF)
 HANDLE_DW_OP(0x29, eq, 0, 2, 2, DWARF)
 HANDLE_DW_OP(0x2a, ge, 0, 2, 2, DWARF)
 HANDLE_DW_OP(0x2b, gt, 0, 2, 2, DWARF)



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

[Lldb-commits] [lldb] [LLDB] Add a target.launch-working-dir setting (PR #113521)

[Walter Erquinigo via lldb-commits]

walter-erquinigo wrote:

Friendly ping, otherwise I'll merge it in a couple of days

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

[Lldb-commits] [lldb] 62ff85f - [lldb-dap] Fix for missing 'raw_string_ostream::flush' removal in ProgressEvent.cpp; addressing #108745 (#114087)

[via lldb-commits]

Author: Santhosh Kumar Ellendula
Date: 2024-10-30T10:50:59+05:30
New Revision: 62ff85f0799560b42754ef77b5f64ca2c7feeff7

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

LOG: [lldb-dap] Fix for missing 'raw_string_ostream::flush' removal in 
ProgressEvent.cpp; addressing #108745 (#114087)

I hope it was missed unintentionally, pushing the same for the review.
Ref: https://github.com/llvm/llvm-project/pull/108745

-

Co-authored-by: Santhosh Kumar Ellendula 
Co-authored-by: Santhosh Kumar Ellendula 

Added: 


Modified: 
lldb/tools/lldb-dap/ProgressEvent.cpp

Removed: 




diff  --git a/lldb/tools/lldb-dap/ProgressEvent.cpp 
b/lldb/tools/lldb-dap/ProgressEvent.cpp
index 8a660b50af1205..0dcc2ee81001d5 100644
--- a/lldb/tools/lldb-dap/ProgressEvent.cpp
+++ b/lldb/tools/lldb-dap/ProgressEvent.cpp
@@ -110,7 +110,6 @@ json::Value ProgressEvent::ToJSON() const {
   std::string progress_id_str;
   llvm::raw_string_ostream progress_id_strm(progress_id_str);
   progress_id_strm << m_progress_id;
-  progress_id_strm.flush();
   body.try_emplace("progressId", progress_id_str);
 
   if (m_event_type == progressStart) {



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

[Lldb-commits] [lldb] [lldb-dap] Fix for missing 'raw_string_ostream::flush' removal in ProgressEvent.cpp; addressing #108745 (PR #114087)

[Santhosh Kumar Ellendula via lldb-commits]

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