[Lldb-commits] [lldb] [llvm] [lldb][RISCV] function calls support in lldb expressions (PR #99336)

2024-09-19 Thread David Spickett via lldb-commits

DavidSpickett wrote:

Reminder to update the PR description now that the large code model has been 
implemented over in llvm.

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


[Lldb-commits] [lldb] [lldb-dap][docs] Improve README (PR #109266)

2024-09-19 Thread Adrian Vogelsgesang via lldb-commits

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

>From 006f7cbe4aa1621b9490ae534ea6e17f56e3f6af Mon Sep 17 00:00:00 2001
From: Adrian Vogelsgesang 
Date: Thu, 19 Sep 2024 11:45:29 +0200
Subject: [PATCH] [lldb-dap][docs] Improve README

* Document how to procure and configure the `lldb-dap` binary
* Improve documentation for `launch.json`:
   * Show the examples before the reference. Most new users just want to
 get going, and will only need the reference later on
   * Deduplicate the list of "launch" and "attach" config settings
   * Remove the `stopOnEntry` setting from "attach", since this is a
 launch-only setting
   * Document the previously undocumented settings `sourcePath`,
 `commandEscapePrefix`, `custom{Frame,Thread}Format`,
 `runInTerminal`
   * Add the settings `debuggerRoot` and `sourceMap` to the common
 section. So far they were documented as launch-only settings.
* Document that the Debug Console prints variables / expressions by
  default and that LLDB commands need to be escaped.
---
 lldb/tools/lldb-dap/README.md | 150 +++---
 1 file changed, 86 insertions(+), 64 deletions(-)

diff --git a/lldb/tools/lldb-dap/README.md b/lldb/tools/lldb-dap/README.md
index 11a14d29ab51e2..f757c25fa3ab2c 100644
--- a/lldb/tools/lldb-dap/README.md
+++ b/lldb/tools/lldb-dap/README.md
@@ -1,71 +1,30 @@
 # LLDB DAP
 
-## `lldb-dap` Configurations
+## Procuring the `lldb-dap` binary
 
-The extension requires the `lldb-dap` (formerly `lldb-vscode`) binary. It is a
-command line tool that implements the [Debug Adapter
-Protocol](https://microsoft.github.io/debug-adapter-protocol/). It is used to 
power the Visual Studio Code extension but can also be used with other IDEs and 
editors that support DAP.
-The protocol is easy to run remotely and also can allow other tools and IDEs to
-get a full featured debugger with a well defined protocol.
+The extension requires the `lldb-dap` (formerly `lldb-vscode`) binary.
+This binary is not currently packaged with the VS-Code extension. 
 
-## Launching & Attaching Configuration
+There are multiple ways to obtain this binary:
+* build it from source (see [LLDB's build 
instructions](https://lldb.llvm.org/resources/build.html))
+* download it one of the relase packages from the [LLVM release 
page](https://github.com/llvm/llvm-project/releases/). The 
`LLVM-19.1.0-{operating_system}.tar.xz` packages contain a prebuilt `lldb-dap` 
binary.
+* contact your toolchain vendor
 
-Launching to attaching require you to create a [launch 
configuration](https://code.visualstudio.com/Docs/editor/debugging#_launch-configurations).
-This file defines arguments that get passed to `lldb-dap` and the 
configuration settings control how the launch or attach happens.
-
-### Launch Configuration Settings
-
-When you launch a program with Visual Studio Code you will need to create a 
[launch.json](https://code.visualstudio.com/Docs/editor/debugging#_launch-configurations)
-file that defines how your program will be run. The JSON configuration file 
can contain the following `lldb-dap` specific launch key/value pairs:
-
-|parameter  |type|req | |
-|---||:--:|-|
-|**name**   |string|Y| A configuration name that will be displayed in 
the IDE.
-|**type**   |string|Y| Must be "lldb-dap".
-|**request**|string|Y| Must be "launch".
-|**program**|string|Y| Path to the executable to launch.
-|**args**   |[string]|| An array of command line argument strings to 
be passed to the program being launched.
-|**cwd**|string| | The program working directory.
-|**env**|dictionary| | Environment variables to set when launching 
the program. The format of each environment variable string is "VAR=VALUE" for 
environment variables with values or just "VAR" for environment variables with 
no values.
-|**stopOnEntry**|boolean| | Whether to stop program immediately after 
launching.
-|**initCommands**   |[string]| | LLDB commands executed upon debugger startup 
prior to creating the LLDB target. Commands and command output will be sent to 
the debugger console when they are executed.
-|**preRunCommands** |[string]| | LLDB commands executed just before launching 
after the LLDB target has been created. Commands and command output will be 
sent to the debugger console when they are executed.
-|**stopCommands**   |[string]| | LLDB commands executed just after each stop. 
Commands and command output will be sent to the debugger console when they are 
executed.
-|**launchCommands** |[string]| | LLDB commands executed to launch the program. 
Commands and command output will be sent to the debugger console when they are 
executed.
-|**exitCommands**   |[string]| | LLDB commands executed when the program 
exits. Commands and command output will be sent to the debugger console when 
they are executed.
-|**terminateCommands** |[str

[Lldb-commits] [lldb] [lldb-dap][docs] Improve README (PR #109266)

2024-09-19 Thread via lldb-commits

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Adrian Vogelsgesang (vogelsgesang)


Changes

* Document how to procure and configure the `lldb-dap` binary
* Improve documentation for `launch.json`:
   * Show the examples before the reference. Most new users just want to get 
going, and will only need the reference later on
   * Deduplicate the list of "launch" and "attach" config settings
   * Remove the `stopOnEntry` setting from "attach", since this is a 
launch-only setting
   * Document the previously undocumented settings `sourcePath`, 
`commandEscapePrefix`, `custom{Frame,Thread}Format`, `runInTerminal`
   * Add the settings `debuggerRoot` and `sourceMap` to the common section. So 
far they were documented as launch-only settings.
* Document that the Debug Console prints variables / expressions by default and 
that LLDB commands need to be escaped.

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


1 Files Affected:

- (modified) lldb/tools/lldb-dap/README.md (+80-61) 


``diff
diff --git a/lldb/tools/lldb-dap/README.md b/lldb/tools/lldb-dap/README.md
index 11a14d29ab51e2..eddeab469d9345 100644
--- a/lldb/tools/lldb-dap/README.md
+++ b/lldb/tools/lldb-dap/README.md
@@ -1,71 +1,30 @@
 # LLDB DAP
 
-## `lldb-dap` Configurations
+## Procuring the `lldb-dap` binary
 
-The extension requires the `lldb-dap` (formerly `lldb-vscode`) binary. It is a
-command line tool that implements the [Debug Adapter
-Protocol](https://microsoft.github.io/debug-adapter-protocol/). It is used to 
power the Visual Studio Code extension but can also be used with other IDEs and 
editors that support DAP.
-The protocol is easy to run remotely and also can allow other tools and IDEs to
-get a full featured debugger with a well defined protocol.
+The extension requires the `lldb-dap` (formerly `lldb-vscode`) binary.
+This binary is not currently packaged with the VS-Code extension. 
 
-## Launching & Attaching Configuration
+There are multiple ways to obtain this binary:
+* build it from source (see [LLDB's build 
instructions](https://lldb.llvm.org/resources/build.html))
+* download it one of the relase packages from the [LLVM release 
page](https://github.com/llvm/llvm-project/releases/). The 
`LLVM-19.1.0-{operating_system}.tar.xz` packages contain a prebuilt `lldb-dap` 
binary.
+* contact your toolchain vendor
 
-Launching to attaching require you to create a [launch 
configuration](https://code.visualstudio.com/Docs/editor/debugging#_launch-configurations).
-This file defines arguments that get passed to `lldb-dap` and the 
configuration settings control how the launch or attach happens.
+By default, the VS-Code extension will expect to find `lldb-dap` in your 
`PATH`.
+Alternatively, you can explictly specify the location of the `lldb-dap` binary 
using the `lldb-dap.executable-path` setting.
 
-### Launch Configuration Settings
+### Usage with other editors
 
-When you launch a program with Visual Studio Code you will need to create a 
[launch.json](https://code.visualstudio.com/Docs/editor/debugging#_launch-configurations)
-file that defines how your program will be run. The JSON configuration file 
can contain the following `lldb-dap` specific launch key/value pairs:
+The `lldb-dap` binary is a command line tool that implements the [Debug 
Adapter Protocol](https://microsoft.github.io/debug-adapter-protocol/).
+It is used to power the Visual Studio Code extension but can also be used with 
other IDEs and editors that support DAP.
+The protocol is easy to run remotely and also can allow other tools and IDEs 
to get a full featured debugger with a well defined protocol.
 
-|parameter  |type|req | |
-|---||:--:|-|
-|**name**   |string|Y| A configuration name that will be displayed in 
the IDE.
-|**type**   |string|Y| Must be "lldb-dap".
-|**request**|string|Y| Must be "launch".
-|**program**|string|Y| Path to the executable to launch.
-|**args**   |[string]|| An array of command line argument strings to 
be passed to the program being launched.
-|**cwd**|string| | The program working directory.
-|**env**|dictionary| | Environment variables to set when launching 
the program. The format of each environment variable string is "VAR=VALUE" for 
environment variables with values or just "VAR" for environment variables with 
no values.
-|**stopOnEntry**|boolean| | Whether to stop program immediately after 
launching.
-|**initCommands**   |[string]| | LLDB commands executed upon debugger startup 
prior to creating the LLDB target. Commands and command output will be sent to 
the debugger console when they are executed.
-|**preRunCommands** |[string]| | LLDB commands executed just before launching 
after the LLDB target has been created. Commands and command output will be 
sent to the debugger console when they are executed.
-|**stopCommands**   |[string]| | LLDB commands executed jus

[Lldb-commits] [lldb] [lldb-dap][docs] Improve README (PR #109266)

2024-09-19 Thread Adrian Vogelsgesang via lldb-commits

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

* Document how to procure and configure the `lldb-dap` binary
* Improve documentation for `launch.json`:
   * Show the examples before the reference. Most new users just want to get 
going, and will only need the reference later on
   * Deduplicate the list of "launch" and "attach" config settings
   * Remove the `stopOnEntry` setting from "attach", since this is a 
launch-only setting
   * Document the previously undocumented settings `sourcePath`, 
`commandEscapePrefix`, `custom{Frame,Thread}Format`, `runInTerminal`
   * Add the settings `debuggerRoot` and `sourceMap` to the common section. So 
far they were documented as launch-only settings.
* Document that the Debug Console prints variables / expressions by default and 
that LLDB commands need to be escaped.

>From 02cd59cda789abbed42a26408cf05767cb2f8512 Mon Sep 17 00:00:00 2001
From: Adrian Vogelsgesang 
Date: Thu, 19 Sep 2024 11:45:29 +0200
Subject: [PATCH] [lldb-dap][docs] Improve README

* Document how to procure and configure the `lldb-dap` binary
* Improve documentation for `launch.json`:
   * Show the examples before the reference. Most new users just want to
 get going, and will only need the reference later on
   * Deduplicate the list of "launch" and "attach" config settings
   * Remove the `stopOnEntry` setting from "attach", since this is a
 launch-only setting
   * Document the previously undocumented settings `sourcePath`,
 `commandEscapePrefix`, `custom{Frame,Thread}Format`,
 `runInTerminal`
   * Add the settings `debuggerRoot` and `sourceMap` to the common
 section. So far they were documented as launch-only settings.
* Document that the Debug Console prints variables / expressions by
  default and that LLDB commands need to be escaped.
---
 lldb/tools/lldb-dap/README.md | 141 +++---
 1 file changed, 80 insertions(+), 61 deletions(-)

diff --git a/lldb/tools/lldb-dap/README.md b/lldb/tools/lldb-dap/README.md
index 11a14d29ab51e2..eddeab469d9345 100644
--- a/lldb/tools/lldb-dap/README.md
+++ b/lldb/tools/lldb-dap/README.md
@@ -1,71 +1,30 @@
 # LLDB DAP
 
-## `lldb-dap` Configurations
+## Procuring the `lldb-dap` binary
 
-The extension requires the `lldb-dap` (formerly `lldb-vscode`) binary. It is a
-command line tool that implements the [Debug Adapter
-Protocol](https://microsoft.github.io/debug-adapter-protocol/). It is used to 
power the Visual Studio Code extension but can also be used with other IDEs and 
editors that support DAP.
-The protocol is easy to run remotely and also can allow other tools and IDEs to
-get a full featured debugger with a well defined protocol.
+The extension requires the `lldb-dap` (formerly `lldb-vscode`) binary.
+This binary is not currently packaged with the VS-Code extension. 
 
-## Launching & Attaching Configuration
+There are multiple ways to obtain this binary:
+* build it from source (see [LLDB's build 
instructions](https://lldb.llvm.org/resources/build.html))
+* download it one of the relase packages from the [LLVM release 
page](https://github.com/llvm/llvm-project/releases/). The 
`LLVM-19.1.0-{operating_system}.tar.xz` packages contain a prebuilt `lldb-dap` 
binary.
+* contact your toolchain vendor
 
-Launching to attaching require you to create a [launch 
configuration](https://code.visualstudio.com/Docs/editor/debugging#_launch-configurations).
-This file defines arguments that get passed to `lldb-dap` and the 
configuration settings control how the launch or attach happens.
+By default, the VS-Code extension will expect to find `lldb-dap` in your 
`PATH`.
+Alternatively, you can explictly specify the location of the `lldb-dap` binary 
using the `lldb-dap.executable-path` setting.
 
-### Launch Configuration Settings
+### Usage with other editors
 
-When you launch a program with Visual Studio Code you will need to create a 
[launch.json](https://code.visualstudio.com/Docs/editor/debugging#_launch-configurations)
-file that defines how your program will be run. The JSON configuration file 
can contain the following `lldb-dap` specific launch key/value pairs:
+The `lldb-dap` binary is a command line tool that implements the [Debug 
Adapter Protocol](https://microsoft.github.io/debug-adapter-protocol/).
+It is used to power the Visual Studio Code extension but can also be used with 
other IDEs and editors that support DAP.
+The protocol is easy to run remotely and also can allow other tools and IDEs 
to get a full featured debugger with a well defined protocol.
 
-|parameter  |type|req | |
-|---||:--:|-|
-|**name**   |string|Y| A configuration name that will be displayed in 
the IDE.
-|**type**   |string|Y| Must be "lldb-dap".
-|**request**|string|Y| Must be "launch".
-|**program**|string|Y| Path to the executable to launch.
-|**args**   |[string]|| An array of command li

[Lldb-commits] [lldb] [lldb][FrameRecognizer] Display the first non-std frame on verbose_trap (PR #108825)

2024-09-19 Thread Michael Buch via lldb-commits

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


[Lldb-commits] [lldb] bca5073 - [lldb][FrameRecognizer] Display the first non-std frame on verbose_trap (#108825)

2024-09-19 Thread via lldb-commits

Author: Michael Buch
Date: 2024-09-19T10:06:28+01:00
New Revision: bca507387ae1945137214ec7fb80b709927ee6e8

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

LOG: [lldb][FrameRecognizer] Display the first non-std frame on verbose_trap 
(#108825)

This attempts to improve user-experience when LLDB stops on a
verbose_trap. Currently if a `__builtin_verbose_trap` triggers, we
display the first frame above the call to the verbose_trap. So in the
newly added test case, we would've previously stopped here:
```
(lldb) run
Process 28095 launched: '/Users/michaelbuch/a.out' (arm64)
Process 28095 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = Bounds error: 
out-of-bounds access
frame #1: 0x00013f5c 
a.out`std::__1::vector::operator[](this=0x00016fdfebef size=0, 
(null)=10) at verbose_trap.cpp:6:9
   3template 
   4struct vector {
   5void operator[](unsigned) {
-> 6__builtin_verbose_trap("Bounds error", "out-of-bounds access");
   7}
   8};
```

After this patch, we would stop in the first non-`std` frame:
```
(lldb) run
Process 27843 launched: '/Users/michaelbuch/a.out' (arm64)
Process 27843 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = Bounds error: 
out-of-bounds access
frame #2: 0x00013f44 a.out`g() at verbose_trap.cpp:14:5
   11  
   12   void g() {
   13   std::vector v;
-> 14   v[10];
   15   }
   16  
```

rdar://134490328

Added: 
lldb/test/Shell/Recognizer/Inputs/verbose_trap-in-stl-callback-user-leaf.cpp
lldb/test/Shell/Recognizer/Inputs/verbose_trap-in-stl-callback.cpp
lldb/test/Shell/Recognizer/Inputs/verbose_trap-in-stl-max-depth.cpp
lldb/test/Shell/Recognizer/Inputs/verbose_trap-in-stl-nested.cpp
lldb/test/Shell/Recognizer/Inputs/verbose_trap-in-stl.cpp
lldb/test/Shell/Recognizer/verbose_trap-in-stl-callback-user-leaf.test
lldb/test/Shell/Recognizer/verbose_trap-in-stl-callback.test
lldb/test/Shell/Recognizer/verbose_trap-in-stl-max-depth.test
lldb/test/Shell/Recognizer/verbose_trap-in-stl-nested.test
lldb/test/Shell/Recognizer/verbose_trap-in-stl.test

Modified: 
lldb/source/Target/VerboseTrapFrameRecognizer.cpp

Removed: 




diff  --git a/lldb/source/Target/VerboseTrapFrameRecognizer.cpp 
b/lldb/source/Target/VerboseTrapFrameRecognizer.cpp
index de710fcda54064..03ab58b8c59a9b 100644
--- a/lldb/source/Target/VerboseTrapFrameRecognizer.cpp
+++ b/lldb/source/Target/VerboseTrapFrameRecognizer.cpp
@@ -16,6 +16,39 @@ using namespace llvm;
 using namespace lldb;
 using namespace lldb_private;
 
+/// The 0th frame is the artificial inline frame generated to store
+/// the verbose_trap message. So, starting with the current parent frame,
+/// find the first frame that's not inside of the STL.
+static StackFrameSP FindMostRelevantFrame(Thread &selected_thread) {
+  // Defensive upper-bound of when we stop walking up the frames in
+  // case we somehow ended up looking at an infinite recursion.
+  const size_t max_stack_depth = 128;
+
+  // Start at parent frame.
+  size_t stack_idx = 1;
+  StackFrameSP most_relevant_frame_sp =
+  selected_thread.GetStackFrameAtIndex(stack_idx);
+
+  while (most_relevant_frame_sp && stack_idx <= max_stack_depth) {
+auto const &sc =
+most_relevant_frame_sp->GetSymbolContext(eSymbolContextEverything);
+ConstString frame_name = sc.GetFunctionName();
+if (!frame_name)
+  return nullptr;
+
+// Found a frame outside of the `std` namespace. That's the
+// first frame in user-code that ended up triggering the
+// verbose_trap. Hence that's the one we want to display.
+if (!frame_name.GetStringRef().starts_with("std::"))
+  return most_relevant_frame_sp;
+
+++stack_idx;
+most_relevant_frame_sp = selected_thread.GetStackFrameAtIndex(stack_idx);
+  }
+
+  return nullptr;
+}
+
 VerboseTrapRecognizedStackFrame::VerboseTrapRecognizedStackFrame(
 StackFrameSP most_relevant_frame_sp, std::string stop_desc)
 : m_most_relevant_frame(most_relevant_frame_sp) {
@@ -30,7 +63,7 @@ VerboseTrapFrameRecognizer::RecognizeFrame(lldb::StackFrameSP 
frame_sp) {
   ThreadSP thread_sp = frame_sp->GetThread();
   ProcessSP process_sp = thread_sp->GetProcess();
 
-  StackFrameSP most_relevant_frame_sp = thread_sp->GetStackFrameAtIndex(1);
+  StackFrameSP most_relevant_frame_sp = FindMostRelevantFrame(*thread_sp);
 
   if (!most_relevant_frame_sp) {
 Log *log = GetLog(LLDBLog::Unwind);

diff  --git 
a/lldb/test/Shell/Recognizer/Inputs/verbose_trap-in-stl-callback-user-leaf.cpp 
b/lldb/test/Shell/Recognizer/Inputs/verbose_trap-in-stl-callback-user-leaf.cpp
new file mode 100644
index 00..6c36682626a6ef
--- /dev/null
+++ 
b/lldb/test/Shell/Recognizer/Inp

[Lldb-commits] [lldb] [lldb][FrameRecognizer] Display the first non-std frame on verbose_trap (PR #108825)

2024-09-19 Thread Michael Buch via lldb-commits

https://github.com/Michael137 updated 
https://github.com/llvm/llvm-project/pull/108825

>From 729a0f69583c2c8ac597e68622231e4b719735b8 Mon Sep 17 00:00:00 2001
From: Michael Buch 
Date: Mon, 16 Sep 2024 14:10:46 +0100
Subject: [PATCH 1/3] [lldb][FrameRecognizer] Display the first non-std frame
 on verbose_trap

---
 .../Target/VerboseTrapFrameRecognizer.cpp | 27 ++-
 .../Inputs/verbose_trap-in-stl-callback.cpp   | 22 +++
 .../Inputs/verbose_trap-in-stl-nested.cpp | 21 +++
 .../Recognizer/Inputs/verbose_trap-in-stl.cpp | 17 
 .../verbose_trap-in-stl-callback.test | 13 +
 .../verbose_trap-in-stl-nested.test   | 13 +
 .../Shell/Recognizer/verbose_trap-in-stl.test | 13 +
 7 files changed, 125 insertions(+), 1 deletion(-)
 create mode 100644 
lldb/test/Shell/Recognizer/Inputs/verbose_trap-in-stl-callback.cpp
 create mode 100644 
lldb/test/Shell/Recognizer/Inputs/verbose_trap-in-stl-nested.cpp
 create mode 100644 lldb/test/Shell/Recognizer/Inputs/verbose_trap-in-stl.cpp
 create mode 100644 lldb/test/Shell/Recognizer/verbose_trap-in-stl-callback.test
 create mode 100644 lldb/test/Shell/Recognizer/verbose_trap-in-stl-nested.test
 create mode 100644 lldb/test/Shell/Recognizer/verbose_trap-in-stl.test

diff --git a/lldb/source/Target/VerboseTrapFrameRecognizer.cpp 
b/lldb/source/Target/VerboseTrapFrameRecognizer.cpp
index de710fcda54064..530a8941c8d504 100644
--- a/lldb/source/Target/VerboseTrapFrameRecognizer.cpp
+++ b/lldb/source/Target/VerboseTrapFrameRecognizer.cpp
@@ -16,6 +16,31 @@ using namespace llvm;
 using namespace lldb;
 using namespace lldb_private;
 
+/// The 0th frame is the artificial inline frame generated to store
+/// the verbose_trap message. So, starting with the current parent frame,
+/// find the first frame that's not inside of the STL.
+static StackFrameSP FindMostRelevantFrame(Thread &selected_thread) {
+  StackFrameSP most_relevant_frame_sp = 
selected_thread.GetStackFrameAtIndex(1);
+  while (most_relevant_frame_sp) {
+auto const &sc =
+most_relevant_frame_sp->GetSymbolContext(eSymbolContextEverything);
+ConstString frame_name = sc.GetFunctionName();
+if (!frame_name)
+  return nullptr;
+
+// Found a frame outside of the `std` namespace. That's the
+// first frame in user-code that ended up triggering the
+// verbose_trap. Hence that's the one we want to display.
+if (!frame_name.GetStringRef().starts_with("std::"))
+  return most_relevant_frame_sp;
+
+most_relevant_frame_sp = selected_thread.GetStackFrameAtIndex(
+most_relevant_frame_sp->GetFrameIndex() + 1);
+  }
+
+  return nullptr;
+}
+
 VerboseTrapRecognizedStackFrame::VerboseTrapRecognizedStackFrame(
 StackFrameSP most_relevant_frame_sp, std::string stop_desc)
 : m_most_relevant_frame(most_relevant_frame_sp) {
@@ -30,7 +55,7 @@ VerboseTrapFrameRecognizer::RecognizeFrame(lldb::StackFrameSP 
frame_sp) {
   ThreadSP thread_sp = frame_sp->GetThread();
   ProcessSP process_sp = thread_sp->GetProcess();
 
-  StackFrameSP most_relevant_frame_sp = thread_sp->GetStackFrameAtIndex(1);
+  StackFrameSP most_relevant_frame_sp = FindMostRelevantFrame(*thread_sp);
 
   if (!most_relevant_frame_sp) {
 Log *log = GetLog(LLDBLog::Unwind);
diff --git a/lldb/test/Shell/Recognizer/Inputs/verbose_trap-in-stl-callback.cpp 
b/lldb/test/Shell/Recognizer/Inputs/verbose_trap-in-stl-callback.cpp
new file mode 100644
index 00..23beed4c62c3b3
--- /dev/null
+++ b/lldb/test/Shell/Recognizer/Inputs/verbose_trap-in-stl-callback.cpp
@@ -0,0 +1,22 @@
+namespace std {
+void definitely_aborts() { __builtin_verbose_trap("Failed", "Invariant 
violated"); }
+
+void aborts_soon() { definitely_aborts(); }
+} // namespace std
+
+void g() { std::aborts_soon(); }
+
+namespace std {
+namespace detail {
+void eventually_aborts() { g(); }
+} // namespace detail
+
+inline namespace __1 {
+void eventually_aborts() { detail::eventually_aborts(); }
+} // namespace __1
+} // namespace std
+
+int main() {
+  std::eventually_aborts();
+  return 0;
+}
diff --git a/lldb/test/Shell/Recognizer/Inputs/verbose_trap-in-stl-nested.cpp 
b/lldb/test/Shell/Recognizer/Inputs/verbose_trap-in-stl-nested.cpp
new file mode 100644
index 00..67fa65c9ceae22
--- /dev/null
+++ b/lldb/test/Shell/Recognizer/Inputs/verbose_trap-in-stl-nested.cpp
@@ -0,0 +1,21 @@
+namespace std {
+namespace detail {
+void function_that_aborts() { __builtin_verbose_trap("Bounds error", 
"out-of-bounds access"); }
+} // namespace detail
+
+inline namespace __1 {
+template  struct vector {
+  void operator[](unsigned) { detail::function_that_aborts(); }
+};
+} // namespace __1
+} // namespace std
+
+void g() {
+  std::vector v;
+  v[10];
+}
+
+int main() {
+  g();
+  return 0;
+}
diff --git a/lldb/test/Shell/Recognizer/Inputs/verbose_trap-in-stl.cpp 
b/lldb/test/Shell/Recognizer/Inputs/verbose_trap-in-stl.cpp
new file mode 100644
index 0

[Lldb-commits] [lldb] [lldb/Interpreter] Add requirements to Scripted Interface abstract methods (PR #109063)

2024-09-18 Thread Med Ismail Bennani via lldb-commits

https://github.com/medismailben updated 
https://github.com/llvm/llvm-project/pull/109063

>From e815d5f65a23987d0f27849346610c1770094b6f Mon Sep 17 00:00:00 2001
From: Med Ismail Bennani 
Date: Wed, 18 Sep 2024 23:09:35 -0700
Subject: [PATCH] [lldb/Interpreter] Add requirements to Scripted Interface
 abstract methods

This patch adds new requirements to the Scripted Interface abstract
method checker to check the minimum number of argument for abstract
methods.

This check is done when creating the interface object so the object is
not created if the user implementation doesn't match the abstract method
requirement.

Signed-off-by: Med Ismail Bennani 
---
 .../Interfaces/ScriptedInterface.h|  17 ++-
 .../OperatingSystemPythonInterface.h  |   5 +-
 .../ScriptedPlatformPythonInterface.h |  11 +-
 .../ScriptedProcessPythonInterface.h  |   9 +-
 .../Interfaces/ScriptedPythonInterface.h  | 111 --
 .../ScriptedThreadPlanPythonInterface.h   |   3 +-
 .../ScriptedThreadPythonInterface.h   |   7 +-
 7 files changed, 112 insertions(+), 51 deletions(-)

diff --git a/lldb/include/lldb/Interpreter/Interfaces/ScriptedInterface.h 
b/lldb/include/lldb/Interpreter/Interfaces/ScriptedInterface.h
index 89c0b36d6fc2a1..a3dc52c435561f 100644
--- a/lldb/include/lldb/Interpreter/Interfaces/ScriptedInterface.h
+++ b/lldb/include/lldb/Interpreter/Interfaces/ScriptedInterface.h
@@ -31,7 +31,22 @@ class ScriptedInterface {
 return m_object_instance_sp;
   }
 
-  virtual llvm::SmallVector GetAbstractMethods() const = 
0;
+  struct AbstractMethodRequirement {
+llvm::StringLiteral name;
+size_t min_arg_count = 0;
+  };
+
+  virtual llvm::SmallVector
+  GetAbstractMethodRequirements() const = 0;
+
+  llvm::SmallVector const GetAbstractMethods() const {
+llvm::SmallVector abstract_methods;
+llvm::transform(GetAbstractMethodRequirements(), abstract_methods.begin(),
+[](const AbstractMethodRequirement &requirement) {
+  return requirement.name;
+});
+return abstract_methods;
+  }
 
   template 
   static Ret ErrorWithMessage(llvm::StringRef caller_name,
diff --git 
a/lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/OperatingSystemPythonInterface.h
 
b/lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/OperatingSystemPythonInterface.h
index 92358ac6c34f7e..102c3c39537686 100644
--- 
a/lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/OperatingSystemPythonInterface.h
+++ 
b/lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/OperatingSystemPythonInterface.h
@@ -31,8 +31,9 @@ class OperatingSystemPythonInterface
  StructuredData::DictionarySP args_sp,
  StructuredData::Generic *script_obj = nullptr) override;
 
-  llvm::SmallVector GetAbstractMethods() const override {
-return llvm::SmallVector({"get_thread_info"});
+  llvm::SmallVector
+  GetAbstractMethodRequirements() const override {
+return llvm::SmallVector({{"get_thread_info"}});
   }
 
   StructuredData::DictionarySP CreateThread(lldb::tid_t tid,
diff --git 
a/lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedPlatformPythonInterface.h
 
b/lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedPlatformPythonInterface.h
index 36a219a656993b..3031508f892322 100644
--- 
a/lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedPlatformPythonInterface.h
+++ 
b/lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedPlatformPythonInterface.h
@@ -29,10 +29,13 @@ class ScriptedPlatformPythonInterface : public 
ScriptedPlatformInterface,
  StructuredData::DictionarySP args_sp,
  StructuredData::Generic *script_obj = nullptr) override;
 
-  llvm::SmallVector GetAbstractMethods() const override {
-return llvm::SmallVector(
-{"list_processes", "attach_to_process", "launch_process",
- "kill_process"});
+  llvm::SmallVector
+  GetAbstractMethodRequirements() const override {
+return llvm::SmallVector(
+{{"list_processes"},
+ {"attach_to_process", 1},
+ {"launch_process", 1},
+ {"kill_process", 1}});
   }
 
   StructuredData::DictionarySP ListProcesses() override;
diff --git 
a/lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedProcessPythonInterface.h
 
b/lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedProcessPythonInterface.h
index 1535d573e72f43..fc645981b61b31 100644
--- 
a/lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedProcessPythonInterface.h
+++ 
b/lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedProcessPythonInterface.h
@@ -31,9 +31,12 @@ class ScriptedProcessPythonInterface : public 
ScriptedProcessInterface,
  StructuredData::DictionarySP args_sp,
  StructuredData::Generic *script_obj = nullptr) override;
 
-  llvm::SmallVector GetAbstract

[Lldb-commits] [lldb] [lldb] [debugserver] Use "full" x86_64 GPR state when available. (PR #108663)

2024-09-18 Thread via lldb-commits

github-actions[bot] wrote:



@mrpippy Congratulations on having your first Pull Request (PR) merged into the 
LLVM Project!

Your changes will be combined with recent changes from other authors, then 
tested by our [build bots](https://lab.llvm.org/buildbot/). If there is a 
problem with a build, you may receive a report in an email or a comment on this 
PR.

Please check whether problems have been caused by your change specifically, as 
the builds can include changes from many authors. It is not uncommon for your 
change to be included in a build that fails due to someone else's changes, or 
infrastructure issues.

How to do this, and the rest of the post-merge process, is covered in detail 
[here](https://llvm.org/docs/MyFirstTypoFix.html#myfirsttypofix-issues-after-landing-your-pr).

If your change does cause a problem, it may be reverted, or you can revert it 
yourself. This is a normal part of [LLVM 
development](https://llvm.org/docs/DeveloperPolicy.html#patch-reversion-policy).
 You can fix your changes and open a new PR to merge them again.

If you don't get any reports, no action is required from you. Your changes are 
working as expected, well done!


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


[Lldb-commits] [lldb] [lldb] [debugserver] Use "full" x86_64 GPR state when available. (PR #108663)

2024-09-18 Thread Jason Molenda via lldb-commits

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


[Lldb-commits] [lldb] 7281e0c - [lldb] [debugserver] Use "full" x86_64 GPR state when available. (#108663)

2024-09-18 Thread via lldb-commits

Author: Brendan Shanks
Date: 2024-09-18T22:57:01-07:00
New Revision: 7281e0cb3bbcce396aab8b3ea0967d7a17cd287a

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

LOG: [lldb] [debugserver] Use "full" x86_64 GPR state when available. (#108663)

macOS 10.15 added a "full" x86_64 GPR thread state flavor, equivalent to
the normal one but with DS, ES, SS, and GSbase added. This flavor can
only be used with processes that install a custom LDT (functionality
that was also added in 10.15 and is used by apps like Wine to execute
32-bit code).

Along with allowing DS, ES, SS, and GSbase to be viewed/modified, using
the full flavor is necessary when debugging a thread executing 32-bit
code.
If thread_set_state() is used with the regular thread state flavor, the
kernel resets CS to the 64-bit code segment (see
[set_thread_state64()](https://github.com/apple-oss-distributions/xnu/blob/94d3b452840153a99b38a3a9659680b2a006908e/osfmk/i386/pcb.c#L723),
which makes debugging impossible.

There's no way to detect whether the full flavor is available, try to
use it and fall back to the regular one if it's not available.

A downside is that this patch exposes the DS, ES, SS, and GSbase
registers for all x86_64 processes, even though they are not populated
unless the full thread state is available.
I'm not sure if there's a way to tell LLDB that a register is
unavailable. The classic GDB `g` command [allows returning
`x`](https://sourceware.org/gdb/current/onlinedocs/gdb.html/Packets.html#Packets)
to denote unavailable registers, but it seems like the debug server uses
newer commands like `jThreadsInfo` and I'm not sure if those have the
same support.

Fixes #57591
(also filed as Apple FB11464104)

@jasonmolenda

Added: 


Modified: 
lldb/tools/debugserver/source/MacOSX/x86_64/DNBArchImplX86_64.cpp
lldb/tools/debugserver/source/MacOSX/x86_64/DNBArchImplX86_64.h
lldb/tools/debugserver/source/MacOSX/x86_64/MachRegisterStatesX86_64.h

Removed: 




diff  --git a/lldb/tools/debugserver/source/MacOSX/x86_64/DNBArchImplX86_64.cpp 
b/lldb/tools/debugserver/source/MacOSX/x86_64/DNBArchImplX86_64.cpp
index 5a62e2a8d12e2c..3b3f1f02a2851f 100644
--- a/lldb/tools/debugserver/source/MacOSX/x86_64/DNBArchImplX86_64.cpp
+++ b/lldb/tools/debugserver/source/MacOSX/x86_64/DNBArchImplX86_64.cpp
@@ -182,22 +182,39 @@ kern_return_t DNBArchImplX86_64::GetGPRState(bool force) {
 m_state.context.gpr.__gs = ('g' << 8) + 's';
 m_state.SetError(e_regSetGPR, Read, 0);
 #else
-mach_msg_type_number_t count = e_regSetWordSizeGPR;
+mach_msg_type_number_t count = e_regSetWordSizeGPRFull;
+int flavor = __x86_64_THREAD_FULL_STATE;
 m_state.SetError(
 e_regSetGPR, Read,
-::thread_get_state(m_thread->MachPortNumber(), __x86_64_THREAD_STATE,
+::thread_get_state(m_thread->MachPortNumber(), flavor,
(thread_state_t)&m_state.context.gpr, &count));
+
+if (!m_state.GetError(e_regSetGPR, Read)) {
+  m_state.hasFullGPRState = true;
+} else {
+  m_state.hasFullGPRState = false;
+  count = e_regSetWordSizeGPR;
+  flavor = __x86_64_THREAD_STATE;
+  m_state.SetError(
+  e_regSetGPR, Read,
+  ::thread_get_state(m_thread->MachPortNumber(), flavor,
+ (thread_state_t)&m_state.context.gpr, &count));
+}
 DNBLogThreadedIf(
 LOG_THREAD,
-"::thread_get_state (0x%4.4x, %u, &gpr, %u) => 0x%8.8x"
+"::thread_get_state (0x%4.4x, %u (%s), &gpr, %u) => 0x%8.8x"
 "\n\trax = %16.16llx rbx = %16.16llx rcx = %16.16llx rdx = %16.16llx"
 "\n\trdi = %16.16llx rsi = %16.16llx rbp = %16.16llx rsp = %16.16llx"
 "\n\t r8 = %16.16llx  r9 = %16.16llx r10 = %16.16llx r11 = %16.16llx"
 "\n\tr12 = %16.16llx r13 = %16.16llx r14 = %16.16llx r15 = %16.16llx"
 "\n\trip = %16.16llx"
-"\n\tflg = %16.16llx  cs = %16.16llx  fs = %16.16llx  gs = %16.16llx",
-m_thread->MachPortNumber(), x86_THREAD_STATE64,
-x86_THREAD_STATE64_COUNT, m_state.GetError(e_regSetGPR, Read),
+"\n\tflg = %16.16llx  cs = %16.16llx  fs = %16.16llx  gs = %16.16llx"
+"\n\t ds = %16.16llx  es = %16.16llx  ss = %16.16llx gsB = %16.16llx",
+m_thread->MachPortNumber(), flavor,
+m_state.hasFullGPRState ? "full" : "non-full",
+m_state.hasFullGPRState ? e_regSetWordSizeGPRFull
+: e_regSetWordSizeGPR,
+m_state.GetError(e_regSetGPR, Read),
 m_state.context.gpr.__rax, m_state.context.gpr.__rbx,
 m_state.context.gpr.__rcx, m_state.context.gpr.__rdx,
 m_state.context.gpr.__rdi, m_state.context.gpr.__rsi,
@@ -208,7 +225,9 @@ kern_return_t DNBArchImplX86_64::GetGPRState(bool force) {

[Lldb-commits] [lldb] Add docs and an example use of the scripted command get_flags API. (PR #109176)

2024-09-18 Thread Med Ismail Bennani via lldb-commits

https://github.com/medismailben commented:

LGTM!

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


[Lldb-commits] [lldb] [lldb] Always emit diagnostic events to the system log (PR #90913)

2024-09-18 Thread Igor Kudrin via lldb-commits

igorkudrin wrote:

Hi @JDevlieghere,

This change causes diagnostic messages to be duplicated on Windows. For example:
```
> yaml2obj.exe lldb\test\Shell\ObjectFile\ELF\minidebuginfo-no-lzma.yaml -o 
> t.obj
> lldb-new.exe
(lldb) target create t.obj
(x86_64) C:\tmp\t.obj No LZMA support found for reading .gnu_debugdata warning: 
(x86_64) C:\tmp\t.obj No LZMA support found for reading .gnu_debugdata section
(lldb) Current executable set to 'C:\tmp\t.obj' (x86_64).
(lldb) q
```

Could you fix this?

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


[Lldb-commits] [lldb] Add docs and an example use of the scripted command get_flags API. (PR #109176)

2024-09-18 Thread via lldb-commits

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


[Lldb-commits] [lldb] 615bd9e - Add docs and an example use of the scripted command get_flags API. (#109176)

2024-09-18 Thread via lldb-commits

Author: jimingham
Date: 2024-09-18T18:10:43-07:00
New Revision: 615bd9ee60ca213d0e93a7ddc5c1bf48418952e9

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

LOG: Add docs and an example use of the scripted command get_flags API. 
(#109176)

The API is present, and we even have a test for it, but it isn't
documented so no one probably knows you can set requirements for your
scripted commands. This just adds docs and uses it appropriately in the
`framestats` example command.

Added: 


Modified: 
lldb/docs/use/python-reference.rst
lldb/examples/python/cmdtemplate.py

Removed: 




diff  --git a/lldb/docs/use/python-reference.rst 
b/lldb/docs/use/python-reference.rst
index 041e541a96f083..b12048f1af067d 100644
--- a/lldb/docs/use/python-reference.rst
+++ b/lldb/docs/use/python-reference.rst
@@ -562,6 +562,12 @@ which should implement the following interface:
   this call should return the short help text for this command[1]
   def get_long_help(self):
   this call should return the long help text for this command[1]
+  def get_flags(self):
+  this will be called when the command is added to the command 
interpreter,
+  and should return a flag field made from or-ing together the 
appropriate
+  elements of the lldb.CommandFlags enum to specify the requirements 
of this command.
+  The CommandInterpreter will make sure all these requirements are 
met, and will
+  return the standard lldb error if they are not.[1]
   def get_repeat_command(self, command):
   The auto-repeat command is what will get executed when the user 
types just
   a return at the next prompt after this command is run.  Even if your 
command

diff  --git a/lldb/examples/python/cmdtemplate.py 
b/lldb/examples/python/cmdtemplate.py
index 9a96888508b6f2..b6a21cba7113e6 100644
--- a/lldb/examples/python/cmdtemplate.py
+++ b/lldb/examples/python/cmdtemplate.py
@@ -25,6 +25,9 @@ def register_lldb_command(cls, debugger, module_name):
 '--help" for detailed help.'.format(cls.program)
 )
 
+def get_flags(self):
+return lldb.eCommandRequiresFrame | lldb.eCommandProcessMustBePaused
+
 def setup_command_definition(self):
 
 self.ov_parser.add_option(



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


[Lldb-commits] [lldb] [lldb][FrameRecognizer] Display the first non-std frame on verbose_trap (PR #108825)

2024-09-18 Thread Adrian Prantl via lldb-commits

https://github.com/adrian-prantl approved this pull request.


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


[Lldb-commits] [lldb] [lldb] Change the implementation of Status to store an llvm::Error (NFC) (PR #106774)

2024-09-18 Thread Adrian Prantl via lldb-commits

adrian-prantl wrote:

So I _thought_ I had understood this because I had simulated the missing ip6 
support on the bots inside of Socked::CreateSocket, but I still had failing 
unit tests at the end of the day so I reverted this again for now.

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


[Lldb-commits] [lldb] cb6d531 - Revert "[lldb] Change the implementation of Status to store an llvm::Error (NFC) (#106774)"

2024-09-18 Thread Adrian Prantl via lldb-commits

Author: Adrian Prantl
Date: 2024-09-18T17:28:10-07:00
New Revision: cb6d53198e39838ba6f9d2974c4f4317057d1556

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

LOG: Revert "[lldb] Change the implementation of Status to store an llvm::Error 
(NFC) (#106774)"

This reverts commit 06939fa2e140a171132275ec0ea1857d20c5dbdd.

Added: 


Modified: 
lldb/include/lldb/Utility/Status.h
lldb/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.cpp
lldb/source/Utility/Status.cpp
lldb/unittests/TestingSupport/Host/SocketTestUtilities.cpp
lldb/unittests/Utility/StatusTest.cpp

Removed: 




diff  --git a/lldb/include/lldb/Utility/Status.h 
b/lldb/include/lldb/Utility/Status.h
index 4a09c38ce62f1b..795c830b965173 100644
--- a/lldb/include/lldb/Utility/Status.h
+++ b/lldb/include/lldb/Utility/Status.h
@@ -28,69 +28,6 @@ namespace lldb_private {
 
 const char *ExpressionResultAsCString(lldb::ExpressionResults result);
 
-/// Going a bit against the spirit of llvm::Error,
-/// lldb_private::Status need to store errors long-term and sometimes
-/// copy them. This base class defines an interface for this
-/// operation.
-class CloneableError
-: public llvm::ErrorInfo {
-public:
-  using llvm::ErrorInfo::ErrorInfo;
-  CloneableError() : ErrorInfo() {}
-  virtual std::unique_ptr Clone() const = 0;
-  static char ID;
-};
-
-/// Common base class for all error-code errors.
-class CloneableECError
-: public llvm::ErrorInfo {
-public:
-  using llvm::ErrorInfo::ErrorInfo;
-  CloneableECError() = delete;
-  CloneableECError(std::error_code ec) : ErrorInfo(), EC(ec) {}
-  std::error_code convertToErrorCode() const override { return EC; }
-  void log(llvm::raw_ostream &OS) const override { OS << EC.message(); }
-  std::unique_ptr Clone() const override;
-  static char ID;
-
-protected:
-  std::error_code EC;
-};
-
-/// FIXME: Move these declarations closer to where they're used.
-class MachKernelError
-: public llvm::ErrorInfo {
-public:
-  using llvm::ErrorInfo::ErrorInfo;
-  MachKernelError(std::error_code ec) : ErrorInfo(ec) {}
-  std::string message() const override;
-  std::unique_ptr Clone() const override;
-  static char ID;
-};
-
-class Win32Error : public llvm::ErrorInfo {
-public:
-  using llvm::ErrorInfo::ErrorInfo;
-  Win32Error(std::error_code ec, const llvm::Twine &msg = {}) : ErrorInfo(ec) 
{}
-  std::string message() const override;
-  std::unique_ptr Clone() const override;
-  static char ID;
-};
-
-class ExpressionError
-: public llvm::ErrorInfo {
-public:
-  using llvm::ErrorInfo::ErrorInfo;
-  ExpressionError(std::error_code ec, std::string msg = {})
-  : ErrorInfo(ec), m_string(msg) {}
-  std::unique_ptr Clone() const override;
-  std::string message() const override { return m_string; }
-  static char ID;
-
-protected:
-  std::string m_string;
-};
-
 /// \class Status Status.h "lldb/Utility/Status.h" An error handling class.
 ///
 /// This class is designed to be able to hold any error code that can be
@@ -163,7 +100,9 @@ class Status {
   }
 
   static Status FromExpressionError(lldb::ExpressionResults result,
-std::string msg);
+std::string msg) {
+return Status(result, lldb::eErrorTypeExpression, msg);
+  }
 
   /// Set the current error to errno.
   ///
@@ -176,7 +115,6 @@ class Status {
   const Status &operator=(Status &&);
   /// Avoid using this in new code. Migrate APIs to llvm::Expected instead.
   static Status FromError(llvm::Error error);
-
   /// FIXME: Replace this with a takeError() method.
   llvm::Error ToError() const;
   /// Don't call this function in new code. Instead, redesign the API
@@ -211,20 +149,12 @@ class Status {
 
   /// Access the error value.
   ///
-  /// If the internally stored \ref llvm::Error is an \ref
-  /// llvm::ErrorList then this returns the error value of the first
-  /// error.
-  ///
   /// \return
   /// The error value.
   ValueType GetError() const;
 
   /// Access the error type.
   ///
-  /// If the internally stored \ref llvm::Error is an \ref
-  /// llvm::ErrorList then this returns the error value of the first
-  /// error.
-  ///
   /// \return
   /// The error type enumeration value.
   lldb::ErrorType GetType() const;
@@ -240,9 +170,12 @@ class Status {
   bool Success() const;
 
 protected:
-  Status(llvm::Error error) : m_error(std::move(error)) {}
-  llvm::Error m_error;
-  /// TODO: Replace this with just callling toString(m_error).
+  Status(llvm::Error error);
+  /// Status code as an integer value.
+  ValueType m_code = 0;
+  /// The type of the above error code.
+  lldb::ErrorType m_type = lldb::eErrorTypeInvalid;
+  /// A string representation of the error code.
   mutable std::string m_string;
 };

[Lldb-commits] [lldb] 6dcde73 - Revert "[lldb] Only send "posix" error codes through the gdb-remote protocol"

2024-09-18 Thread Adrian Prantl via lldb-commits

Author: Adrian Prantl
Date: 2024-09-18T17:28:10-07:00
New Revision: 6dcde731eb13aeaa8296504ad8178d62c8ecd3eb

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

LOG: Revert "[lldb] Only send "posix" error codes through the gdb-remote 
protocol"

This reverts commit a7c174502aef45b2d33291129cce10c085fef944.

Added: 


Modified: 
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServer.cpp
lldb/unittests/Process/gdb-remote/GDBRemoteCommunicationServerTest.cpp

Removed: 




diff  --git 
a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServer.cpp 
b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServer.cpp
index d4aa90b2c7731a..9b72cb00352821 100644
--- a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServer.cpp
+++ b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServer.cpp
@@ -103,14 +103,13 @@ GDBRemoteCommunicationServer::SendErrorResponse(uint8_t 
err) {
 
 GDBRemoteCommunication::PacketResult
 GDBRemoteCommunicationServer::SendErrorResponse(const Status &error) {
-  uint8_t code = error.GetType() == eErrorTypePOSIX ? error.GetError() : 0xff;
   if (m_send_error_strings) {
 lldb_private::StreamString packet;
-packet.Printf("E%2.2x;", code);
+packet.Printf("E%2.2x;", static_cast(error.GetError()));
 packet.PutStringAsRawHex8(error.AsCString());
 return SendPacketNoLock(packet.GetString());
-  }
-  return SendErrorResponse(code);
+  } else
+return SendErrorResponse(error.GetError());
 }
 
 GDBRemoteCommunication::PacketResult

diff  --git 
a/lldb/unittests/Process/gdb-remote/GDBRemoteCommunicationServerTest.cpp 
b/lldb/unittests/Process/gdb-remote/GDBRemoteCommunicationServerTest.cpp
index ba9ca6ea73e3be..69ca1720c04fc9 100644
--- a/lldb/unittests/Process/gdb-remote/GDBRemoteCommunicationServerTest.cpp
+++ b/lldb/unittests/Process/gdb-remote/GDBRemoteCommunicationServerTest.cpp
@@ -12,7 +12,6 @@
 #include "Plugins/Process/gdb-remote/GDBRemoteCommunicationServer.h"
 #include "lldb/Utility/Connection.h"
 #include "lldb/Utility/UnimplementedError.h"
-#include "lldb/lldb-enumerations.h"
 
 namespace lldb_private {
 namespace process_gdb_remote {
@@ -26,7 +25,7 @@ TEST(GDBRemoteCommunicationServerTest, 
SendErrorResponse_ErrorNumber) {
 
 TEST(GDBRemoteCommunicationServerTest, SendErrorResponse_Status) {
   MockServerWithMockConnection server;
-  Status status(0x42, lldb::eErrorTypePOSIX, "Test error message");
+  Status status(0x42, lldb::eErrorTypeGeneric, "Test error message");
   server.SendErrorResponse(status);
 
   EXPECT_THAT(



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


[Lldb-commits] [lldb] 2730373 - Revert "Add noexcept qualifier to placate g++"

2024-09-18 Thread Adrian Prantl via lldb-commits

Author: Adrian Prantl
Date: 2024-09-18T17:28:09-07:00
New Revision: 27303736512c32bb87b67a4ecf0b17881a8811c6

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

LOG: Revert "Add noexcept qualifier to placate g++"

This reverts commit b4a8e877ee3002a8cfd613f7950afcbe1d98821c.

Added: 


Modified: 
lldb/source/Utility/Status.cpp

Removed: 




diff  --git a/lldb/source/Utility/Status.cpp b/lldb/source/Utility/Status.cpp
index f557cb540b5655..faa8d3a83c7ed1 100644
--- a/lldb/source/Utility/Status.cpp
+++ b/lldb/source/Utility/Status.cpp
@@ -48,7 +48,7 @@ char ExpressionError::ID;
 namespace {
 /// A std::error_code category for eErrorTypeGeneric.
 class LLDBGenericCategory : public std::error_category {
-  const char *name() const noexcept override { return "LLDBGenericCategory"; }
+  const char *name() const override { return "LLDBGenericCategory"; }
   std::string message(int __ev) const override { return "generic LLDB error"; 
};
 };
 LLDBGenericCategory &lldb_generic_category() {
@@ -58,9 +58,7 @@ LLDBGenericCategory &lldb_generic_category() {
 
 /// A std::error_code category for eErrorTypeExpression.
 class ExpressionCategory : public std::error_category {
-  const char *name() const noexcept override {
-return "LLDBExpressionCategory";
-  }
+  const char *name() const override { return "LLDBExpressionCategory"; }
   std::string message(int __ev) const override {
 return ExpressionResultAsCString(
 static_cast(__ev));



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


[Lldb-commits] [lldb] 8b456b4 - Revert "[lldb] Update SocketTestUtilities.cpp to use CloneableECError"

2024-09-18 Thread Adrian Prantl via lldb-commits

Author: Adrian Prantl
Date: 2024-09-18T17:28:09-07:00
New Revision: 8b456b436f996b4c6dfee0abc704b9219d43f7d2

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

LOG: Revert "[lldb] Update SocketTestUtilities.cpp to use CloneableECError"

This reverts commit 2383bc8216bd7d373bb48337199c09d40922adf2.

Added: 


Modified: 
lldb/unittests/TestingSupport/Host/SocketTestUtilities.cpp

Removed: 




diff  --git a/lldb/unittests/TestingSupport/Host/SocketTestUtilities.cpp 
b/lldb/unittests/TestingSupport/Host/SocketTestUtilities.cpp
index 86aed292ec01f8..86fb5b05ea8009 100644
--- a/lldb/unittests/TestingSupport/Host/SocketTestUtilities.cpp
+++ b/lldb/unittests/TestingSupport/Host/SocketTestUtilities.cpp
@@ -104,13 +104,14 @@ static bool CheckIPSupport(llvm::StringRef Proto, 
llvm::StringRef Addr) {
   bool HasProtocolError = false;
   handleAllErrors(
   std::move(Err),
-  [&](std::unique_ptr ECErr) {
+  [&](std::unique_ptr ECErr) {
 std::error_code ec = ECErr->convertToErrorCode();
 if (ec ==
 std::make_error_code(std::errc::address_family_not_supported) 
||
 ec == std::make_error_code(std::errc::address_not_available))
   HasProtocolError = true;
-  });
+  },
+  [](const llvm::ErrorInfoBase &) {});
   if (HasProtocolError) {
 GTEST_LOG_(WARNING)
 << llvm::formatv(



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


[Lldb-commits] [lldb] 79a69cb - Revert "[lldb] Store ECError as CloneableECError in Status"

2024-09-18 Thread Adrian Prantl via lldb-commits

Author: Adrian Prantl
Date: 2024-09-18T17:28:09-07:00
New Revision: 79a69cb06665859658677b9ade4a1a262490f8c1

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

LOG: Revert "[lldb] Store ECError as CloneableECError in Status"

This reverts commit cf02d8bbb6dfed17081fbdbf44e2071aea1af728.

Added: 


Modified: 
lldb/source/Utility/Status.cpp

Removed: 




diff  --git a/lldb/source/Utility/Status.cpp b/lldb/source/Utility/Status.cpp
index a659456b9b1b39..f557cb540b5655 100644
--- a/lldb/source/Utility/Status.cpp
+++ b/lldb/source/Utility/Status.cpp
@@ -144,19 +144,13 @@ static llvm::Error CloneError(const llvm::Error &error) {
 return llvm::make_error(e.message(),
e.convertToErrorCode(), true);
   };
-  llvm::visitErrors(error, [&](const llvm::ErrorInfoBase &e) {
+  visitErrors(error, [&](const llvm::ErrorInfoBase &e) {
 result = joinErrors(std::move(result), clone(e));
   });
   return result;
 }
 
-Status Status::FromError(llvm::Error error) {
-  if (error.isA()) {
-std::error_code ec = llvm::errorToErrorCode(std::move(error));
-return Status::FromError(llvm::make_error(ec));
-  }
-  return Status(std::move(error));
-}
+Status Status::FromError(llvm::Error error) { return Status(std::move(error)); 
}
 
 llvm::Error Status::ToError() const { return CloneError(m_error); }
 



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


[Lldb-commits] [lldb] 05a292c - Revert "[lldb] Add handling of ECError to unit test to validate a hypothesis on the bots"

2024-09-18 Thread Adrian Prantl via lldb-commits

Author: Adrian Prantl
Date: 2024-09-18T17:28:09-07:00
New Revision: 05a292caa57de13a6d0bc25dee2be25c2a0dcee3

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

LOG: Revert "[lldb] Add handling of ECError to unit test to validate a 
hypothesis on the bots"

This reverts commit c86b1b0f44509585390c8df09b41d707e6a14011.

Added: 


Modified: 
lldb/unittests/TestingSupport/Host/SocketTestUtilities.cpp

Removed: 




diff  --git a/lldb/unittests/TestingSupport/Host/SocketTestUtilities.cpp 
b/lldb/unittests/TestingSupport/Host/SocketTestUtilities.cpp
index 9777555d57..86aed292ec01f8 100644
--- a/lldb/unittests/TestingSupport/Host/SocketTestUtilities.cpp
+++ b/lldb/unittests/TestingSupport/Host/SocketTestUtilities.cpp
@@ -110,14 +110,6 @@ static bool CheckIPSupport(llvm::StringRef Proto, 
llvm::StringRef Addr) {
 std::make_error_code(std::errc::address_family_not_supported) 
||
 ec == std::make_error_code(std::errc::address_not_available))
   HasProtocolError = true;
-  },
-  [&](std::unique_ptr ECErr) {
-// FIXME: This code path should not be reachable.
-std::error_code ec = ECErr->convertToErrorCode();
-if (ec ==
-std::make_error_code(std::errc::address_family_not_supported) ||
-ec == std::make_error_code(std::errc::address_not_available))
-  HasProtocolError = true;
   });
   if (HasProtocolError) {
 GTEST_LOG_(WARNING)



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


[Lldb-commits] [lldb] Improve type and namespace lookup using parent chain (PR #108907)

2024-09-18 Thread via lldb-commits

jeffreytan81 wrote:

Ping, anyone wants to review this? Thanks

https://github.com/llvm/llvm-project/pull/108907
___
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)

2024-09-18 Thread Adrian Vogelsgesang via lldb-commits

vogelsgesang wrote:

> What I could imagine is to drive this via attributes instead of a heuristic. 
> We could potentially mark implementation details of libc++ as such to control 
> what the debugging experience is like at a much finer grain if we used 
> attributes, but obviously this would also increase complexity in the code and 
> it would be yet another thing that we have to slap on almost every 
> declaration.

Mayve we could also find some other convention. E.g. hiding the 
`std::*::__detail` namespace. (You could still move all those `__` methods into 
a different namespace, right? They are not part of the stable ABI, are they?). 
Using a namespace would have the benefit that

1. you don't need to annotate each individual method, you can simply use a scope
2. we don't need to add a new attribute to clang, dwarf etc.

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] c86b1b0 - [lldb] Add handling of ECError to unit test to validate a hypothesis on the bots

2024-09-18 Thread Adrian Prantl via lldb-commits

Author: Adrian Prantl
Date: 2024-09-18T16:39:22-07:00
New Revision: c86b1b0f44509585390c8df09b41d707e6a14011

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

LOG: [lldb] Add handling of ECError to unit test to validate a hypothesis on 
the bots

Added: 


Modified: 
lldb/unittests/TestingSupport/Host/SocketTestUtilities.cpp

Removed: 




diff  --git a/lldb/unittests/TestingSupport/Host/SocketTestUtilities.cpp 
b/lldb/unittests/TestingSupport/Host/SocketTestUtilities.cpp
index 86aed292ec01f8..9777555d57 100644
--- a/lldb/unittests/TestingSupport/Host/SocketTestUtilities.cpp
+++ b/lldb/unittests/TestingSupport/Host/SocketTestUtilities.cpp
@@ -110,6 +110,14 @@ static bool CheckIPSupport(llvm::StringRef Proto, 
llvm::StringRef Addr) {
 std::make_error_code(std::errc::address_family_not_supported) 
||
 ec == std::make_error_code(std::errc::address_not_available))
   HasProtocolError = true;
+  },
+  [&](std::unique_ptr ECErr) {
+// FIXME: This code path should not be reachable.
+std::error_code ec = ECErr->convertToErrorCode();
+if (ec ==
+std::make_error_code(std::errc::address_family_not_supported) ||
+ec == std::make_error_code(std::errc::address_not_available))
+  HasProtocolError = true;
   });
   if (HasProtocolError) {
 GTEST_LOG_(WARNING)



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

2024-09-18 Thread Adrian Vogelsgesang via lldb-commits

vogelsgesang wrote:

> We really should add a "disable" to the frame recognizers

Do you mean something like #109219? (Test cases still missing; rest should be 
ready for review)

> Seems to me like this feature should be tuned to "users of libc++" not 
> "developers of libc++".

Agree, I think that should be the goal here

> I wonder if a heuristic for the callback case could be: mark all but the 
> first libc++ entry point as an implementation detail. Would this be even more 
> aggressive? Also, the implementation of this might be a bit awkward. Not 
> sure. Wdyt?

🤔 Might be a good idea... I will have to experiment a bit with this... 

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] Add support for disabling frame recognizers (PR #109219)

2024-09-18 Thread via lldb-commits

github-actions[bot] wrote:




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



You can test this locally with the following command:


``bash
git-clang-format --diff e0ad34e56590fa2e6ffdf617e044de7eadee2139 
c471c2fe615082fb9f9c5f39466bd47ec5b86bb0 --extensions h,cpp -- 
lldb/include/lldb/Target/StackFrameRecognizer.h 
lldb/source/Commands/CommandObjectFrame.cpp 
lldb/source/Target/StackFrameRecognizer.cpp
``





View the diff from clang-format here.


``diff
diff --git a/lldb/include/lldb/Target/StackFrameRecognizer.h 
b/lldb/include/lldb/Target/StackFrameRecognizer.h
index 0deb4d4645..d2797b548e 100644
--- a/lldb/include/lldb/Target/StackFrameRecognizer.h
+++ b/lldb/include/lldb/Target/StackFrameRecognizer.h
@@ -124,12 +124,12 @@ public:
  Mangled::NamePreference symbol_mangling,
  bool first_instruction_only = true);
 
-  void ForEach(std::function<
-   void(uint32_t recognizer_id, bool enabled,
-std::string recognizer_name, std::string module,
-llvm::ArrayRef symbols,
-Mangled::NamePreference name_reference, bool regexp)> const
-   &callback);
+  void
+  ForEach(std::function symbols,
+ Mangled::NamePreference name_reference,
+ bool regexp)> const &callback);
 
   bool SetEnabledForID(uint32_t recognizer_id, bool enabled);
   bool RemoveRecognizerWithID(uint32_t recognizer_id);
diff --git a/lldb/source/Commands/CommandObjectFrame.cpp 
b/lldb/source/Commands/CommandObjectFrame.cpp
index 86db334ddc..d42cbeaba1 100644
--- a/lldb/source/Commands/CommandObjectFrame.cpp
+++ b/lldb/source/Commands/CommandObjectFrame.cpp
@@ -964,15 +964,15 @@ PrintRecognizerDetails(Stream &strm, const std::string 
&name, bool enabled,
 
 // Base class for commands which accept a single frame recognizer as an 
argument
 class CommandObjectWithFrameRecognizerArg : public CommandObjectParsed {
-  public:
-CommandObjectWithFrameRecognizerArg(CommandInterpreter &interpreter,
-const char *name,
-const char *help = nullptr,
-const char *syntax = nullptr,
-uint32_t flags = 0)
-: CommandObjectParsed(interpreter, name, help, syntax, flags) {
-  AddSimpleArgumentList(eArgTypeRecognizerID);
-}
+public:
+  CommandObjectWithFrameRecognizerArg(CommandInterpreter &interpreter,
+  const char *name,
+  const char *help = nullptr,
+  const char *syntax = nullptr,
+  uint32_t flags = 0)
+  : CommandObjectParsed(interpreter, name, help, syntax, flags) {
+AddSimpleArgumentList(eArgTypeRecognizerID);
+  }
 
   void
   HandleArgumentCompletion(CompletionRequest &request,
@@ -982,7 +982,8 @@ class CommandObjectWithFrameRecognizerArg : public 
CommandObjectParsed {
   return;
 
 GetTarget().GetFrameRecognizerManager().ForEach(
-[&request](uint32_t rid, bool enabled, std::string rname, std::string 
module,
+[&request](uint32_t rid, bool enabled, std::string rname,
+   std::string module,
llvm::ArrayRef symbols,
Mangled::NamePreference symbol_mangling, bool regexp) {
   StreamString strm;
@@ -996,7 +997,8 @@ class CommandObjectWithFrameRecognizerArg : public 
CommandObjectParsed {
 });
   }
 
-  virtual void DoExecuteWithId(CommandReturnObject &result, uint32_t 
recognizer_id) = 0;
+  virtual void DoExecuteWithId(CommandReturnObject &result,
+   uint32_t recognizer_id) = 0;
 
   void DoExecute(Args &command, CommandReturnObject &result) override {
 if (command.GetArgumentCount() != 1) {
@@ -1016,7 +1018,8 @@ class CommandObjectWithFrameRecognizerArg : public 
CommandObjectParsed {
   }
 };
 
-class CommandObjectFrameRecognizerEnable : public 
CommandObjectWithFrameRecognizerArg {
+class CommandObjectFrameRecognizerEnable
+: public CommandObjectWithFrameRecognizerArg {
 public:
   CommandObjectFrameRecognizerEnable(CommandInterpreter &interpreter)
   : CommandObjectWithFrameRecognizerArg(
@@ -1028,8 +1031,9 @@ public:
   ~CommandObjectFrameRecognizerEnable() override = default;
 
 protected:
-  void DoExecuteWithId(CommandReturnObject &result, uint32_t recognizer_id) 
override {
-auto& recognizer_mgr = GetTarget().GetFrameRecognizerManager();
+  void DoExecuteWithId(CommandReturnObject &result,
+   uint32_t recognizer_id) override {
+auto &recognizer_mgr = GetTarget().GetFrameRecognizerManager();
 if (!recognizer_mgr.SetEnabledForID(recognizer_id, true)) {
   result.AppendErrorWithFormat("'%u' is not a valid recognize

[Lldb-commits] [lldb] [lldb] Add support for disabling frame recognizers (PR #109219)

2024-09-18 Thread Adrian Vogelsgesang via lldb-commits

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

Sometimes you only want to temporarily disable a frame recognizer instead of 
deleting it. In particular, when dealing with one of the builtin frame 
recognizers, which cannot be restored after deletion.

>From c471c2fe615082fb9f9c5f39466bd47ec5b86bb0 Mon Sep 17 00:00:00 2001
From: Adrian Vogelsgesang 
Date: Wed, 18 Sep 2024 22:34:30 +
Subject: [PATCH] [lldb] Add support for disabling frame recognizers

Sometimes you only want to temporarily disable a frame recognizer
instead of deleting it. In particular, when dealing with one of the
builtin frame recognizers, which cannot be restored after deletion.
---
 .../lldb/Target/StackFrameRecognizer.h|   7 +-
 lldb/source/Commands/CommandObjectFrame.cpp   | 144 +-
 lldb/source/Target/StackFrameRecognizer.cpp   |  29 +++-
 3 files changed, 131 insertions(+), 49 deletions(-)

diff --git a/lldb/include/lldb/Target/StackFrameRecognizer.h 
b/lldb/include/lldb/Target/StackFrameRecognizer.h
index 617b1617d404a1..0deb4d46454784 100644
--- a/lldb/include/lldb/Target/StackFrameRecognizer.h
+++ b/lldb/include/lldb/Target/StackFrameRecognizer.h
@@ -125,11 +125,13 @@ class StackFrameRecognizerManager {
  bool first_instruction_only = true);
 
   void ForEach(std::function<
-   void(uint32_t recognizer_id, std::string recognizer_name,
-std::string module, llvm::ArrayRef symbols,
+   void(uint32_t recognizer_id, bool enabled,
+std::string recognizer_name, std::string module,
+llvm::ArrayRef symbols,
 Mangled::NamePreference name_reference, bool regexp)> const
&callback);
 
+  bool SetEnabledForID(uint32_t recognizer_id, bool enabled);
   bool RemoveRecognizerWithID(uint32_t recognizer_id);
 
   void RemoveAllRecognizers();
@@ -155,6 +157,7 @@ class StackFrameRecognizerManager {
 lldb::RegularExpressionSP symbol_regexp;
 Mangled::NamePreference symbol_mangling;
 bool first_instruction_only;
+bool enabled;
   };
 
   std::deque m_recognizers;
diff --git a/lldb/source/Commands/CommandObjectFrame.cpp 
b/lldb/source/Commands/CommandObjectFrame.cpp
index d8091e8993fde1..86db334ddc677e 100644
--- a/lldb/source/Commands/CommandObjectFrame.cpp
+++ b/lldb/source/Commands/CommandObjectFrame.cpp
@@ -31,8 +31,10 @@
 #include "lldb/Target/Thread.h"
 #include "lldb/Utility/Args.h"
 
+#include 
 #include 
 #include 
+#include 
 #include 
 
 using namespace lldb;
@@ -930,10 +932,13 @@ class CommandObjectFrameRecognizerClear : public 
CommandObjectParsed {
 };
 
 static void
-PrintRecognizerDetails(Stream &strm, const std::string &name,
+PrintRecognizerDetails(Stream &strm, const std::string &name, bool enabled,
const std::string &module,
llvm::ArrayRef symbols,
Mangled::NamePreference symbol_mangling, bool regexp) {
+  if (!enabled)
+strm << "[disabled] ";
+
   strm << name << ", ";
 
   if (!module.empty())
@@ -957,53 +962,43 @@ PrintRecognizerDetails(Stream &strm, const std::string 
&name,
   llvm::interleaveComma(symbols, strm);
 }
 
-class CommandObjectFrameRecognizerDelete : public CommandObjectParsed {
-public:
-  CommandObjectFrameRecognizerDelete(CommandInterpreter &interpreter)
-  : CommandObjectParsed(interpreter, "frame recognizer delete",
-"Delete an existing frame recognizer by id.",
-nullptr) {
-AddSimpleArgumentList(eArgTypeRecognizerID);
-  }
-
-  ~CommandObjectFrameRecognizerDelete() override = default;
+// Base class for commands which accept a single frame recognizer as an 
argument
+class CommandObjectWithFrameRecognizerArg : public CommandObjectParsed {
+  public:
+CommandObjectWithFrameRecognizerArg(CommandInterpreter &interpreter,
+const char *name,
+const char *help = nullptr,
+const char *syntax = nullptr,
+uint32_t flags = 0)
+: CommandObjectParsed(interpreter, name, help, syntax, flags) {
+  AddSimpleArgumentList(eArgTypeRecognizerID);
+}
 
   void
   HandleArgumentCompletion(CompletionRequest &request,
OptionElementVector &opt_element_vector) override {
+std::cerr << request.GetCursorIndex() << std::endl;
 if (request.GetCursorIndex() != 0)
   return;
 
 GetTarget().GetFrameRecognizerManager().ForEach(
-[&request](uint32_t rid, std::string rname, std::string module,
+[&request](uint32_t rid, bool enabled, std::string rname, std::string 
module,
llvm::ArrayRef symbols,
Mangled::NamePreference symbol_mangling, bool regexp) {
   StreamString strm;
   if (rname.empty()

[Lldb-commits] [lldb] cf02d8b - [lldb] Store ECError as CloneableECError in Status

2024-09-18 Thread Adrian Prantl via lldb-commits

Author: Adrian Prantl
Date: 2024-09-18T16:23:29-07:00
New Revision: cf02d8bbb6dfed17081fbdbf44e2071aea1af728

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

LOG: [lldb] Store ECError as CloneableECError in Status

Added: 


Modified: 
lldb/source/Utility/Status.cpp

Removed: 




diff  --git a/lldb/source/Utility/Status.cpp b/lldb/source/Utility/Status.cpp
index f557cb540b5655..a659456b9b1b39 100644
--- a/lldb/source/Utility/Status.cpp
+++ b/lldb/source/Utility/Status.cpp
@@ -144,13 +144,19 @@ static llvm::Error CloneError(const llvm::Error &error) {
 return llvm::make_error(e.message(),
e.convertToErrorCode(), true);
   };
-  visitErrors(error, [&](const llvm::ErrorInfoBase &e) {
+  llvm::visitErrors(error, [&](const llvm::ErrorInfoBase &e) {
 result = joinErrors(std::move(result), clone(e));
   });
   return result;
 }
 
-Status Status::FromError(llvm::Error error) { return Status(std::move(error)); 
}
+Status Status::FromError(llvm::Error error) {
+  if (error.isA()) {
+std::error_code ec = llvm::errorToErrorCode(std::move(error));
+return Status::FromError(llvm::make_error(ec));
+  }
+  return Status(std::move(error));
+}
 
 llvm::Error Status::ToError() const { return CloneError(m_error); }
 



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


[Lldb-commits] [lldb] [lldb] [debugserver] Use "full" x86_64 GPR state when available. (PR #108663)

2024-09-18 Thread Brendan Shanks via lldb-commits

mrpippy wrote:

Great, no I don't think I have permissions to merge.

I pushed a new version that fixed a typo in the `GetGPRState` log call, and in 
`SetGPRState` adds the new fields to the log call.

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


[Lldb-commits] [lldb] [lldb/Interpreter] Add requirements to Scripted Interface abstract methods (PR #109063)

2024-09-18 Thread Med Ismail Bennani via lldb-commits


@@ -78,8 +100,11 @@ class ScriptedPythonInterface : virtual public 
ScriptedInterface {
 using namespace python;
 using Locker = ScriptInterpreterPythonImpl::Locker;
 
-auto create_error = [](std::string message) {
-  return llvm::createStringError(llvm::inconvertibleErrorCode(), message);
+Log *log = GetLog(LLDBLog::Script);
+auto create_error = [](llvm::StringRef format, auto &&...ts) {

medismailben wrote:

Made it an `llvm::StringLitteral` instead ;)

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


[Lldb-commits] [lldb] [lldb] [debugserver] Use "full" x86_64 GPR state when available. (PR #108663)

2024-09-18 Thread Brendan Shanks via lldb-commits

https://github.com/mrpippy updated 
https://github.com/llvm/llvm-project/pull/108663

>From a9b19cbd20083e2b1d6c8de342206cb0ec6183b7 Mon Sep 17 00:00:00 2001
From: Brendan Shanks 
Date: Thu, 12 Sep 2024 16:01:30 -0700
Subject: [PATCH] [lldb] [debugserver] Use "full" x86_64 GPR state when
 available.

macOS 10.15 added a "full" x86_64 GPR thread state flavor, equivalent to
the normal one but with DS, ES, SS, and GSbase added.
This flavor can only be used with processes that install a custom LDT
(functionality that was also added in 10.15 and is used by apps like
Wine to execute 32-bit code).

Along with allowing DS, ES, SS, and GSbase to be viewed/modified, using
the full flavor is necessary when debugging a thread executing 32-bit
code.
If thread_set_state() is used with the regular thread state flavor, the
kernel resets CS to the 64-bit code segment, which makes debugging
impossible.

There's no way to detect whether the full flavor is available, try to
use it and fall back to the regular one if it's not available.

A downside is that this patch exposes the DS, ES, SS, and GSbase
registers for all x86_64 processes, even though they are not populated
unless the full thread state is available.

Fixes #57591
---
 .../MacOSX/x86_64/DNBArchImplX86_64.cpp   | 67 +++
 .../source/MacOSX/x86_64/DNBArchImplX86_64.h  |  4 +-
 .../MacOSX/x86_64/MachRegisterStatesX86_64.h  |  5 ++
 3 files changed, 61 insertions(+), 15 deletions(-)

diff --git a/lldb/tools/debugserver/source/MacOSX/x86_64/DNBArchImplX86_64.cpp 
b/lldb/tools/debugserver/source/MacOSX/x86_64/DNBArchImplX86_64.cpp
index 5a62e2a8d12e2c..3b3f1f02a2851f 100644
--- a/lldb/tools/debugserver/source/MacOSX/x86_64/DNBArchImplX86_64.cpp
+++ b/lldb/tools/debugserver/source/MacOSX/x86_64/DNBArchImplX86_64.cpp
@@ -182,22 +182,39 @@ kern_return_t DNBArchImplX86_64::GetGPRState(bool force) {
 m_state.context.gpr.__gs = ('g' << 8) + 's';
 m_state.SetError(e_regSetGPR, Read, 0);
 #else
-mach_msg_type_number_t count = e_regSetWordSizeGPR;
+mach_msg_type_number_t count = e_regSetWordSizeGPRFull;
+int flavor = __x86_64_THREAD_FULL_STATE;
 m_state.SetError(
 e_regSetGPR, Read,
-::thread_get_state(m_thread->MachPortNumber(), __x86_64_THREAD_STATE,
+::thread_get_state(m_thread->MachPortNumber(), flavor,
(thread_state_t)&m_state.context.gpr, &count));
+
+if (!m_state.GetError(e_regSetGPR, Read)) {
+  m_state.hasFullGPRState = true;
+} else {
+  m_state.hasFullGPRState = false;
+  count = e_regSetWordSizeGPR;
+  flavor = __x86_64_THREAD_STATE;
+  m_state.SetError(
+  e_regSetGPR, Read,
+  ::thread_get_state(m_thread->MachPortNumber(), flavor,
+ (thread_state_t)&m_state.context.gpr, &count));
+}
 DNBLogThreadedIf(
 LOG_THREAD,
-"::thread_get_state (0x%4.4x, %u, &gpr, %u) => 0x%8.8x"
+"::thread_get_state (0x%4.4x, %u (%s), &gpr, %u) => 0x%8.8x"
 "\n\trax = %16.16llx rbx = %16.16llx rcx = %16.16llx rdx = %16.16llx"
 "\n\trdi = %16.16llx rsi = %16.16llx rbp = %16.16llx rsp = %16.16llx"
 "\n\t r8 = %16.16llx  r9 = %16.16llx r10 = %16.16llx r11 = %16.16llx"
 "\n\tr12 = %16.16llx r13 = %16.16llx r14 = %16.16llx r15 = %16.16llx"
 "\n\trip = %16.16llx"
-"\n\tflg = %16.16llx  cs = %16.16llx  fs = %16.16llx  gs = %16.16llx",
-m_thread->MachPortNumber(), x86_THREAD_STATE64,
-x86_THREAD_STATE64_COUNT, m_state.GetError(e_regSetGPR, Read),
+"\n\tflg = %16.16llx  cs = %16.16llx  fs = %16.16llx  gs = %16.16llx"
+"\n\t ds = %16.16llx  es = %16.16llx  ss = %16.16llx gsB = %16.16llx",
+m_thread->MachPortNumber(), flavor,
+m_state.hasFullGPRState ? "full" : "non-full",
+m_state.hasFullGPRState ? e_regSetWordSizeGPRFull
+: e_regSetWordSizeGPR,
+m_state.GetError(e_regSetGPR, Read),
 m_state.context.gpr.__rax, m_state.context.gpr.__rbx,
 m_state.context.gpr.__rcx, m_state.context.gpr.__rdx,
 m_state.context.gpr.__rdi, m_state.context.gpr.__rsi,
@@ -208,7 +225,9 @@ kern_return_t DNBArchImplX86_64::GetGPRState(bool force) {
 m_state.context.gpr.__r14, m_state.context.gpr.__r15,
 m_state.context.gpr.__rip, m_state.context.gpr.__rflags,
 m_state.context.gpr.__cs, m_state.context.gpr.__fs,
-m_state.context.gpr.__gs);
+m_state.context.gpr.__gs, m_state.context.gpr.__ds,
+m_state.context.gpr.__es, m_state.context.gpr.__ss,
+m_state.context.gpr.__gsbase );
 
 //  DNBLogThreadedIf (LOG_THREAD, "thread_get_state(0x%4.4x, %u, &gpr, %u)
 //  => 0x%8.8x"
@@ -459,21 +478,26 @@ kern_return_t DNBArchImplX86_64::SetGPRState() {
   "(SetGPRState() for stop_count = %u)",
   m_thread->MachPortNumber(), kret, m_thread->Process()->StopCount());
 
+  mach_msg_type_number_t count 

[Lldb-commits] [lldb] 2383bc8 - [lldb] Update SocketTestUtilities.cpp to use CloneableECError

2024-09-18 Thread Adrian Prantl via lldb-commits

Author: Adrian Prantl
Date: 2024-09-18T15:54:24-07:00
New Revision: 2383bc8216bd7d373bb48337199c09d40922adf2

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

LOG: [lldb] Update SocketTestUtilities.cpp to use CloneableECError

Added: 


Modified: 
lldb/unittests/TestingSupport/Host/SocketTestUtilities.cpp

Removed: 




diff  --git a/lldb/unittests/TestingSupport/Host/SocketTestUtilities.cpp 
b/lldb/unittests/TestingSupport/Host/SocketTestUtilities.cpp
index 86fb5b05ea8009..86aed292ec01f8 100644
--- a/lldb/unittests/TestingSupport/Host/SocketTestUtilities.cpp
+++ b/lldb/unittests/TestingSupport/Host/SocketTestUtilities.cpp
@@ -104,14 +104,13 @@ static bool CheckIPSupport(llvm::StringRef Proto, 
llvm::StringRef Addr) {
   bool HasProtocolError = false;
   handleAllErrors(
   std::move(Err),
-  [&](std::unique_ptr ECErr) {
+  [&](std::unique_ptr ECErr) {
 std::error_code ec = ECErr->convertToErrorCode();
 if (ec ==
 std::make_error_code(std::errc::address_family_not_supported) 
||
 ec == std::make_error_code(std::errc::address_not_available))
   HasProtocolError = true;
-  },
-  [](const llvm::ErrorInfoBase &) {});
+  });
   if (HasProtocolError) {
 GTEST_LOG_(WARNING)
 << llvm::formatv(



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


[Lldb-commits] [lldb] [lldb] Store expression evaluator diagnostics in an llvm::Error (NFC) (PR #106442)

2024-09-18 Thread Adrian Prantl via lldb-commits

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

>From a857ea027be6dbdc06d2834b65906a356b2a4128 Mon Sep 17 00:00:00 2001
From: Adrian Prantl 
Date: Wed, 28 Aug 2024 10:04:33 -0700
Subject: [PATCH] [lldb] Store expression evaluator diagnostics in an
 llvm::Error (NFC)

This patch is a reworking of Pete Lawrence's (@PortalPete) proposal
for better expression evaluator error messages:
https://github.com/llvm/llvm-project/pull/80938

This patch is preparatory patch for improving the rendering of
expression evaluator diagnostics. Currently diagnostics are rendered
into a string and the command interpreter layer then textually parses
words like "error:" to (sometimes) color the output accordingly. In
order to enable user interfaces to do better with diagnostics, we need
to store them in a machine-readable fromat. This patch does this by
adding a new llvm::Error kind wrapping a DiagnosticDetail struct that
is used when the error type is eErrorTypeExpression. Multiple
diagnostics are modeled using llvm::ErrorList.

Right now the extra information is not used by the CommandInterpreter,
this will be added in a follow-up patch!
---
 .../lldb/Expression/DiagnosticManager.h   | 86 ++-
 lldb/include/lldb/Utility/Status.h|  5 +-
 lldb/source/Breakpoint/BreakpointLocation.cpp | 10 +--
 lldb/source/Expression/DiagnosticManager.cpp  | 82 ++
 lldb/source/Expression/ExpressionParser.cpp   |  5 +-
 lldb/source/Expression/UserExpression.cpp | 28 +++---
 lldb/source/Expression/UtilityFunction.cpp| 16 ++--
 .../ExpressionParser/Clang/ClangDiagnostic.h  |  5 +-
 .../Clang/ClangExpressionParser.cpp   | 57 +---
 .../Plugins/Platform/POSIX/PlatformPOSIX.cpp  | 10 +--
 .../Platform/Windows/PlatformWindows.cpp  | 10 +--
 lldb/source/Target/Target.cpp |  2 +-
 lldb/source/Utility/Status.cpp|  6 ++
 .../TestModulesCompileError.py|  2 +-
 .../Expression/DiagnosticManagerTest.cpp  | 12 +--
 15 files changed, 226 insertions(+), 110 deletions(-)

diff --git a/lldb/include/lldb/Expression/DiagnosticManager.h 
b/lldb/include/lldb/Expression/DiagnosticManager.h
index d49b7c99b114fb..fb9502f4b3ffba 100644
--- a/lldb/include/lldb/Expression/DiagnosticManager.h
+++ b/lldb/include/lldb/Expression/DiagnosticManager.h
@@ -12,6 +12,9 @@
 #include "lldb/lldb-defines.h"
 #include "lldb/lldb-types.h"
 
+#include "lldb/Utility/FileSpec.h"
+#include "lldb/Utility/Status.h"
+
 #include "llvm/ADT/STLExtras.h"
 #include "llvm/ADT/StringRef.h"
 
@@ -20,6 +23,47 @@
 
 namespace lldb_private {
 
+/// A compiler-independent representation of a Diagnostic. Expression
+/// evaluation failures often have more than one diagnostic that a UI
+/// layer might want to render differently, for example to colorize
+/// it.
+///
+/// Running example:
+///   (lldb) expr 1+foo
+///   error: :1:3: use of undeclared identifier 'foo'
+///   1+foo
+/// ^
+struct DiagnosticDetail {
+  struct SourceLocation {
+FileSpec file;
+unsigned line = 0;
+uint16_t column = 0;
+uint16_t length = 0;
+bool in_user_input = false;
+  };
+  /// Contains {{}, 1, 3, 3, true} in the example above.
+  std::optional source_location;
+  /// Contains eSeverityError in the example above.
+  lldb::Severity severity = lldb::eSeverityInfo;
+  /// Contains "use of undeclared identifier 'x'" in the example above.
+  std::string message;
+  /// Contains the fully rendered error message.
+  std::string rendered;
+};
+
+/// An llvm::Error used to communicate diagnostics in Status. Multiple
+/// diagnostics may be chained in an llvm::ErrorList.
+class DetailedExpressionError
+: public llvm::ErrorInfo {
+  DiagnosticDetail m_detail;
+
+public:
+  using llvm::ErrorInfo::ErrorInfo;
+  DetailedExpressionError(DiagnosticDetail detail) : m_detail(detail) {}
+  std::string message() const override;
+  static char ID;
+};
+
 enum DiagnosticOrigin {
   eDiagnosticOriginUnknown = 0,
   eDiagnosticOriginLLDB,
@@ -49,37 +93,28 @@ class Diagnostic {
 }
   }
 
-  Diagnostic(llvm::StringRef message, lldb::Severity severity,
- DiagnosticOrigin origin, uint32_t compiler_id)
-  : m_message(message), m_severity(severity), m_origin(origin),
-m_compiler_id(compiler_id) {}
-
-  Diagnostic(const Diagnostic &rhs)
-  : m_message(rhs.m_message), m_severity(rhs.m_severity),
-m_origin(rhs.m_origin), m_compiler_id(rhs.m_compiler_id) {}
+  Diagnostic(DiagnosticOrigin origin, uint32_t compiler_id,
+ DiagnosticDetail detail)
+  : m_origin(origin), m_compiler_id(compiler_id), m_detail(detail) {}
 
   virtual ~Diagnostic() = default;
 
   virtual bool HasFixIts() const { return false; }
 
-  lldb::Severity GetSeverity() const { return m_severity; }
+  lldb::Severity GetSeverity() const { return m_detail.severity; }
 
   uint32_t GetCompilerID() const { return m_compiler_id; }
 
-  llvm::StringRef 

[Lldb-commits] [lldb] [lldb] Change the implementation of Status to store an llvm::Error (NFC) (PR #106774)

2024-09-18 Thread LLVM Continuous Integration via lldb-commits

llvm-ci wrote:

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

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


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

```
Step 6 (test) failure: build (failure)
...
PASS: lldb-unit :: Expression/./ExpressionTests/5/12 (1789 of 2024)
PASS: lldb-shell :: Watchpoint/SetErrorCases.test (1790 of 2024)
PASS: lldb-unit :: Expression/./ExpressionTests/6/12 (1791 of 2024)
PASS: lldb-unit :: Expression/./ExpressionTests/7/12 (1792 of 2024)
PASS: lldb-unit :: Expression/./ExpressionTests/8/12 (1793 of 2024)
PASS: lldb-unit :: Expression/./ExpressionTests/9/12 (1794 of 2024)
PASS: lldb-unit :: Host/./HostTests/1/12 (1795 of 2024)
PASS: lldb-unit :: Host/./HostTests/10/12 (1796 of 2024)
PASS: lldb-shell :: Watchpoint/ExpressionLanguage.test (1797 of 2024)
PASS: lldb-unit :: Core/./LLDBCoreTests/5/8 (1798 of 2024)
FAIL: lldb-unit :: Host/./HostTests/4/12 (1799 of 2024)
 TEST 'lldb-unit :: Host/./HostTests/4/12' FAILED 

Script(shard):
--
GTEST_OUTPUT=json:/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/tools/lldb/unittests/Host/./HostTests-lldb-unit-3284472-4-12.json
 GTEST_SHUFFLE=0 GTEST_TOTAL_SHARDS=12 GTEST_SHARD_INDEX=4 
/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/tools/lldb/unittests/Host/./HostTests
--

Script:
--
/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/tools/lldb/unittests/Host/./HostTests
 --gtest_filter=SocketTests/SocketTest.TCPMainLoopAccept/ipv6
--

[WARNING] 
../llvm-project/lldb/unittests/TestingSupport/Host/SocketTestUtilities.cpp:100::
 Creating a canary IPv6 TCP socket failed: Cannot assign requested address.

[WARNING] 
../llvm-project/lldb/unittests/TestingSupport/Host/SocketTestUtilities.cpp:122::
 Continuing anyway. The test will probably fail.
../llvm-project/lldb/unittests/Host/SocketTest.cpp:145: Failure
Value of: llvm::detail::TakeError(error.ToError())
Expected: succeeded
  Actual: failed  (Cannot assign requested address)


../llvm-project/lldb/unittests/Host/SocketTest.cpp:145
Value of: llvm::detail::TakeError(error.ToError())
Expected: succeeded
  Actual: failed  (Cannot assign requested address)




PASS: lldb-unit :: Core/./LLDBCoreTests/7/8 (1800 of 2024)
FAIL: lldb-unit :: Host/./HostTests/5/12 (1801 of 2024)
 TEST 'lldb-unit :: Host/./HostTests/5/12' FAILED 

Script(shard):
--
GTEST_OUTPUT=json:/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/tools/lldb/unittests/Host/./HostTests-lldb-unit-3284472-5-12.json
 GTEST_SHUFFLE=0 GTEST_TOTAL_SHARDS=12 GTEST_SHARD_INDEX=5 
/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/tools/lldb/unittests/Host/./HostTests
--

Note: This is test shard 6 of 12.
[==] Running 7 tests from 7 test suites.

```



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


[Lldb-commits] [lldb] [lldb] Store expression evaluator diagnostics in an llvm::Error (NFC) (PR #106442)

2024-09-18 Thread Adrian Prantl via lldb-commits

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

>From 8a2af995f80cc518f4776c2236a86d0ca32abe03 Mon Sep 17 00:00:00 2001
From: Adrian Prantl 
Date: Wed, 28 Aug 2024 10:04:33 -0700
Subject: [PATCH] [lldb] Store expression evaluator diagnostics in an
 llvm::Error (NFC)

This patch is a reworking of Pete Lawrence's (@PortalPete) proposal
for better expression evaluator error messages:
https://github.com/llvm/llvm-project/pull/80938

This patch is preparatory patch for improving the rendering of
expression evaluator diagnostics. Currently diagnostics are rendered
into a string and the command interpreter layer then textually parses
words like "error:" to (sometimes) color the output accordingly. In
order to enable user interfaces to do better with diagnostics, we need
to store them in a machine-readable fromat. This patch does this by
adding a new llvm::Error kind wrapping a DiagnosticDetail struct that
is used when the error type is eErrorTypeExpression. Multiple
diagnostics are modeled using llvm::ErrorList.

Right now the extra information is not used by the CommandInterpreter,
this will be added in a follow-up patch!
---
 .../lldb/Expression/DiagnosticManager.h   | 86 ++-
 lldb/include/lldb/Utility/Status.h|  5 +-
 lldb/source/Breakpoint/BreakpointLocation.cpp | 10 +--
 lldb/source/Expression/DiagnosticManager.cpp  | 82 ++
 lldb/source/Expression/ExpressionParser.cpp   |  5 +-
 lldb/source/Expression/UserExpression.cpp | 28 +++---
 lldb/source/Expression/UtilityFunction.cpp| 16 ++--
 .../ExpressionParser/Clang/ClangDiagnostic.h  |  5 +-
 .../Clang/ClangExpressionParser.cpp   | 57 +---
 .../Plugins/Platform/POSIX/PlatformPOSIX.cpp  | 10 +--
 .../Platform/Windows/PlatformWindows.cpp  | 10 +--
 lldb/source/Target/Target.cpp |  2 +-
 lldb/source/Utility/Status.cpp|  7 ++
 .../TestModulesCompileError.py|  2 +-
 .../Expression/DiagnosticManagerTest.cpp  | 12 +--
 15 files changed, 227 insertions(+), 110 deletions(-)

diff --git a/lldb/include/lldb/Expression/DiagnosticManager.h 
b/lldb/include/lldb/Expression/DiagnosticManager.h
index d49b7c99b114fb..fb9502f4b3ffba 100644
--- a/lldb/include/lldb/Expression/DiagnosticManager.h
+++ b/lldb/include/lldb/Expression/DiagnosticManager.h
@@ -12,6 +12,9 @@
 #include "lldb/lldb-defines.h"
 #include "lldb/lldb-types.h"
 
+#include "lldb/Utility/FileSpec.h"
+#include "lldb/Utility/Status.h"
+
 #include "llvm/ADT/STLExtras.h"
 #include "llvm/ADT/StringRef.h"
 
@@ -20,6 +23,47 @@
 
 namespace lldb_private {
 
+/// A compiler-independent representation of a Diagnostic. Expression
+/// evaluation failures often have more than one diagnostic that a UI
+/// layer might want to render differently, for example to colorize
+/// it.
+///
+/// Running example:
+///   (lldb) expr 1+foo
+///   error: :1:3: use of undeclared identifier 'foo'
+///   1+foo
+/// ^
+struct DiagnosticDetail {
+  struct SourceLocation {
+FileSpec file;
+unsigned line = 0;
+uint16_t column = 0;
+uint16_t length = 0;
+bool in_user_input = false;
+  };
+  /// Contains {{}, 1, 3, 3, true} in the example above.
+  std::optional source_location;
+  /// Contains eSeverityError in the example above.
+  lldb::Severity severity = lldb::eSeverityInfo;
+  /// Contains "use of undeclared identifier 'x'" in the example above.
+  std::string message;
+  /// Contains the fully rendered error message.
+  std::string rendered;
+};
+
+/// An llvm::Error used to communicate diagnostics in Status. Multiple
+/// diagnostics may be chained in an llvm::ErrorList.
+class DetailedExpressionError
+: public llvm::ErrorInfo {
+  DiagnosticDetail m_detail;
+
+public:
+  using llvm::ErrorInfo::ErrorInfo;
+  DetailedExpressionError(DiagnosticDetail detail) : m_detail(detail) {}
+  std::string message() const override;
+  static char ID;
+};
+
 enum DiagnosticOrigin {
   eDiagnosticOriginUnknown = 0,
   eDiagnosticOriginLLDB,
@@ -49,37 +93,28 @@ class Diagnostic {
 }
   }
 
-  Diagnostic(llvm::StringRef message, lldb::Severity severity,
- DiagnosticOrigin origin, uint32_t compiler_id)
-  : m_message(message), m_severity(severity), m_origin(origin),
-m_compiler_id(compiler_id) {}
-
-  Diagnostic(const Diagnostic &rhs)
-  : m_message(rhs.m_message), m_severity(rhs.m_severity),
-m_origin(rhs.m_origin), m_compiler_id(rhs.m_compiler_id) {}
+  Diagnostic(DiagnosticOrigin origin, uint32_t compiler_id,
+ DiagnosticDetail detail)
+  : m_origin(origin), m_compiler_id(compiler_id), m_detail(detail) {}
 
   virtual ~Diagnostic() = default;
 
   virtual bool HasFixIts() const { return false; }
 
-  lldb::Severity GetSeverity() const { return m_severity; }
+  lldb::Severity GetSeverity() const { return m_detail.severity; }
 
   uint32_t GetCompilerID() const { return m_compiler_id; }
 
-  llvm::StringRef 

[Lldb-commits] [lldb] [lldb] Store expression evaluator diagnostics in an llvm::Error (NFC) (PR #106442)

2024-09-18 Thread Adrian Prantl via lldb-commits

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

>From 40d336f5ffcbf36346eb017f65c0c150fc7190d2 Mon Sep 17 00:00:00 2001
From: Adrian Prantl 
Date: Wed, 28 Aug 2024 10:04:33 -0700
Subject: [PATCH] [lldb] Store expression evaluator diagnostics in an
 llvm::Error (NFC)

This patch is a reworking of Pete Lawrence's (@PortalPete) proposal
for better expression evaluator error messages:
https://github.com/llvm/llvm-project/pull/80938

This patch is preparatory patch for improving the rendering of
expression evaluator diagnostics. Currently diagnostics are rendered
into a string and the command interpreter layer then textually parses
words like "error:" to (sometimes) color the output accordingly. In
order to enable user interfaces to do better with diagnostics, we need
to store them in a machine-readable fromat. This patch does this by
adding a new llvm::Error kind wrapping a DiagnosticDetail struct that
is used when the error type is eErrorTypeExpression. Multiple
diagnostics are modeled using llvm::ErrorList.

Right now the extra information is not used by the CommandInterpreter,
this will be added in a follow-up patch!
---
 .../lldb/Expression/DiagnosticManager.h   | 88 ++-
 lldb/include/lldb/Utility/Status.h|  5 +-
 lldb/source/Breakpoint/BreakpointLocation.cpp | 10 +--
 lldb/source/Expression/DiagnosticManager.cpp  | 83 +
 lldb/source/Expression/ExpressionParser.cpp   |  5 +-
 lldb/source/Expression/UserExpression.cpp | 28 +++---
 lldb/source/Expression/UtilityFunction.cpp| 16 ++--
 .../ExpressionParser/Clang/ClangDiagnostic.h  |  5 +-
 .../Clang/ClangExpressionParser.cpp   | 57 +---
 .../Plugins/Platform/POSIX/PlatformPOSIX.cpp  | 10 +--
 .../Platform/Windows/PlatformWindows.cpp  | 10 +--
 lldb/source/Target/Target.cpp |  2 +-
 lldb/source/Utility/Status.cpp|  7 ++
 .../TestModulesCompileError.py|  2 +-
 .../Expression/DiagnosticManagerTest.cpp  | 12 +--
 15 files changed, 229 insertions(+), 111 deletions(-)

diff --git a/lldb/include/lldb/Expression/DiagnosticManager.h 
b/lldb/include/lldb/Expression/DiagnosticManager.h
index d49b7c99b114fb..bcf108a4d9d398 100644
--- a/lldb/include/lldb/Expression/DiagnosticManager.h
+++ b/lldb/include/lldb/Expression/DiagnosticManager.h
@@ -12,6 +12,9 @@
 #include "lldb/lldb-defines.h"
 #include "lldb/lldb-types.h"
 
+#include "lldb/Utility/FileSpec.h"
+#include "lldb/Utility/Status.h"
+
 #include "llvm/ADT/STLExtras.h"
 #include "llvm/ADT/StringRef.h"
 
@@ -20,6 +23,47 @@
 
 namespace lldb_private {
 
+/// A compiler-independent representation of a Diagnostic. Expression
+/// evaluation failures often have more than one diagnostic that a UI
+/// layer might want to render differently, for example to colorize
+/// it.
+///
+/// Running example:
+///   (lldb) expr 1+foo
+///   error: :1:3: use of undeclared identifier 'foo'
+///   1+foo
+/// ^
+struct DiagnosticDetail {
+  struct SourceLocation {
+FileSpec file;
+unsigned line = 0;
+uint16_t column = 0;
+uint16_t length = 0;
+bool in_user_input = false;
+  };
+  /// Contains {{}, 1, 3, 3, true} in the example above.
+  std::optional source_location;
+  /// Contains eSeverityError in the example above.
+  lldb::Severity severity = lldb::eSeverityInfo;
+  /// Contains "use of undeclared identifier 'x'" in the example above.
+  std::string message;
+  /// Contains the fully rendered error message.
+  std::string rendered;
+};
+
+/// An llvm::Error used to communicate diagnostics in Status. Multiple
+/// diagnostics may be chained in an llvm::ErrorList.
+class DetailedExpressionError
+: public llvm::ErrorInfo {
+  DiagnosticDetail m_detail;
+
+public:
+  using llvm::ErrorInfo::ErrorInfo;
+  DetailedExpressionError(DiagnosticDetail detail) : m_detail(detail) {}
+  std::string message() const override;
+  static char ID;
+};
+
 enum DiagnosticOrigin {
   eDiagnosticOriginUnknown = 0,
   eDiagnosticOriginLLDB,
@@ -49,37 +93,28 @@ class Diagnostic {
 }
   }
 
-  Diagnostic(llvm::StringRef message, lldb::Severity severity,
- DiagnosticOrigin origin, uint32_t compiler_id)
-  : m_message(message), m_severity(severity), m_origin(origin),
-m_compiler_id(compiler_id) {}
-
-  Diagnostic(const Diagnostic &rhs)
-  : m_message(rhs.m_message), m_severity(rhs.m_severity),
-m_origin(rhs.m_origin), m_compiler_id(rhs.m_compiler_id) {}
+  Diagnostic(DiagnosticOrigin origin, uint32_t compiler_id,
+ DiagnosticDetail detail)
+  : m_origin(origin), m_compiler_id(compiler_id), m_detail(detail) {}
 
   virtual ~Diagnostic() = default;
 
   virtual bool HasFixIts() const { return false; }
 
-  lldb::Severity GetSeverity() const { return m_severity; }
+  lldb::Severity GetSeverity() const { return m_detail.severity; }
 
   uint32_t GetCompilerID() const { return m_compiler_id; }
 
-  llvm::StringRef G

[Lldb-commits] [lldb] b4a8e87 - Add noexcept qualifier to placate g++

2024-09-18 Thread Adrian Prantl via lldb-commits

Author: Adrian Prantl
Date: 2024-09-18T15:03:41-07:00
New Revision: b4a8e877ee3002a8cfd613f7950afcbe1d98821c

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

LOG: Add noexcept qualifier to placate g++

Added: 


Modified: 
lldb/source/Utility/Status.cpp

Removed: 




diff  --git a/lldb/source/Utility/Status.cpp b/lldb/source/Utility/Status.cpp
index faa8d3a83c7ed1..f557cb540b5655 100644
--- a/lldb/source/Utility/Status.cpp
+++ b/lldb/source/Utility/Status.cpp
@@ -48,7 +48,7 @@ char ExpressionError::ID;
 namespace {
 /// A std::error_code category for eErrorTypeGeneric.
 class LLDBGenericCategory : public std::error_category {
-  const char *name() const override { return "LLDBGenericCategory"; }
+  const char *name() const noexcept override { return "LLDBGenericCategory"; }
   std::string message(int __ev) const override { return "generic LLDB error"; 
};
 };
 LLDBGenericCategory &lldb_generic_category() {
@@ -58,7 +58,9 @@ LLDBGenericCategory &lldb_generic_category() {
 
 /// A std::error_code category for eErrorTypeExpression.
 class ExpressionCategory : public std::error_category {
-  const char *name() const override { return "LLDBExpressionCategory"; }
+  const char *name() const noexcept override {
+return "LLDBExpressionCategory";
+  }
   std::string message(int __ev) const override {
 return ExpressionResultAsCString(
 static_cast(__ev));



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


[Lldb-commits] [lldb] [lldb] Store expression evaluator diagnostics in an llvm::Error (NFC) (PR #106442)

2024-09-18 Thread Adrian Prantl via lldb-commits

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

>From 334ef4edf74541e4c67b24c7078a90c939692122 Mon Sep 17 00:00:00 2001
From: Adrian Prantl 
Date: Wed, 4 Sep 2024 12:50:37 -0700
Subject: [PATCH] [lldb] Change the implementation of Status to store an
 llvm::Error (NFC)

Most APIs that currently vend a Status would be better served by
returning llvm::Expected<> instead. Where possible, APIs should be
refactored to avoid Status. The only legitimate long-term uses of
Status are objects that need to store an error for a long time (which
should be questioned as a design decision, too).

This patch makes the transition to llvm::Error easier by making the
places that cannot switch to llvm::Error explicit: They are marked
with a call to Status::clone(). Every other API can and should be
refactored to use llvm::Expected. In the end Status should only be
used in very few places.

Whenever an unchecked Error is dropped by Status it logs this to the
verbose API channel.

Implementation notes:

This patch introduces two new kinds of error_category as well as new
llvm::Error types. Here is the mapping of lldb::ErrorType to
llvm::Errors:

   (eErrorTypeInvalid)
   eErrorTypeGeneric  llvm::StringError
   eErrorTypePOSIXllvm::ECError
   eErrorTypeMachKernel   MachKernelError
   eErrorTypeExpression   llvm::ErrorList
   eErrorTypeWin32Win32Error
---
 lldb/include/lldb/Utility/Status.h|  83 +-
 .../Python/PythonDataObjects.cpp  |  31 ++-
 lldb/source/Utility/Status.cpp| 245 --
 lldb/unittests/Utility/StatusTest.cpp |   8 +
 4 files changed, 266 insertions(+), 101 deletions(-)

diff --git a/lldb/include/lldb/Utility/Status.h 
b/lldb/include/lldb/Utility/Status.h
index 795c830b965173..64e193f8d84206 100644
--- a/lldb/include/lldb/Utility/Status.h
+++ b/lldb/include/lldb/Utility/Status.h
@@ -28,6 +28,67 @@ namespace lldb_private {
 
 const char *ExpressionResultAsCString(lldb::ExpressionResults result);
 
+/// Going a bit against the spirit of llvm::Error,
+/// lldb_private::Status need to store errors long-term and sometimes
+/// copy them. This base class defines an interface for this
+/// operation.
+class CloneableError
+: public llvm::ErrorInfo {
+public:
+  using llvm::ErrorInfo::ErrorInfo;
+  CloneableError() : ErrorInfo() {}
+  virtual std::unique_ptr Clone() const = 0;
+  static char ID;
+};
+
+/// Common base class for all error-code errors.
+class CloneableECError
+: public llvm::ErrorInfo {
+public:
+  using llvm::ErrorInfo::ErrorInfo;
+  CloneableECError(std::error_code ec) : ErrorInfo() {}
+  std::error_code convertToErrorCode() const override { return EC; }
+  void log(llvm::raw_ostream &OS) const override { OS << EC.message(); }
+  static char ID;
+
+protected:
+  std::error_code EC;
+};
+
+/// FIXME: Move these declarations closer to where they're used.
+class MachKernelError
+: public llvm::ErrorInfo {
+public:
+  using llvm::ErrorInfo::ErrorInfo;
+  MachKernelError(std::error_code ec) : ErrorInfo(ec) {}
+  std::string message() const override;
+  std::unique_ptr Clone() const override;
+  static char ID;
+};
+
+class Win32Error : public llvm::ErrorInfo {
+public:
+  using llvm::ErrorInfo::ErrorInfo;
+  Win32Error(std::error_code ec, const llvm::Twine &msg = {}) : ErrorInfo(ec) 
{}
+  std::string message() const override;
+  std::unique_ptr Clone() const override;
+  static char ID;
+};
+
+class ExpressionError
+: public llvm::ErrorInfo {
+public:
+  using llvm::ErrorInfo::ErrorInfo;
+  ExpressionError(std::error_code ec, std::string msg = {})
+  : ErrorInfo(ec), m_string(msg) {}
+  std::unique_ptr Clone() const override;
+  std::string message() const override { return m_string; }
+  static char ID;
+
+protected:
+  std::string m_string;
+};
+
 /// \class Status Status.h "lldb/Utility/Status.h" An error handling class.
 ///
 /// This class is designed to be able to hold any error code that can be
@@ -100,9 +161,7 @@ class Status {
   }
 
   static Status FromExpressionError(lldb::ExpressionResults result,
-std::string msg) {
-return Status(result, lldb::eErrorTypeExpression, msg);
-  }
+std::string msg);
 
   /// Set the current error to errno.
   ///
@@ -115,6 +174,7 @@ class Status {
   const Status &operator=(Status &&);
   /// Avoid using this in new code. Migrate APIs to llvm::Expected instead.
   static Status FromError(llvm::Error error);
+
   /// FIXME: Replace this with a takeError() method.
   llvm::Error ToError() const;
   /// Don't call this function in new code. Instead, redesign the API
@@ -149,12 +209,20 @@ class Status {
 
   /// Access the error value.
   ///
+  /// If the internally stored \ref llvm::Error is an \ref
+  /// llvm::ErrorList then this returns the error value of the first
+  /// error.
+  ///
   /// \return
   /// The error v

[Lldb-commits] [lldb] [lldb] Change the implementation of Status to store an llvm::Error (NFC) (PR #106774)

2024-09-18 Thread LLVM Continuous Integration via lldb-commits

llvm-ci wrote:

LLVM Buildbot has detected a new failure on builder 
`cross-project-tests-sie-ubuntu` running on `doug-worker-1a` while building 
`lldb` at step 5 "build-unified-tree".

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


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

```
Step 5 (build-unified-tree) failure: build (failure)
...
30.949 [870/8/41] Building CXX object 
tools/lldb/source/Host/CMakeFiles/lldbHost.dir/posix/HostProcessPosix.cpp.o
31.619 [869/8/42] Building CXX object 
tools/lldb/source/Host/CMakeFiles/lldbHost.dir/posix/LockFilePosix.cpp.o
32.578 [868/8/43] Building CXX object 
tools/lldb/source/Host/CMakeFiles/lldbHost.dir/posix/ConnectionFileDescriptorPosix.cpp.o
33.587 [867/8/44] Building CXX object 
tools/lldb/source/Host/CMakeFiles/lldbHost.dir/linux/AbstractSocket.cpp.o
33.702 [866/8/45] Building CXX object lib/LTO/CMakeFiles/LLVMLTO.dir/LTO.cpp.o
34.561 [865/8/46] Building CXX object 
tools/lldb/source/Host/CMakeFiles/lldbHost.dir/posix/MainLoopPosix.cpp.o
35.570 [864/8/47] Building CXX object 
tools/lldb/source/Host/CMakeFiles/lldbHost.dir/posix/PipePosix.cpp.o
35.601 [863/8/48] Generating VCSVersion.inc
36.510 [862/8/49] Building CXX object 
tools/lldb/source/Utility/CMakeFiles/lldbUtility.dir/StringExtractorGDBRemote.cpp.o
36.578 [861/8/50] Building CXX object 
tools/lldb/source/Utility/CMakeFiles/lldbUtility.dir/Status.cpp.o
FAILED: tools/lldb/source/Utility/CMakeFiles/lldbUtility.dir/Status.cpp.o 
/opt/ccache/bin/g++ -DGTEST_HAS_RTTI=0 -DHAVE_ROUND -D_DEBUG 
-D_GLIBCXX_ASSERTIONS -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS 
-D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS 
-I/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu/build/tools/lldb/source/Utility
 
-I/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu/llvm-project/lldb/source/Utility
 
-I/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu/llvm-project/lldb/include
 
-I/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu/build/tools/lldb/include
 -I/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu/build/include 
-I/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu/llvm-project/llvm/include
 -I/usr/include/python3.8 
-I/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu/llvm-project/llvm/../clang/include
 
-I/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu/build/tools/lldb/../clang/include
 -I/usr/include/libxml2 
-I/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu/llvm-project/lldb/source
 
-I/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu/build/tools/lldb/source
 -fPIC -fno-semantic-interposition -fvisibility-inlines-hidden 
-Werror=date-time -fno-lifetime-dse -Wall -Wextra -Wno-unused-parameter 
-Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic 
-Wno-long-long -Wimplicit-fallthrough -Wno-uninitialized -Wno-nonnull 
-Wno-class-memaccess -Wno-redundant-move -Wno-pessimizing-move 
-Wno-noexcept-type -Wdelete-non-virtual-dtor -Wsuggest-override -Wno-comment 
-Wno-misleading-indentation -fdiagnostics-color -ffunction-sections 
-fdata-sections -Wno-deprecated-declarations -Wno-unknown-pragmas 
-Wno-strict-aliasing -Wno-stringop-truncation -O3 -DNDEBUG  -fno-exceptions 
-funwind-tables -fno-rtti -UNDEBUG -std=c++17 -MD -MT 
tools/lldb/source/Utility/CMakeFiles/lldbUtility.dir/Status.cpp.o -MF 
tools/lldb/source/Utility/CMakeFiles/lldbUtility.dir/Status.cpp.o.d -o 
tools/lldb/source/Utility/CMakeFiles/lldbUtility.dir/Status.cpp.o -c 
/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu/llvm-project/lldb/source/Utility/Status.cpp
/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu/llvm-project/lldb/source/Utility/Status.cpp:51:15:
 error: looser throw specifier for ‘virtual const char* 
{anonymous}::LLDBGenericCategory::name() const’
   51 |   const char *name() const override { return "LLDBGenericCategory"; }
  |   ^~~~
In file included from /usr/include/c++/9/bits/ios_base.h:46,
 from /usr/include/c++/9/ios:42,
 from /usr/include/c++/9/ostream:38,
 from /usr/include/c++/9/iterator:64,
 from 
/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu/llvm-project/llvm/include/llvm/ADT/ADL.h:13,
 from 
/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu/llvm-project/llvm/include/llvm/ADT/iterator_range.h:21,
 from 
/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu/llvm-project/llvm/include/llvm/ADT/StringRef.h:14,
 from 
/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu/llvm-project/lldb/include/lldb/Utility/Status.h:14,
 from 
/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu/llvm-project/lldb/source/Utility/Status.cpp:9:
/usr/include/c++/9/system_error:85:5: note: overridden function is ‘virtual 
const char* std::_V2::error_category::name() const noexcept’
   85 |

[Lldb-commits] [lldb] [lldb] Change the implementation of Status to store an llvm::Error (NFC) (PR #106774)

2024-09-18 Thread LLVM Continuous Integration via lldb-commits

llvm-ci wrote:

LLVM Buildbot has detected a new failure on builder 
`cross-project-tests-sie-ubuntu-dwarf5` running on `doug-worker-1b` while 
building `lldb` at step 5 "build-unified-tree".

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


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

```
Step 5 (build-unified-tree) failure: build (failure)
...
26.658 [871/8/40] Building CXX object 
tools/lldb/source/Host/CMakeFiles/lldbHost.dir/posix/HostProcessPosix.cpp.o
27.193 [870/8/41] Building CXX object 
tools/lldb/source/Host/CMakeFiles/lldbHost.dir/posix/HostThreadPosix.cpp.o
27.872 [869/8/42] Building CXX object 
tools/lldb/source/Host/CMakeFiles/lldbHost.dir/posix/LockFilePosix.cpp.o
28.928 [868/8/43] Building CXX object 
tools/lldb/source/Host/CMakeFiles/lldbHost.dir/posix/ConnectionFileDescriptorPosix.cpp.o
29.459 [867/8/44] Building CXX object 
tools/lldb/source/Host/CMakeFiles/lldbHost.dir/linux/AbstractSocket.cpp.o
30.363 [866/8/45] Building CXX object 
tools/lldb/source/Host/CMakeFiles/lldbHost.dir/posix/MainLoopPosix.cpp.o
30.684 [865/8/46] Building CXX object lib/LTO/CMakeFiles/LLVMLTO.dir/LTO.cpp.o
30.898 [864/8/47] Building CXX object 
tools/lldb/source/Host/CMakeFiles/lldbHost.dir/posix/PipePosix.cpp.o
30.957 [863/8/48] Generating VCSVersion.inc
32.072 [862/8/49] Building CXX object 
tools/lldb/source/Utility/CMakeFiles/lldbUtility.dir/Status.cpp.o
FAILED: tools/lldb/source/Utility/CMakeFiles/lldbUtility.dir/Status.cpp.o 
/opt/ccache/bin/g++ -DGTEST_HAS_RTTI=0 -DHAVE_ROUND -D_DEBUG 
-D_GLIBCXX_ASSERTIONS -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS 
-D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS 
-I/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu-dwarf5/build/tools/lldb/source/Utility
 
-I/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu-dwarf5/llvm-project/lldb/source/Utility
 
-I/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu-dwarf5/llvm-project/lldb/include
 
-I/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu-dwarf5/build/tools/lldb/include
 
-I/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu-dwarf5/build/include
 
-I/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu-dwarf5/llvm-project/llvm/include
 -I/usr/include/python3.10 
-I/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu-dwarf5/llvm-project/llvm/../clang/include
 
-I/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu-dwarf5/build/tools/lldb/../clang/include
 
-I/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu-dwarf5/llvm-project/lldb/source
 
-I/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu-dwarf5/build/tools/lldb/source
 -fPIC -fno-semantic-interposition -fvisibility-inlines-hidden 
-Werror=date-time -fno-lifetime-dse -Wall -Wextra -Wno-unused-parameter 
-Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic 
-Wno-long-long -Wimplicit-fallthrough -Wno-uninitialized -Wno-nonnull 
-Wno-class-memaccess -Wno-redundant-move -Wno-pessimizing-move 
-Wno-noexcept-type -Wdelete-non-virtual-dtor -Wsuggest-override -Wno-comment 
-Wno-misleading-indentation -Wctad-maybe-unsupported -fdiagnostics-color 
-ffunction-sections -fdata-sections -Wno-deprecated-declarations 
-Wno-unknown-pragmas -Wno-strict-aliasing -Wno-stringop-truncation -O3 -DNDEBUG 
 -fno-exceptions -funwind-tables -fno-rtti -UNDEBUG -std=c++17 -MD -MT 
tools/lldb/source/Utility/CMakeFiles/lldbUtility.dir/Status.cpp.o -MF 
tools/lldb/source/Utility/CMakeFiles/lldbUtility.dir/Status.cpp.o.d -o 
tools/lldb/source/Utility/CMakeFiles/lldbUtility.dir/Status.cpp.o -c 
/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu-dwarf5/llvm-project/lldb/source/Utility/Status.cpp
/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu-dwarf5/llvm-project/lldb/source/Utility/Status.cpp:51:15:
 error: looser exception specification on overriding virtual function ‘virtual 
const char* {anonymous}::LLDBGenericCategory::name() const’
   51 |   const char *name() const override { return "LLDBGenericCategory"; }
  |   ^~~~
In file included from /usr/include/c++/11/bits/ios_base.h:46,
 from /usr/include/c++/11/streambuf:41,
 from /usr/include/c++/11/bits/streambuf_iterator.h:35,
 from /usr/include/c++/11/iterator:66,
 from 
/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu-dwarf5/llvm-project/llvm/include/llvm/ADT/ADL.h:13,
 from 
/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu-dwarf5/llvm-project/llvm/include/llvm/ADT/iterator_range.h:21,
 from 
/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu-dwarf5/llvm-project/llvm/include/llvm/ADT/StringRef.h:14,
 from 
/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu-dwarf5/llvm-project/lldb/include/lldb/Utility/Status.h:14,
 from 
/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu-dwarf5/llvm-pr

[Lldb-commits] [lldb] [llvm] [lldb][RISCV] function calls support in lldb expressions (PR #99336)

2024-09-18 Thread Jason Molenda via lldb-commits

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

I don't feel like I am an authoritative owner of the parts being modified by 
this PR, but I am fine with this fwiw.

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


[Lldb-commits] [lldb] [lldb] Change the implementation of Status to store an llvm::Error (NFC) (PR #106774)

2024-09-18 Thread Adrian Prantl via lldb-commits

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


[Lldb-commits] [lldb] 06939fa - [lldb] Change the implementation of Status to store an llvm::Error (NFC) (#106774)

2024-09-18 Thread via lldb-commits

Author: Adrian Prantl
Date: 2024-09-18T14:54:49-07:00
New Revision: 06939fa2e140a171132275ec0ea1857d20c5dbdd

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

LOG: [lldb] Change the implementation of Status to store an llvm::Error (NFC) 
(#106774)

(based on a conversation I had with @labath yesterday in
https://github.com/llvm/llvm-project/pull/106442)

Most APIs that currently vend a Status would be better served by
returning llvm::Expected<> instead. If possibles APIs should be
refactored to avoid Status. The only legitimate long-term uses of Status
are objects that need to store an error for a long time (which should be
questioned as a design decision, too).

This patch makes the transition to llvm::Error easier by making the
places that cannot switch to llvm::Error explicit: They are marked with
a call to Status::clone(). Every other API can and should be refactored
to use llvm::Expected. In the end Status should only be used in very few
places.

Whenever an unchecked Error is dropped by Status it logs this to the
verbose API channel.

Implementation notes:

This patch introduces two new kinds of error_category as well as new
llvm::Error types. Here is the mapping of lldb::ErrorType to
llvm::Errors:
```
   (eErrorTypeInvalid)
   eErrorTypeGeneric  llvm::StringError
   eErrorTypePOSIXllvm::ECError
   eErrorTypeMachKernel   MachKernelError
   eErrorTypeExpression   llvm::ErrorList
   eErrorTypeWin32Win32Error
```

Added: 


Modified: 
lldb/include/lldb/Utility/Status.h
lldb/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.cpp
lldb/source/Utility/Status.cpp
lldb/unittests/TestingSupport/Host/SocketTestUtilities.cpp
lldb/unittests/Utility/StatusTest.cpp

Removed: 




diff  --git a/lldb/include/lldb/Utility/Status.h 
b/lldb/include/lldb/Utility/Status.h
index 795c830b965173..4a09c38ce62f1b 100644
--- a/lldb/include/lldb/Utility/Status.h
+++ b/lldb/include/lldb/Utility/Status.h
@@ -28,6 +28,69 @@ namespace lldb_private {
 
 const char *ExpressionResultAsCString(lldb::ExpressionResults result);
 
+/// Going a bit against the spirit of llvm::Error,
+/// lldb_private::Status need to store errors long-term and sometimes
+/// copy them. This base class defines an interface for this
+/// operation.
+class CloneableError
+: public llvm::ErrorInfo {
+public:
+  using llvm::ErrorInfo::ErrorInfo;
+  CloneableError() : ErrorInfo() {}
+  virtual std::unique_ptr Clone() const = 0;
+  static char ID;
+};
+
+/// Common base class for all error-code errors.
+class CloneableECError
+: public llvm::ErrorInfo {
+public:
+  using llvm::ErrorInfo::ErrorInfo;
+  CloneableECError() = delete;
+  CloneableECError(std::error_code ec) : ErrorInfo(), EC(ec) {}
+  std::error_code convertToErrorCode() const override { return EC; }
+  void log(llvm::raw_ostream &OS) const override { OS << EC.message(); }
+  std::unique_ptr Clone() const override;
+  static char ID;
+
+protected:
+  std::error_code EC;
+};
+
+/// FIXME: Move these declarations closer to where they're used.
+class MachKernelError
+: public llvm::ErrorInfo {
+public:
+  using llvm::ErrorInfo::ErrorInfo;
+  MachKernelError(std::error_code ec) : ErrorInfo(ec) {}
+  std::string message() const override;
+  std::unique_ptr Clone() const override;
+  static char ID;
+};
+
+class Win32Error : public llvm::ErrorInfo {
+public:
+  using llvm::ErrorInfo::ErrorInfo;
+  Win32Error(std::error_code ec, const llvm::Twine &msg = {}) : ErrorInfo(ec) 
{}
+  std::string message() const override;
+  std::unique_ptr Clone() const override;
+  static char ID;
+};
+
+class ExpressionError
+: public llvm::ErrorInfo {
+public:
+  using llvm::ErrorInfo::ErrorInfo;
+  ExpressionError(std::error_code ec, std::string msg = {})
+  : ErrorInfo(ec), m_string(msg) {}
+  std::unique_ptr Clone() const override;
+  std::string message() const override { return m_string; }
+  static char ID;
+
+protected:
+  std::string m_string;
+};
+
 /// \class Status Status.h "lldb/Utility/Status.h" An error handling class.
 ///
 /// This class is designed to be able to hold any error code that can be
@@ -100,9 +163,7 @@ class Status {
   }
 
   static Status FromExpressionError(lldb::ExpressionResults result,
-std::string msg) {
-return Status(result, lldb::eErrorTypeExpression, msg);
-  }
+std::string msg);
 
   /// Set the current error to errno.
   ///
@@ -115,6 +176,7 @@ class Status {
   const Status &operator=(Status &&);
   /// Avoid using this in new code. Migrate APIs to llvm::Expected instead.
   static Status FromError(llvm::Error error);
+
   /// FIXME: Replace this with a takeError() method.
   llvm::Error ToError() const;
   /// Don't call

[Lldb-commits] [lldb] [lldb] Change the implementation of Status to store an llvm::Error (NFC) (PR #106774)

2024-09-18 Thread Adrian Prantl via lldb-commits

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

>From 6d240b3254192763f0b67b70ed36616dfcf9e565 Mon Sep 17 00:00:00 2001
From: Adrian Prantl 
Date: Wed, 4 Sep 2024 12:50:37 -0700
Subject: [PATCH] [lldb] Change the implementation of Status to store an
 llvm::Error (NFC)

Most APIs that currently vend a Status would be better served by
returning llvm::Expected<> instead. Where possible, APIs should be
refactored to avoid Status. The only legitimate long-term uses of
Status are objects that need to store an error for a long time (which
should be questioned as a design decision, too).

This patch makes the transition to llvm::Error easier by making the
places that cannot switch to llvm::Error explicit: They are marked
with a call to Status::clone(). Every other API can and should be
refactored to use llvm::Expected. In the end Status should only be
used in very few places.

Whenever an unchecked Error is dropped by Status it logs this to the
verbose API channel.

Implementation notes:

This patch introduces two new kinds of error_category as well as new
llvm::Error types. Here is the mapping of lldb::ErrorType to
llvm::Errors:

   (eErrorTypeInvalid)
   eErrorTypeGeneric  llvm::StringError
   eErrorTypePOSIXllvm::ECError
   eErrorTypeMachKernel   MachKernelError
   eErrorTypeExpression   llvm::ErrorList
   eErrorTypeWin32Win32Error
---
 lldb/include/lldb/Utility/Status.h|  85 +-
 .../Python/PythonDataObjects.cpp  |  31 ++-
 lldb/source/Utility/Status.cpp| 253 --
 .../Host/SocketTestUtilities.cpp  |  16 +-
 lldb/unittests/Utility/StatusTest.cpp |   8 +
 5 files changed, 285 insertions(+), 108 deletions(-)

diff --git a/lldb/include/lldb/Utility/Status.h 
b/lldb/include/lldb/Utility/Status.h
index 795c830b965173..4a09c38ce62f1b 100644
--- a/lldb/include/lldb/Utility/Status.h
+++ b/lldb/include/lldb/Utility/Status.h
@@ -28,6 +28,69 @@ namespace lldb_private {
 
 const char *ExpressionResultAsCString(lldb::ExpressionResults result);
 
+/// Going a bit against the spirit of llvm::Error,
+/// lldb_private::Status need to store errors long-term and sometimes
+/// copy them. This base class defines an interface for this
+/// operation.
+class CloneableError
+: public llvm::ErrorInfo {
+public:
+  using llvm::ErrorInfo::ErrorInfo;
+  CloneableError() : ErrorInfo() {}
+  virtual std::unique_ptr Clone() const = 0;
+  static char ID;
+};
+
+/// Common base class for all error-code errors.
+class CloneableECError
+: public llvm::ErrorInfo {
+public:
+  using llvm::ErrorInfo::ErrorInfo;
+  CloneableECError() = delete;
+  CloneableECError(std::error_code ec) : ErrorInfo(), EC(ec) {}
+  std::error_code convertToErrorCode() const override { return EC; }
+  void log(llvm::raw_ostream &OS) const override { OS << EC.message(); }
+  std::unique_ptr Clone() const override;
+  static char ID;
+
+protected:
+  std::error_code EC;
+};
+
+/// FIXME: Move these declarations closer to where they're used.
+class MachKernelError
+: public llvm::ErrorInfo {
+public:
+  using llvm::ErrorInfo::ErrorInfo;
+  MachKernelError(std::error_code ec) : ErrorInfo(ec) {}
+  std::string message() const override;
+  std::unique_ptr Clone() const override;
+  static char ID;
+};
+
+class Win32Error : public llvm::ErrorInfo {
+public:
+  using llvm::ErrorInfo::ErrorInfo;
+  Win32Error(std::error_code ec, const llvm::Twine &msg = {}) : ErrorInfo(ec) 
{}
+  std::string message() const override;
+  std::unique_ptr Clone() const override;
+  static char ID;
+};
+
+class ExpressionError
+: public llvm::ErrorInfo {
+public:
+  using llvm::ErrorInfo::ErrorInfo;
+  ExpressionError(std::error_code ec, std::string msg = {})
+  : ErrorInfo(ec), m_string(msg) {}
+  std::unique_ptr Clone() const override;
+  std::string message() const override { return m_string; }
+  static char ID;
+
+protected:
+  std::string m_string;
+};
+
 /// \class Status Status.h "lldb/Utility/Status.h" An error handling class.
 ///
 /// This class is designed to be able to hold any error code that can be
@@ -100,9 +163,7 @@ class Status {
   }
 
   static Status FromExpressionError(lldb::ExpressionResults result,
-std::string msg) {
-return Status(result, lldb::eErrorTypeExpression, msg);
-  }
+std::string msg);
 
   /// Set the current error to errno.
   ///
@@ -115,6 +176,7 @@ class Status {
   const Status &operator=(Status &&);
   /// Avoid using this in new code. Migrate APIs to llvm::Expected instead.
   static Status FromError(llvm::Error error);
+
   /// FIXME: Replace this with a takeError() method.
   llvm::Error ToError() const;
   /// Don't call this function in new code. Instead, redesign the API
@@ -149,12 +211,20 @@ class Status {
 
   /// Access the error value.
   ///
+  /// If the internally stored \ref llvm::Error 

[Lldb-commits] [lldb] a7c1745 - [lldb] Only send "posix" error codes through the gdb-remote protocol

2024-09-18 Thread Adrian Prantl via lldb-commits

Author: Pavel Labath
Date: 2024-09-18T14:53:42-07:00
New Revision: a7c174502aef45b2d33291129cce10c085fef944

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

LOG: [lldb] Only send "posix" error codes through the gdb-remote protocol

The other side has no way of telling which namespace do these codes
belong to, so mashing them all together is not very helpful.

I'm mainly doing this to simplify some code in a pending patch
,
and I've picked the posix error category semi-randomly. If we wanted to
be serious about assigning meaning to these error codes, we should
create a special error category for "gdb errors".

Added: 


Modified: 
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServer.cpp
lldb/unittests/Process/gdb-remote/GDBRemoteCommunicationServerTest.cpp

Removed: 




diff  --git 
a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServer.cpp 
b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServer.cpp
index 9b72cb00352821..d4aa90b2c7731a 100644
--- a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServer.cpp
+++ b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServer.cpp
@@ -103,13 +103,14 @@ GDBRemoteCommunicationServer::SendErrorResponse(uint8_t 
err) {
 
 GDBRemoteCommunication::PacketResult
 GDBRemoteCommunicationServer::SendErrorResponse(const Status &error) {
+  uint8_t code = error.GetType() == eErrorTypePOSIX ? error.GetError() : 0xff;
   if (m_send_error_strings) {
 lldb_private::StreamString packet;
-packet.Printf("E%2.2x;", static_cast(error.GetError()));
+packet.Printf("E%2.2x;", code);
 packet.PutStringAsRawHex8(error.AsCString());
 return SendPacketNoLock(packet.GetString());
-  } else
-return SendErrorResponse(error.GetError());
+  }
+  return SendErrorResponse(code);
 }
 
 GDBRemoteCommunication::PacketResult

diff  --git 
a/lldb/unittests/Process/gdb-remote/GDBRemoteCommunicationServerTest.cpp 
b/lldb/unittests/Process/gdb-remote/GDBRemoteCommunicationServerTest.cpp
index 69ca1720c04fc9..ba9ca6ea73e3be 100644
--- a/lldb/unittests/Process/gdb-remote/GDBRemoteCommunicationServerTest.cpp
+++ b/lldb/unittests/Process/gdb-remote/GDBRemoteCommunicationServerTest.cpp
@@ -12,6 +12,7 @@
 #include "Plugins/Process/gdb-remote/GDBRemoteCommunicationServer.h"
 #include "lldb/Utility/Connection.h"
 #include "lldb/Utility/UnimplementedError.h"
+#include "lldb/lldb-enumerations.h"
 
 namespace lldb_private {
 namespace process_gdb_remote {
@@ -25,7 +26,7 @@ TEST(GDBRemoteCommunicationServerTest, 
SendErrorResponse_ErrorNumber) {
 
 TEST(GDBRemoteCommunicationServerTest, SendErrorResponse_Status) {
   MockServerWithMockConnection server;
-  Status status(0x42, lldb::eErrorTypeGeneric, "Test error message");
+  Status status(0x42, lldb::eErrorTypePOSIX, "Test error message");
   server.SendErrorResponse(status);
 
   EXPECT_THAT(



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


[Lldb-commits] [lldb] [llvm] [lldb][RISCV] function calls support in lldb expressions (PR #99336)

2024-09-18 Thread Jason Molenda via lldb-commits

jasonmolenda wrote:

> As for lldb, maybe it can be useful to obtain features flags from `ArchSpec`, 
> but I think this should be done in a separate PR, if you don't mind.

Yes, agree with doing this separately so we can get this PR landed.

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


[Lldb-commits] [lldb] [lldb] Change the implementation of Status to store an llvm::Error (NFC) (PR #106774)

2024-09-18 Thread Adrian Prantl via lldb-commits

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

>From 34a856d47322cd35a7b568a335adbcd804f2302d Mon Sep 17 00:00:00 2001
From: Pavel Labath 
Date: Wed, 11 Sep 2024 10:35:37 +0200
Subject: [PATCH 1/2] [lldb] Only send "posix" error codes through the
 gdb-remote protocol

The other side has no way of telling which namespace do these codes
belong to, so mashing them all together is not very helpful.

I'm mainly doing this to simplify some code in a pending patch
,
and I've picked the posix error category semi-randomly. If we wanted to
be serious about assigning meaning to these error codes, we should
create a special error category for "gdb errors".
---
 .../Process/gdb-remote/GDBRemoteCommunicationServer.cpp| 7 ---
 .../gdb-remote/GDBRemoteCommunicationServerTest.cpp| 3 ++-
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git 
a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServer.cpp 
b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServer.cpp
index 9b72cb00352821..d4aa90b2c7731a 100644
--- a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServer.cpp
+++ b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServer.cpp
@@ -103,13 +103,14 @@ GDBRemoteCommunicationServer::SendErrorResponse(uint8_t 
err) {
 
 GDBRemoteCommunication::PacketResult
 GDBRemoteCommunicationServer::SendErrorResponse(const Status &error) {
+  uint8_t code = error.GetType() == eErrorTypePOSIX ? error.GetError() : 0xff;
   if (m_send_error_strings) {
 lldb_private::StreamString packet;
-packet.Printf("E%2.2x;", static_cast(error.GetError()));
+packet.Printf("E%2.2x;", code);
 packet.PutStringAsRawHex8(error.AsCString());
 return SendPacketNoLock(packet.GetString());
-  } else
-return SendErrorResponse(error.GetError());
+  }
+  return SendErrorResponse(code);
 }
 
 GDBRemoteCommunication::PacketResult
diff --git 
a/lldb/unittests/Process/gdb-remote/GDBRemoteCommunicationServerTest.cpp 
b/lldb/unittests/Process/gdb-remote/GDBRemoteCommunicationServerTest.cpp
index 69ca1720c04fc9..ba9ca6ea73e3be 100644
--- a/lldb/unittests/Process/gdb-remote/GDBRemoteCommunicationServerTest.cpp
+++ b/lldb/unittests/Process/gdb-remote/GDBRemoteCommunicationServerTest.cpp
@@ -12,6 +12,7 @@
 #include "Plugins/Process/gdb-remote/GDBRemoteCommunicationServer.h"
 #include "lldb/Utility/Connection.h"
 #include "lldb/Utility/UnimplementedError.h"
+#include "lldb/lldb-enumerations.h"
 
 namespace lldb_private {
 namespace process_gdb_remote {
@@ -25,7 +26,7 @@ TEST(GDBRemoteCommunicationServerTest, 
SendErrorResponse_ErrorNumber) {
 
 TEST(GDBRemoteCommunicationServerTest, SendErrorResponse_Status) {
   MockServerWithMockConnection server;
-  Status status(0x42, lldb::eErrorTypeGeneric, "Test error message");
+  Status status(0x42, lldb::eErrorTypePOSIX, "Test error message");
   server.SendErrorResponse(status);
 
   EXPECT_THAT(

>From 3f483c96cc1bf34e9bd05350f4d0b8e8b2e2 Mon Sep 17 00:00:00 2001
From: Adrian Prantl 
Date: Wed, 4 Sep 2024 12:50:37 -0700
Subject: [PATCH 2/2] [lldb] Change the implementation of Status to store an
 llvm::Error (NFC)

Most APIs that currently vend a Status would be better served by
returning llvm::Expected<> instead. Where possible, APIs should be
refactored to avoid Status. The only legitimate long-term uses of
Status are objects that need to store an error for a long time (which
should be questioned as a design decision, too).

This patch makes the transition to llvm::Error easier by making the
places that cannot switch to llvm::Error explicit: They are marked
with a call to Status::clone(). Every other API can and should be
refactored to use llvm::Expected. In the end Status should only be
used in very few places.

Whenever an unchecked Error is dropped by Status it logs this to the
verbose API channel.

Implementation notes:

This patch introduces two new kinds of error_category as well as new
llvm::Error types. Here is the mapping of lldb::ErrorType to
llvm::Errors:

   (eErrorTypeInvalid)
   eErrorTypeGeneric  llvm::StringError
   eErrorTypePOSIXllvm::ECError
   eErrorTypeMachKernel   MachKernelError
   eErrorTypeExpression   llvm::ErrorList
   eErrorTypeWin32Win32Error
---
 lldb/include/lldb/Utility/Status.h|  85 +-
 .../Python/PythonDataObjects.cpp  |  31 ++-
 lldb/source/Utility/Status.cpp| 253 --
 .../Host/SocketTestUtilities.cpp  |  16 +-
 lldb/unittests/Utility/StatusTest.cpp |   8 +
 5 files changed, 285 insertions(+), 108 deletions(-)

diff --git a/lldb/include/lldb/Utility/Status.h 
b/lldb/include/lldb/Utility/Status.h
index 795c830b965173..4a09c38ce62f1b 100644
--- a/lldb/include/lldb/Utility/Status.h
+++ b/lldb/include/lldb/Utility/Status.h
@@ -28,6 +28,69 @@ namespace lldb_private 

[Lldb-commits] [lldb] Add docs and an example use of the scripted command get_flags API. (PR #109176)

2024-09-18 Thread Adrian Vogelsgesang via lldb-commits

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


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


[Lldb-commits] [lldb] [lldb-dap] Implement value locations for function pointers (PR #104589)

2024-09-18 Thread Adrian Vogelsgesang via lldb-commits


@@ -1198,6 +1198,26 @@ std::string 
VariableDescription::GetResult(llvm::StringRef context) {
   return description.trim().str();
 }
 
+bool HasValueLocation(lldb::SBValue v) {
+  if (!v.GetType().IsPointerType() && !v.GetType().IsReferenceType()) {
+return false;
+  }

vogelsgesang wrote:

should be fixed in the updated PR

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


[Lldb-commits] [lldb] [lldb-dap] Implement value locations for function pointers (PR #104589)

2024-09-18 Thread Adrian Vogelsgesang via lldb-commits

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

>From 79684ccb2b6312b0938de73641e89d7cd29ce1a8 Mon Sep 17 00:00:00 2001
From: Adrian Vogelsgesang 
Date: Mon, 12 Aug 2024 14:53:31 +
Subject: [PATCH 1/3] [lldb-dap] Implement value locations for function
 pointers

This commit adds `valueLocationReference` to function pointers and
function references. Thereby, users can navigate directly to the
pointed-to function from within the "variables" pane.

In general, it would be useful to also a similar location references
also to member function pointers, `std::source_location`,
`std::function`,  and many more. Doing so would require extending the
formatters to provide such a source code location.

There were two RFCs about this a while ago:
https://discourse.llvm.org/t/rfc-extending-formatters-with-a-source-code-reference/68375
https://discourse.llvm.org/t/rfc-sbvalue-metadata-provider/68377/26

However, both RFCs ended without a conclusion. As such, this commit now
solve the lowest-hanging fruit, i.e. function pointers. If people find
it useful, I will revive the RFC afterwards.
---
 .../API/tools/lldb-dap/locations/Makefile |   2 +-
 .../lldb-dap/locations/TestDAP_locations.py   |  49 +++-
 lldb/test/API/tools/lldb-dap/locations/main.c |   5 -
 .../API/tools/lldb-dap/locations/main.cpp |  11 ++
 lldb/tools/lldb-dap/JSONUtils.cpp |  33 -
 lldb/tools/lldb-dap/JSONUtils.h   |   3 +
 lldb/tools/lldb-dap/lldb-dap.cpp  | 113 +-
 7 files changed, 176 insertions(+), 40 deletions(-)
 delete mode 100644 lldb/test/API/tools/lldb-dap/locations/main.c
 create mode 100644 lldb/test/API/tools/lldb-dap/locations/main.cpp

diff --git a/lldb/test/API/tools/lldb-dap/locations/Makefile 
b/lldb/test/API/tools/lldb-dap/locations/Makefile
index 10495940055b63..8b20bcb050 100644
--- a/lldb/test/API/tools/lldb-dap/locations/Makefile
+++ b/lldb/test/API/tools/lldb-dap/locations/Makefile
@@ -1,3 +1,3 @@
-C_SOURCES := main.c
+CXX_SOURCES := main.cpp
 
 include Makefile.rules
diff --git a/lldb/test/API/tools/lldb-dap/locations/TestDAP_locations.py 
b/lldb/test/API/tools/lldb-dap/locations/TestDAP_locations.py
index 76d938d3908492..45f836a2fa3c39 100644
--- a/lldb/test/API/tools/lldb-dap/locations/TestDAP_locations.py
+++ b/lldb/test/API/tools/lldb-dap/locations/TestDAP_locations.py
@@ -19,11 +19,11 @@ def test_locations(self):
 """
 program = self.getBuildArtifact("a.out")
 self.build_and_launch(program)
-source = "main.c"
+source = "main.cpp"
 self.source_path = os.path.join(os.getcwd(), source)
 self.set_source_breakpoints(
 source,
-[line_number(source, "// BREAK HERE")],
+[line_number(source, "break here")],
 )
 self.continue_to_next_stop()
 
@@ -36,5 +36,46 @@ def test_locations(self):
 locals["var1"]["declarationLocationReference"]
 )
 self.assertTrue(loc_var1["success"])
-self.assertTrue(loc_var1["body"]["source"]["path"].endswith("main.c"))
-self.assertEqual(loc_var1["body"]["line"], 2)
+
self.assertTrue(loc_var1["body"]["source"]["path"].endswith("main.cpp"))
+self.assertEqual(loc_var1["body"]["line"], 6)
+
+# func_ptr has both a declaration and a valueLocation
+self.assertIn("declarationLocationReference", 
locals["func_ptr"].keys())
+self.assertIn("valueLocationReference", locals["func_ptr"].keys())
+decl_loc_func_ptr = self.dap_server.request_locations(
+locals["func_ptr"]["declarationLocationReference"]
+)
+self.assertTrue(decl_loc_func_ptr["success"])
+self.assertTrue(
+decl_loc_func_ptr["body"]["source"]["path"].endswith("main.cpp")
+)
+self.assertEqual(decl_loc_func_ptr["body"]["line"], 7)
+val_loc_func_ptr = self.dap_server.request_locations(
+locals["func_ptr"]["valueLocationReference"]
+)
+self.assertTrue(val_loc_func_ptr["success"])
+
self.assertTrue(val_loc_func_ptr["body"]["source"]["path"].endswith("main.cpp"))
+self.assertEqual(val_loc_func_ptr["body"]["line"], 3)
+
+# func_ref has both a declaration and a valueLocation
+self.assertIn("declarationLocationReference", 
locals["func_ref"].keys())
+self.assertIn("valueLocationReference", locals["func_ref"].keys())
+decl_loc_func_ref = self.dap_server.request_locations(
+locals["func_ref"]["declarationLocationReference"]
+)
+self.assertTrue(decl_loc_func_ref["success"])
+self.assertTrue(
+decl_loc_func_ref["body"]["source"]["path"].endswith("main.cpp")
+)
+self.assertEqual(decl_loc_func_ref["body"]["line"], 8)
+val_loc_func_ref = self.dap_server.request_locations(
+locals["func_ref"]["valueLocationReference"]
+)
+s

[Lldb-commits] [lldb] [lldb/Interpreter] Add requirements to Scripted Interface abstract methods (PR #109063)

2024-09-18 Thread Alex Langford via lldb-commits


@@ -78,8 +100,11 @@ class ScriptedPythonInterface : virtual public 
ScriptedInterface {
 using namespace python;
 using Locker = ScriptInterpreterPythonImpl::Locker;
 
-auto create_error = [](std::string message) {
-  return llvm::createStringError(llvm::inconvertibleErrorCode(), message);
+Log *log = GetLog(LLDBLog::Script);
+auto create_error = [](llvm::StringRef format, auto &&...ts) {

bulbazord wrote:

I think it would be better to be specific with the type here: `const char *`.
`llvm::StringRef` may or may not point to a null-terminated string so calling 
`.data()` on the parameter sets off alarm bells in my head. I can manually 
verify that this is never called with anything other than a `const char *` but 
somebody else may not be so careful in the future.

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


[Lldb-commits] [lldb] [lldb] Change the implementation of Status to store an llvm::Error (NFC) (PR #106774)

2024-09-18 Thread Adrian Prantl via lldb-commits

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

>From 34a856d47322cd35a7b568a335adbcd804f2302d Mon Sep 17 00:00:00 2001
From: Pavel Labath 
Date: Wed, 11 Sep 2024 10:35:37 +0200
Subject: [PATCH 1/2] [lldb] Only send "posix" error codes through the
 gdb-remote protocol

The other side has no way of telling which namespace do these codes
belong to, so mashing them all together is not very helpful.

I'm mainly doing this to simplify some code in a pending patch
,
and I've picked the posix error category semi-randomly. If we wanted to
be serious about assigning meaning to these error codes, we should
create a special error category for "gdb errors".
---
 .../Process/gdb-remote/GDBRemoteCommunicationServer.cpp| 7 ---
 .../gdb-remote/GDBRemoteCommunicationServerTest.cpp| 3 ++-
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git 
a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServer.cpp 
b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServer.cpp
index 9b72cb00352821..d4aa90b2c7731a 100644
--- a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServer.cpp
+++ b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServer.cpp
@@ -103,13 +103,14 @@ GDBRemoteCommunicationServer::SendErrorResponse(uint8_t 
err) {
 
 GDBRemoteCommunication::PacketResult
 GDBRemoteCommunicationServer::SendErrorResponse(const Status &error) {
+  uint8_t code = error.GetType() == eErrorTypePOSIX ? error.GetError() : 0xff;
   if (m_send_error_strings) {
 lldb_private::StreamString packet;
-packet.Printf("E%2.2x;", static_cast(error.GetError()));
+packet.Printf("E%2.2x;", code);
 packet.PutStringAsRawHex8(error.AsCString());
 return SendPacketNoLock(packet.GetString());
-  } else
-return SendErrorResponse(error.GetError());
+  }
+  return SendErrorResponse(code);
 }
 
 GDBRemoteCommunication::PacketResult
diff --git 
a/lldb/unittests/Process/gdb-remote/GDBRemoteCommunicationServerTest.cpp 
b/lldb/unittests/Process/gdb-remote/GDBRemoteCommunicationServerTest.cpp
index 69ca1720c04fc9..ba9ca6ea73e3be 100644
--- a/lldb/unittests/Process/gdb-remote/GDBRemoteCommunicationServerTest.cpp
+++ b/lldb/unittests/Process/gdb-remote/GDBRemoteCommunicationServerTest.cpp
@@ -12,6 +12,7 @@
 #include "Plugins/Process/gdb-remote/GDBRemoteCommunicationServer.h"
 #include "lldb/Utility/Connection.h"
 #include "lldb/Utility/UnimplementedError.h"
+#include "lldb/lldb-enumerations.h"
 
 namespace lldb_private {
 namespace process_gdb_remote {
@@ -25,7 +26,7 @@ TEST(GDBRemoteCommunicationServerTest, 
SendErrorResponse_ErrorNumber) {
 
 TEST(GDBRemoteCommunicationServerTest, SendErrorResponse_Status) {
   MockServerWithMockConnection server;
-  Status status(0x42, lldb::eErrorTypeGeneric, "Test error message");
+  Status status(0x42, lldb::eErrorTypePOSIX, "Test error message");
   server.SendErrorResponse(status);
 
   EXPECT_THAT(

>From 881811e0e47504ef43a9ba71deae4ac7c2ed8767 Mon Sep 17 00:00:00 2001
From: Adrian Prantl 
Date: Wed, 4 Sep 2024 12:50:37 -0700
Subject: [PATCH 2/2] [lldb] Change the implementation of Status to store an
 llvm::Error (NFC)

Most APIs that currently vend a Status would be better served by
returning llvm::Expected<> instead. Where possible, APIs should be
refactored to avoid Status. The only legitimate long-term uses of
Status are objects that need to store an error for a long time (which
should be questioned as a design decision, too).

This patch makes the transition to llvm::Error easier by making the
places that cannot switch to llvm::Error explicit: They are marked
with a call to Status::clone(). Every other API can and should be
refactored to use llvm::Expected. In the end Status should only be
used in very few places.

Whenever an unchecked Error is dropped by Status it logs this to the
verbose API channel.

Implementation notes:

This patch introduces two new kinds of error_category as well as new
llvm::Error types. Here is the mapping of lldb::ErrorType to
llvm::Errors:

   (eErrorTypeInvalid)
   eErrorTypeGeneric  llvm::StringError
   eErrorTypePOSIXllvm::ECError
   eErrorTypeMachKernel   MachKernelError
   eErrorTypeExpression   llvm::ErrorList
   eErrorTypeWin32Win32Error
---
 lldb/include/lldb/Utility/Status.h|  85 +-
 .../Python/PythonDataObjects.cpp  |  31 ++-
 lldb/source/Utility/Status.cpp| 255 --
 .../Host/SocketTestUtilities.cpp  |  16 +-
 lldb/unittests/Utility/StatusTest.cpp |   8 +
 5 files changed, 287 insertions(+), 108 deletions(-)

diff --git a/lldb/include/lldb/Utility/Status.h 
b/lldb/include/lldb/Utility/Status.h
index 795c830b965173..4a09c38ce62f1b 100644
--- a/lldb/include/lldb/Utility/Status.h
+++ b/lldb/include/lldb/Utility/Status.h
@@ -28,6 +28,69 @@ namespace lldb_private 

[Lldb-commits] [lldb] [lldb] Change the implementation of Status to store an llvm::Error (NFC) (PR #106774)

2024-09-18 Thread Adrian Prantl via lldb-commits

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

>From 34a856d47322cd35a7b568a335adbcd804f2302d Mon Sep 17 00:00:00 2001
From: Pavel Labath 
Date: Wed, 11 Sep 2024 10:35:37 +0200
Subject: [PATCH 1/2] [lldb] Only send "posix" error codes through the
 gdb-remote protocol

The other side has no way of telling which namespace do these codes
belong to, so mashing them all together is not very helpful.

I'm mainly doing this to simplify some code in a pending patch
,
and I've picked the posix error category semi-randomly. If we wanted to
be serious about assigning meaning to these error codes, we should
create a special error category for "gdb errors".
---
 .../Process/gdb-remote/GDBRemoteCommunicationServer.cpp| 7 ---
 .../gdb-remote/GDBRemoteCommunicationServerTest.cpp| 3 ++-
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git 
a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServer.cpp 
b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServer.cpp
index 9b72cb00352821..d4aa90b2c7731a 100644
--- a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServer.cpp
+++ b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServer.cpp
@@ -103,13 +103,14 @@ GDBRemoteCommunicationServer::SendErrorResponse(uint8_t 
err) {
 
 GDBRemoteCommunication::PacketResult
 GDBRemoteCommunicationServer::SendErrorResponse(const Status &error) {
+  uint8_t code = error.GetType() == eErrorTypePOSIX ? error.GetError() : 0xff;
   if (m_send_error_strings) {
 lldb_private::StreamString packet;
-packet.Printf("E%2.2x;", static_cast(error.GetError()));
+packet.Printf("E%2.2x;", code);
 packet.PutStringAsRawHex8(error.AsCString());
 return SendPacketNoLock(packet.GetString());
-  } else
-return SendErrorResponse(error.GetError());
+  }
+  return SendErrorResponse(code);
 }
 
 GDBRemoteCommunication::PacketResult
diff --git 
a/lldb/unittests/Process/gdb-remote/GDBRemoteCommunicationServerTest.cpp 
b/lldb/unittests/Process/gdb-remote/GDBRemoteCommunicationServerTest.cpp
index 69ca1720c04fc9..ba9ca6ea73e3be 100644
--- a/lldb/unittests/Process/gdb-remote/GDBRemoteCommunicationServerTest.cpp
+++ b/lldb/unittests/Process/gdb-remote/GDBRemoteCommunicationServerTest.cpp
@@ -12,6 +12,7 @@
 #include "Plugins/Process/gdb-remote/GDBRemoteCommunicationServer.h"
 #include "lldb/Utility/Connection.h"
 #include "lldb/Utility/UnimplementedError.h"
+#include "lldb/lldb-enumerations.h"
 
 namespace lldb_private {
 namespace process_gdb_remote {
@@ -25,7 +26,7 @@ TEST(GDBRemoteCommunicationServerTest, 
SendErrorResponse_ErrorNumber) {
 
 TEST(GDBRemoteCommunicationServerTest, SendErrorResponse_Status) {
   MockServerWithMockConnection server;
-  Status status(0x42, lldb::eErrorTypeGeneric, "Test error message");
+  Status status(0x42, lldb::eErrorTypePOSIX, "Test error message");
   server.SendErrorResponse(status);
 
   EXPECT_THAT(

>From 9e9dc217075b72d057acccf6dd3aaa9e795632c3 Mon Sep 17 00:00:00 2001
From: Adrian Prantl 
Date: Wed, 4 Sep 2024 12:50:37 -0700
Subject: [PATCH 2/2] [lldb] Change the implementation of Status to store an
 llvm::Error (NFC)

Most APIs that currently vend a Status would be better served by
returning llvm::Expected<> instead. Where possible, APIs should be
refactored to avoid Status. The only legitimate long-term uses of
Status are objects that need to store an error for a long time (which
should be questioned as a design decision, too).

This patch makes the transition to llvm::Error easier by making the
places that cannot switch to llvm::Error explicit: They are marked
with a call to Status::clone(). Every other API can and should be
refactored to use llvm::Expected. In the end Status should only be
used in very few places.

Whenever an unchecked Error is dropped by Status it logs this to the
verbose API channel.

Implementation notes:

This patch introduces two new kinds of error_category as well as new
llvm::Error types. Here is the mapping of lldb::ErrorType to
llvm::Errors:

   (eErrorTypeInvalid)
   eErrorTypeGeneric  llvm::StringError
   eErrorTypePOSIXllvm::ECError
   eErrorTypeMachKernel   MachKernelError
   eErrorTypeExpression   llvm::ErrorList
   eErrorTypeWin32Win32Error
---
 lldb/include/lldb/Utility/Status.h|  84 +-
 .../Python/PythonDataObjects.cpp  |  31 ++-
 lldb/source/Utility/Status.cpp| 253 --
 .../Host/SocketTestUtilities.cpp  |  16 +-
 lldb/unittests/Utility/StatusTest.cpp |   8 +
 5 files changed, 284 insertions(+), 108 deletions(-)

diff --git a/lldb/include/lldb/Utility/Status.h 
b/lldb/include/lldb/Utility/Status.h
index 795c830b965173..f94684cf68e2ed 100644
--- a/lldb/include/lldb/Utility/Status.h
+++ b/lldb/include/lldb/Utility/Status.h
@@ -28,6 +28,68 @@ namespace lldb_private 

[Lldb-commits] [lldb] Add docs and an example use of the scripted command get_flags API. (PR #109176)

2024-09-18 Thread via lldb-commits

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: None (jimingham)


Changes

The API is present, and we even have a test for it, but it isn't documented so 
no one probably knows you can set requirements for your scripted commands.  
This just adds docs and uses it appropriately in the `framestats` example 
command.

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


2 Files Affected:

- (modified) lldb/docs/use/python-reference.rst (+6) 
- (modified) lldb/examples/python/cmdtemplate.py (+3) 


``diff
diff --git a/lldb/docs/use/python-reference.rst 
b/lldb/docs/use/python-reference.rst
index 041e541a96f083..b12048f1af067d 100644
--- a/lldb/docs/use/python-reference.rst
+++ b/lldb/docs/use/python-reference.rst
@@ -562,6 +562,12 @@ which should implement the following interface:
   this call should return the short help text for this command[1]
   def get_long_help(self):
   this call should return the long help text for this command[1]
+  def get_flags(self):
+  this will be called when the command is added to the command 
interpreter,
+  and should return a flag field made from or-ing together the 
appropriate
+  elements of the lldb.CommandFlags enum to specify the requirements 
of this command.
+  The CommandInterpreter will make sure all these requirements are 
met, and will
+  return the standard lldb error if they are not.[1]
   def get_repeat_command(self, command):
   The auto-repeat command is what will get executed when the user 
types just
   a return at the next prompt after this command is run.  Even if your 
command
diff --git a/lldb/examples/python/cmdtemplate.py 
b/lldb/examples/python/cmdtemplate.py
index 9a96888508b6f2..b6a21cba7113e6 100644
--- a/lldb/examples/python/cmdtemplate.py
+++ b/lldb/examples/python/cmdtemplate.py
@@ -25,6 +25,9 @@ def register_lldb_command(cls, debugger, module_name):
 '--help" for detailed help.'.format(cls.program)
 )
 
+def get_flags(self):
+return lldb.eCommandRequiresFrame | lldb.eCommandProcessMustBePaused
+
 def setup_command_definition(self):
 
 self.ov_parser.add_option(

``




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


[Lldb-commits] [lldb] Add docs and an example use of the scripted command get_flags API. (PR #109176)

2024-09-18 Thread via lldb-commits

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

The API is present, and we even have a test for it, but it isn't documented so 
no one probably knows you can set requirements for your scripted commands.  
This just adds docs and uses it appropriately in the `framestats` example 
command.

>From 93810c16d5fa0d0a60d7d8ee2087ec091f2ad770 Mon Sep 17 00:00:00 2001
From: Jim Ingham 
Date: Wed, 18 Sep 2024 11:47:47 -0700
Subject: [PATCH] Add docs and an example use of the scripted command get_flags
 API.

---
 lldb/docs/use/python-reference.rst  | 6 ++
 lldb/examples/python/cmdtemplate.py | 3 +++
 2 files changed, 9 insertions(+)

diff --git a/lldb/docs/use/python-reference.rst 
b/lldb/docs/use/python-reference.rst
index 041e541a96f083..b12048f1af067d 100644
--- a/lldb/docs/use/python-reference.rst
+++ b/lldb/docs/use/python-reference.rst
@@ -562,6 +562,12 @@ which should implement the following interface:
   this call should return the short help text for this command[1]
   def get_long_help(self):
   this call should return the long help text for this command[1]
+  def get_flags(self):
+  this will be called when the command is added to the command 
interpreter,
+  and should return a flag field made from or-ing together the 
appropriate
+  elements of the lldb.CommandFlags enum to specify the requirements 
of this command.
+  The CommandInterpreter will make sure all these requirements are 
met, and will
+  return the standard lldb error if they are not.[1]
   def get_repeat_command(self, command):
   The auto-repeat command is what will get executed when the user 
types just
   a return at the next prompt after this command is run.  Even if your 
command
diff --git a/lldb/examples/python/cmdtemplate.py 
b/lldb/examples/python/cmdtemplate.py
index 9a96888508b6f2..b6a21cba7113e6 100644
--- a/lldb/examples/python/cmdtemplate.py
+++ b/lldb/examples/python/cmdtemplate.py
@@ -25,6 +25,9 @@ def register_lldb_command(cls, debugger, module_name):
 '--help" for detailed help.'.format(cls.program)
 )
 
+def get_flags(self):
+return lldb.eCommandRequiresFrame | lldb.eCommandProcessMustBePaused
+
 def setup_command_definition(self):
 
 self.ov_parser.add_option(

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


[Lldb-commits] [lldb] [lldb] Change the implementation of Status to store an llvm::Error (NFC) (PR #106774)

2024-09-18 Thread Adrian Prantl via lldb-commits

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

>From 34a856d47322cd35a7b568a335adbcd804f2302d Mon Sep 17 00:00:00 2001
From: Pavel Labath 
Date: Wed, 11 Sep 2024 10:35:37 +0200
Subject: [PATCH 1/2] [lldb] Only send "posix" error codes through the
 gdb-remote protocol

The other side has no way of telling which namespace do these codes
belong to, so mashing them all together is not very helpful.

I'm mainly doing this to simplify some code in a pending patch
,
and I've picked the posix error category semi-randomly. If we wanted to
be serious about assigning meaning to these error codes, we should
create a special error category for "gdb errors".
---
 .../Process/gdb-remote/GDBRemoteCommunicationServer.cpp| 7 ---
 .../gdb-remote/GDBRemoteCommunicationServerTest.cpp| 3 ++-
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git 
a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServer.cpp 
b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServer.cpp
index 9b72cb00352821..d4aa90b2c7731a 100644
--- a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServer.cpp
+++ b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServer.cpp
@@ -103,13 +103,14 @@ GDBRemoteCommunicationServer::SendErrorResponse(uint8_t 
err) {
 
 GDBRemoteCommunication::PacketResult
 GDBRemoteCommunicationServer::SendErrorResponse(const Status &error) {
+  uint8_t code = error.GetType() == eErrorTypePOSIX ? error.GetError() : 0xff;
   if (m_send_error_strings) {
 lldb_private::StreamString packet;
-packet.Printf("E%2.2x;", static_cast(error.GetError()));
+packet.Printf("E%2.2x;", code);
 packet.PutStringAsRawHex8(error.AsCString());
 return SendPacketNoLock(packet.GetString());
-  } else
-return SendErrorResponse(error.GetError());
+  }
+  return SendErrorResponse(code);
 }
 
 GDBRemoteCommunication::PacketResult
diff --git 
a/lldb/unittests/Process/gdb-remote/GDBRemoteCommunicationServerTest.cpp 
b/lldb/unittests/Process/gdb-remote/GDBRemoteCommunicationServerTest.cpp
index 69ca1720c04fc9..ba9ca6ea73e3be 100644
--- a/lldb/unittests/Process/gdb-remote/GDBRemoteCommunicationServerTest.cpp
+++ b/lldb/unittests/Process/gdb-remote/GDBRemoteCommunicationServerTest.cpp
@@ -12,6 +12,7 @@
 #include "Plugins/Process/gdb-remote/GDBRemoteCommunicationServer.h"
 #include "lldb/Utility/Connection.h"
 #include "lldb/Utility/UnimplementedError.h"
+#include "lldb/lldb-enumerations.h"
 
 namespace lldb_private {
 namespace process_gdb_remote {
@@ -25,7 +26,7 @@ TEST(GDBRemoteCommunicationServerTest, 
SendErrorResponse_ErrorNumber) {
 
 TEST(GDBRemoteCommunicationServerTest, SendErrorResponse_Status) {
   MockServerWithMockConnection server;
-  Status status(0x42, lldb::eErrorTypeGeneric, "Test error message");
+  Status status(0x42, lldb::eErrorTypePOSIX, "Test error message");
   server.SendErrorResponse(status);
 
   EXPECT_THAT(

>From eed276ed3961318336da0e2ed4c039de2996d467 Mon Sep 17 00:00:00 2001
From: Adrian Prantl 
Date: Wed, 4 Sep 2024 12:50:37 -0700
Subject: [PATCH 2/2] [lldb] Change the implementation of Status to store an
 llvm::Error (NFC)

Most APIs that currently vend a Status would be better served by
returning llvm::Expected<> instead. Where possible, APIs should be
refactored to avoid Status. The only legitimate long-term uses of
Status are objects that need to store an error for a long time (which
should be questioned as a design decision, too).

This patch makes the transition to llvm::Error easier by making the
places that cannot switch to llvm::Error explicit: They are marked
with a call to Status::clone(). Every other API can and should be
refactored to use llvm::Expected. In the end Status should only be
used in very few places.

Whenever an unchecked Error is dropped by Status it logs this to the
verbose API channel.

Implementation notes:

This patch introduces two new kinds of error_category as well as new
llvm::Error types. Here is the mapping of lldb::ErrorType to
llvm::Errors:

   (eErrorTypeInvalid)
   eErrorTypeGeneric  llvm::StringError
   eErrorTypePOSIXllvm::ECError
   eErrorTypeMachKernel   MachKernelError
   eErrorTypeExpression   llvm::ErrorList
   eErrorTypeWin32Win32Error
---
 lldb/include/lldb/Utility/Status.h|  84 +-
 .../Python/PythonDataObjects.cpp  |  31 ++-
 lldb/source/Utility/Status.cpp| 251 --
 .../Host/SocketTestUtilities.cpp  |  16 +-
 lldb/unittests/Utility/StatusTest.cpp |   8 +
 5 files changed, 282 insertions(+), 108 deletions(-)

diff --git a/lldb/include/lldb/Utility/Status.h 
b/lldb/include/lldb/Utility/Status.h
index 795c830b965173..56bb7fd7f95cd2 100644
--- a/lldb/include/lldb/Utility/Status.h
+++ b/lldb/include/lldb/Utility/Status.h
@@ -28,6 +28,68 @@ namespace lldb_private 

[Lldb-commits] [lldb] [lldb] Change the implementation of Status to store an llvm::Error (NFC) (PR #106774)

2024-09-18 Thread Adrian Prantl via lldb-commits

adrian-prantl wrote:

> Actually, the CI failure appears to be relevant. The error path in the test 
> is `errno->std::error_code->Status->Expected` and the code in 
> `CheckIPSupport` expects to get a `llvm::ECError`. It looks like it gets a 
> different type now, and I think that's probably fine, but we should also 
> relax the expectation there.

The problem here is that Status::FromErrno() doesn't create a CloneableECError, 
so these get lowered to a StringError during cloning. Fix coming up.

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


[Lldb-commits] [lldb] [lldb-dap] Implement value locations for function pointers (PR #104589)

2024-09-18 Thread Greg Clayton via lldb-commits


@@ -0,0 +1,11 @@
+#include 
+
+void greet() { printf("Hello"); }
+
+int main(void) {
+  int var1 = 1;
+  void (*func_ptr)() = &greet;
+  void (&func_ref)() = greet;
+  __builtin_printf("break here");

clayborg wrote:

We don't need the printf here right? Just put a comment on the line below:
```
  return 0; // break here
```

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


[Lldb-commits] [lldb] [lldb-dap] Implement value locations for function pointers (PR #104589)

2024-09-18 Thread Greg Clayton via lldb-commits


@@ -1198,6 +1198,26 @@ std::string 
VariableDescription::GetResult(llvm::StringRef context) {
   return description.trim().str();
 }
 
+bool HasValueLocation(lldb::SBValue v) {
+  if (!v.GetType().IsPointerType() && !v.GetType().IsReferenceType()) {
+return false;
+  }

clayborg wrote:

no parens for single line if statements per llvm coding guidelines. The name 
isn't quite clear for what this is doing. Maybe `ValuePointsToCode` would be 
better? This is also adding some extra work for every variable that is a 
pointer or reference. Is there no way to limit this to function pointers only? 
It would be great to skip the resolving of the load address if we can help it, 
right now it will do an address resolving on every pointer and reference.

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


[Lldb-commits] [lldb] [lldb-dap] Implement value locations for function pointers (PR #104589)

2024-09-18 Thread Greg Clayton via lldb-commits

https://github.com/clayborg commented:

My only question here is do we really want to do an address resolution for any 
pointer or reference or can we limit that for only function pointers? I worry a 
bit about the extra cost for any variable view that has tons of pointers or 
references as this will cause LLDB to lookup their address all the time. If 
this should be just for function pointers, it would be good to limit the extra 
searches to only those. 

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


[Lldb-commits] [lldb] [lldb-dap] Implement value locations for function pointers (PR #104589)

2024-09-18 Thread Greg Clayton via lldb-commits

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


[Lldb-commits] [lldb] Add warning message to `session save` when transcript isn't saved. (PR #109020)

2024-09-18 Thread Med Ismail Bennani via lldb-commits

medismailben wrote:

> Maybe `interpreter.save-transcript` could be true by default as well. Any 
> feedback welcome.

Although that could be useful but I'm concerned of the performance aspect of 
it. Not everyone cares to save transcripts so I'm not sure it should be on by 
default. I like this patch because it explains to the user what they need to do 
to save the transaction (enable the settings), may be that's good enough.

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


[Lldb-commits] [lldb] Add warning message to `session save` when transcript isn't saved. (PR #109020)

2024-09-18 Thread Med Ismail Bennani via lldb-commits

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


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


[Lldb-commits] [lldb] Add warning message to `session save` when transcript isn't saved. (PR #109020)

2024-09-18 Thread Med Ismail Bennani via lldb-commits


@@ -3306,6 +3306,8 @@ bool CommandInterpreter::SaveTranscript(
   result.SetStatus(eReturnStatusSuccessFinishNoResult);
   result.AppendMessageWithFormat("Session's transcripts saved to %s\n",
  output_file->c_str());
+  if (!GetSaveTranscript())
+result.AppendError("Note: the setting interpreter.save-transcript is set 
to false, so the transcript might not have been recorded.");

medismailben wrote:

We should do this at the beginning of the function, before doing the work and 
return early if `save-transcript` is disabled.

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


[Lldb-commits] [lldb] Add warning message to `session save` when transcript isn't saved. (PR #109020)

2024-09-18 Thread via lldb-commits


@@ -3306,6 +3306,8 @@ bool CommandInterpreter::SaveTranscript(
   result.SetStatus(eReturnStatusSuccessFinishNoResult);
   result.AppendMessageWithFormat("Session's transcripts saved to %s\n",
  output_file->c_str());
+  if (!GetSaveTranscript())
+result.AppendError("Note: the setting interpreter.save-transcript is set 
to false, so the transcript might not have been recorded.");

jeffreytan81 wrote:

I am not sure why we are using `might not` here. Since `GetSaveTranscript()` is 
false, isn't the transcript definitely won't be saved? Maybe rewording to: 

```
Note: the interpreter.save-transcript setting is disabled (false), so the 
transcript will not be saved.
```

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


[Lldb-commits] [lldb] Add warning message to `session save` when transcript isn't saved. (PR #109020)

2024-09-18 Thread via lldb-commits

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


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


[Lldb-commits] [lldb] [llvm] [lldb][RISCV] function calls support in lldb expressions (PR #99336)

2024-09-18 Thread via lldb-commits

dlav-sc wrote:

> That code doesn't look right.

Yeah, it looks really suspicious. 

> Shouldn't it be using eRISCV_float_abi_mask.

I think you are right.

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


[Lldb-commits] [lldb] [llvm] [lldb][RISCV] function calls support in lldb expressions (PR #99336)

2024-09-18 Thread via lldb-commits

dlav-sc wrote:

> I expect these will be at risk of diverging if done separately

Your concern is reasonable, I see this stuff in two places: 
`DisassemblerLLVMC::DisassemblerLLVMC` and `GetValObjFromFPRegs` in 
`ABISysV_riscv.cpp` (also `ObjectFileELF::GetSectionHeaderInfo` works with 
float flags, but it just parses elf header and takes features from there).

> I wonder if our ArchSpec should have a method to get the clang feature flags.

I've expected that `CompilerInstance` (`m_compiler`) has this method, because 
clang should get features somehow and as I know, it uses march for this 
purposes, but I couldn't find this functionality. As for lldb, maybe it can be 
useful to obtain features flags from `ArchSpec`, but I think this should be 
done in a separate PR, if you don't mind.

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


[Lldb-commits] [lldb] [lldb-dap] Implement value locations for function pointers (PR #104589)

2024-09-18 Thread Adrian Vogelsgesang via lldb-commits


@@ -1611,16 +1624,17 @@ void request_evaluate(const llvm::json::Object 
&request) {
   VariableDescription desc(value);
   EmplaceSafeString(body, "result", desc.GetResult(context));
   EmplaceSafeString(body, "type", desc.display_type_name);
-  if (value.MightHaveChildren()) {
-auto variableReference = g_dap.variables.InsertVariable(
-value, /*is_permanent=*/context == "repl");
-body.try_emplace("variablesReference", variableReference);
-  } else {
+  auto var_ref = g_dap.variables.InsertVariable(
+  value, /*is_permanent=*/context == "repl");

vogelsgesang wrote:

Solved this slightly differently, without a lambda. Please let me know if you 
are also fine with the current solution

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


[Lldb-commits] [lldb] [lldb-dap] Implement value locations for function pointers (PR #104589)

2024-09-18 Thread Adrian Vogelsgesang via lldb-commits

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

>From 79684ccb2b6312b0938de73641e89d7cd29ce1a8 Mon Sep 17 00:00:00 2001
From: Adrian Vogelsgesang 
Date: Mon, 12 Aug 2024 14:53:31 +
Subject: [PATCH 1/2] [lldb-dap] Implement value locations for function
 pointers

This commit adds `valueLocationReference` to function pointers and
function references. Thereby, users can navigate directly to the
pointed-to function from within the "variables" pane.

In general, it would be useful to also a similar location references
also to member function pointers, `std::source_location`,
`std::function`,  and many more. Doing so would require extending the
formatters to provide such a source code location.

There were two RFCs about this a while ago:
https://discourse.llvm.org/t/rfc-extending-formatters-with-a-source-code-reference/68375
https://discourse.llvm.org/t/rfc-sbvalue-metadata-provider/68377/26

However, both RFCs ended without a conclusion. As such, this commit now
solve the lowest-hanging fruit, i.e. function pointers. If people find
it useful, I will revive the RFC afterwards.
---
 .../API/tools/lldb-dap/locations/Makefile |   2 +-
 .../lldb-dap/locations/TestDAP_locations.py   |  49 +++-
 lldb/test/API/tools/lldb-dap/locations/main.c |   5 -
 .../API/tools/lldb-dap/locations/main.cpp |  11 ++
 lldb/tools/lldb-dap/JSONUtils.cpp |  33 -
 lldb/tools/lldb-dap/JSONUtils.h   |   3 +
 lldb/tools/lldb-dap/lldb-dap.cpp  | 113 +-
 7 files changed, 176 insertions(+), 40 deletions(-)
 delete mode 100644 lldb/test/API/tools/lldb-dap/locations/main.c
 create mode 100644 lldb/test/API/tools/lldb-dap/locations/main.cpp

diff --git a/lldb/test/API/tools/lldb-dap/locations/Makefile 
b/lldb/test/API/tools/lldb-dap/locations/Makefile
index 10495940055b63..8b20bcb050 100644
--- a/lldb/test/API/tools/lldb-dap/locations/Makefile
+++ b/lldb/test/API/tools/lldb-dap/locations/Makefile
@@ -1,3 +1,3 @@
-C_SOURCES := main.c
+CXX_SOURCES := main.cpp
 
 include Makefile.rules
diff --git a/lldb/test/API/tools/lldb-dap/locations/TestDAP_locations.py 
b/lldb/test/API/tools/lldb-dap/locations/TestDAP_locations.py
index 76d938d3908492..45f836a2fa3c39 100644
--- a/lldb/test/API/tools/lldb-dap/locations/TestDAP_locations.py
+++ b/lldb/test/API/tools/lldb-dap/locations/TestDAP_locations.py
@@ -19,11 +19,11 @@ def test_locations(self):
 """
 program = self.getBuildArtifact("a.out")
 self.build_and_launch(program)
-source = "main.c"
+source = "main.cpp"
 self.source_path = os.path.join(os.getcwd(), source)
 self.set_source_breakpoints(
 source,
-[line_number(source, "// BREAK HERE")],
+[line_number(source, "break here")],
 )
 self.continue_to_next_stop()
 
@@ -36,5 +36,46 @@ def test_locations(self):
 locals["var1"]["declarationLocationReference"]
 )
 self.assertTrue(loc_var1["success"])
-self.assertTrue(loc_var1["body"]["source"]["path"].endswith("main.c"))
-self.assertEqual(loc_var1["body"]["line"], 2)
+
self.assertTrue(loc_var1["body"]["source"]["path"].endswith("main.cpp"))
+self.assertEqual(loc_var1["body"]["line"], 6)
+
+# func_ptr has both a declaration and a valueLocation
+self.assertIn("declarationLocationReference", 
locals["func_ptr"].keys())
+self.assertIn("valueLocationReference", locals["func_ptr"].keys())
+decl_loc_func_ptr = self.dap_server.request_locations(
+locals["func_ptr"]["declarationLocationReference"]
+)
+self.assertTrue(decl_loc_func_ptr["success"])
+self.assertTrue(
+decl_loc_func_ptr["body"]["source"]["path"].endswith("main.cpp")
+)
+self.assertEqual(decl_loc_func_ptr["body"]["line"], 7)
+val_loc_func_ptr = self.dap_server.request_locations(
+locals["func_ptr"]["valueLocationReference"]
+)
+self.assertTrue(val_loc_func_ptr["success"])
+
self.assertTrue(val_loc_func_ptr["body"]["source"]["path"].endswith("main.cpp"))
+self.assertEqual(val_loc_func_ptr["body"]["line"], 3)
+
+# func_ref has both a declaration and a valueLocation
+self.assertIn("declarationLocationReference", 
locals["func_ref"].keys())
+self.assertIn("valueLocationReference", locals["func_ref"].keys())
+decl_loc_func_ref = self.dap_server.request_locations(
+locals["func_ref"]["declarationLocationReference"]
+)
+self.assertTrue(decl_loc_func_ref["success"])
+self.assertTrue(
+decl_loc_func_ref["body"]["source"]["path"].endswith("main.cpp")
+)
+self.assertEqual(decl_loc_func_ref["body"]["line"], 8)
+val_loc_func_ref = self.dap_server.request_locations(
+locals["func_ref"]["valueLocationReference"]
+)
+s

[Lldb-commits] [lldb] [lldb-dap][test] Fix `readMemory` test (PR #109057)

2024-09-18 Thread Adrian Vogelsgesang via lldb-commits

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


[Lldb-commits] [lldb] 620738e - [lldb-dap][test] Fix `readMemory` test (#109057)

2024-09-18 Thread via lldb-commits

Author: Adrian Vogelsgesang
Date: 2024-09-18T16:16:31+02:00
New Revision: 620738e66260f00f08808b3e676a697fc32db92e

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

LOG: [lldb-dap][test] Fix `readMemory` test (#109057)

So far, the test case was also testing the offset -1. This test cases
failed if the string is immediately at the beginning of the memory
region, though, and the offset -1 hence belonged to a different memory
region.

The fix is rather straightforward:
Passing an offset of -1 is not used by any actual clients of lldb-dap,
anyway. As such, this commit simply removes the corresponding test case.

Added: 


Modified: 
lldb/test/API/tools/lldb-dap/memory/TestDAP_memory.py

Removed: 




diff  --git a/lldb/test/API/tools/lldb-dap/memory/TestDAP_memory.py 
b/lldb/test/API/tools/lldb-dap/memory/TestDAP_memory.py
index 3d8aaeda7f4b85..1082541aebcf7c 100644
--- a/lldb/test/API/tools/lldb-dap/memory/TestDAP_memory.py
+++ b/lldb/test/API/tools/lldb-dap/memory/TestDAP_memory.py
@@ -74,10 +74,6 @@ def test_memory_refs_set_variable(self):
 ].keys(),
 )
 
-# lldb-dap assumes that all reads will be within the same region. On 
Windows
-# the target string is at the very start of a region so the -1 offset 
causes
-# the read to only read from the previous region and only return 1 byte.
-@skipIfWindows
 def test_readMemory(self):
 """
 Tests the 'readMemory' request
@@ -104,10 +100,6 @@ def test_readMemory(self):
 mem = self.dap_server.request_readMemory(memref, 2, 3)["body"]
 self.assertEqual(b64decode(mem["data"]), b"ad\0")
 
-# Use a negative offset
-mem = self.dap_server.request_readMemory(memref, -1, 6)["body"]
-self.assertEqual(b64decode(mem["data"])[1:], b"dead\0")
-
 # Reads of size 0 are successful
 # VS-Code sends those in order to check if a `memoryReference` can 
actually be dereferenced.
 mem = self.dap_server.request_readMemory(memref, 0, 0)



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


[Lldb-commits] [lldb] 9690b30 - [LLDB] Fix operators <= and >= returning a wrong result when comparing to a floating point NaN (#108060)

2024-09-18 Thread via lldb-commits

Author: Ilia Kuklin
Date: 2024-09-18T17:50:09+05:00
New Revision: 9690b30ba9acc3deb1068deb37f3b507826b27fe

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

LOG: [LLDB] Fix operators <= and >= returning a wrong result when comparing to 
a floating point NaN (#108060)

Implement operators `<=` and `>=` to explicitly check the comparison
results to be `cmpLessThan` or `cmpEqual` instead of negating the result
of `operators<`.

Fixes #85947

Added: 
lldb/test/API/lang/cpp/fpnan/Makefile
lldb/test/API/lang/cpp/fpnan/TestFPNaN.py
lldb/test/API/lang/cpp/fpnan/main.cpp

Modified: 
lldb/include/lldb/Utility/Scalar.h
lldb/source/Utility/Scalar.cpp

Removed: 




diff  --git a/lldb/include/lldb/Utility/Scalar.h 
b/lldb/include/lldb/Utility/Scalar.h
index 0d8eba3c9726d5..b4b9c7e1895825 100644
--- a/lldb/include/lldb/Utility/Scalar.h
+++ b/lldb/include/lldb/Utility/Scalar.h
@@ -210,6 +210,7 @@ class Scalar {
   static PromotionKey GetFloatPromoKey(const llvm::fltSemantics &semantics);
 
 private:
+  friend llvm::APFloat::cmpResult compare(Scalar lhs, Scalar rhs);
   friend const Scalar operator+(const Scalar &lhs, const Scalar &rhs);
   friend const Scalar operator-(Scalar lhs, Scalar rhs);
   friend const Scalar operator/(Scalar lhs, Scalar rhs);
@@ -220,9 +221,9 @@ class Scalar {
   friend const Scalar operator^(Scalar lhs, Scalar rhs);
   friend const Scalar operator<<(const Scalar &lhs, const Scalar &rhs);
   friend const Scalar operator>>(const Scalar &lhs, const Scalar &rhs);
-  friend bool operator==(Scalar lhs, Scalar rhs);
+  friend bool operator==(const Scalar &lhs, const Scalar &rhs);
   friend bool operator!=(const Scalar &lhs, const Scalar &rhs);
-  friend bool operator<(Scalar lhs, Scalar rhs);
+  friend bool operator<(const Scalar &lhs, const Scalar &rhs);
   friend bool operator<=(const Scalar &lhs, const Scalar &rhs);
   friend bool operator>(const Scalar &lhs, const Scalar &rhs);
   friend bool operator>=(const Scalar &lhs, const Scalar &rhs);
@@ -241,6 +242,7 @@ class Scalar {
 //  Item 19 of "Effective C++ Second Edition" by Scott Meyers
 //  Differentiate among members functions, non-member functions, and
 //  friend functions
+llvm::APFloat::cmpResult compare(Scalar lhs, Scalar rhs);
 const Scalar operator+(const Scalar &lhs, const Scalar &rhs);
 const Scalar operator-(Scalar lhs, Scalar rhs);
 const Scalar operator/(Scalar lhs, Scalar rhs);
@@ -251,9 +253,9 @@ const Scalar operator%(Scalar lhs, Scalar rhs);
 const Scalar operator^(Scalar lhs, Scalar rhs);
 const Scalar operator<<(const Scalar &lhs, const Scalar &rhs);
 const Scalar operator>>(const Scalar &lhs, const Scalar &rhs);
-bool operator==(Scalar lhs, Scalar rhs);
+bool operator==(const Scalar &lhs, const Scalar &rhs);
 bool operator!=(const Scalar &lhs, const Scalar &rhs);
-bool operator<(Scalar lhs, Scalar rhs);
+bool operator<(const Scalar &lhs, const Scalar &rhs);
 bool operator<=(const Scalar &lhs, const Scalar &rhs);
 bool operator>(const Scalar &lhs, const Scalar &rhs);
 bool operator>=(const Scalar &lhs, const Scalar &rhs);

diff  --git a/lldb/source/Utility/Scalar.cpp b/lldb/source/Utility/Scalar.cpp
index 329f5b6e4b9a5b..f07a9f3bed00c7 100644
--- a/lldb/source/Utility/Scalar.cpp
+++ b/lldb/source/Utility/Scalar.cpp
@@ -852,57 +852,50 @@ llvm::APFloat 
Scalar::CreateAPFloatFromAPFloat(lldb::BasicType basic_type) {
   }
 }
 
-bool lldb_private::operator==(Scalar lhs, Scalar rhs) {
+APFloat::cmpResult lldb_private::compare(Scalar lhs, Scalar rhs) {
   // If either entry is void then we can just compare the types
   if (lhs.m_type == Scalar::e_void || rhs.m_type == Scalar::e_void)
-return lhs.m_type == rhs.m_type;
+return lhs.m_type == rhs.m_type ? APFloat::cmpEqual : 
APFloat::cmpUnordered;
 
-  llvm::APFloat::cmpResult result;
   switch (Scalar::PromoteToMaxType(lhs, rhs)) {
   case Scalar::e_void:
 break;
   case Scalar::e_int:
-return lhs.m_integer == rhs.m_integer;
+if (lhs.m_integer < rhs.m_integer)
+  return APFloat::cmpLessThan;
+if (lhs.m_integer > rhs.m_integer)
+  return APFloat::cmpGreaterThan;
+return APFloat::cmpEqual;
   case Scalar::e_float:
-result = lhs.m_float.compare(rhs.m_float);
-if (result == llvm::APFloat::cmpEqual)
-  return true;
+return lhs.m_float.compare(rhs.m_float);
   }
-  return false;
+  return APFloat::cmpUnordered;
 }
 
-bool lldb_private::operator!=(const Scalar &lhs, const Scalar &rhs) {
-  return !(lhs == rhs);
+bool lldb_private::operator==(const Scalar &lhs, const Scalar &rhs) {
+  return compare(lhs, rhs) == APFloat::cmpEqual;
 }
 
-bool lldb_private::operator<(Scalar lhs, Scalar rhs) {
-  if (lhs.m_type == Scalar::e_void || rhs.m_type == Scalar::e_void)
-return false;
+bool lldb_private::operat

[Lldb-commits] [lldb] [LLDB] Fix operators <= and >= returning a wrong result when comparing to a floating point NaN (PR #108060)

2024-09-18 Thread Ilia Kuklin via lldb-commits

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


[Lldb-commits] [lldb] [lldb] refactor Target::Install function (PR #108996)

2024-09-18 Thread via lldb-commits

dlav-sc wrote:

> Sure, please update the PR title and description to reflect that, then I'll 
> take a look.

Thanks

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


[Lldb-commits] [lldb] [lldb] refactor Target::Install function (PR #108996)

2024-09-18 Thread via lldb-commits

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


[Lldb-commits] [lldb] [lldb] refactor Target::Install function (PR #108996)

2024-09-18 Thread via lldb-commits

https://github.com/dlav-sc edited 
https://github.com/llvm/llvm-project/pull/108996
___
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 check using an MD5 hash for whether a file needs to be installed on the remote target (PR #108996)

2024-09-18 Thread via lldb-commits

https://github.com/dlav-sc updated 
https://github.com/llvm/llvm-project/pull/108996

>From 5161bbab487703278a53bda03e705c5408c80cd8 Mon Sep 17 00:00:00 2001
From: Daniil Avdeev 
Date: Tue, 23 Jul 2024 11:08:13 +
Subject: [PATCH] [lldb] refactor Target::Install function

---
 lldb/source/Target/Target.cpp | 133 --
 1 file changed, 93 insertions(+), 40 deletions(-)

diff --git a/lldb/source/Target/Target.cpp b/lldb/source/Target/Target.cpp
index f1659aae0800db..e8bcbbe7f07eae 100644
--- a/lldb/source/Target/Target.cpp
+++ b/lldb/source/Target/Target.cpp
@@ -76,6 +76,79 @@
 using namespace lldb;
 using namespace lldb_private;
 
+namespace {
+
+struct ExecutableInstaller {
+
+  ExecutableInstaller(PlatformSP platform, ModuleSP module)
+  : m_platform{platform}, m_module{module},
+m_local_file{m_module->GetFileSpec()},
+m_remote_file{m_module->GetRemoteInstallFileSpec()} {}
+
+  void setRemoteFile() const { m_module->SetPlatformFileSpec(m_remote_file); }
+
+  PlatformSP m_platform;
+  ModuleSP m_module;
+  const FileSpec m_local_file;
+  const FileSpec m_remote_file;
+};
+
+struct MainExecutableInstaller {
+
+  MainExecutableInstaller(PlatformSP platform, TargetSP target, ModuleSP 
module,
+  ProcessLaunchInfo *launch_info)
+  : m_platform{platform},  m_module{module},
+m_local_file{m_module->GetFileSpec()},
+m_remote_file{
+getRemoteFileSpec(m_platform, target, m_module, m_local_file)},
+m_launch_info{launch_info} {}
+
+  void setRemoteFile() const {
+m_module->SetPlatformFileSpec(m_remote_file);
+m_launch_info->SetExecutableFile(m_remote_file,
+ false /*add_exe_file_as_first_arg*/);
+m_platform->SetFilePermissions(m_remote_file, 0700 /*-rwx--*/);
+  }
+
+  PlatformSP m_platform;
+  ModuleSP m_module;
+  const FileSpec m_local_file;
+  const FileSpec m_remote_file;
+  ProcessLaunchInfo *m_launch_info;
+
+private:
+  static FileSpec getRemoteFileSpec(PlatformSP platform, TargetSP target,
+ModuleSP module,
+const FileSpec &local_file) {
+FileSpec remote_file = module->GetRemoteInstallFileSpec();
+if (remote_file || !target->GetAutoInstallMainExecutable())
+  return remote_file;
+
+if (!local_file)
+  return {};
+
+remote_file = platform->GetRemoteWorkingDirectory();
+remote_file.AppendPathComponent(local_file.GetFilename().GetCString());
+
+return remote_file;
+  }
+};
+} // namespace
+
+template 
+static Status installExecutable(const Installer &installer) {
+  if (!installer.m_local_file || !installer.m_remote_file)
+return Status();
+
+  Status error = installer.m_platform->Install(installer.m_local_file,
+   installer.m_remote_file);
+  if (error.Fail())
+return error;
+
+  installer.setRemoteFile();
+  return Status();
+}
+
 constexpr std::chrono::milliseconds EvaluateExpressionOptions::default_timeout;
 
 Target::Arch::Arch(const ArchSpec &spec)
@@ -3076,48 +3149,28 @@ TargetProperties &Target::GetGlobalProperties() {
 Status Target::Install(ProcessLaunchInfo *launch_info) {
   Status error;
   PlatformSP platform_sp(GetPlatform());
-  if (platform_sp) {
-if (platform_sp->IsRemote()) {
-  if (platform_sp->IsConnected()) {
-// Install all files that have an install path when connected to a
-// remote platform. If target.auto-install-main-executable is set then
-// also install the main executable even if it does not have an 
explicit
-// install path specified.
-const ModuleList &modules = GetImages();
-const size_t num_images = modules.GetSize();
-for (size_t idx = 0; idx < num_images; ++idx) {
-  ModuleSP module_sp(modules.GetModuleAtIndex(idx));
-  if (module_sp) {
-const bool is_main_executable = module_sp == GetExecutableModule();
-FileSpec local_file(module_sp->GetFileSpec());
-if (local_file) {
-  FileSpec remote_file(module_sp->GetRemoteInstallFileSpec());
-  if (!remote_file) {
-if (is_main_executable && GetAutoInstallMainExecutable()) {
-  // Automatically install the main executable.
-  remote_file = platform_sp->GetRemoteWorkingDirectory();
-  remote_file.AppendPathComponent(
-  module_sp->GetFileSpec().GetFilename().GetCString());
-}
-  }
-  if (remote_file) {
-error = platform_sp->Install(local_file, remote_file);
-if (error.Success()) {
-  module_sp->SetPlatformFileSpec(remote_file);
-  if (is_main_executable) {
-platform_sp->SetFilePermissions(remote_file, 0700);
-if (launch_info)
-  lau

[Lldb-commits] [lldb] [lldb] add a check using an MD5 hash for whether a file needs to be installed on the remote target (PR #108996)

2024-09-18 Thread via lldb-commits

https://github.com/dlav-sc updated 
https://github.com/llvm/llvm-project/pull/108996

>From 5161bbab487703278a53bda03e705c5408c80cd8 Mon Sep 17 00:00:00 2001
From: Daniil Avdeev 
Date: Tue, 23 Jul 2024 11:08:13 +
Subject: [PATCH 1/2] [lldb] refactor Target::Install function

---
 lldb/source/Target/Target.cpp | 133 --
 1 file changed, 93 insertions(+), 40 deletions(-)

diff --git a/lldb/source/Target/Target.cpp b/lldb/source/Target/Target.cpp
index f1659aae0800db..e8bcbbe7f07eae 100644
--- a/lldb/source/Target/Target.cpp
+++ b/lldb/source/Target/Target.cpp
@@ -76,6 +76,79 @@
 using namespace lldb;
 using namespace lldb_private;
 
+namespace {
+
+struct ExecutableInstaller {
+
+  ExecutableInstaller(PlatformSP platform, ModuleSP module)
+  : m_platform{platform}, m_module{module},
+m_local_file{m_module->GetFileSpec()},
+m_remote_file{m_module->GetRemoteInstallFileSpec()} {}
+
+  void setRemoteFile() const { m_module->SetPlatformFileSpec(m_remote_file); }
+
+  PlatformSP m_platform;
+  ModuleSP m_module;
+  const FileSpec m_local_file;
+  const FileSpec m_remote_file;
+};
+
+struct MainExecutableInstaller {
+
+  MainExecutableInstaller(PlatformSP platform, TargetSP target, ModuleSP 
module,
+  ProcessLaunchInfo *launch_info)
+  : m_platform{platform},  m_module{module},
+m_local_file{m_module->GetFileSpec()},
+m_remote_file{
+getRemoteFileSpec(m_platform, target, m_module, m_local_file)},
+m_launch_info{launch_info} {}
+
+  void setRemoteFile() const {
+m_module->SetPlatformFileSpec(m_remote_file);
+m_launch_info->SetExecutableFile(m_remote_file,
+ false /*add_exe_file_as_first_arg*/);
+m_platform->SetFilePermissions(m_remote_file, 0700 /*-rwx--*/);
+  }
+
+  PlatformSP m_platform;
+  ModuleSP m_module;
+  const FileSpec m_local_file;
+  const FileSpec m_remote_file;
+  ProcessLaunchInfo *m_launch_info;
+
+private:
+  static FileSpec getRemoteFileSpec(PlatformSP platform, TargetSP target,
+ModuleSP module,
+const FileSpec &local_file) {
+FileSpec remote_file = module->GetRemoteInstallFileSpec();
+if (remote_file || !target->GetAutoInstallMainExecutable())
+  return remote_file;
+
+if (!local_file)
+  return {};
+
+remote_file = platform->GetRemoteWorkingDirectory();
+remote_file.AppendPathComponent(local_file.GetFilename().GetCString());
+
+return remote_file;
+  }
+};
+} // namespace
+
+template 
+static Status installExecutable(const Installer &installer) {
+  if (!installer.m_local_file || !installer.m_remote_file)
+return Status();
+
+  Status error = installer.m_platform->Install(installer.m_local_file,
+   installer.m_remote_file);
+  if (error.Fail())
+return error;
+
+  installer.setRemoteFile();
+  return Status();
+}
+
 constexpr std::chrono::milliseconds EvaluateExpressionOptions::default_timeout;
 
 Target::Arch::Arch(const ArchSpec &spec)
@@ -3076,48 +3149,28 @@ TargetProperties &Target::GetGlobalProperties() {
 Status Target::Install(ProcessLaunchInfo *launch_info) {
   Status error;
   PlatformSP platform_sp(GetPlatform());
-  if (platform_sp) {
-if (platform_sp->IsRemote()) {
-  if (platform_sp->IsConnected()) {
-// Install all files that have an install path when connected to a
-// remote platform. If target.auto-install-main-executable is set then
-// also install the main executable even if it does not have an 
explicit
-// install path specified.
-const ModuleList &modules = GetImages();
-const size_t num_images = modules.GetSize();
-for (size_t idx = 0; idx < num_images; ++idx) {
-  ModuleSP module_sp(modules.GetModuleAtIndex(idx));
-  if (module_sp) {
-const bool is_main_executable = module_sp == GetExecutableModule();
-FileSpec local_file(module_sp->GetFileSpec());
-if (local_file) {
-  FileSpec remote_file(module_sp->GetRemoteInstallFileSpec());
-  if (!remote_file) {
-if (is_main_executable && GetAutoInstallMainExecutable()) {
-  // Automatically install the main executable.
-  remote_file = platform_sp->GetRemoteWorkingDirectory();
-  remote_file.AppendPathComponent(
-  module_sp->GetFileSpec().GetFilename().GetCString());
-}
-  }
-  if (remote_file) {
-error = platform_sp->Install(local_file, remote_file);
-if (error.Success()) {
-  module_sp->SetPlatformFileSpec(remote_file);
-  if (is_main_executable) {
-platform_sp->SetFilePermissions(remote_file, 0700);
-if (launch_info)
- 

[Lldb-commits] [lldb] [lldb] add a check using an MD5 hash for whether a file needs to be installed on the remote target (PR #108996)

2024-09-18 Thread via lldb-commits

github-actions[bot] wrote:




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



You can test this locally with the following command:


``bash
git-clang-format --diff 0f97b4824a8cf040bd3ce7b644dee9d60065ac61 
5161bbab487703278a53bda03e705c5408c80cd8 --extensions cpp -- 
lldb/source/Target/Target.cpp
``





View the diff from clang-format here.


``diff
diff --git a/lldb/source/Target/Target.cpp b/lldb/source/Target/Target.cpp
index e8bcbbe7f0..a6693a14a8 100644
--- a/lldb/source/Target/Target.cpp
+++ b/lldb/source/Target/Target.cpp
@@ -97,7 +97,7 @@ struct MainExecutableInstaller {
 
   MainExecutableInstaller(PlatformSP platform, TargetSP target, ModuleSP 
module,
   ProcessLaunchInfo *launch_info)
-  : m_platform{platform},  m_module{module},
+  : m_platform{platform}, m_module{module},
 m_local_file{m_module->GetFileSpec()},
 m_remote_file{
 getRemoteFileSpec(m_platform, target, m_module, m_local_file)},

``




https://github.com/llvm/llvm-project/pull/108996
___
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 check using an MD5 hash for whether a file needs to be installed on the remote target (PR #108996)

2024-09-18 Thread via lldb-commits

dlav-sc wrote:

> I'm surprised that #88812 did not also fix this. Perhaps putfile and install 
> are different code paths.

Nope, I simply didn't have this commit, my bad. Maybe we can consider this PR 
as the refactoring one, if you don't mind.

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


[Lldb-commits] [lldb] [lldb-dap][test] Fix `readMemory` test (PR #109057)

2024-09-18 Thread David Spickett via lldb-commits

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

Assuming all read memory requests are generated from variables, this makes 
sense. They wouldn't be split across regions.

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


[Lldb-commits] [lldb] [LLDB][lldb-dap][vscode-lldb] Add Environment configuration for the lldb-dap process (PR #108948)

2024-09-17 Thread via lldb-commits

github-actions[bot] wrote:



@serby2000 Congratulations on having your first Pull Request (PR) merged into 
the LLVM Project!

Your changes will be combined with recent changes from other authors, then 
tested by our [build bots](https://lab.llvm.org/buildbot/). If there is a 
problem with a build, you may receive a report in an email or a comment on this 
PR.

Please check whether problems have been caused by your change specifically, as 
the builds can include changes from many authors. It is not uncommon for your 
change to be included in a build that fails due to someone else's changes, or 
infrastructure issues.

How to do this, and the rest of the post-merge process, is covered in detail 
[here](https://llvm.org/docs/MyFirstTypoFix.html#myfirsttypofix-issues-after-landing-your-pr).

If your change does cause a problem, it may be reverted, or you can revert it 
yourself. This is a normal part of [LLVM 
development](https://llvm.org/docs/DeveloperPolicy.html#patch-reversion-policy).
 You can fix your changes and open a new PR to merge them again.

If you don't get any reports, no action is required from you. Your changes are 
working as expected, well done!


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


[Lldb-commits] [lldb] 30eb193 - [LLDB][lldb-dap][vscode-lldb] Add Environment configuration for the lldb-dap process (#108948)

2024-09-17 Thread via lldb-commits

Author: Serban
Date: 2024-09-18T08:05:35+02:00
New Revision: 30eb19321349827056facd54afab9b856b9f9d0a

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

LOG: [LLDB][lldb-dap][vscode-lldb] Add Environment configuration for the 
lldb-dap process (#108948)

Frequently, environment variables such as `LLDB_USE_NATIVE_PDB_READER`
are needed to be able to use lldb-dap in vscode

This PR adds a way to set the environment for the lldb-dap process using
configuration.

Added: 


Modified: 
lldb/tools/lldb-dap/package-lock.json
lldb/tools/lldb-dap/package.json
lldb/tools/lldb-dap/src-ts/extension.ts

Removed: 




diff  --git a/lldb/tools/lldb-dap/package-lock.json 
b/lldb/tools/lldb-dap/package-lock.json
index 96570e42dbfdc4..8663659715590a 100644
--- a/lldb/tools/lldb-dap/package-lock.json
+++ b/lldb/tools/lldb-dap/package-lock.json
@@ -1,12 +1,12 @@
 {
   "name": "lldb-dap",
-  "version": "0.2.4",
+  "version": "0.2.6",
   "lockfileVersion": 3,
   "requires": true,
   "packages": {
 "": {
   "name": "lldb-dap",
-  "version": "0.2.4",
+  "version": "0.2.6",
   "license": "Apache 2.0 License with LLVM exceptions",
   "devDependencies": {
 "@types/node": "^18.11.18",

diff  --git a/lldb/tools/lldb-dap/package.json 
b/lldb/tools/lldb-dap/package.json
index d35accfb6ec4e8..33b09d56ab17e2 100644
--- a/lldb/tools/lldb-dap/package.json
+++ b/lldb/tools/lldb-dap/package.json
@@ -1,7 +1,7 @@
 {
   "name": "lldb-dap",
   "displayName": "LLDB DAP",
-  "version": "0.2.5",
+  "version": "0.2.6",
   "publisher": "llvm-vs-code-extensions",
   "homepage": "https://lldb.llvm.org";,
   "description": "LLDB debugging from VSCode",
@@ -78,6 +78,15 @@
   "scope": "resource",
   "type": "string",
   "description": "The log path for lldb-dap (if any)"
+},
+"lldb-dap.environment": {
+  "scope": "resource",
+  "type": "object",
+  "default": {},
+  "description": "The environment of the lldb-dap process.",
+  "additionalProperties": {
+ "type": "string"
+  }
 }
   }
 },

diff  --git a/lldb/tools/lldb-dap/src-ts/extension.ts 
b/lldb/tools/lldb-dap/src-ts/extension.ts
index fdc4f47b238b5a..36d3dfba18c142 100644
--- a/lldb/tools/lldb-dap/src-ts/extension.ts
+++ b/lldb/tools/lldb-dap/src-ts/extension.ts
@@ -25,9 +25,15 @@ function createDefaultLLDBDapOptions(): LLDBDapOptions {
   if (log_path) {
 env["LLDBDAP_LOG"] = log_path;
   }
-
+  const configEnvironment = config.get<{ [key: string]: string 
}>("environment") || {};
   if (path) {
-return new vscode.DebugAdapterExecutable(path, [], { env });
+const dbgOptions = {
+  env: {
+...configEnvironment,
+...env,
+  }
+};
+return new vscode.DebugAdapterExecutable(path, [], dbgOptions);
   } else if (packageJSONExecutable) {
 return new vscode.DebugAdapterExecutable(
   packageJSONExecutable.command,
@@ -36,6 +42,7 @@ function createDefaultLLDBDapOptions(): LLDBDapOptions {
 ...packageJSONExecutable.options,
 env: {
   ...packageJSONExecutable.options?.env,
+  ...configEnvironment,
   ...env,
 },
   },



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


[Lldb-commits] [lldb] [LLDB][lldb-dap][vscode-lldb] Add Environment configuration for the lldb-dap process (PR #108948)

2024-09-17 Thread Adrian Vogelsgesang via lldb-commits

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


[Lldb-commits] [lldb] [LLDB][lldb-dap][vscode-lldb] Add Environment configuration for the lldb-dap process (PR #108948)

2024-09-17 Thread via lldb-commits

serby2000 wrote:

> @serby2000 do you have the necessary permissions to merge this? Or does one 
> of us need to press the button?

I don't have the permissions

https://github.com/llvm/llvm-project/pull/108948
___
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)

2024-09-17 Thread via lldb-commits

jimingham wrote:

Do we need to worry about whether this recognizer hides frames that might be 
useful to someone actually working on the libc++ they are debugging?  I would 
imagine in that case, you'd probably want to turn off this recognizer anyway, 
since you want to see the details.

Seems to me like this feature should be tuned to "users of libc++" not 
"developers of libc++".

We really should add a "disable" to the frame recognizers.  Once you delete 
them you can't really get the built-in ones back.  People who are working ON 
libc++ still spend a bunch of their time debugging "uses" of it, and likely 
would benefit from the implementation hiding, then every so often want to see 
the details.  We should make that easier.

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] Add the ability to define custom completers to the parsed_cmd template. (PR #109062)

2024-09-17 Thread via lldb-commits

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

>From a0b5801ab231670215657ec720fa0c89bc262c04 Mon Sep 17 00:00:00 2001
From: Jim Ingham 
Date: Thu, 29 Aug 2024 18:22:13 -0700
Subject: [PATCH 1/2] Add the ability to define custom completers for option
 values and arguments to the parsed_cmd template.

---
 lldb/bindings/python/python-wrapper.swig  |  73 +++
 lldb/docs/use/python-reference.rst| 144 +-
 lldb/examples/python/cmdtemplate.py   |  15 +-
 lldb/examples/python/templates/parsed_cmd.py  |  84 +++-
 .../lldb/Interpreter/ScriptInterpreter.h  |  15 ++
 lldb/include/lldb/Utility/CompletionRequest.h |   2 +
 .../source/Commands/CommandObjectCommands.cpp | 187 ++
 lldb/source/Interpreter/Options.cpp   |   5 +-
 .../Python/SWIGPythonBridge.h |   8 +
 .../Python/ScriptInterpreterPython.cpp|  40 
 .../Python/ScriptInterpreterPythonImpl.h  |   8 +
 .../script/add/TestAddParsedCommand.py| 115 +++
 .../command/script/add/test_commands.py   |  64 --
 .../Python/PythonTestSuite.cpp|  13 ++
 14 files changed, 706 insertions(+), 67 deletions(-)

diff --git a/lldb/bindings/python/python-wrapper.swig 
b/lldb/bindings/python/python-wrapper.swig
index 810673aaec5d19..1f5012af99a291 100644
--- a/lldb/bindings/python/python-wrapper.swig
+++ b/lldb/bindings/python/python-wrapper.swig
@@ -752,6 +752,79 @@ 
lldb_private::python::SWIGBridge::LLDBSwigPythonGetRepeatCommandForScriptedComma
   return result.Str().GetString().str();
 }
 
+StructuredData::DictionarySP
+lldb_private::python::SWIGBridge::LLDBSwigPythonHandleArgumentCompletionForScriptedCommand(PyObject
 *implementor,
+std::vector &args_vec, size_t args_pos, size_t 
pos_in_arg) {
+
+  PyErr_Cleaner py_err_cleaner(true);
+
+  PythonObject self(PyRefType::Borrowed, implementor);
+  auto pfunc = self.ResolveName("handle_argument_completion");
+  // If this isn't implemented, return an empty dict to signal falling back to 
default completion:
+  if (!pfunc.IsAllocated())
+return {};
+
+  PythonList args_list(PyInitialValue::Empty);
+  for (auto elem : args_vec)
+args_list.AppendItem(PythonString(elem));
+
+  PythonObject result = pfunc(args_list, PythonInteger(args_pos), 
PythonInteger(pos_in_arg));
+  // Returning None means do the ordinary completion
+  if (result.IsNone())
+return {};
+
+  // Convert the return dictionary to a DictionarySP.
+  StructuredData::ObjectSP result_obj_sp = result.CreateStructuredObject();
+  if (!result_obj_sp)
+return {};
+
+  StructuredData::DictionarySP dict_sp(new 
StructuredData::Dictionary(result_obj_sp));
+  if (dict_sp->GetType() == lldb::eStructuredDataTypeInvalid)
+return {};
+  return dict_sp;
+}
+
+StructuredData::DictionarySP
+lldb_private::python::SWIGBridge::LLDBSwigPythonHandleOptionArgumentCompletionForScriptedCommand(PyObject
 *implementor,
+llvm::StringRef &long_option, size_t pos_in_arg) {
+
+  PyErr_Cleaner py_err_cleaner(true);
+
+  PythonObject self(PyRefType::Borrowed, implementor);
+  auto pfunc = 
self.ResolveName("handle_option_argument_completion");
+  // If this isn't implemented, return an empty dict to signal falling back to 
default completion:
+  if (!pfunc.IsAllocated())
+return {};
+
+  PythonObject result = pfunc(PythonString(long_option), 
PythonInteger(pos_in_arg));
+  // Returning None means do the ordinary completion
+  if (result.IsNone())
+return {};
+
+  // Returning a boolean:
+  // True means the completion was handled, but there were no completions
+  // False means that the completion was not handled, again, do the ordinary 
completion:
+  if (result.GetObjectType() == PyObjectType::Boolean) {
+if (!result.IsTrue())
+  return {};
+// Make up a completion dictionary with the right element:
+StructuredData::DictionarySP dict_sp(new StructuredData::Dictionary());
+dict_sp->AddBooleanItem("no-completion", true);
+return dict_sp;
+  }
+
+
+  // Convert the return dictionary to a DictionarySP.
+  StructuredData::ObjectSP result_obj_sp = result.CreateStructuredObject();
+  if (!result_obj_sp)
+return {};
+
+  StructuredData::DictionarySP dict_sp(new 
StructuredData::Dictionary(result_obj_sp));
+  if (dict_sp->GetType() == lldb::eStructuredDataTypeInvalid)
+return {};
+  return dict_sp;
+}
+
 #include "lldb/Interpreter/CommandReturnObject.h"
 
 bool lldb_private::python::SWIGBridge::LLDBSwigPythonCallParsedCommandObject(
diff --git a/lldb/docs/use/python-reference.rst 
b/lldb/docs/use/python-reference.rst
index 041e541a96f083..de4f219a13292f 100644
--- a/lldb/docs/use/python-reference.rst
+++ b/lldb/docs/use/python-reference.rst
@@ -587,8 +587,150 @@ say
 SBCommandReturnObject and SBStream both support this file-like behavior by
 providing write() and flush() calls at the Python layer.
 
+The commands that are added using this Class definition are w

[Lldb-commits] [lldb] [lldb/Interpreter] Introduce `ScriptedStopHook{, Python}Interface` & make use of it (PR #105449)

2024-09-17 Thread Med Ismail Bennani via lldb-commits

medismailben wrote:

Depends on https://github.com/llvm/llvm-project/pull/109063/files

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


[Lldb-commits] [lldb] Add the ability to define custom completers to the parsed_cmd template. (PR #109062)

2024-09-17 Thread via lldb-commits

github-actions[bot] wrote:




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



You can test this locally with the following command:


``bash
git-clang-format --diff 090850f15dba926e2436089ff679b7015bb59e11 
a0b5801ab231670215657ec720fa0c89bc262c04 --extensions h,cpp -- 
lldb/include/lldb/Interpreter/ScriptInterpreter.h 
lldb/include/lldb/Utility/CompletionRequest.h 
lldb/source/Commands/CommandObjectCommands.cpp 
lldb/source/Interpreter/Options.cpp 
lldb/source/Plugins/ScriptInterpreter/Python/SWIGPythonBridge.h 
lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp 
lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPythonImpl.h 
lldb/unittests/ScriptInterpreter/Python/PythonTestSuite.cpp
``





View the diff from clang-format here.


``diff
diff --git a/lldb/include/lldb/Interpreter/ScriptInterpreter.h 
b/lldb/include/lldb/Interpreter/ScriptInterpreter.h
index 6fc9746689..7561585d98 100644
--- a/lldb/include/lldb/Interpreter/ScriptInterpreter.h
+++ b/lldb/include/lldb/Interpreter/ScriptInterpreter.h
@@ -436,19 +436,18 @@ public:
  Args &args) {
 return std::nullopt;
   }
-  
-  virtual StructuredData::DictionarySP 
HandleArgumentCompletionForScriptedCommand(
-  StructuredData::GenericSP impl_obj_sp, std::vector 
&args, 
-  size_t args_pos, size_t char_in_arg)
-  {
+
+  virtual StructuredData::DictionarySP
+  HandleArgumentCompletionForScriptedCommand(
+  StructuredData::GenericSP impl_obj_sp, std::vector 
&args,
+  size_t args_pos, size_t char_in_arg) {
 return {};
   }
 
-  virtual StructuredData::DictionarySP 
+  virtual StructuredData::DictionarySP
   HandleOptionArgumentCompletionForScriptedCommand(
-  StructuredData::GenericSP impl_obj_sp, llvm::StringRef &long_name, 
-  size_t char_in_arg)
-  {
+  StructuredData::GenericSP impl_obj_sp, llvm::StringRef &long_name,
+  size_t char_in_arg) {
 return {};
   }
 
diff --git a/lldb/include/lldb/Utility/CompletionRequest.h 
b/lldb/include/lldb/Utility/CompletionRequest.h
index 242ff38304..650158a197 100644
--- a/lldb/include/lldb/Utility/CompletionRequest.h
+++ b/lldb/include/lldb/Utility/CompletionRequest.h
@@ -138,7 +138,7 @@ public:
   const Args::ArgEntry &GetParsedArg() {
 return GetParsedLine()[GetCursorIndex()];
   }
-  
+
   size_t GetCursorCharPos() const { return m_cursor_char_position; }
 
   /// Drops the first argument from the argument list.
diff --git a/lldb/source/Commands/CommandObjectCommands.cpp 
b/lldb/source/Commands/CommandObjectCommands.cpp
index ec1c4be377..845b89a75b 100644
--- a/lldb/source/Commands/CommandObjectCommands.cpp
+++ b/lldb/source/Commands/CommandObjectCommands.cpp
@@ -1636,16 +1636,16 @@ private:
 }
 
 size_t GetNumOptions() { return m_num_options; }
-
-void PrepareOptionsForCompletion(CompletionRequest &request, 
-OptionElementVector &option_vec,
-ExecutionContext *exe_ctx) {
+
+void PrepareOptionsForCompletion(CompletionRequest &request,
+ OptionElementVector &option_vec,
+ ExecutionContext *exe_ctx) {
   // I'm not sure if we'll get into trouble doing an option parsing start
   // and end in this context.  If so, then I'll have to directly tell the
   // scripter to do this.
   OptionParsingStarting(exe_ctx);
   auto opt_defs = GetDefinitions();
-  
+
   // Iterate through the options we found so far, and push them into
   // the scripted side.
   for (auto option_elem : option_vec) {
@@ -1662,26 +1662,30 @@ private:
   if (cur_arg_pos != OptionArgElement::eUnrecognizedArg &&
   cur_arg_pos != OptionArgElement::eBareDash &&
   cur_arg_pos != OptionArgElement::eBareDoubleDash) {
-cur_arg_value = 
request.GetParsedLine().GetArgumentAtIndex(cur_arg_pos);
-
+cur_arg_value =
+request.GetParsedLine().GetArgumentAtIndex(cur_arg_pos);
   }
 }
 SetOptionValue(cur_defs_index, cur_arg_value, exe_ctx);
   }
   OptionParsingFinished(exe_ctx);
 }
-
-void ProcessCompletionDict(CompletionRequest &request, 
StructuredData::DictionarySP &completion_dict_sp) {
+
+void
+ProcessCompletionDict(CompletionRequest &request,
+  StructuredData::DictionarySP &completion_dict_sp) {
   // We don't know how to process an empty completion dict, our callers 
have
   // to do that.
   assert(completion_dict_sp && "Must have valid completion dict");
   // First handle the case of a single completion:
   llvm::StringRef completion;
   // If the dictionary has one element "no-completion" then we return here
-  if (completion_dict_sp->GetValueForKeyAsString("no-completion", 
completion))
+  if (completion

[Lldb-commits] [lldb] Add the ability to define custom completers to the parsed_cmd template. (PR #109062)

2024-09-17 Thread 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 
090850f15dba926e2436089ff679b7015bb59e11...a0b5801ab231670215657ec720fa0c89bc262c04
 lldb/examples/python/cmdtemplate.py 
lldb/examples/python/templates/parsed_cmd.py 
lldb/test/API/commands/command/script/add/TestAddParsedCommand.py 
lldb/test/API/commands/command/script/add/test_commands.py
``





View the diff from darker here.


``diff
--- examples/python/templates/parsed_cmd.py 2024-09-17 23:24:25.00 +
+++ examples/python/templates/parsed_cmd.py 2024-09-17 23:33:31.276094 +
@@ -282,17 +282,17 @@
 object.__setattr__(self, elem["dest"], value)
 elem["_value_set"] = True
 return True
 
 def was_set(self, opt_name):
-""" Call this in the __call__ method of your command to determine
-whether this option was set on the command line.  It is sometimes
-useful to know whether an option has the default value because the
-user set it explicitly (was_set -> True) or not.
-You can also call this in a handle_completion method, but it will
-currently only report true values for the options mentioned 
-BEFORE the cursor point in the command line.
+"""Call this in the __call__ method of your command to determine
+whether this option was set on the command line.  It is sometimes
+useful to know whether an option has the default value because the
+user set it explicitly (was_set -> True) or not.
+You can also call this in a handle_completion method, but it will
+currently only report true values for the options mentioned
+BEFORE the cursor point in the command line.
 """
 
 elem = self.get_option_element(opt_name)
 if not elem:
 return False
@@ -300,12 +300,12 @@
 return elem["_value_set"]
 except AttributeError:
 return False
 
 def dest_for_option(self, opt_name):
-""" This will return the value of the dest variable you defined for 
opt_name.
-Mostly useful for handle_completion where you get passed the long 
option.
+"""This will return the value of the dest variable you defined for 
opt_name.
+Mostly useful for handle_completion where you get passed the long 
option.
 """
 elem = self.get_option_element(opt_name)
 if not elem:
 return None
 value = self.__dict__[elem["dest"]]
@@ -329,12 +329,12 @@
 value_type: one of the lldb.eArgType enum values.  Some of the common 
arg
 types also have default completers, which will be applied 
automatically.
 completion_type: currently these are values form the 
lldb.CompletionType enum.  If
  you need custom completions, implement 
handle_option_argument_completion.
 enum_values: An array of duples: ["element_name", "element_help"].  If 
provided,
- only one of the enum elements is allowed.  The value will 
be the 
- element_name for the chosen enum element as a string. 
+ only one of the enum elements is allowed.  The value will 
be the
+ element_name for the chosen enum element as a string.
 """
 if not dest:
 dest = long_option
 
 if not completion_type:
--- test/API/commands/command/script/add/TestAddParsedCommand.py
2024-09-17 23:24:25.00 +
+++ test/API/commands/command/script/add/TestAddParsedCommand.py
2024-09-17 23:33:31.376819 +
@@ -66,43 +66,61 @@
 
 self.assertEqual(n_errors, expected_num_errors)
 
 return results
 
-def handle_completion(self, cmd_str, exp_num_completions, exp_matches, 
exp_descriptions, match_description):
+def handle_completion(
+self,
+cmd_str,
+exp_num_completions,
+exp_matches,
+exp_descriptions,
+match_description,
+):
 matches = lldb.SBStringList()
 descriptions = lldb.SBStringList()
 
 interp = self.dbg.GetCommandInterpreter()
 num_completions = interp.HandleCompletionWithDescriptions(
 cmd_str, len(cmd_str), 0, 1000, matches, descriptions
 )
-self.assertEqual(num_completions, exp_num_completions, "Number of 
completions is right.")
+self.assertEqual(
+num_completions, exp_num_completions, "Number of completions is 
right."
+)
 num_matches = matches.GetSize()
-self.assertEqual(num_matches, exp_matches.GetSize(), "matches and 
expected matches of different lengths")
+self.assertEqual(
+num_matches,
+exp_matches.GetSize(),
+"matches and expected matches of differen

[Lldb-commits] [lldb] [lldb/Interpreter] Add requirements to Scripted Interface abstract methods (PR #109063)

2024-09-17 Thread via lldb-commits

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Med Ismail Bennani (medismailben)


Changes

This patch adds new requirements to the Scripted Interface abstract method 
checker to check the minimum number of argument for abstract methods.

This check is done when creating the interface object so the object is not 
created if the user implementation doesn't match the abstract method 
requirement.

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


7 Files Affected:

- (modified) lldb/include/lldb/Interpreter/Interfaces/ScriptedInterface.h 
(+16-1) 
- (modified) 
lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/OperatingSystemPythonInterface.h
 (+3-2) 
- (modified) 
lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedPlatformPythonInterface.h
 (+7-4) 
- (modified) 
lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedProcessPythonInterface.h
 (+6-3) 
- (modified) 
lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedPythonInterface.h
 (+70-37) 
- (modified) 
lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedThreadPlanPythonInterface.h
 (+2-1) 
- (modified) 
lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedThreadPythonInterface.h
 (+4-3) 


``diff
diff --git a/lldb/include/lldb/Interpreter/Interfaces/ScriptedInterface.h 
b/lldb/include/lldb/Interpreter/Interfaces/ScriptedInterface.h
index 89c0b36d6fc2a1..a3dc52c435561f 100644
--- a/lldb/include/lldb/Interpreter/Interfaces/ScriptedInterface.h
+++ b/lldb/include/lldb/Interpreter/Interfaces/ScriptedInterface.h
@@ -31,7 +31,22 @@ class ScriptedInterface {
 return m_object_instance_sp;
   }
 
-  virtual llvm::SmallVector GetAbstractMethods() const = 
0;
+  struct AbstractMethodRequirement {
+llvm::StringLiteral name;
+size_t min_arg_count = 0;
+  };
+
+  virtual llvm::SmallVector
+  GetAbstractMethodRequirements() const = 0;
+
+  llvm::SmallVector const GetAbstractMethods() const {
+llvm::SmallVector abstract_methods;
+llvm::transform(GetAbstractMethodRequirements(), abstract_methods.begin(),
+[](const AbstractMethodRequirement &requirement) {
+  return requirement.name;
+});
+return abstract_methods;
+  }
 
   template 
   static Ret ErrorWithMessage(llvm::StringRef caller_name,
diff --git 
a/lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/OperatingSystemPythonInterface.h
 
b/lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/OperatingSystemPythonInterface.h
index 92358ac6c34f7e..102c3c39537686 100644
--- 
a/lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/OperatingSystemPythonInterface.h
+++ 
b/lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/OperatingSystemPythonInterface.h
@@ -31,8 +31,9 @@ class OperatingSystemPythonInterface
  StructuredData::DictionarySP args_sp,
  StructuredData::Generic *script_obj = nullptr) override;
 
-  llvm::SmallVector GetAbstractMethods() const override {
-return llvm::SmallVector({"get_thread_info"});
+  llvm::SmallVector
+  GetAbstractMethodRequirements() const override {
+return llvm::SmallVector({{"get_thread_info"}});
   }
 
   StructuredData::DictionarySP CreateThread(lldb::tid_t tid,
diff --git 
a/lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedPlatformPythonInterface.h
 
b/lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedPlatformPythonInterface.h
index 36a219a656993b..3031508f892322 100644
--- 
a/lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedPlatformPythonInterface.h
+++ 
b/lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedPlatformPythonInterface.h
@@ -29,10 +29,13 @@ class ScriptedPlatformPythonInterface : public 
ScriptedPlatformInterface,
  StructuredData::DictionarySP args_sp,
  StructuredData::Generic *script_obj = nullptr) override;
 
-  llvm::SmallVector GetAbstractMethods() const override {
-return llvm::SmallVector(
-{"list_processes", "attach_to_process", "launch_process",
- "kill_process"});
+  llvm::SmallVector
+  GetAbstractMethodRequirements() const override {
+return llvm::SmallVector(
+{{"list_processes"},
+ {"attach_to_process", 1},
+ {"launch_process", 1},
+ {"kill_process", 1}});
   }
 
   StructuredData::DictionarySP ListProcesses() override;
diff --git 
a/lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedProcessPythonInterface.h
 
b/lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedProcessPythonInterface.h
index 1535d573e72f43..fc645981b61b31 100644
--- 
a/lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedProcessPythonInterface.h
+++ 
b/lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedProcessPythonInterface.h
@@ -31,9 +31,12 @@ class ScriptedProcessPythonInterface : public 
ScriptedProcessInterface,
  StructuredD

[Lldb-commits] [lldb] [lldb/Interpreter] Add requirements to Scripted Interface abstract methods (PR #109063)

2024-09-17 Thread Med Ismail Bennani via lldb-commits

https://github.com/medismailben created 
https://github.com/llvm/llvm-project/pull/109063

This patch adds new requirements to the Scripted Interface abstract method 
checker to check the minimum number of argument for abstract methods.

This check is done when creating the interface object so the object is not 
created if the user implementation doesn't match the abstract method 
requirement.

>From 91d993c5ccb6301037b5e28ae686bc8e6aef6efe Mon Sep 17 00:00:00 2001
From: Med Ismail Bennani 
Date: Fri, 6 Sep 2024 14:00:23 -0700
Subject: [PATCH] [lldb/Interpreter] Add requirements to Scripted Interface
 abstract methods

This patch adds new requirements to the Scripted Interface abstract
method checker to check the minimum number of argument for abstract
methods.

This check is done when creating the interface object so the object is
not created if the user implementation doesn't match the abstract method
requirement.

Signed-off-by: Med Ismail Bennani 
---
 .../Interfaces/ScriptedInterface.h|  17 ++-
 .../OperatingSystemPythonInterface.h  |   5 +-
 .../ScriptedPlatformPythonInterface.h |  11 +-
 .../ScriptedProcessPythonInterface.h  |   9 +-
 .../Interfaces/ScriptedPythonInterface.h  | 107 --
 .../ScriptedThreadPlanPythonInterface.h   |   3 +-
 .../ScriptedThreadPythonInterface.h   |   7 +-
 7 files changed, 108 insertions(+), 51 deletions(-)

diff --git a/lldb/include/lldb/Interpreter/Interfaces/ScriptedInterface.h 
b/lldb/include/lldb/Interpreter/Interfaces/ScriptedInterface.h
index 89c0b36d6fc2a1..a3dc52c435561f 100644
--- a/lldb/include/lldb/Interpreter/Interfaces/ScriptedInterface.h
+++ b/lldb/include/lldb/Interpreter/Interfaces/ScriptedInterface.h
@@ -31,7 +31,22 @@ class ScriptedInterface {
 return m_object_instance_sp;
   }
 
-  virtual llvm::SmallVector GetAbstractMethods() const = 
0;
+  struct AbstractMethodRequirement {
+llvm::StringLiteral name;
+size_t min_arg_count = 0;
+  };
+
+  virtual llvm::SmallVector
+  GetAbstractMethodRequirements() const = 0;
+
+  llvm::SmallVector const GetAbstractMethods() const {
+llvm::SmallVector abstract_methods;
+llvm::transform(GetAbstractMethodRequirements(), abstract_methods.begin(),
+[](const AbstractMethodRequirement &requirement) {
+  return requirement.name;
+});
+return abstract_methods;
+  }
 
   template 
   static Ret ErrorWithMessage(llvm::StringRef caller_name,
diff --git 
a/lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/OperatingSystemPythonInterface.h
 
b/lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/OperatingSystemPythonInterface.h
index 92358ac6c34f7e..102c3c39537686 100644
--- 
a/lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/OperatingSystemPythonInterface.h
+++ 
b/lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/OperatingSystemPythonInterface.h
@@ -31,8 +31,9 @@ class OperatingSystemPythonInterface
  StructuredData::DictionarySP args_sp,
  StructuredData::Generic *script_obj = nullptr) override;
 
-  llvm::SmallVector GetAbstractMethods() const override {
-return llvm::SmallVector({"get_thread_info"});
+  llvm::SmallVector
+  GetAbstractMethodRequirements() const override {
+return llvm::SmallVector({{"get_thread_info"}});
   }
 
   StructuredData::DictionarySP CreateThread(lldb::tid_t tid,
diff --git 
a/lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedPlatformPythonInterface.h
 
b/lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedPlatformPythonInterface.h
index 36a219a656993b..3031508f892322 100644
--- 
a/lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedPlatformPythonInterface.h
+++ 
b/lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedPlatformPythonInterface.h
@@ -29,10 +29,13 @@ class ScriptedPlatformPythonInterface : public 
ScriptedPlatformInterface,
  StructuredData::DictionarySP args_sp,
  StructuredData::Generic *script_obj = nullptr) override;
 
-  llvm::SmallVector GetAbstractMethods() const override {
-return llvm::SmallVector(
-{"list_processes", "attach_to_process", "launch_process",
- "kill_process"});
+  llvm::SmallVector
+  GetAbstractMethodRequirements() const override {
+return llvm::SmallVector(
+{{"list_processes"},
+ {"attach_to_process", 1},
+ {"launch_process", 1},
+ {"kill_process", 1}});
   }
 
   StructuredData::DictionarySP ListProcesses() override;
diff --git 
a/lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedProcessPythonInterface.h
 
b/lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedProcessPythonInterface.h
index 1535d573e72f43..fc645981b61b31 100644
--- 
a/lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedProcessPythonInterface.h
+++ 
b/lldb/source/Plugins/ScriptInterpreter/Python/Int

[Lldb-commits] [lldb] Add the ability to define custom completers to the parsed_cmd template. (PR #109062)

2024-09-17 Thread via lldb-commits

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: None (jimingham)


Changes

If  your arguments or option values are of a type that naturally uses one of 
our common completion mechanisms, you will get completion for free.  But if you 
have your own custom values or if you want to do fancy things like have `break 
set -s foo.dylib -n ba` only complete on symbols in foo.dylib, you 
can use this new mechanism to achieve that.

---

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


14 Files Affected:

- (modified) lldb/bindings/python/python-wrapper.swig (+73) 
- (modified) lldb/docs/use/python-reference.rst (+143-1) 
- (modified) lldb/examples/python/cmdtemplate.py (+8-7) 
- (modified) lldb/examples/python/templates/parsed_cmd.py (+79-5) 
- (modified) lldb/include/lldb/Interpreter/ScriptInterpreter.h (+15) 
- (modified) lldb/include/lldb/Utility/CompletionRequest.h (+2) 
- (modified) lldb/source/Commands/CommandObjectCommands.cpp (+187) 
- (modified) lldb/source/Interpreter/Options.cpp (+3-2) 
- (modified) lldb/source/Plugins/ScriptInterpreter/Python/SWIGPythonBridge.h 
(+8) 
- (modified) 
lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp (+40) 
- (modified) 
lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPythonImpl.h (+8) 
- (modified) lldb/test/API/commands/command/script/add/TestAddParsedCommand.py 
(+81-34) 
- (modified) lldb/test/API/commands/command/script/add/test_commands.py 
(+46-18) 
- (modified) lldb/unittests/ScriptInterpreter/Python/PythonTestSuite.cpp (+13) 


``diff
diff --git a/lldb/bindings/python/python-wrapper.swig 
b/lldb/bindings/python/python-wrapper.swig
index 810673aaec5d19..1f5012af99a291 100644
--- a/lldb/bindings/python/python-wrapper.swig
+++ b/lldb/bindings/python/python-wrapper.swig
@@ -752,6 +752,79 @@ 
lldb_private::python::SWIGBridge::LLDBSwigPythonGetRepeatCommandForScriptedComma
   return result.Str().GetString().str();
 }
 
+StructuredData::DictionarySP
+lldb_private::python::SWIGBridge::LLDBSwigPythonHandleArgumentCompletionForScriptedCommand(PyObject
 *implementor,
+std::vector &args_vec, size_t args_pos, size_t 
pos_in_arg) {
+
+  PyErr_Cleaner py_err_cleaner(true);
+
+  PythonObject self(PyRefType::Borrowed, implementor);
+  auto pfunc = self.ResolveName("handle_argument_completion");
+  // If this isn't implemented, return an empty dict to signal falling back to 
default completion:
+  if (!pfunc.IsAllocated())
+return {};
+
+  PythonList args_list(PyInitialValue::Empty);
+  for (auto elem : args_vec)
+args_list.AppendItem(PythonString(elem));
+
+  PythonObject result = pfunc(args_list, PythonInteger(args_pos), 
PythonInteger(pos_in_arg));
+  // Returning None means do the ordinary completion
+  if (result.IsNone())
+return {};
+
+  // Convert the return dictionary to a DictionarySP.
+  StructuredData::ObjectSP result_obj_sp = result.CreateStructuredObject();
+  if (!result_obj_sp)
+return {};
+
+  StructuredData::DictionarySP dict_sp(new 
StructuredData::Dictionary(result_obj_sp));
+  if (dict_sp->GetType() == lldb::eStructuredDataTypeInvalid)
+return {};
+  return dict_sp;
+}
+
+StructuredData::DictionarySP
+lldb_private::python::SWIGBridge::LLDBSwigPythonHandleOptionArgumentCompletionForScriptedCommand(PyObject
 *implementor,
+llvm::StringRef &long_option, size_t pos_in_arg) {
+
+  PyErr_Cleaner py_err_cleaner(true);
+
+  PythonObject self(PyRefType::Borrowed, implementor);
+  auto pfunc = 
self.ResolveName("handle_option_argument_completion");
+  // If this isn't implemented, return an empty dict to signal falling back to 
default completion:
+  if (!pfunc.IsAllocated())
+return {};
+
+  PythonObject result = pfunc(PythonString(long_option), 
PythonInteger(pos_in_arg));
+  // Returning None means do the ordinary completion
+  if (result.IsNone())
+return {};
+
+  // Returning a boolean:
+  // True means the completion was handled, but there were no completions
+  // False means that the completion was not handled, again, do the ordinary 
completion:
+  if (result.GetObjectType() == PyObjectType::Boolean) {
+if (!result.IsTrue())
+  return {};
+// Make up a completion dictionary with the right element:
+StructuredData::DictionarySP dict_sp(new StructuredData::Dictionary());
+dict_sp->AddBooleanItem("no-completion", true);
+return dict_sp;
+  }
+
+
+  // Convert the return dictionary to a DictionarySP.
+  StructuredData::ObjectSP result_obj_sp = result.CreateStructuredObject();
+  if (!result_obj_sp)
+return {};
+
+  StructuredData::DictionarySP dict_sp(new 
StructuredData::Dictionary(result_obj_sp));
+  if (dict_sp->GetType() == lldb::eStructuredDataTypeInvalid)
+return {};
+  return dict_sp;
+}
+
 #include "lldb/Interpreter/CommandReturnObject.h"
 
 bool lldb_private::python::SWIGBridge::LLDBSwigPythonCallParsedCommandObject(
diff --git a/lldb/docs/use/python-referenc

[Lldb-commits] [lldb] Add the ability to define custom completers to the parsed_cmd template. (PR #109062)

2024-09-17 Thread via lldb-commits

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

If  your arguments or option values are of a type that naturally uses one of 
our common completion mechanisms, you will get completion for free.  But if you 
have your own custom values or if you want to do fancy things like have `break 
set -s foo.dylib -n ba` only complete on symbols in foo.dylib, you can use 
this new mechanism to achieve that.

>From a0b5801ab231670215657ec720fa0c89bc262c04 Mon Sep 17 00:00:00 2001
From: Jim Ingham 
Date: Thu, 29 Aug 2024 18:22:13 -0700
Subject: [PATCH] Add the ability to define custom completers for option values
 and arguments to the parsed_cmd template.

---
 lldb/bindings/python/python-wrapper.swig  |  73 +++
 lldb/docs/use/python-reference.rst| 144 +-
 lldb/examples/python/cmdtemplate.py   |  15 +-
 lldb/examples/python/templates/parsed_cmd.py  |  84 +++-
 .../lldb/Interpreter/ScriptInterpreter.h  |  15 ++
 lldb/include/lldb/Utility/CompletionRequest.h |   2 +
 .../source/Commands/CommandObjectCommands.cpp | 187 ++
 lldb/source/Interpreter/Options.cpp   |   5 +-
 .../Python/SWIGPythonBridge.h |   8 +
 .../Python/ScriptInterpreterPython.cpp|  40 
 .../Python/ScriptInterpreterPythonImpl.h  |   8 +
 .../script/add/TestAddParsedCommand.py| 115 +++
 .../command/script/add/test_commands.py   |  64 --
 .../Python/PythonTestSuite.cpp|  13 ++
 14 files changed, 706 insertions(+), 67 deletions(-)

diff --git a/lldb/bindings/python/python-wrapper.swig 
b/lldb/bindings/python/python-wrapper.swig
index 810673aaec5d19..1f5012af99a291 100644
--- a/lldb/bindings/python/python-wrapper.swig
+++ b/lldb/bindings/python/python-wrapper.swig
@@ -752,6 +752,79 @@ 
lldb_private::python::SWIGBridge::LLDBSwigPythonGetRepeatCommandForScriptedComma
   return result.Str().GetString().str();
 }
 
+StructuredData::DictionarySP
+lldb_private::python::SWIGBridge::LLDBSwigPythonHandleArgumentCompletionForScriptedCommand(PyObject
 *implementor,
+std::vector &args_vec, size_t args_pos, size_t 
pos_in_arg) {
+
+  PyErr_Cleaner py_err_cleaner(true);
+
+  PythonObject self(PyRefType::Borrowed, implementor);
+  auto pfunc = self.ResolveName("handle_argument_completion");
+  // If this isn't implemented, return an empty dict to signal falling back to 
default completion:
+  if (!pfunc.IsAllocated())
+return {};
+
+  PythonList args_list(PyInitialValue::Empty);
+  for (auto elem : args_vec)
+args_list.AppendItem(PythonString(elem));
+
+  PythonObject result = pfunc(args_list, PythonInteger(args_pos), 
PythonInteger(pos_in_arg));
+  // Returning None means do the ordinary completion
+  if (result.IsNone())
+return {};
+
+  // Convert the return dictionary to a DictionarySP.
+  StructuredData::ObjectSP result_obj_sp = result.CreateStructuredObject();
+  if (!result_obj_sp)
+return {};
+
+  StructuredData::DictionarySP dict_sp(new 
StructuredData::Dictionary(result_obj_sp));
+  if (dict_sp->GetType() == lldb::eStructuredDataTypeInvalid)
+return {};
+  return dict_sp;
+}
+
+StructuredData::DictionarySP
+lldb_private::python::SWIGBridge::LLDBSwigPythonHandleOptionArgumentCompletionForScriptedCommand(PyObject
 *implementor,
+llvm::StringRef &long_option, size_t pos_in_arg) {
+
+  PyErr_Cleaner py_err_cleaner(true);
+
+  PythonObject self(PyRefType::Borrowed, implementor);
+  auto pfunc = 
self.ResolveName("handle_option_argument_completion");
+  // If this isn't implemented, return an empty dict to signal falling back to 
default completion:
+  if (!pfunc.IsAllocated())
+return {};
+
+  PythonObject result = pfunc(PythonString(long_option), 
PythonInteger(pos_in_arg));
+  // Returning None means do the ordinary completion
+  if (result.IsNone())
+return {};
+
+  // Returning a boolean:
+  // True means the completion was handled, but there were no completions
+  // False means that the completion was not handled, again, do the ordinary 
completion:
+  if (result.GetObjectType() == PyObjectType::Boolean) {
+if (!result.IsTrue())
+  return {};
+// Make up a completion dictionary with the right element:
+StructuredData::DictionarySP dict_sp(new StructuredData::Dictionary());
+dict_sp->AddBooleanItem("no-completion", true);
+return dict_sp;
+  }
+
+
+  // Convert the return dictionary to a DictionarySP.
+  StructuredData::ObjectSP result_obj_sp = result.CreateStructuredObject();
+  if (!result_obj_sp)
+return {};
+
+  StructuredData::DictionarySP dict_sp(new 
StructuredData::Dictionary(result_obj_sp));
+  if (dict_sp->GetType() == lldb::eStructuredDataTypeInvalid)
+return {};
+  return dict_sp;
+}
+
 #include "lldb/Interpreter/CommandReturnObject.h"
 
 bool lldb_private::python::SWIGBridge::LLDBSwigPythonCallParsedCommandObject(
diff --git a/lldb/docs/use/python-reference.rst 
b/lldb/docs/use/python-reference.rst
in

[Lldb-commits] [lldb] [llvm] [lldb][RISCV] function calls support in lldb expressions (PR #99336)

2024-09-17 Thread Craig Topper via lldb-commits

topperc wrote:

> I read through the patch again cleanly, and I don't have any problems with 
> the PR at this point. The only thing I would note is that in 
> `GetClangTargetABI` we're constructing a string which indicates which ISA 
> extensions are enabled (that are relevant here) to return a string like 
> `lp64f`, which is then used in `SetupTargetOpts` to add the feature flags 
> that should be enabled for clang. We are doing the exact same thing in 
> `DisassemblerLLVMC::DisassemblerLLVMC`,
> 
> ```
>   if (triple.isRISCV()) {
> uint32_t arch_flags = arch.GetFlags();
> if (arch_flags & ArchSpec::eRISCV_rvc)
>   features_str += "+c,";
> if (arch_flags & ArchSpec::eRISCV_rve)
>   features_str += "+e,";
> if ((arch_flags & ArchSpec::eRISCV_float_abi_single) ==
> ArchSpec::eRISCV_float_abi_single)
>   features_str += "+f,";
> if ((arch_flags & ArchSpec::eRISCV_float_abi_double) ==
> ArchSpec::eRISCV_float_abi_double)
>   features_str += "+f,+d,";
> ```
> 
> etc. It's a small bit of duplication, but I expect these will be at risk of 
> diverging if done separately. I wonder if our ArchSpec should have a method 
> to get the clang feature flags.

That code doesn't look right. Shouldn't it be using eRISCV_float_abi_mask. It's 
treat each single and double as bit positions, but they are really encodings in 
2-bit field.

```
 if ((arch_flags & ArchSpec::eRISCV_float_abi_mask) ==
 ArchSpec::eRISCV_float_abi_single)
   features_str += "+f,";
 if ((arch_flags & ArchSpec::eRISCV_float_abi_mask) ==
 ArchSpec::eRISCV_float_abi_double)
   features_str += "+f,+d,";
```

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


[Lldb-commits] [lldb] [llvm] [lldb][RISCV] function calls support in lldb expressions (PR #99336)

2024-09-17 Thread Jason Molenda via lldb-commits

jasonmolenda wrote:

I read through the patch again cleanly, and I don't have any problems with the 
PR at this point.  The only thing I would note is that in `GetClangTargetABI` 
we're constructing a string which indicates which ISA extensions are enabled 
(that are relevant here) to return a string like `lp64f`, which is then used in 
`SetupTargetOpts` to add the feature flags that should be enabled for clang.  
We are doing the exact same thing in `DisassemblerLLVMC::DisassemblerLLVMC`, 

```
  if (triple.isRISCV()) {
uint32_t arch_flags = arch.GetFlags();
if (arch_flags & ArchSpec::eRISCV_rvc)
  features_str += "+c,";
if (arch_flags & ArchSpec::eRISCV_rve)
  features_str += "+e,";
if ((arch_flags & ArchSpec::eRISCV_float_abi_single) ==
ArchSpec::eRISCV_float_abi_single)
  features_str += "+f,";
if ((arch_flags & ArchSpec::eRISCV_float_abi_double) ==
ArchSpec::eRISCV_float_abi_double)
  features_str += "+f,+d,";
```
etc.  It's a small bit of duplication, but I expect these will be at risk of 
diverging if done separately.  I wonder if our ArchSpec should have a method to 
get the clang feature flags.

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


[Lldb-commits] [lldb] [lldb-dap] Support inspecting memory (PR #104317)

2024-09-17 Thread Adrian Vogelsgesang via lldb-commits

vogelsgesang wrote:

I think there is actually an even simpler fix for this test failure...
https://github.com/llvm/llvm-project/pull/109057

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


<    1   2   3   4   5   6   7   8   9   10   >