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

[Adrian Vogelsgesang via lldb-commits]

vogelsgesang wrote:

> [...] like I said I'm a bit scared of it being too aggressive.

Yes, this is also my main concern here. E.g., for `std::ranges::sort`, it 
already turns out to be slightly too aggressive, as discussed in the commit 
message and the test case comment. The "`std::ranges::sort` calls an operator() 
of an internal struct type" pattern is already slightly problematic...

Do you have an idea how we could de-risk this change? E.g., would do you have a 
couple more scenarios in mind for which I should add test cases? Are there 
similar patterns to the `operator()` which I should also cover?

Do we have some libc++ developers which are using lldb top-of-tree for their 
day-to-day work on libc++ and who would make us aware in case this commit turns 
out to be too aggressive?

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] [libcxx] [lldb] [lldb][libc++] Hide all libc++ implementation details from stacktraces (PR #108870)

[Michael Buch via lldb-commits]

Michael137 wrote:

When you're stopped in a frame and you have libc++ frames above you in the 
backtrace, you're either stopped in a callback (like `std::function`, 
`std::make_unique`, `std::sort`), or you're deliberately stepping into libc++ 
code. For the latter, you probably don't want to hide any of the implementation 
details (though the libc++ devs might be able to comment better on their 
workflow here). I would find it weird if I stepped into a series of function 
calls manually but the backtrace omitted my path down.

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? Not sure. Wdyt?

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 AST node classes, functions, etc. for Data Inspection Lang… (PR #95738)

[Michael Buch via lldb-commits]

Michael137 wrote:

> > Is the plan to get the DIL data structures merged before the rest of the 
> > patch series is up for review? I think it'd be great to see how the 
> > infrastructure introduced here will be used
> 
> There are 3 major pieces to the DIL implementation (soon to be 4, once I've 
> got the lexer written): The AST bit; the parser, which is a recursive descent 
> parser using the .ebnf grammar; and the interpreter/evaluator. The parser 
> performs parsing and type-checking on the input expression, building up the 
> AST as it goes. Once the AST is built, it gets passed to the 
> interpreter/evaluator, which evaluates the AST (performing more correctness 
> checks along the way), returning an LLDB ValueObjectSP at the end. I have 
> both 'stripped down' and 'full' versions of all of these pieces. The 
> 'stripped down' pieces match the current 'frame variable' functionality, and 
> the 'full' versions implement extensions to that functionality (allowing it 
> to handle all the expressions that lldb-eval could handle).
> 
> The plan is to submit a series of PRs as follows: 1). the AST parts (this 
> PR). 2). the not-yet-written lexer (with any necessary changes to the already 
> submitted AST parts); 3). the parser; 4) the evaluator; 5); the 'glue', i.e. 
> updates to things like StackFrame.cpp & CommandObjectFrame.cpp, to hook up 
> the new DIL implementation (optionally), as well as the test cases. 
> Currently, the stripped down parser is ~2700 lines of code, and the stripped 
> down evaluator is ~1000 lines of code.
> 
> As I mentioned in an earlier comment (on June 24), you can see the full (not 
> stripped down) implementation at 
> https://github.com/cmtice/llvm-project/tree/DIL-work-new/ , although I have 
> not (yet) updated that with the updates that have gone into this PR.
> 
> Does that answer all of your questions? Or is there more you would like to 
> know or see?

Thanks for the breakdown! I was just wondering whether the plan was to merge 
this before the other PRs are up. I think it'd be preferable to merge them once 
they all have been approved. Though if others are ok with the current strategy 
I don't want to block this.



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

[Lldb-commits] [lldb] [lldb/DWARF] Cache negative results of variable parsing (PR #108810)

[Michael Buch via lldb-commits]

https://github.com/Michael137 commented:

Are there cases where we fail to `ParseVariableDIE` the first time around but 
could succeed later on in the debug sessions?

This comment seems to suggest that's possible: 
https://github.com/llvm/llvm-project/blob/bbab5e47c17c0ebc9dfe20f43c8aeaae95f37b9e/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp#L3714-L3719

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

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

[Adrian Vogelsgesang via lldb-commits]

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

>From 60b26a50218e20431dd645b93d341403ff5b2ee4 Mon Sep 17 00:00:00 2001
From: Adrian Vogelsgesang 
Date: Tue, 27 Aug 2024 17:34:11 +
Subject: [PATCH 1/2] [lldb][libc++] Hide all libc++ implementation details
 from stacktraces

This commit changes the libc++ frame recognizer to hide implementation
details of libc++ more aggressively. The applied heuristic is rather
straightforward: We consider every function name starting with `__` as
an implementation detail.

This works pretty neatly for `std::invoke`, `std::function`,
`std::sort`, `std::map::emplace` and many others. Also, this should
align quite nicely with libc++'s general coding convention of using the
`__` for their implementation details, thereby keeping the future
maintenance effort low.

However, it is noteworthy, that this does not work 100% in all cases:
E.g., for `std::ranges::sort`, itself is not really a function call, but
an object with an overloaded `operator()`, which means that there is no
actual call `std::ranges::sort` in the call stack.
---
 libcxx/docs/UserDocumentation.rst | 26 ++
 .../CPlusPlus/CPPLanguageRuntime.cpp  | 27 ++
 .../cpp/libcxx-internals-recognizer/Makefile  |  5 ++
 .../TestLibcxxInternalsRecognizer.py  | 56 
 .../cpp/libcxx-internals-recognizer/main.cpp  | 86 +++
 5 files changed, 181 insertions(+), 19 deletions(-)
 create mode 100644 lldb/test/API/lang/cpp/libcxx-internals-recognizer/Makefile
 create mode 100644 
lldb/test/API/lang/cpp/libcxx-internals-recognizer/TestLibcxxInternalsRecognizer.py
 create mode 100644 lldb/test/API/lang/cpp/libcxx-internals-recognizer/main.cpp

diff --git a/libcxx/docs/UserDocumentation.rst 
b/libcxx/docs/UserDocumentation.rst
index 6659fa54f49df5..8999b4f23e91d2 100644
--- a/libcxx/docs/UserDocumentation.rst
+++ b/libcxx/docs/UserDocumentation.rst
@@ -346,6 +346,32 @@ Third-party Integrations
 
 Libc++ provides integration with a few third-party tools.
 
+Debugging libc++ internals in LLDB
+--
+
+LLDB hides the implementation details of libc++ by default.
+
+E.g., when setting a breakpoint in a comparator passed to ``std::sort``, the
+backtrace will read as
+
+.. code-block::
+
+  (lldb) thread backtrace
+  * thread #1, name = 'a.out', stop reason = breakpoint 3.1
+* frame #0: 0x520e a.out`my_comparator(a=1, b=8) at 
test-std-sort.cpp:6:3
+  frame #7: 0x5615 a.out`void 
std::__1::sort[abi:ne20], bool (*)(int, 
int)>(__first=(item = 8), __last=(item = 0), __comp=(a.out`my_less(int, int) at 
test-std-sort.cpp:5)) at sort.h:1003:3
+  frame #8: 0x531a a.out`main at test-std-sort.cpp:24:3
+
+Note how the caller of ``my_comparator`` is shown as ``std::sort``. Looking at
+the frame numbers, we can see that frames #1 until #6 were hidden. Those frames
+represent internal implementation details such as ``__sort4`` and similar
+utility functions.
+
+To also show those implementation details, use ``thread backtrace -u``.
+Alternatively, to disable those compact backtraces for good, use
+``frame recognizer list`` and ``frame recognizer delete`` to delete the libc++
+frame recognizer.
+
 GDB Pretty printers for libc++
 --
 
diff --git 
a/lldb/source/Plugins/LanguageRuntime/CPlusPlus/CPPLanguageRuntime.cpp 
b/lldb/source/Plugins/LanguageRuntime/CPlusPlus/CPPLanguageRuntime.cpp
index faa05e8f834ea1..d0e84bdeb94f01 100644
--- a/lldb/source/Plugins/LanguageRuntime/CPlusPlus/CPPLanguageRuntime.cpp
+++ b/lldb/source/Plugins/LanguageRuntime/CPlusPlus/CPPLanguageRuntime.cpp
@@ -45,7 +45,7 @@ char CPPLanguageRuntime::ID = 0;
 /// A frame recognizer that is installed to hide libc++ implementation
 /// details from the backtrace.
 class LibCXXFrameRecognizer : public StackFrameRecognizer {
-  std::array m_hidden_regex;
+  std::array m_hidden_regex;
   RecognizedStackFrameSP m_hidden_frame;
 
   struct LibCXXHiddenFrame : public RecognizedStackFrame {
@@ -55,28 +55,17 @@ class LibCXXFrameRecognizer : public StackFrameRecognizer {
 public:
   LibCXXFrameRecognizer()
   : m_hidden_regex{
-// internal implementation details of std::function
+// internal implementation details in the `std::` namespace
 //std::__1::__function::__alloc_func, void ()>::operator()[abi:ne20]
 //std::__1::__function::__func, void ()>::operator()
 //std::__1::__function::__value_func::operator()[abi:ne20]() const
-RegularExpression{""
-  R"(^std::__[^:]*::)" // Namespace.
-  R"(__function::.*::operator\(\))"},
-// internal implementation details of std::function in ABI v2
 //std::__2::__function::__policy_invoker::__call_impl[abi:ne20]>
-RegularExpression{""
-  R"(^std::__[^:]*::)" // Namespace.
-

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

[via lldb-commits]

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

>From 30e1a6fdc39f637095eec89584f6b163bc53037d Mon Sep 17 00:00:00 2001
From: Serby 
Date: Tue, 17 Sep 2024 12:19:36 +0300
Subject: [PATCH] vscode-lldb - Add Environment configuration for the lldb-dap
 process

---
 lldb/tools/lldb-dap/package-lock.json   |  4 ++--
 lldb/tools/lldb-dap/package.json| 11 ++-
 lldb/tools/lldb-dap/src-ts/extension.ts | 11 +--
 3 files changed, 21 insertions(+), 5 deletions(-)

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

[via lldb-commits]

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Serban (serby2000)


Changes

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.

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


3 Files Affected:

- (modified) lldb/tools/lldb-dap/package-lock.json (+2-2) 
- (modified) lldb/tools/lldb-dap/package.json (+10-1) 
- (modified) lldb/tools/lldb-dap/src-ts/extension.ts (+9-2) 


``diff
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..cbe098b6fc7e37 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,
 },
   },

``




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] b39a100 - [lldb][lldb-dap] Remove unused includes in memory test

[David Spickett via lldb-commits]

Author: David Spickett
Date: 2024-09-17T09:30:14Z
New Revision: b39a100ff4ec16f1f9cafcc48ea7fed920726650

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

LOG: [lldb][lldb-dap] Remove unused includes in memory test

Added in 3acb1eac5eb6ef4e60dd64b7845615e076cc6a3e

Added: 


Modified: 
lldb/test/API/tools/lldb-dap/memory/main.cpp

Removed: 




diff  --git a/lldb/test/API/tools/lldb-dap/memory/main.cpp 
b/lldb/test/API/tools/lldb-dap/memory/main.cpp
index 14ac1ad95e330f..0db7b78e93383d 100644
--- a/lldb/test/API/tools/lldb-dap/memory/main.cpp
+++ b/lldb/test/API/tools/lldb-dap/memory/main.cpp
@@ -1,6 +1,3 @@
-#include 
-#include 
-
 int main() {
   int not_a_ptr = 666;
   const char *rawptr = "dead";



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

[Lldb-commits] [clang] [lldb] [ASTImporter][lldb] Avoid implicit imports in VisitFieldDecl (PR #107828)

[Andrew Savonichev via lldb-commits]

asavonic wrote:

> Our idea is summarized in 
> https://discourse.llvm.org/t/rfc-lldb-more-reliable-completion-of-record-types/77442.
>  Basically the goal is to guarantee that a call to `getDefinition`, _will_ 
> fetch the definition. This is something that Clang already does, but we just 
> never implement (via `CompleteRedeclChain`). You're right that the "minimal 
> import" mode was implemented for perf. reasons. Though we should probably 
> revisit this. I think we can make LLDB use non-minimal import for record 
> types while keeping the number of transitive imports contained. It would 
> still require changes to the importer to be smarter about what we import, but 
> we wouldn't have these "complete but incomplete" types floating around.

Thanks a lot Michael. It's a lot of work to get the redesign ready, considering 
both functional and performance requirements.

In the meantime, should we merge this patch to fix at least some current 
problems?


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

[David Spickett via lldb-commits]

DavidSpickett wrote:

The test case is failing on Windows, for reasons not related to it being 
Windows but due to data layout.

The const string is placed at the start of a region:
```
(lldb) p rawptr
(const char *) 0x7ff77fcb5000 "dead"
(lldb) memory region --all
<...>
[0x7ff77fc61000-0x7ff77fcb5000) r-x .text
[0x7ff77fcb5000-0x7ff77fcc2000) r-- .rdata
```
This means that when you read with offset `-1` it starts 1 byte into the 
`.text` section, reads that single byte, then returns.

(same thing would happen if the memory was the last part of a region, a 
positive offset would make the read end early when it hit the end of the region)

Your code needs to be aware that this may happen, or just do the memory read 
without looking up the region and assume that the lower layers do the right 
thing (I don't know if they do).

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

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

[Egor Zhdan via lldb-commits]

egorzhdan wrote:

This is a great UX improvement, thanks!

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] ab38ec9 - [lldb][lldb-dap] Disable read memory test on Windows

[David Spickett via lldb-commits]

Author: David Spickett
Date: 2024-09-17T12:51:46Z
New Revision: ab38ec9ac312460e4f71c8ad3f50b9b5723469f6

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

LOG: [lldb][lldb-dap] Disable read memory test on Windows

This isn't strictly a Windows issue but for now it's the only bot
that was hit by this failure.

It can happen on Linux too but I expect we'll fix it and remove the
skip soon anyway.

Test was added in #104317.

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 8bee70e50dcad9..3d8aaeda7f4b85 100644
--- a/lldb/test/API/tools/lldb-dap/memory/TestDAP_memory.py
+++ b/lldb/test/API/tools/lldb-dap/memory/TestDAP_memory.py
@@ -74,6 +74,10 @@ 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



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

[via lldb-commits]

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

>From 08b0bb18e46be06ddf6397455382c5b75bc3b757 Mon Sep 17 00:00:00 2001
From: Daniil Avdeev 
Date: Thu, 11 Jul 2024 11:21:36 +
Subject: [PATCH 1/5] [lldb][RISCV] add jitted function calls to ABI

Function calls support in LLDB expressions for RISCV: 1 of 5

Augments corresponding functionality to RISCV ABI, which allows to jit
lldb expressions and thus make function calls inside them. Only function
calls with integer and void function arguments and return value are
supported.
---
 .../Plugins/ABI/RISCV/ABISysV_riscv.cpp   | 91 +--
 1 file changed, 84 insertions(+), 7 deletions(-)

diff --git a/lldb/source/Plugins/ABI/RISCV/ABISysV_riscv.cpp 
b/lldb/source/Plugins/ABI/RISCV/ABISysV_riscv.cpp
index de304183f67175..38d452b6ab560c 100644
--- a/lldb/source/Plugins/ABI/RISCV/ABISysV_riscv.cpp
+++ b/lldb/source/Plugins/ABI/RISCV/ABISysV_riscv.cpp
@@ -10,7 +10,9 @@
 
 #include 
 #include 
+#include 
 
+#include "llvm/ADT/STLExtras.h"
 #include "llvm/IR/DerivedTypes.h"
 
 #include "Utility/RISCV_DWARF_Registers.h"
@@ -20,6 +22,7 @@
 #include "lldb/Target/RegisterContext.h"
 #include "lldb/Target/StackFrame.h"
 #include "lldb/Target/Thread.h"
+#include "lldb/Utility/LLDBLog.h"
 #include "lldb/Utility/RegisterValue.h"
 
 #define DEFINE_REG_NAME(reg_num) ConstString(#reg_num).GetCString()
@@ -120,6 +123,10 @@ static const std::array g_register_infos 
= {
 } // namespace dwarf
 } // namespace
 
+// Number of argument registers (the base integer calling convention
+// provides 8 argument registers, a0-a7)
+static constexpr size_t g_regs_for_args_count = 8U;
+
 const RegisterInfo *ABISysV_riscv::GetRegisterInfoArray(uint32_t &count) {
   count = dwarf::g_register_infos.size();
   return dwarf::g_register_infos.data();
@@ -164,11 +171,81 @@ TotalArgsSizeInWords(bool is_rv64,
   return total_size;
 }
 
+static bool UpdateRegister(RegisterContext *reg_ctx,
+   const lldb::RegisterKind reg_kind,
+   const uint32_t reg_num, const addr_t value) {
+  Log *log = GetLog(LLDBLog::Expressions);
+
+  const RegisterInfo *reg_info = reg_ctx->GetRegisterInfo(reg_kind, reg_num);
+
+  LLDB_LOG(log, "Writing {0}: 0x{1:x}", reg_info->name,
+   static_cast(value));
+  if (!reg_ctx->WriteRegisterFromUnsigned(reg_info, value)) {
+LLDB_LOG(log, "Writing {0}: failed", reg_info->name);
+return false;
+  }
+  return true;
+}
+
+static void LogInitInfo(Log &log, const Thread &thread, addr_t sp,
+addr_t func_addr, addr_t return_addr,
+const llvm::ArrayRef args) {
+  std::stringstream ss;
+  ss << "ABISysV_riscv::PrepareTrivialCall"
+ << " (tid = 0x" << std::hex << thread.GetID() << ", sp = 0x" << sp
+ << ", func_addr = 0x" << func_addr << ", return_addr = 0x" << return_addr;
+
+  for (auto [idx, arg] : enumerate(args))
+ss << ", arg" << std::dec << idx << " = 0x" << std::hex << arg;
+  ss << ")";
+  log.PutString(ss.str());
+}
+
 bool ABISysV_riscv::PrepareTrivialCall(Thread &thread, addr_t sp,
addr_t func_addr, addr_t return_addr,
llvm::ArrayRef args) const {
-  // TODO: Implement
-  return false;
+  Log *log = GetLog(LLDBLog::Expressions);
+  if (log)
+LogInitInfo(*log, thread, sp, func_addr, return_addr, args);
+
+  const auto reg_ctx_sp = thread.GetRegisterContext();
+  if (!reg_ctx_sp) {
+LLDB_LOG(log, "Failed to get RegisterContext");
+return false;
+  }
+
+  if (args.size() > g_regs_for_args_count) {
+LLDB_LOG(log, "Function has {0} arguments, but only {1} are allowed!",
+ args.size(), g_regs_for_args_count);
+return false;
+  }
+
+  // Write arguments to registers
+  for (auto [idx, arg] : enumerate(args)) {
+const RegisterInfo *reg_info = reg_ctx_sp->GetRegisterInfo(
+eRegisterKindGeneric, LLDB_REGNUM_GENERIC_ARG1 + idx);
+LLDB_LOG(log, "About to write arg{0} (0x{1:x}) into {2}", idx, arg,
+ reg_info->name);
+
+if (!reg_ctx_sp->WriteRegisterFromUnsigned(reg_info, arg)) {
+  LLDB_LOG(log, "Failed to write arg{0} (0x{1:x}) into {2}", idx, arg,
+   reg_info->name);
+  return false;
+}
+  }
+
+  if (!UpdateRegister(reg_ctx_sp.get(), eRegisterKindGeneric,
+  LLDB_REGNUM_GENERIC_PC, func_addr))
+return false;
+  if (!UpdateRegister(reg_ctx_sp.get(), eRegisterKindGeneric,
+  LLDB_REGNUM_GENERIC_SP, sp))
+return false;
+  if (!UpdateRegister(reg_ctx_sp.get(), eRegisterKindGeneric,
+  LLDB_REGNUM_GENERIC_RA, return_addr))
+return false;
+
+  LLDB_LOG(log, "ABISysV_riscv::{0}() success", __FUNCTION__);
+  return true;
 }
 
 bool ABISysV_riscv::PrepareTrivialCall(
@@ -222,14 +299,14 @@ bool ABISysV_riscv::PrepareTrivialCall(
   assert(prototype.getFunctionNumParams() == args.size());
 

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

[via lldb-commits]

@@ -124,6 +124,9 @@ class ABISysV_riscv : public lldb_private::RegInfoBasedABI {
   using lldb_private::RegInfoBasedABI::RegInfoBasedABI; // Call CreateInstance
 // instead.
   bool m_is_rv64; // true if target is riscv64; false if target is riscv32
+  static constexpr size_t s_regs_for_args_count =

dlav-sc wrote:

addressed

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)

[David Spickett via lldb-commits]

DavidSpickett wrote:

I've disabled this on Windows for now but please address the issue generally.

Testing memory region overlaps is tricky. I did it for memory tagging by hoping 
that the kernel would allocate pages in the right order, which worked for at 
least simulated systems. Pavel recently added 
`lldb/test/API/functionalities/memory/holes/main.cpp` which has Windows and 
Linux code for allocating regions.

It's tricky though, because you need to split a region here instead of making a 
gap. Maybe you can allocate a larger area, unmap part of it, then remap that 
part again.

If you don't have a Windows machine to do that on, I'm happy for the test to be 
Linux specific because:
* The functionality is pretty generic, if it works there, it'll work on Windows.
* I'm happy to add the Windows support code myself.

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

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

[Adrian Vogelsgesang via lldb-commits]

@@ -78,6 +78,15 @@
   "scope": "resource",
   "type": "string",
   "description": "The log path for lldb-dap (if any)"
+},
+   "lldb-dap.environment": {

vogelsgesang wrote:

Use whitespaces instead of tabs for indentation

```suggestion
},
"lldb-dap.environment": {
```

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)

[Adrian Vogelsgesang via lldb-commits]

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

LGTM

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)

[Adrian Vogelsgesang via lldb-commits]

https://github.com/vogelsgesang edited 
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)

[via lldb-commits]

https://github.com/serby2000 updated 
https://github.com/llvm/llvm-project/pull/108948

>From 30e1a6fdc39f637095eec89584f6b163bc53037d Mon Sep 17 00:00:00 2001
From: Serby 
Date: Tue, 17 Sep 2024 12:19:36 +0300
Subject: [PATCH 1/2] vscode-lldb - Add Environment configuration for the
 lldb-dap process

---
 lldb/tools/lldb-dap/package-lock.json   |  4 ++--
 lldb/tools/lldb-dap/package.json| 11 ++-
 lldb/tools/lldb-dap/src-ts/extension.ts | 11 +--
 3 files changed, 21 insertions(+), 5 deletions(-)

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..cbe098b6fc7e37 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,
 },
   },

>From 29bc146ff5c0f6ee00b17cb3b4df4f503e1addf5 Mon Sep 17 00:00:00 2001
From: Serban 
Date: Tue, 17 Sep 2024 16:23:41 +0300
Subject: [PATCH 2/2] Update lldb/tools/lldb-dap/package.json

Whitespaces instead of tabs for indentation in package.json

Co-authored-by: Adrian Vogelsgesang 
---
 lldb/tools/lldb-dap/package.json | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lldb/tools/lldb-dap/package.json b/lldb/tools/lldb-dap/package.json
index cbe098b6fc7e37..33b09d56ab17e2 100644
--- a/lldb/tools/lldb-dap/package.json
+++ b/lldb/tools/lldb-dap/package.json
@@ -79,7 +79,7 @@
   "type": "string",
   "description": "The log path for lldb-dap (if any)"
 },
-   "lldb-dap.environment": {
+"lldb-dap.environment": {
   "scope": "resource",
   "type": "object",
   "default": {},

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

[David Spickett via lldb-commits]

@@ -0,0 +1,96 @@
+"""
+Test RISC-V expressions evaluation.
+"""

DavidSpickett wrote:

Are these tests going to be removed then?

On the grounds that existing tests in the test suite will cover these scenarios.

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)

[David Spickett via lldb-commits]

@@ -1011,6 +1011,135 @@ void RuntimeDyldELF::resolveBPFRelocation(const 
SectionEntry &Section,
   }
 }
 
+static void applyUTypeImmRISCV(uint8_t *InstrAddr, uint32_t Imm) {

DavidSpickett wrote:

Does this still need to be done?

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)

[David Spickett via lldb-commits]

@@ -279,6 +279,9 @@ void IRExecutionUnit::GetRunnableInfo(Status &error, 
lldb::addr_t &func_addr,
   .setMCJITMemoryManager(std::make_unique(*this))
   .setOptLevel(llvm::CodeGenOptLevel::Less);
 
+  if (triple.isRISCV64())

DavidSpickett wrote:

This should have a comment. If every other arch set the code model it'd be 
fine, but this sticks out.

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)

[David Spickett via lldb-commits]

DavidSpickett wrote:

If folks could close any of their comments that have now been addressed, it 
would be much easier to determine what is left to do.

We're going for the "most thorough review" record here :) Thanks for sticking 
with it @dlav-sc .

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] Add AST node classes, functions, etc. for Data Inspection Lang… (PR #95738)

[via lldb-commits]

cmtice wrote:

> > > Is the plan to get the DIL data structures merged before the rest of the 
> > > patch series is up for review? I think it'd be great to see how the 
> > > infrastructure introduced here will be used
> > 
> > 
> > There are 3 major pieces to the DIL implementation (soon to be 4, once I've 
> > got the lexer written): The AST bit; the parser, which is a recursive 
> > descent parser using the .ebnf grammar; and the interpreter/evaluator. The 
> > parser performs parsing and type-checking on the input expression, building 
> > up the AST as it goes. Once the AST is built, it gets passed to the 
> > interpreter/evaluator, which evaluates the AST (performing more correctness 
> > checks along the way), returning an LLDB ValueObjectSP at the end. I have 
> > both 'stripped down' and 'full' versions of all of these pieces. The 
> > 'stripped down' pieces match the current 'frame variable' functionality, 
> > and the 'full' versions implement extensions to that functionality 
> > (allowing it to handle all the expressions that lldb-eval could handle).
> > The plan is to submit a series of PRs as follows: 1). the AST parts (this 
> > PR). 2). the not-yet-written lexer (with any necessary changes to the 
> > already submitted AST parts); 3). the parser; 4) the evaluator; 5); the 
> > 'glue', i.e. updates to things like StackFrame.cpp & 
> > CommandObjectFrame.cpp, to hook up the new DIL implementation (optionally), 
> > as well as the test cases. Currently, the stripped down parser is ~2700 
> > lines of code, and the stripped down evaluator is ~1000 lines of code.
> > As I mentioned in an earlier comment (on June 24), you can see the full 
> > (not stripped down) implementation at 
> > https://github.com/cmtice/llvm-project/tree/DIL-work-new/ , although I have 
> > not (yet) updated that with the updates that have gone into this PR.
> > Does that answer all of your questions? Or is there more you would like to 
> > know or see?
> 
> Thanks for the breakdown! I was just wondering whether the plan was to merge 
> this before the other PRs are up. I think it'd be preferable to merge them 
> once they all have been approved. Though if others are ok with the current 
> strategy I don't want to block this.

I was under the impression that the plan was to merge each PR as it was 
approved (I thought things might be less confusing that way). But I am 
certainly open to alternatives.  If the folks reviewing these DIL PR's would 
prefer to have all the PRs available for review at the same time, I can put 
most of the others out for review now as well.  Just let me know.



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

[Adrian Prantl via lldb-commits]

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

adrian-prantl wrote:

can you add an upper bound for the loop? I'm afraid that this recognizer might 
be triggered when looking at the backtrace of an infinite recursion, for 
example, and then LLDB just hangs.

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][FrameRecognizer] Display the first non-std frame on verbose_trap (PR #108825)

[Adrian Prantl via lldb-commits]

@@ -0,0 +1,13 @@
+# Tests that we show the first non-STL frame when
+# a verbose_trap triggers from within the STL.
+
+# UNSUPPORTED: system-windows
+#
+# RUN: %clang_host -g -O0 %S/Inputs/verbose_trap-in-stl-nested.cpp -o %t.out
+# RUN: %lldb -b -s %s %t.out | FileCheck %s --check-prefixes=CHECK

adrian-prantl wrote:

Is there a good reason why this isn't an API test?

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] add a check using an MD5 hash for whether a file needs to be installed on the remote target (PR #108996)

[via lldb-commits]

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

Lldb documentation says that during remote debugging lldb client should check 
the existence of the desired executable file on the remote target and only if 
the file is missing copy it there. There is no such check in fact, so during an 
attempt to copy the executable ETXTBSY error can occur. This patch adds the 
check using a MD5 file hash value.

Fixed tests:
TestProcessHandle.py
TestFdLeak.py

>From a647e415d2a2407f87d931ba968ffa6c4f81575e Mon Sep 17 00:00:00 2001
From: Daniil Avdeev 
Date: Tue, 23 Jul 2024 11:08:13 +
Subject: [PATCH] [lldb] add a check using an MD5 hash for whether a file needs
 to be installed on the remote target

Lldb documentation says that during remote debugging lldb client
should check the existence of desired executable file on a remote
tagret and only if the file is missing copy it there. There is no
such check in fact, so during an attempt to copy the executable
ETXTBSY error can occur. This patch adds the check using a MD5 file
hash value.

Fixed tests:
TestProcessHandle.py
TestFdLeak.py
---
 lldb/source/Target/Target.cpp | 165 +-
 1 file changed, 125 insertions(+), 40 deletions(-)

diff --git a/lldb/source/Target/Target.cpp b/lldb/source/Target/Target.cpp
index f1659aae0800db..8f1cfc7b4f0b67 100644
--- a/lldb/source/Target/Target.cpp
+++ b/lldb/source/Target/Target.cpp
@@ -76,6 +76,106 @@
 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_target{target}, m_module{module},
+m_local_file{m_module->GetFileSpec()},
+m_remote_file{
+getRemoteFileSpec(m_platform, m_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;
+  TargetSP m_target;
+  ModuleSP m_module;
+  const FileSpec m_local_file;
+  const FileSpec m_remote_file;
+  ProcessLaunchInfo *m_launch_info;
+
+private:
+  // Creates a filename "_" for a file
+  // on a remote target. This is needed to check existance of the file on a
+  // remote machine and then install it if the file is missing.
+  static std::optional
+  getRemoteFileName(const FileSpec &local_file) {
+auto local_md5 = llvm::sys::fs::md5_contents(local_file.GetPath());
+if (!local_md5)
+  return std::nullopt;
+
+auto [high, low] = local_md5->words();
+
+std::stringstream ss;
+ss << local_file.GetFilename().GetCString() << "_" << high << low;
+return ss.str();
+  }
+
+  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 {};
+
+auto remote_filename = getRemoteFileName(local_file);
+if (!remote_filename)
+  return {};
+
+remote_file = platform->GetRemoteWorkingDirectory();
+remote_file.AppendPathComponent(remote_filename.value());
+
+return remote_file;
+  }
+};
+} // namespace
+
+template 
+static Status installExecutable(const Installer &installer) {
+  // Firstly check is the file already exists on a remote machine
+  if (installer.m_platform->GetFileExists(installer.m_remote_file)) {
+installer.setRemoteFile();
+return Status();
+  }
+
+  if (!installer.m_local_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 +3176,33 @@ TargetProperties &Target::GetGlobalProperties() {
 Status Target::Install(ProcessLaunchInfo *launch_info) {
   Status error;
   PlatformSP

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

[via lldb-commits]

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: None (dlav-sc)


Changes

Lldb documentation says that during remote debugging lldb client should check 
the existence of the desired executable file on the remote target and only if 
the file is missing copy it there. There is no such check in fact, so during an 
attempt to copy the executable ETXTBSY error can occur. This patch adds the 
check using a MD5 file hash value.

Fixed tests:
TestProcessHandle.py
TestFdLeak.py

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


1 Files Affected:

- (modified) lldb/source/Target/Target.cpp (+125-40) 


``diff
diff --git a/lldb/source/Target/Target.cpp b/lldb/source/Target/Target.cpp
index f1659aae0800db..8f1cfc7b4f0b67 100644
--- a/lldb/source/Target/Target.cpp
+++ b/lldb/source/Target/Target.cpp
@@ -76,6 +76,106 @@
 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_target{target}, m_module{module},
+m_local_file{m_module->GetFileSpec()},
+m_remote_file{
+getRemoteFileSpec(m_platform, m_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;
+  TargetSP m_target;
+  ModuleSP m_module;
+  const FileSpec m_local_file;
+  const FileSpec m_remote_file;
+  ProcessLaunchInfo *m_launch_info;
+
+private:
+  // Creates a filename "_" for a file
+  // on a remote target. This is needed to check existance of the file on a
+  // remote machine and then install it if the file is missing.
+  static std::optional
+  getRemoteFileName(const FileSpec &local_file) {
+auto local_md5 = llvm::sys::fs::md5_contents(local_file.GetPath());
+if (!local_md5)
+  return std::nullopt;
+
+auto [high, low] = local_md5->words();
+
+std::stringstream ss;
+ss << local_file.GetFilename().GetCString() << "_" << high << low;
+return ss.str();
+  }
+
+  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 {};
+
+auto remote_filename = getRemoteFileName(local_file);
+if (!remote_filename)
+  return {};
+
+remote_file = platform->GetRemoteWorkingDirectory();
+remote_file.AppendPathComponent(remote_filename.value());
+
+return remote_file;
+  }
+};
+} // namespace
+
+template 
+static Status installExecutable(const Installer &installer) {
+  // Firstly check is the file already exists on a remote machine
+  if (installer.m_platform->GetFileExists(installer.m_remote_file)) {
+installer.setRemoteFile();
+return Status();
+  }
+
+  if (!installer.m_local_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 +3176,33 @@ 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.GetModuleAt

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

[Walter Erquinigo via lldb-commits]

@@ -4087,32 +4114,64 @@ void request_variables(const llvm::json::Object 
&request) {
 void request_locations(const llvm::json::Object &request) {
   llvm::json::Object response;
   FillResponse(request, response);
-  auto arguments = request.getObject("arguments");
+  auto *arguments = request.getObject("arguments");

walter-erquinigo wrote:

please remove the auto here. An explicit type would make this more readable

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)

[Walter Erquinigo 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");

walter-erquinigo wrote:

Instead of unconditionally creating the var_ref, why don't you create a small 
lambda that creates it just when needed (lines 1630 and 1637)?

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)

[Walter Erquinigo via lldb-commits]

@@ -1390,7 +1414,10 @@ llvm::json::Value CreateVariable(lldb::SBValue v, 
int64_t var_ref,
 object.try_emplace("variablesReference", 0);
 
   if (v.GetDeclaration().IsValid())
-object.try_emplace("declarationLocationReference", var_ref);
+object.try_emplace("declarationLocationReference", var_ref << 1);
+
+  if (HasValueLocation(v))
+object.try_emplace("valueLocationReference", (var_ref << 1) | 1);

walter-erquinigo wrote:

Please create helper functions that do these bitwise manipulations. That would 
make it more obvious what's going on. E.g. varRefToDeclLocationRef and 
varRefToValueLocationRef

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][FrameRecognizer] Display the first non-std frame on verbose_trap (PR #108825)

[Michael Buch via lldb-commits]

@@ -0,0 +1,13 @@
+# Tests that we show the first non-STL frame when
+# a verbose_trap triggers from within the STL.
+
+# UNSUPPORTED: system-windows
+#
+# RUN: %clang_host -g -O0 %S/Inputs/verbose_trap-in-stl-nested.cpp -o %t.out
+# RUN: %lldb -b -s %s %t.out | FileCheck %s --check-prefixes=CHECK

Michael137 wrote:

I find it much easier to understand what the test is trying to check when it's 
done as a `Shell` test. Especially for when we just want to inspect the format 
of the frame. (FWIW, all the other frame format tests are also `Shell` tests).

>From the [Testing FAQ](https://lldb.llvm.org/resources/test.html):
> API tests: Integration tests that interact with the debugger through the SB 
> API. These are written in Python and use LLDB’s dotest.py testing framework 
> on top of Python’s 
> [unittest](https://docs.python.org/3/library/unittest.html).

And later:
> A good rule of thumb is to prefer shell tests when what is being tested is 
> relatively simple. Expressivity is limited compared to the API tests, which 
> means that you have to have a well-defined test scenario that you can easily 
> match with FileCheck.

IMO these tests fit into the latter category.

But I'm happy to change these to API tests if that is more appropriate.

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] add a check using an MD5 hash for whether a file needs to be installed on the remote target (PR #108996)

[David Spickett via lldb-commits]

DavidSpickett wrote:

Will look at this properly tomorrow but just looking at the title, I'm 
surprised that https://github.com/llvm/llvm-project/pull/88812 did not also fix 
this. Perhaps putfile and install are different paths.

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] Do not use LC_FUNCTION_STARTS data to determine symbol size as symbols are created (PR #106791)

[via lldb-commits]

royitaqi wrote:

Do we have a sense of whether it's just a broken test, or if the PR broke some 
functionality?   We tested the change on some internal scenarios and it showed 
good improvement, so we'd like to cherry-pick this patch (or a new patch).

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

[Tom Yang via lldb-commits]

https://github.com/zhyty created 
https://github.com/llvm/llvm-project/pull/109020

Somewhat recently, we made the change to hide the behavior to save LLDB session 
history to the transcript buffer behind the flag `interpreter.save-transcript`. 
By default, `interpreter.save-transcript` is false. See #90703 for context.

I'm making a small update here to our `session save` messaging and some help 
docs to clarify for users that aren't aware of this change. Maybe 
`interpreter.save-transcript` could be true by default as well. Any feedback 
welcome.

# Tests
```
bin/lldb-dotest -p TestSessionSave
```

>From 60045b710e1102d6f220dfd4367f997b73bb64df Mon Sep 17 00:00:00 2001
From: Tom Yang 
Date: Tue, 17 Sep 2024 09:56:09 -0700
Subject: [PATCH] Add warning message to `session save` when transcript isn't
 saved.

Somewhat recently, we made the change to hide the behavior to save LLDB
session history to the transcript buffer behind the flag
`interpreter.save-transcript`.
---
 lldb/source/Commands/CommandObjectSession.cpp |  3 +-
 .../source/Interpreter/CommandInterpreter.cpp |  2 ++
 .../Interpreter/InterpreterProperties.td  |  2 +-
 .../commands/session/save/TestSessionSave.py  | 29 +++
 4 files changed, 34 insertions(+), 2 deletions(-)

diff --git a/lldb/source/Commands/CommandObjectSession.cpp 
b/lldb/source/Commands/CommandObjectSession.cpp
index c381ba4f74f120..3f714cec414695 100644
--- a/lldb/source/Commands/CommandObjectSession.cpp
+++ b/lldb/source/Commands/CommandObjectSession.cpp
@@ -19,7 +19,8 @@ class CommandObjectSessionSave : public CommandObjectParsed {
   : CommandObjectParsed(interpreter, "session save",
 "Save the current session transcripts to a file.\n"
 "If no file if specified, transcripts will be "
-"saved to a temporary file.",
+"saved to a temporary file.\n"
+"Note: transcripts will only be saved if 
interpreter.save-transcript is true.\n",
 "session save [file]") {
 AddSimpleArgumentList(eArgTypePath, eArgRepeatOptional);
   }
diff --git a/lldb/source/Interpreter/CommandInterpreter.cpp 
b/lldb/source/Interpreter/CommandInterpreter.cpp
index b93f47a8a8d5ec..05426771ba0335 100644
--- a/lldb/source/Interpreter/CommandInterpreter.cpp
+++ b/lldb/source/Interpreter/CommandInterpreter.cpp
@@ -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.");
 
   if (GetOpenTranscriptInEditor() && Host::IsInteractiveGraphicSession()) {
 const FileSpec file_spec;
diff --git a/lldb/source/Interpreter/InterpreterProperties.td 
b/lldb/source/Interpreter/InterpreterProperties.td
index a5fccbbca091cf..834f7be17480c6 100644
--- a/lldb/source/Interpreter/InterpreterProperties.td
+++ b/lldb/source/Interpreter/InterpreterProperties.td
@@ -16,7 +16,7 @@ let Definition = "interpreter" in {
   def SaveSessionOnQuit: Property<"save-session-on-quit", "Boolean">,
 Global,
 DefaultFalse,
-Desc<"If true, LLDB will save the session's transcripts before quitting.">;
+Desc<"If true, LLDB will save the session's transcripts before quitting. 
Note: transcripts will only be saved if interpreter.save-transcript is true.">;
   def OpenTranscriptInEditor: Property<"open-transcript-in-editor", "Boolean">,
 Global,
 DefaultTrue,
diff --git a/lldb/test/API/commands/session/save/TestSessionSave.py 
b/lldb/test/API/commands/session/save/TestSessionSave.py
index aa99bcd56aed46..c81ff645d9d3b8 100644
--- a/lldb/test/API/commands/session/save/TestSessionSave.py
+++ b/lldb/test/API/commands/session/save/TestSessionSave.py
@@ -85,6 +85,8 @@ def test_session_save(self):
 interpreter.HandleCommand("session save", res)
 self.assertTrue(res.Succeeded())
 raw += self.raw_transcript_builder(cmd, res)
+# Also check that we don't print an error message about an empty 
transcript.
+self.assertNotIn("interpreter.save-transcript is set to false", 
res.GetError())
 
 with open(os.path.join(td.name, os.listdir(td.name)[0]), "r") as file:
 content = file.read()
@@ -93,6 +95,33 @@ def test_session_save(self):
 for line in lines:
 self.assertIn(line, content)
 
+@no_debug_info_test
+def test_session_save_no_transcript_warning(self):
+interpreter = self.dbg.GetCommandInterpreter()
+
+self.runCmd("settings set interpreter.save-transcript false")
+
+# These commands won't be saved, so are arbitrary.
+commands = [
+"p 1",
+"settings set i

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

[via lldb-commits]

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Tom Yang (zhyty)


Changes

Somewhat recently, we made the change to hide the behavior to save LLDB session 
history to the transcript buffer behind the flag `interpreter.save-transcript`. 
By default, `interpreter.save-transcript` is false. See #90703 for 
context.

I'm making a small update here to our `session save` messaging and some help 
docs to clarify for users that aren't aware of this change. Maybe 
`interpreter.save-transcript` could be true by default as well. Any feedback 
welcome.

# Tests
```
bin/lldb-dotest -p TestSessionSave
```

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


4 Files Affected:

- (modified) lldb/source/Commands/CommandObjectSession.cpp (+2-1) 
- (modified) lldb/source/Interpreter/CommandInterpreter.cpp (+2) 
- (modified) lldb/source/Interpreter/InterpreterProperties.td (+1-1) 
- (modified) lldb/test/API/commands/session/save/TestSessionSave.py (+29) 


``diff
diff --git a/lldb/source/Commands/CommandObjectSession.cpp 
b/lldb/source/Commands/CommandObjectSession.cpp
index c381ba4f74f120..3f714cec414695 100644
--- a/lldb/source/Commands/CommandObjectSession.cpp
+++ b/lldb/source/Commands/CommandObjectSession.cpp
@@ -19,7 +19,8 @@ class CommandObjectSessionSave : public CommandObjectParsed {
   : CommandObjectParsed(interpreter, "session save",
 "Save the current session transcripts to a file.\n"
 "If no file if specified, transcripts will be "
-"saved to a temporary file.",
+"saved to a temporary file.\n"
+"Note: transcripts will only be saved if 
interpreter.save-transcript is true.\n",
 "session save [file]") {
 AddSimpleArgumentList(eArgTypePath, eArgRepeatOptional);
   }
diff --git a/lldb/source/Interpreter/CommandInterpreter.cpp 
b/lldb/source/Interpreter/CommandInterpreter.cpp
index b93f47a8a8d5ec..05426771ba0335 100644
--- a/lldb/source/Interpreter/CommandInterpreter.cpp
+++ b/lldb/source/Interpreter/CommandInterpreter.cpp
@@ -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.");
 
   if (GetOpenTranscriptInEditor() && Host::IsInteractiveGraphicSession()) {
 const FileSpec file_spec;
diff --git a/lldb/source/Interpreter/InterpreterProperties.td 
b/lldb/source/Interpreter/InterpreterProperties.td
index a5fccbbca091cf..834f7be17480c6 100644
--- a/lldb/source/Interpreter/InterpreterProperties.td
+++ b/lldb/source/Interpreter/InterpreterProperties.td
@@ -16,7 +16,7 @@ let Definition = "interpreter" in {
   def SaveSessionOnQuit: Property<"save-session-on-quit", "Boolean">,
 Global,
 DefaultFalse,
-Desc<"If true, LLDB will save the session's transcripts before quitting.">;
+Desc<"If true, LLDB will save the session's transcripts before quitting. 
Note: transcripts will only be saved if interpreter.save-transcript is true.">;
   def OpenTranscriptInEditor: Property<"open-transcript-in-editor", "Boolean">,
 Global,
 DefaultTrue,
diff --git a/lldb/test/API/commands/session/save/TestSessionSave.py 
b/lldb/test/API/commands/session/save/TestSessionSave.py
index aa99bcd56aed46..c81ff645d9d3b8 100644
--- a/lldb/test/API/commands/session/save/TestSessionSave.py
+++ b/lldb/test/API/commands/session/save/TestSessionSave.py
@@ -85,6 +85,8 @@ def test_session_save(self):
 interpreter.HandleCommand("session save", res)
 self.assertTrue(res.Succeeded())
 raw += self.raw_transcript_builder(cmd, res)
+# Also check that we don't print an error message about an empty 
transcript.
+self.assertNotIn("interpreter.save-transcript is set to false", 
res.GetError())
 
 with open(os.path.join(td.name, os.listdir(td.name)[0]), "r") as file:
 content = file.read()
@@ -93,6 +95,33 @@ def test_session_save(self):
 for line in lines:
 self.assertIn(line, content)
 
+@no_debug_info_test
+def test_session_save_no_transcript_warning(self):
+interpreter = self.dbg.GetCommandInterpreter()
+
+self.runCmd("settings set interpreter.save-transcript false")
+
+# These commands won't be saved, so are arbitrary.
+commands = [
+"p 1",
+"settings set interpreter.save-session-on-quit true",
+"fr v",
+"settings set interpreter.echo-comment-commands true",
+]
+
+for command in commands:
+res = lldb.SBCommandReturnObject()
+interpreter.HandleCommand(command, res)
+
+  

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

[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 
2d13302d3851747a023ffecc6388585e888cd0e9...60045b710e1102d6f220dfd4367f997b73bb64df
 lldb/test/API/commands/session/save/TestSessionSave.py
``





View the diff from darker here.


``diff
--- TestSessionSave.py  2024-09-17 16:56:09.00 +
+++ TestSessionSave.py  2024-09-17 17:34:46.082913 +
@@ -111,18 +111,21 @@
 
 for command in commands:
 res = lldb.SBCommandReturnObject()
 interpreter.HandleCommand(command, res)
 
-output_file = self.getBuildArtifact('my-session')
+output_file = self.getBuildArtifact("my-session")
 
 res = lldb.SBCommandReturnObject()
 interpreter.HandleCommand("session save " + output_file, res)
 self.assertTrue(res.Succeeded())
 # We should warn about the setting being false.
 self.assertIn("interpreter.save-transcript is set to false", 
res.GetError())
-self.assertTrue(os.path.getsize(output_file) == 0, "Output file should 
be empty since we didn't save the transcript.")
+self.assertTrue(
+os.path.getsize(output_file) == 0,
+"Output file should be empty since we didn't save the transcript.",
+)
 
 @no_debug_info_test
 def test_session_save_on_quit(self):
 raw = ""
 interpreter = self.dbg.GetCommandInterpreter()

``




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)

[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 2d13302d3851747a023ffecc6388585e888cd0e9 
60045b710e1102d6f220dfd4367f997b73bb64df --extensions cpp -- 
lldb/source/Commands/CommandObjectSession.cpp 
lldb/source/Interpreter/CommandInterpreter.cpp
``





View the diff from clang-format here.


``diff
diff --git a/lldb/source/Commands/CommandObjectSession.cpp 
b/lldb/source/Commands/CommandObjectSession.cpp
index 3f714cec41..ac7eec5e04 100644
--- a/lldb/source/Commands/CommandObjectSession.cpp
+++ b/lldb/source/Commands/CommandObjectSession.cpp
@@ -20,7 +20,8 @@ public:
 "Save the current session transcripts to a file.\n"
 "If no file if specified, transcripts will be "
 "saved to a temporary file.\n"
-"Note: transcripts will only be saved if 
interpreter.save-transcript is true.\n",
+"Note: transcripts will only be saved if "
+"interpreter.save-transcript is true.\n",
 "session save [file]") {
 AddSimpleArgumentList(eArgTypePath, eArgRepeatOptional);
   }
diff --git a/lldb/source/Interpreter/CommandInterpreter.cpp 
b/lldb/source/Interpreter/CommandInterpreter.cpp
index 05426771ba..f6537a0135 100644
--- a/lldb/source/Interpreter/CommandInterpreter.cpp
+++ b/lldb/source/Interpreter/CommandInterpreter.cpp
@@ -3307,7 +3307,9 @@ bool CommandInterpreter::SaveTranscript(
   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.");
+result.AppendError(
+"Note: the setting interpreter.save-transcript is set to false, so the 
"
+"transcript might not have been recorded.");
 
   if (GetOpenTranscriptInEditor() && Host::IsInteractiveGraphicSession()) {
 const FileSpec file_spec;

``




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] [lldb-dap] Add feature to remember last non-empty expression. (PR #107485)

[via lldb-commits]

https://github.com/cmtice updated 
https://github.com/llvm/llvm-project/pull/107485

>From 15541f354decf80586d590db9f9cb353be04b122 Mon Sep 17 00:00:00 2001
From: Caroline Tice 
Date: Thu, 5 Sep 2024 15:51:35 -0700
Subject: [PATCH 1/8] [lldb-dap] Add feature to remember last non-empty
 expression.

Update lldb-dap so if the user just presses return, which sends an
empty expression, it re-evaluates the most recent non-empty
expression/command. Also udpated test to test this case.
---
 lldb/test/API/tools/lldb-dap/evaluate/TestDAP_evaluate.py | 3 +++
 lldb/tools/lldb-dap/lldb-dap.cpp  | 8 
 2 files changed, 11 insertions(+)

diff --git a/lldb/test/API/tools/lldb-dap/evaluate/TestDAP_evaluate.py 
b/lldb/test/API/tools/lldb-dap/evaluate/TestDAP_evaluate.py
index 29548a835c6919..9ed0fc564268a7 100644
--- a/lldb/test/API/tools/lldb-dap/evaluate/TestDAP_evaluate.py
+++ b/lldb/test/API/tools/lldb-dap/evaluate/TestDAP_evaluate.py
@@ -60,7 +60,10 @@ def run_test_evaluate_expressions(
 
 # Expressions at breakpoint 1, which is in main
 self.assertEvaluate("var1", "20")
+# Empty expression should equate to the previous expression.
+self.assertEvaluate("", "20")
 self.assertEvaluate("var2", "21")
+self.assertEvaluate("", "21")
 self.assertEvaluate("static_int", "42")
 self.assertEvaluate("non_static_int", "43")
 self.assertEvaluate("struct1.foo", "15")
diff --git a/lldb/tools/lldb-dap/lldb-dap.cpp b/lldb/tools/lldb-dap/lldb-dap.cpp
index c5c4b09f15622b..a6a701dc2219fa 100644
--- a/lldb/tools/lldb-dap/lldb-dap.cpp
+++ b/lldb/tools/lldb-dap/lldb-dap.cpp
@@ -1363,6 +1363,14 @@ void request_evaluate(const llvm::json::Object &request) 
{
   lldb::SBFrame frame = g_dap.GetLLDBFrame(*arguments);
   std::string expression = GetString(arguments, "expression").str();
   llvm::StringRef context = GetString(arguments, "context");
+  static std::string last_nonempty_expression;
+
+  // Remember the last non-empty expression from the user, and use that if
+  // the current expression is empty (i.e. the user hit plain 'return').
+  if (!expression.empty())
+last_nonempty_expression = expression;
+  else
+expression = last_nonempty_expression;
 
   if (context == "repl" && g_dap.DetectExpressionContext(frame, expression) ==
ExpressionContext::Command) {

>From e35928e08f792163dd4886e797bc6de3d16ea6e6 Mon Sep 17 00:00:00 2001
From: Caroline Tice 
Date: Fri, 6 Sep 2024 10:02:18 -0700
Subject: [PATCH 2/8] [lldb] Add feature to remember last non-empty expression

Make last_nonempty_spression part of DAP struct rather than a
static variable.
---
 lldb/tools/lldb-dap/DAP.h| 1 +
 lldb/tools/lldb-dap/lldb-dap.cpp | 5 ++---
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/lldb/tools/lldb-dap/DAP.h b/lldb/tools/lldb-dap/DAP.h
index f4fdec6e895ad1..4220c15d3ae70d 100644
--- a/lldb/tools/lldb-dap/DAP.h
+++ b/lldb/tools/lldb-dap/DAP.h
@@ -205,6 +205,7 @@ struct DAP {
   std::string command_escape_prefix = "`";
   lldb::SBFormat frame_format;
   lldb::SBFormat thread_format;
+  std::string last_nonempty_expression;
 
   DAP();
   ~DAP();
diff --git a/lldb/tools/lldb-dap/lldb-dap.cpp b/lldb/tools/lldb-dap/lldb-dap.cpp
index a6a701dc2219fa..d3728df9183aa1 100644
--- a/lldb/tools/lldb-dap/lldb-dap.cpp
+++ b/lldb/tools/lldb-dap/lldb-dap.cpp
@@ -1363,14 +1363,13 @@ void request_evaluate(const llvm::json::Object 
&request) {
   lldb::SBFrame frame = g_dap.GetLLDBFrame(*arguments);
   std::string expression = GetString(arguments, "expression").str();
   llvm::StringRef context = GetString(arguments, "context");
-  static std::string last_nonempty_expression;
 
   // Remember the last non-empty expression from the user, and use that if
   // the current expression is empty (i.e. the user hit plain 'return').
   if (!expression.empty())
-last_nonempty_expression = expression;
+g_dap.last_nonempty_expression = expression;
   else
-expression = last_nonempty_expression;
+expression = g_dap.last_nonempty_expression;
 
   if (context == "repl" && g_dap.DetectExpressionContext(frame, expression) ==
ExpressionContext::Command) {

>From 616017152f3f0611462e9863273754036b52f7eb Mon Sep 17 00:00:00 2001
From: Caroline Tice 
Date: Thu, 12 Sep 2024 10:52:32 -0700
Subject: [PATCH 3/8] [lldb-dap] Add feature to remember last non-empty
 expression

Update to handle commands & variables separately: empty command
expressions are passed to the CommandIntepreter to handle as it
normally does; empty variable expressions are updated to use the last
non-empty variable expression, if the last expression was a variable (not
a command).  Also updated the test case to test these cases properly, and
added a 'memory read' followed by an empty expression, to make sure it
handles that sequence correctly.
---
 .../lldb-dap/evaluate/TestDAP_evaluate.py | 16 +++--
 ...

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

[Walter Erquinigo via lldb-commits]

https://github.com/walter-erquinigo approved this pull request.


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] Do not use LC_FUNCTION_STARTS data to determine symbol size as symbols are created (PR #106791)

[Alex Langford via lldb-commits]

bulbazord wrote:

> Do we have a sense of whether it's just a broken test, or if the PR broke 
> some functionality? We tested the change on some internal scenarios and it 
> showed good improvement, so we'd like to cherry-pick this patch (or a new 
> patch).

I'm not sure yet, I haven't had time to investigate what broke exactly. The 
test suite passes on arm64 on all the machines I tried it on, so it may be 
specific to x86_64. I'll try to find some time to investigate this week or the 
next.

https://github.com/llvm/llvm-project/pull/106791
___
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] Added readMemory and WriteMemory, var type correction (PR #108036)

[Jennifer Phillips via lldb-commits]

jennphilqc wrote:

> Given this, I think we should take the best parts of both PRs 🙂 What do you 
> think about the following path forward?
> 
> * rebase this PR on top of [[lldb-dap] Support inspecting memory 
> #104317](https://github.com/llvm/llvm-project/pull/104317)
> * scope this PR down to `writeMemory`
> * modify this PR to also extend the test cases in `TestDAP_memory.py` (added 
> by my PR) to introduce test coverage also for `writeMemory`

It sounds like a great idea to work together on this, @vogelsgesang ! Let me 
set up the rebase and work on all the suggested edits above.

> 
> Also, I noticed that you did not introduce any `memoryReference`s as part of 
> your pull request. With your PR, how can a user even open the hex-viewer in 
> VS-Code? Is there some way which I am not aware of to open the hex-viewer 
> without a `memoryReference`? Asking, because I was considering introducing a 
> "View memory address" via TypeScript, similar to [what VSCodeLLDB 
> does](https://github.com/vadimcn/codelldb/blob/05502bf75e4e7878a99b0bf0a7a81bba2922cbe3/extension/main.ts#L476)
>  - but if there already is some other way to pop up the memory-viewer, doing 
> so would be unnecessary

I actually wrote this for a team that already has their own viewer. We've 
suggested that they upstream that as well.

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

[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 22bf01e8e5f4830bbb44937910a9121f66d5f45c 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|  83 +-
 .../Python/PythonDataObjects.cpp  |  31 ++-
 lldb/source/Utility/Status.cpp| 245 --
 .../Host/SocketTestUtilities.cpp  |  16 +-
 lldb/unittests/Utility/StatusTest.cpp |   8 +
 5 files changed, 276 insertions(+), 107 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 

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

[via lldb-commits]

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

>From 2fc70cf82a7e67bde2d4fb35d2457d2812b34273 Mon Sep 17 00:00:00 2001
From: Daniil Avdeev 
Date: Thu, 11 Jul 2024 11:21:36 +
Subject: [PATCH 1/4] [lldb][RISCV] add jitted function calls to ABI

Function calls support in LLDB expressions for RISCV: 1 of 5

Augments corresponding functionality to RISCV ABI, which allows to jit
lldb expressions and thus make function calls inside them. Only function
calls with integer and void function arguments and return value are
supported.
---
 .../Plugins/ABI/RISCV/ABISysV_riscv.cpp   | 91 +--
 1 file changed, 84 insertions(+), 7 deletions(-)

diff --git a/lldb/source/Plugins/ABI/RISCV/ABISysV_riscv.cpp 
b/lldb/source/Plugins/ABI/RISCV/ABISysV_riscv.cpp
index de304183f67175..38d452b6ab560c 100644
--- a/lldb/source/Plugins/ABI/RISCV/ABISysV_riscv.cpp
+++ b/lldb/source/Plugins/ABI/RISCV/ABISysV_riscv.cpp
@@ -10,7 +10,9 @@
 
 #include 
 #include 
+#include 
 
+#include "llvm/ADT/STLExtras.h"
 #include "llvm/IR/DerivedTypes.h"
 
 #include "Utility/RISCV_DWARF_Registers.h"
@@ -20,6 +22,7 @@
 #include "lldb/Target/RegisterContext.h"
 #include "lldb/Target/StackFrame.h"
 #include "lldb/Target/Thread.h"
+#include "lldb/Utility/LLDBLog.h"
 #include "lldb/Utility/RegisterValue.h"
 
 #define DEFINE_REG_NAME(reg_num) ConstString(#reg_num).GetCString()
@@ -120,6 +123,10 @@ static const std::array g_register_infos 
= {
 } // namespace dwarf
 } // namespace
 
+// Number of argument registers (the base integer calling convention
+// provides 8 argument registers, a0-a7)
+static constexpr size_t g_regs_for_args_count = 8U;
+
 const RegisterInfo *ABISysV_riscv::GetRegisterInfoArray(uint32_t &count) {
   count = dwarf::g_register_infos.size();
   return dwarf::g_register_infos.data();
@@ -164,11 +171,81 @@ TotalArgsSizeInWords(bool is_rv64,
   return total_size;
 }
 
+static bool UpdateRegister(RegisterContext *reg_ctx,
+   const lldb::RegisterKind reg_kind,
+   const uint32_t reg_num, const addr_t value) {
+  Log *log = GetLog(LLDBLog::Expressions);
+
+  const RegisterInfo *reg_info = reg_ctx->GetRegisterInfo(reg_kind, reg_num);
+
+  LLDB_LOG(log, "Writing {0}: 0x{1:x}", reg_info->name,
+   static_cast(value));
+  if (!reg_ctx->WriteRegisterFromUnsigned(reg_info, value)) {
+LLDB_LOG(log, "Writing {0}: failed", reg_info->name);
+return false;
+  }
+  return true;
+}
+
+static void LogInitInfo(Log &log, const Thread &thread, addr_t sp,
+addr_t func_addr, addr_t return_addr,
+const llvm::ArrayRef args) {
+  std::stringstream ss;
+  ss << "ABISysV_riscv::PrepareTrivialCall"
+ << " (tid = 0x" << std::hex << thread.GetID() << ", sp = 0x" << sp
+ << ", func_addr = 0x" << func_addr << ", return_addr = 0x" << return_addr;
+
+  for (auto [idx, arg] : enumerate(args))
+ss << ", arg" << std::dec << idx << " = 0x" << std::hex << arg;
+  ss << ")";
+  log.PutString(ss.str());
+}
+
 bool ABISysV_riscv::PrepareTrivialCall(Thread &thread, addr_t sp,
addr_t func_addr, addr_t return_addr,
llvm::ArrayRef args) const {
-  // TODO: Implement
-  return false;
+  Log *log = GetLog(LLDBLog::Expressions);
+  if (log)
+LogInitInfo(*log, thread, sp, func_addr, return_addr, args);
+
+  const auto reg_ctx_sp = thread.GetRegisterContext();
+  if (!reg_ctx_sp) {
+LLDB_LOG(log, "Failed to get RegisterContext");
+return false;
+  }
+
+  if (args.size() > g_regs_for_args_count) {
+LLDB_LOG(log, "Function has {0} arguments, but only {1} are allowed!",
+ args.size(), g_regs_for_args_count);
+return false;
+  }
+
+  // Write arguments to registers
+  for (auto [idx, arg] : enumerate(args)) {
+const RegisterInfo *reg_info = reg_ctx_sp->GetRegisterInfo(
+eRegisterKindGeneric, LLDB_REGNUM_GENERIC_ARG1 + idx);
+LLDB_LOG(log, "About to write arg{0} (0x{1:x}) into {2}", idx, arg,
+ reg_info->name);
+
+if (!reg_ctx_sp->WriteRegisterFromUnsigned(reg_info, arg)) {
+  LLDB_LOG(log, "Failed to write arg{0} (0x{1:x}) into {2}", idx, arg,
+   reg_info->name);
+  return false;
+}
+  }
+
+  if (!UpdateRegister(reg_ctx_sp.get(), eRegisterKindGeneric,
+  LLDB_REGNUM_GENERIC_PC, func_addr))
+return false;
+  if (!UpdateRegister(reg_ctx_sp.get(), eRegisterKindGeneric,
+  LLDB_REGNUM_GENERIC_SP, sp))
+return false;
+  if (!UpdateRegister(reg_ctx_sp.get(), eRegisterKindGeneric,
+  LLDB_REGNUM_GENERIC_RA, return_addr))
+return false;
+
+  LLDB_LOG(log, "ABISysV_riscv::{0}() success", __FUNCTION__);
+  return true;
 }
 
 bool ABISysV_riscv::PrepareTrivialCall(
@@ -222,14 +299,14 @@ bool ABISysV_riscv::PrepareTrivialCall(
   assert(prototype.getFunctionNumParams() == args.size());
 

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

[via lldb-commits]

@@ -0,0 +1,96 @@
+"""
+Test RISC-V expressions evaluation.
+"""

dlav-sc wrote:

yep, addressed

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)

[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 ce1b84f2679f253504db8c62f6d7c716b745f9e8 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|  83 +-
 .../Python/PythonDataObjects.cpp  |  31 ++-
 lldb/source/Utility/Status.cpp| 245 --
 .../Host/SocketTestUtilities.cpp  |  16 +-
 lldb/unittests/Utility/StatusTest.cpp |   8 +
 5 files changed, 276 insertions(+), 107 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 

[Lldb-commits] [lldb] [llvm] [lldb]Implement LLDB Telemetry (PR #98528)

[Vy Nguyen via lldb-commits]

@@ -682,17 +683,51 @@ PacketStatus DAP::GetNextObject(llvm::json::Object 
&object) {
 }
 
 bool DAP::HandleObject(const llvm::json::Object &object) {
+  auto start_time = std::chrono::steady_clock::now();
   const auto packet_type = GetString(object, "type");
   if (packet_type == "request") {
 const auto command = GetString(object, "command");
 auto handler_pos = request_handlers.find(std::string(command));
+lldb::SBStructuredData telemetry_entry;
+
+// There does not seem to be a direct way to construct an SBStructuredData.
+// So we first create a json::Array object,
+// then we serialize it to a string,
+// and finally call SBStructuredData::SetFromJSON(string).
+//
+// TODO: This seems unnecessarily complex. Ideally, we should be able to

oontvoo wrote:

@labath Hi Pavel, do you have any suggestion for avoiding this round-about?

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

[Louis Dionne via lldb-commits]

ldionne wrote:


> Do you have an idea how we could de-risk this change? E.g., would do you have 
> a couple more scenarios in mind for which I should add test cases? Are there 
> similar patterns to the `operator()` which I should also cover in test cases?

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.

> Do we have some libc++ developers which are using lldb top-of-tree for their 
> day-to-day work on libc++ and who would make us aware in case this commit 
> turns out to be too aggressive?

I'm not aware of anyone. I just use `lldb` provided by the platform usually.


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][lldb-dap] Added readMemory and WriteMemory, var type correction (PR #108036)

[Adrian Vogelsgesang via lldb-commits]

vogelsgesang wrote:

> I actually wrote this for a team that already has their own viewer. We've 
> suggested that they upstream that as well.

Is that viewer in VS-Code or in some other editor? (Trying to avoid duplicating 
effort, so I don't accidentally implement the same thing)

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

[Adrian Vogelsgesang via lldb-commits]

vogelsgesang wrote:

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

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)

[via lldb-commits]

https://github.com/serby2000 updated 
https://github.com/llvm/llvm-project/pull/108948

>From 30e1a6fdc39f637095eec89584f6b163bc53037d Mon Sep 17 00:00:00 2001
From: Serby 
Date: Tue, 17 Sep 2024 12:19:36 +0300
Subject: [PATCH 1/2] vscode-lldb - Add Environment configuration for the
 lldb-dap process

---
 lldb/tools/lldb-dap/package-lock.json   |  4 ++--
 lldb/tools/lldb-dap/package.json| 11 ++-
 lldb/tools/lldb-dap/src-ts/extension.ts | 11 +--
 3 files changed, 21 insertions(+), 5 deletions(-)

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..cbe098b6fc7e37 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,
 },
   },

>From 29bc146ff5c0f6ee00b17cb3b4df4f503e1addf5 Mon Sep 17 00:00:00 2001
From: Serban 
Date: Tue, 17 Sep 2024 16:23:41 +0300
Subject: [PATCH 2/2] Update lldb/tools/lldb-dap/package.json

Whitespaces instead of tabs for indentation in package.json

Co-authored-by: Adrian Vogelsgesang 
---
 lldb/tools/lldb-dap/package.json | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lldb/tools/lldb-dap/package.json b/lldb/tools/lldb-dap/package.json
index cbe098b6fc7e37..33b09d56ab17e2 100644
--- a/lldb/tools/lldb-dap/package.json
+++ b/lldb/tools/lldb-dap/package.json
@@ -79,7 +79,7 @@
   "type": "string",
   "description": "The log path for lldb-dap (if any)"
 },
-   "lldb-dap.environment": {
+"lldb-dap.environment": {
   "scope": "resource",
   "type": "object",
   "default": {},

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

[via lldb-commits]

https://github.com/jeffreytan81 edited 
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] [lldb] [lldb] gdb rsp file error pass fix (PR #106950)

[Jason Molenda via lldb-commits]

@@ -3064,22 +3064,41 @@ static int gdb_errno_to_system(int err) {
 
 static uint64_t ParseHostIOPacketResponse(StringExtractorGDBRemote &response,
   uint64_t fail_result, Status &error) 
{
+  // The packet is expected to have the following format:
+  // 'F,'
+
   response.SetFilePos(0);
   if (response.GetChar() != 'F')
 return fail_result;
+
   int32_t result = response.GetS32(-2, 16);
   if (result == -2)
 return fail_result;
-  if (response.GetChar() == ',') {
-int result_errno = gdb_errno_to_system(response.GetS32(-1, 16));
-if (result_errno != -1)
-  error = Status(result_errno, eErrorTypePOSIX);
-else
-  error = Status(-1, eErrorTypeGeneric);
-  } else
+
+  if (response.GetChar() != ',') {
 error.Clear();
+return result;
+  }
+
+  // Response packet should contain a error code at the end. This code
+  // corresponds either to the gdb IOFile error code, or to the posix errno.

jasonmolenda wrote:

Sorry for the delay in replying.  I didn't realize that gdb has implemented 
this differently than lldb did - I thought https://reviews.llvm.org/D34945 was 
pulling over a gdb-originated feature. It looks like gdb needs to send 
`error-message` in the qSupported list at the start of the debug session to get 
those error strings (v. 
https://sourceware.org/gdb/current/onlinedocs/gdb.html/General-Query-Packets.html#error_002dmessage
 ) although looking a little more closely, I think this feature was only added 
to the gdb remote serial protocol in May of this year?  lldb's 
QEnableErrorStrings was added in 2017.  v. 
https://sourceware.org/pipermail/gdb-patches/2024-May/209040.html

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

[Lldb-commits] [lldb] [lldb] gdb rsp file error pass fix (PR #106950)

[Jason Molenda via lldb-commits]

@@ -3064,22 +3064,41 @@ static int gdb_errno_to_system(int err) {
 
 static uint64_t ParseHostIOPacketResponse(StringExtractorGDBRemote &response,
   uint64_t fail_result, Status &error) 
{
+  // The packet is expected to have the following format:
+  // 'F,'
+
   response.SetFilePos(0);
   if (response.GetChar() != 'F')
 return fail_result;
+
   int32_t result = response.GetS32(-2, 16);
   if (result == -2)
 return fail_result;
-  if (response.GetChar() == ',') {
-int result_errno = gdb_errno_to_system(response.GetS32(-1, 16));
-if (result_errno != -1)
-  error = Status(result_errno, eErrorTypePOSIX);
-else
-  error = Status(-1, eErrorTypeGeneric);
-  } else
+
+  if (response.GetChar() != ',') {
 error.Clear();
+return result;
+  }
+
+  // Response packet should contain a error code at the end. This code
+  // corresponds either to the gdb IOFile error code, or to the posix errno.

jasonmolenda wrote:

We should have lldb send `error-message` in our QSupported list, and accept 
this style of error reporting from the remote stub, but that's clearly an 
entirely different topic than the one being discussed here.

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

[Lldb-commits] [lldb] [lldb] gdb rsp file error pass fix (PR #106950)

[Jason Molenda via lldb-commits]

@@ -3064,22 +3064,41 @@ static int gdb_errno_to_system(int err) {
 
 static uint64_t ParseHostIOPacketResponse(StringExtractorGDBRemote &response,
   uint64_t fail_result, Status &error) 
{
+  // The packet is expected to have the following format:
+  // 'F,'
+
   response.SetFilePos(0);
   if (response.GetChar() != 'F')
 return fail_result;
+
   int32_t result = response.GetS32(-2, 16);
   if (result == -2)
 return fail_result;
-  if (response.GetChar() == ',') {
-int result_errno = gdb_errno_to_system(response.GetS32(-1, 16));
-if (result_errno != -1)
-  error = Status(result_errno, eErrorTypePOSIX);
-else
-  error = Status(-1, eErrorTypeGeneric);
-  } else
+
+  if (response.GetChar() != ',') {
 error.Clear();
+return result;
+  }
+
+  // Response packet should contain a error code at the end. This code
+  // corresponds either to the gdb IOFile error code, or to the posix errno.

jasonmolenda wrote:

> Note that the error strings, as currently used by `QEnableErrorStrings`, are 
> only relevant for gdb protocol errors (packets of format `Exx`). The "host 
> IO" packets discussed here use a different format for reporting errors, and 
> we don't currently have a way to include error strings in those.

Ah, excellent point, I'd forgotten that the vFile packets have a special error 
reporting mechanism that's entirely different. 
https://sourceware.org/gdb/current/onlinedocs/gdb.html/Host-I_002fO-Packets.html#Host-I_002fO-Packets

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

[via lldb-commits]

https://github.com/jeffreytan81 edited 
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] [lldb] [lldb-dap][test] Fix `readMemory` test (PR #109057)

[Adrian Vogelsgesang via lldb-commits]

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

>From 2a30bef69682b669661d1a4122a9f5e3f1a4fd85 Mon Sep 17 00:00:00 2001
From: Adrian Vogelsgesang 
Date: Tue, 17 Sep 2024 22:21:32 +
Subject: [PATCH] [lldb-dap][test] Fix `readMemory` test

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.
---
 lldb/test/API/tools/lldb-dap/memory/TestDAP_memory.py | 8 
 1 file changed, 8 deletions(-)

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] [lldb-dap][test] Fix `readMemory` test (PR #109057)

[via lldb-commits]

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Adrian Vogelsgesang (vogelsgesang)


Changes

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.

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


1 Files Affected:

- (modified) lldb/test/API/tools/lldb-dap/memory/TestDAP_memory.py (-8) 


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

``




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-dap] Support inspecting memory (PR #104317)

[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

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

[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] [llvm] [lldb][RISCV] function calls support in lldb expressions (PR #99336)

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

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

[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] [lldb/Interpreter] Add requirements to Scripted Interface abstract methods (PR #109063)

[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] [lldb/Interpreter] Add requirements to Scripted Interface abstract methods (PR #109063)

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

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

[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] [lldb/Interpreter] Introduce `ScriptedStopHook{, Python}Interface` & make use of it (PR #105449)

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

[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] [libcxx] [lldb] [lldb][libc++] Hide all libc++ implementation details from stacktraces (PR #108870)

[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] [LLDB][lldb-dap][vscode-lldb] Add Environment configuration for the lldb-dap process (PR #108948)

[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] [lldb] [LLDB][lldb-dap][vscode-lldb] Add Environment configuration for the lldb-dap process (PR #108948)

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

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

[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