date:20240916

[Lldb-commits] [lldb] [lldb][test] Remove benchmark API tests (PR #108629)

2024-09-16 Thread Pavel Labath via lldb-commits


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

I believe these weren't functional for a very long time now.

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

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

2024-09-16 Thread Pavel Labath via lldb-commits


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


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

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

2024-09-16 Thread Pavel Labath via lldb-commits


https://github.com/labath commented:

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

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

[Lldb-commits] [lldb] [lldb] Introduce an always-on system log category/channel (PR #108495)

2024-09-16 Thread Pavel Labath via lldb-commits

labath wrote:

> * Everyone (else) I talked to liked the idea of reusing the logging system 
> because that's what we already use and are familiar with. Promoting a log 
> message to be part of this log becomes as easy as adding a `GetLog` and using 
> the same macro.

I'm all for code reuse, and reusing some part of the logging machinery for this 
makes sense to me. The thing I'm not sure about is whether this is plugging 
into the machinery at the right level. The most irritating part is the 
`internal` flag -- like, we do all the motions to place the channel into the 
global log channel map (which is the source of truth for all user-facing log 
commands), but then set this flag which basically says "pretend this channel 
isn't here". 

I think this would look better if the flag wasn't there. Like, what if we had a 
separate way to create/register one of these "system" channels -- one which 
does not involve putting it in a list with all the other channels. Maybe the 
`Initialize` function could be something like:
```
Log g_system(g_system_channel);
g_system->Enable(...);
```
(The `Enable` function is currently private, but I think it would make sense to 
make it public, especially since it's possible (like you're effectively doing 
now) to bypass this restriction by calling the static string-based 
EnableLogChannel function. Alternatively, we could make the existence of this 
channel a feature of the generic log machinery (I expect we'll never want to 
have more than one of these), and then we can do this work from within 
`Log::Initialize`)

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

[Lldb-commits] [lldb] [lldb] Support new libc++ __compressed_pair layout (PR #96538)

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


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

>From 16ae2c3c04d908807d78224a8fee34f772a337fa Mon Sep 17 00:00:00 2001
From: Michael Buch 
Date: Mon, 29 Jan 2024 16:23:16 +
Subject: [PATCH 1/4] [lldb] Support new libc++ __compressed_pair layout

---
 lldb/examples/synthetic/libcxx.py |  26 ++-
 .../Plugins/Language/CPlusPlus/LibCxx.cpp |  85 ++---
 .../Plugins/Language/CPlusPlus/LibCxx.h   |   3 +-
 .../Plugins/Language/CPlusPlus/LibCxxList.cpp |  72 +---
 .../Plugins/Language/CPlusPlus/LibCxxMap.cpp  |  41 +++--
 .../Language/CPlusPlus/LibCxxUnorderedMap.cpp | 166 +++---
 .../Language/CPlusPlus/LibCxxVector.cpp   |  38 ++--
 .../list/TestDataFormatterGenericList.py  |   2 +-
 8 files changed, 282 insertions(+), 151 deletions(-)

diff --git a/lldb/examples/synthetic/libcxx.py 
b/lldb/examples/synthetic/libcxx.py
index 474aaa428fa23a..060ff901008497 100644
--- a/lldb/examples/synthetic/libcxx.py
+++ b/lldb/examples/synthetic/libcxx.py
@@ -721,6 +721,12 @@ def _get_value_of_compressed_pair(self, pair):
 def update(self):
 logger = lldb.formatters.Logger.Logger()
 try:
+has_compressed_pair_layout = True
+alloc_valobj = self.valobj.GetChildMemberWithName("__alloc_")
+size_valobj = self.valobj.GetChildMemberWithName("__size_")
+if alloc_valobj.IsValid() and size_valobj.IsValid():
+has_compressed_pair_layout = False
+
 # A deque is effectively a two-dim array, with fixed width.
 # 'map' contains pointers to the rows of this array. The
 # full memory area allocated by the deque is delimited
@@ -734,9 +740,13 @@ def update(self):
 # variable tells which element in this NxM array is the 0th
 # one, and the 'size' element gives the number of elements
 # in the deque.
-count = self._get_value_of_compressed_pair(
-self.valobj.GetChildMemberWithName("__size_")
-)
+if has_compressed_pair_layout:
+count = self._get_value_of_compressed_pair(
+self.valobj.GetChildMemberWithName("__size_")
+)
+else:
+count = size_valobj.GetValueAsUnsigned(0)
+
 # give up now if we cant access memory reliably
 if self.block_size < 0:
 logger.write("block_size < 0")
@@ -748,9 +758,13 @@ def update(self):
 self.map_begin = map_.GetChildMemberWithName("__begin_")
 map_begin = self.map_begin.GetValueAsUnsigned(0)
 map_end = 
map_.GetChildMemberWithName("__end_").GetValueAsUnsigned(0)
-map_endcap = self._get_value_of_compressed_pair(
-map_.GetChildMemberWithName("__end_cap_")
-)
+
+if has_compressed_pair_layout:
+map_endcap = self._get_value_of_compressed_pair(
+map_.GetChildMemberWithName("__end_cap_")
+)
+else:
+map_endcap = 
map_.GetChildMemberWithName("__end_cap_").GetValueAsUnsigned(0)
 
 # check consistency
 if not map_first <= map_begin <= map_end <= map_endcap:
diff --git a/lldb/source/Plugins/Language/CPlusPlus/LibCxx.cpp 
b/lldb/source/Plugins/Language/CPlusPlus/LibCxx.cpp
index feaa51a96843ab..7d3b2410a7296e 100644
--- a/lldb/source/Plugins/Language/CPlusPlus/LibCxx.cpp
+++ b/lldb/source/Plugins/Language/CPlusPlus/LibCxx.cpp
@@ -27,6 +27,7 @@
 #include "Plugins/LanguageRuntime/CPlusPlus/CPPLanguageRuntime.h"
 #include "Plugins/TypeSystem/Clang/TypeSystemClang.h"
 #include "lldb/lldb-enumerations.h"
+#include "lldb/lldb-forward.h"
 #include 
 #include 
 
@@ -34,6 +35,32 @@ using namespace lldb;
 using namespace lldb_private;
 using namespace lldb_private::formatters;
 
+static void consumeInlineNamespace(llvm::StringRef &name) {
+  // Delete past an inline namespace, if any: __[a-zA-Z0-9_]+::
+  auto scratch = name;
+  if (scratch.consume_front("__") && std::isalnum(scratch[0])) {
+scratch = scratch.drop_while([](char c) { return std::isalnum(c); });
+if (scratch.consume_front("::")) {
+  // Successfully consumed a namespace.
+  name = scratch;
+}
+  }
+}
+
+bool lldb_private::formatters::isOldCompressedPairLayout(
+ValueObject &pair_obj) {
+  return isStdTemplate(pair_obj.GetTypeName(), "__compressed_pair");
+}
+
+bool lldb_private::formatters::isStdTemplate(ConstString type_name,
+ llvm::StringRef type) {
+  llvm::StringRef name = type_name.GetStringRef();
+  // The type name may be prefixed with `std::__::`.
+  if (name.consume_front("std::"))
+consumeInlineNamespace(name);
+  return name.consume_front(type) && name.starts_with("<");
+}
+
 lldb::ValueObjectSP lldb_private::formatters::GetChildMemberWithName(
 ValueObject &obj, llvm::ArrayRef alternative_nam

[Lldb-commits] [lldb] 9e9b117 - [lldb] Support new libc++ __compressed_pair layout (#96538)

2024-09-16 Thread via lldb-commits


Author: Michael Buch
Date: 2024-09-16T10:11:49+01:00
New Revision: 9e9b1178ca435f690381ffe8241e4bf1bb7e60fb

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

LOG: [lldb] Support new libc++ __compressed_pair layout (#96538)

This patch is in preparation for the `__compressed_pair` refactor in
https://github.com/llvm/llvm-project/pull/76756.

This is mostly reviewable now. With the new layout we no longer need to
unwrap the `__compressed_pair`. Instead, we just need to look for child
members. E.g., to get to the underlying pointer of `std::unique_ptr` we
no longer do,
```
GetFirstValueOfCXXCompressedPair(GetChildMemberWithName("__ptr_"))

```
but instead do
```
GetChildMemberWithName("__ptr_")
```

We need to be slightly careful because previously the
`__compressed_pair` had a member called `__value_`, whereas now
`__value_` might be a member of the class that used to hold the
`__compressed_pair`. So before unwrapping the pair, we added checks for
`isOldCompressedLayout` (not sure yet whether folding this check into
`GetFirstValueOfCXXCompressedPair` is better).

Added: 


Modified: 
lldb/examples/synthetic/libcxx.py
lldb/source/Plugins/Language/CPlusPlus/LibCxx.cpp
lldb/source/Plugins/Language/CPlusPlus/LibCxx.h
lldb/source/Plugins/Language/CPlusPlus/LibCxxList.cpp
lldb/source/Plugins/Language/CPlusPlus/LibCxxMap.cpp
lldb/source/Plugins/Language/CPlusPlus/LibCxxUnorderedMap.cpp
lldb/source/Plugins/Language/CPlusPlus/LibCxxVector.cpp

lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/list/TestDataFormatterGenericList.py

Removed: 




diff  --git a/lldb/examples/synthetic/libcxx.py 
b/lldb/examples/synthetic/libcxx.py
index 474aaa428fa23a..b078a4eb2f6394 100644
--- a/lldb/examples/synthetic/libcxx.py
+++ b/lldb/examples/synthetic/libcxx.py
@@ -721,6 +721,12 @@ def _get_value_of_compressed_pair(self, pair):
 def update(self):
 logger = lldb.formatters.Logger.Logger()
 try:
+has_compressed_pair_layout = True
+alloc_valobj = self.valobj.GetChildMemberWithName("__alloc_")
+size_valobj = self.valobj.GetChildMemberWithName("__size_")
+if alloc_valobj.IsValid() and size_valobj.IsValid():
+has_compressed_pair_layout = False
+
 # A deque is effectively a two-dim array, with fixed width.
 # 'map' contains pointers to the rows of this array. The
 # full memory area allocated by the deque is delimited
@@ -734,9 +740,13 @@ def update(self):
 # variable tells which element in this NxM array is the 0th
 # one, and the 'size' element gives the number of elements
 # in the deque.
-count = self._get_value_of_compressed_pair(
-self.valobj.GetChildMemberWithName("__size_")
-)
+if has_compressed_pair_layout:
+count = self._get_value_of_compressed_pair(
+self.valobj.GetChildMemberWithName("__size_")
+)
+else:
+count = size_valobj.GetValueAsUnsigned(0)
+
 # give up now if we cant access memory reliably
 if self.block_size < 0:
 logger.write("block_size < 0")
@@ -748,9 +758,15 @@ def update(self):
 self.map_begin = map_.GetChildMemberWithName("__begin_")
 map_begin = self.map_begin.GetValueAsUnsigned(0)
 map_end = 
map_.GetChildMemberWithName("__end_").GetValueAsUnsigned(0)
-map_endcap = self._get_value_of_compressed_pair(
-map_.GetChildMemberWithName("__end_cap_")
-)
+
+if has_compressed_pair_layout:
+map_endcap = self._get_value_of_compressed_pair(
+map_.GetChildMemberWithName("__end_cap_")
+)
+else:
+map_endcap = map_.GetChildMemberWithName(
+"__end_cap_"
+).GetValueAsUnsigned(0)
 
 # check consistency
 if not map_first <= map_begin <= map_end <= map_endcap:

diff  --git a/lldb/source/Plugins/Language/CPlusPlus/LibCxx.cpp 
b/lldb/source/Plugins/Language/CPlusPlus/LibCxx.cpp
index feaa51a96843ab..7d3b2410a7296e 100644
--- a/lldb/source/Plugins/Language/CPlusPlus/LibCxx.cpp
+++ b/lldb/source/Plugins/Language/CPlusPlus/LibCxx.cpp
@@ -27,6 +27,7 @@
 #include "Plugins/LanguageRuntime/CPlusPlus/CPPLanguageRuntime.h"
 #include "Plugins/TypeSystem/Clang/TypeSystemClang.h"
 #include "lldb/lldb-enumerations.h"
+#include "lldb/lldb-forward.h"
 #include 
 #include 
 
@@ -34,6 +35,32 @@ using namespace lldb;
 using namespace lldb_private;
 using namespace lldb_private::formatters;
 
+static void consumeInlineNamespace(

[Lldb-commits] [lldb] [lldb] Support new libc++ __compressed_pair layout (PR #96538)

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


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

[Lldb-commits] [lldb] 7e5fe3e - [lldb][test] Remove benchmark API tests (#108629)

2024-09-16 Thread via lldb-commits


Author: Michael Buch
Date: 2024-09-16T10:15:52+01:00
New Revision: 7e5fe3ec5aed001c3b8f0bf59167b6472b91b9cc

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

LOG: [lldb][test] Remove benchmark API tests (#108629)

These benchmarks don't get run as part of the regular API test-suite.
And I'm not aware of any CI running this. Also, I haven't quite managed
to actually run them locally using the `bench.py` script. It looks like
these are obsolete, so I'm proposing to remove the infrastructure around
it entirely.

If anyone does know of a use for these do let me know.

Added: 


Modified: 
lldb/packages/Python/lldbsuite/test/decorators.py

Removed: 
lldb/packages/Python/lldbsuite/test/bench.py
lldb/test/API/benchmarks/continue/Makefile
lldb/test/API/benchmarks/continue/TestBenchmarkContinue.py
lldb/test/API/benchmarks/continue/main.cpp
lldb/test/API/benchmarks/expression/Makefile
lldb/test/API/benchmarks/expression/TestExpressionCmd.py
lldb/test/API/benchmarks/expression/TestRepeatedExprs.py
lldb/test/API/benchmarks/expression/main.cpp
lldb/test/API/benchmarks/frame_variable/TestFrameVariableResponse.py
lldb/test/API/benchmarks/libcxxlist/Makefile
lldb/test/API/benchmarks/libcxxlist/TestBenchmarkLibcxxList.py
lldb/test/API/benchmarks/libcxxlist/main.cpp
lldb/test/API/benchmarks/libcxxmap/Makefile
lldb/test/API/benchmarks/libcxxmap/TestBenchmarkLibcxxMap.py
lldb/test/API/benchmarks/libcxxmap/main.cpp
lldb/test/API/benchmarks/startup/TestStartupDelays.py
lldb/test/API/benchmarks/stepping/TestSteppingSpeed.py
lldb/test/API/benchmarks/turnaround/TestCompileRunToBreakpointTurnaround.py



diff  --git a/lldb/packages/Python/lldbsuite/test/bench.py 
b/lldb/packages/Python/lldbsuite/test/bench.py
deleted file mode 100644
index 1a11b3ef4f0e64..00
--- a/lldb/packages/Python/lldbsuite/test/bench.py
+++ /dev/null
@@ -1,77 +0,0 @@
-#!/usr/bin/env python
-
-"""
-A simple bench runner which delegates to the ./dotest.py test driver to run the
-benchmarks defined in the list named 'benches'.
-
-You need to hand edit 'benches' to modify/change the command lines passed to 
the
-test driver.
-
-Use the following to get only the benchmark results in your terminal output:
-
-./bench.py -e /Volumes/data/lldb/svn/regression/build/Debug/lldb -x '-F 
Driver::MainLoop()' 2>&1 | grep -P '^lldb.*benchmark:'
-"""
-
-import os
-from optparse import OptionParser
-
-# dotest.py invocation with no '-e exe-path' uses lldb as the inferior program,
-# unless there is a mentioning of custom executable program.
-benches = [
-# Measure startup delays creating a target, setting a breakpoint, and run
-# to breakpoint stop.
-"./dotest.py -v +b %E %X -n -p TestStartupDelays.py",
-# Measure 'frame variable' response after stopping at a breakpoint.
-"./dotest.py -v +b %E %X -n -p TestFrameVariableResponse.py",
-# Measure stepping speed after stopping at a breakpoint.
-"./dotest.py -v +b %E %X -n -p TestSteppingSpeed.py",
-# Measure expression cmd response with a simple custom executable program.
-"./dotest.py +b -n -p TestExpressionCmd.py",
-# Attach to a spawned process then run disassembly benchmarks.
-"./dotest.py -v +b -n %E -p TestDoAttachThenDisassembly.py",
-]
-
-
-def main():
-"""Read the items from 'benches' and run the command line one by one."""
-parser = OptionParser(
-usage="""\
-%prog [options]
-Run the standard benchmarks defined in the list named 'benches'.\
-"""
-)
-parser.add_option(
-"-e",
-"--executable",
-type="string",
-action="store",
-dest="exe",
-help="The target program launched by lldb.",
-)
-parser.add_option(
-"-x",
-"--breakpoint-spec",
-type="string",
-action="store",
-dest="break_spec",
-help="The lldb breakpoint spec for the target program.",
-)
-
-# Parses the options, if any.
-opts, args = parser.parse_args()
-
-print("Starting bench runner")
-
-for item in benches:
-command = item.replace("%E", '-e "%s"' % opts.exe if opts.exe else "")
-command = command.replace(
-"%X", '-x "%s"' % opts.break_spec if opts.break_spec else ""
-)
-print("Running %s" % (command))
-os.system(command)
-
-print("Bench runner done.")
-
-
-if __name__ == "__main__":
-main()

diff  --git a/lldb/packages/Python/lldbsuite/test/decorators.py 
b/lldb/packages/Python/lldbsuite/test/decorators.py
index 834f01aaa61e6b..34319e203a3177 100644
--- a/lldb/packages/Python/lldbsuite/test/decorators.py
+++ b/lldb/packages/Python/lldbsuite/test/decorators.py
@@ -426,18 +426,6 @@ def impl(func):

[Lldb-commits] [lldb] [lldb][test] Remove benchmark API tests (PR #108629)

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


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

[Lldb-commits] [lldb] [lldb/DWARF] Downgrade the "parent of variable is not CU" error (PR #108806)

2024-09-16 Thread Pavel Labath via lldb-commits


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

This can legitimately happen for static function-local variables with a 
non-manual dwarf index. According to the DWARF spec, these variables should be 
(and are) included in the compiler generated indexes, but they are ignored by 
our manual index. Encountering them does not indicate any sort of error.

The error message is particularly annoying due to a combination of the fact 
that we don't cache negative hits (so we print it every time we encounter it), 
VSCode's aggresive tab completion (which attempts a lookup after every 
keypress) and the fact that some low-level libraries (e.g. tcmalloc) have 
several local variables called "v". The result is a console full of error 
messages everytime you type "v ".

We already have tests (e.g. find-basic-variable.cpp), which check that these 
variables are not included in the result (and by extension, that their presence 
does not crash lldb). It would be possible to extend it to make sure it does 
*not* print this error message, but it doesn't seem like it would be 
particularly useful.

>From baea580cd620065bbe0f4e653bfbd5316e7f63ee Mon Sep 17 00:00:00 2001
From: Pavel Labath 
Date: Mon, 16 Sep 2024 10:52:00 +0200
Subject: [PATCH] [lldb/DWARF] Downgrade the "parent of variable is not CU"
 error

This can legitimately happen for static function-local variables with a
non-manual dwarf index. According to the DWARF spec, these variables
should be (and are) included in the compiler generated indexes, but they
are ignored by our manual index. Encountering them does not indicate any
sort of error.

The error message is particularly annoying due to a combination of the
fact that we don't cache negative hits (so we print it every time we
encounter it), VSCode's aggresive tab completion (which attempts a
lookup after every keypress) and the fact that some low-level libraries
(e.g. tcmalloc) have several local variables called "v". The result is a
console full of error messages everytime you type "v ".

We already have tests (e.g. find-basic-variable.cpp), which check that
these variables are not included in the result (and by extension, that
their presence does not crash lldb). It would be possible to extend it
to make sure it does *not* print this error message, but it doesn't seem
like it would be particularly useful.
---
 lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
index f721ca00fd3559..082c437321e38b 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
@@ -3828,10 +3828,8 @@ void SymbolFileDWARF::ParseAndAppendGlobalVariable(
 break;
 
   default:
-GetObjectFile()->GetModule()->ReportError(
-"didn't find appropriate parent DIE for variable list for {0:x8} "
-"{1} ({2}).\n",
-die.GetID(), DW_TAG_value_to_name(die.Tag()), die.Tag());
+LLDB_LOG(GetLog(DWARFLog::Lookups),
+ "DIE {0:x8} is not a global variable - ignoring", die.GetID());
 return;
   }
 

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

[Lldb-commits] [lldb] [lldb/DWARF] Downgrade the "parent of variable is not CU" error (PR #108806)

2024-09-16 Thread via lldb-commits


llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Pavel Labath (labath)


Changes

This can legitimately happen for static function-local variables with a 
non-manual dwarf index. According to the DWARF spec, these variables should be 
(and are) included in the compiler generated indexes, but they are ignored by 
our manual index. Encountering them does not indicate any sort of error.

The error message is particularly annoying due to a combination of the fact 
that we don't cache negative hits (so we print it every time we encounter it), 
VSCode's aggresive tab completion (which attempts a lookup after every 
keypress) and the fact that some low-level libraries (e.g. tcmalloc) have 
several local variables called "v". The result is a console full of error 
messages everytime you type "v ".

We already have tests (e.g. find-basic-variable.cpp), which check that these 
variables are not included in the result (and by extension, that their presence 
does not crash lldb). It would be possible to extend it to make sure it does 
*not* print this error message, but it doesn't seem like it would be 
particularly useful.

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


1 Files Affected:

- (modified) lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp (+2-4) 


``diff
diff --git a/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
index f721ca00fd3559..082c437321e38b 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
@@ -3828,10 +3828,8 @@ void SymbolFileDWARF::ParseAndAppendGlobalVariable(
 break;
 
   default:
-GetObjectFile()->GetModule()->ReportError(
-"didn't find appropriate parent DIE for variable list for {0:x8} "
-"{1} ({2}).\n",
-die.GetID(), DW_TAG_value_to_name(die.Tag()), die.Tag());
+LLDB_LOG(GetLog(DWARFLog::Lookups),
+ "DIE {0:x8} is not a global variable - ignoring", die.GetID());
 return;
   }
 

``




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

2024-09-16 Thread Pavel Labath via lldb-commits


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

Use a `nullptr` map entry to mean "variable parse was attempted and it failed" 
an the absence of an entry to mean "parsing hasn't been attempted yet".

I ran into this because parsing of function-static variables was generating a 
lot of errors (see #108806), but this seems like a good idea in general.

In theory this should be NFC, except for possibly reducing some amount of work.

>From fddb89e718e3bc96ce5e051ce9a8e63f37ce5a25 Mon Sep 17 00:00:00 2001
From: Pavel Labath 
Date: Mon, 16 Sep 2024 11:46:05 +0200
Subject: [PATCH] [lldb/DWARF] Cache negative results of variable parsing

Use a `nullptr` map entry to mean "variable parse was attempted and it
failed" an the absence of an entry to mean "parsing hasn't been
attempted yet".

I ran into this because parsing of function-static variables was
generating a lot of errors (see #108806), but this seems like a good
idea in general.

In theory this should be NFC, except for possibly reducing some amount
of work.
---
 .../SymbolFile/DWARF/SymbolFileDWARF.cpp  | 26 +--
 1 file changed, 12 insertions(+), 14 deletions(-)

diff --git a/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
index f721ca00fd3559..bacea848988467 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
@@ -3377,16 +3377,13 @@ VariableSP 
SymbolFileDWARF::ParseVariableDIECached(const SymbolContext &sc,
 
   DIEToVariableSP &die_to_variable = die.GetDWARF()->GetDIEToVariable();
 
-  VariableSP var_sp = die_to_variable[die.GetDIE()];
-  if (var_sp)
-return var_sp;
-
-  var_sp = ParseVariableDIE(sc, die, LLDB_INVALID_ADDRESS);
-  if (var_sp) {
-die_to_variable[die.GetDIE()] = var_sp;
-if (DWARFDIE spec_die = die.GetReferencedDIE(DW_AT_specification))
-  die_to_variable[spec_die.GetDIE()] = var_sp;
-  }
+  if (auto it = die_to_variable.find(die.GetDIE()); it != 
die_to_variable.end())
+return it->second;
+
+  VariableSP var_sp = ParseVariableDIE(sc, die, LLDB_INVALID_ADDRESS);
+  die_to_variable.insert_or_assign(die.GetDIE(), var_sp);
+  if (DWARFDIE spec_die = die.GetReferencedDIE(DW_AT_specification))
+die_to_variable.insert_or_assign(spec_die.GetDIE(), var_sp);
   return var_sp;
 }
 
@@ -3799,9 +3796,10 @@ void SymbolFileDWARF::ParseAndAppendGlobalVariable(
 return;
 
   // Check to see if we have already parsed this variable or constant?
-  VariableSP var_sp = GetDIEToVariable()[die.GetDIE()];
-  if (var_sp) {
-cc_variable_list.AddVariableIfUnique(var_sp);
+  DIEToVariableSP &die_to_variable = GetDIEToVariable();
+  if (auto it = die_to_variable.find(die.GetDIE());
+  it != die_to_variable.end()) {
+cc_variable_list.AddVariableIfUnique(it->second);
 return;
   }
 
@@ -3835,7 +3833,7 @@ void SymbolFileDWARF::ParseAndAppendGlobalVariable(
 return;
   }
 
-  var_sp = ParseVariableDIECached(sc, die);
+  VariableSP var_sp = ParseVariableDIECached(sc, die);
   if (!var_sp)
 return;
 

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

2024-09-16 Thread via lldb-commits


llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Pavel Labath (labath)


Changes

Use a `nullptr` map entry to mean "variable parse was attempted and it failed" 
an the absence of an entry to mean "parsing hasn't been attempted yet".

I ran into this because parsing of function-static variables was generating a 
lot of errors (see #108806), but this seems like a good idea in general.

In theory this should be NFC, except for possibly reducing some amount of work.

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


1 Files Affected:

- (modified) lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp (+12-14) 


``diff
diff --git a/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
index f721ca00fd3559..bacea848988467 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
@@ -3377,16 +3377,13 @@ VariableSP 
SymbolFileDWARF::ParseVariableDIECached(const SymbolContext &sc,
 
   DIEToVariableSP &die_to_variable = die.GetDWARF()->GetDIEToVariable();
 
-  VariableSP var_sp = die_to_variable[die.GetDIE()];
-  if (var_sp)
-return var_sp;
-
-  var_sp = ParseVariableDIE(sc, die, LLDB_INVALID_ADDRESS);
-  if (var_sp) {
-die_to_variable[die.GetDIE()] = var_sp;
-if (DWARFDIE spec_die = die.GetReferencedDIE(DW_AT_specification))
-  die_to_variable[spec_die.GetDIE()] = var_sp;
-  }
+  if (auto it = die_to_variable.find(die.GetDIE()); it != 
die_to_variable.end())
+return it->second;
+
+  VariableSP var_sp = ParseVariableDIE(sc, die, LLDB_INVALID_ADDRESS);
+  die_to_variable.insert_or_assign(die.GetDIE(), var_sp);
+  if (DWARFDIE spec_die = die.GetReferencedDIE(DW_AT_specification))
+die_to_variable.insert_or_assign(spec_die.GetDIE(), var_sp);
   return var_sp;
 }
 
@@ -3799,9 +3796,10 @@ void SymbolFileDWARF::ParseAndAppendGlobalVariable(
 return;
 
   // Check to see if we have already parsed this variable or constant?
-  VariableSP var_sp = GetDIEToVariable()[die.GetDIE()];
-  if (var_sp) {
-cc_variable_list.AddVariableIfUnique(var_sp);
+  DIEToVariableSP &die_to_variable = GetDIEToVariable();
+  if (auto it = die_to_variable.find(die.GetDIE());
+  it != die_to_variable.end()) {
+cc_variable_list.AddVariableIfUnique(it->second);
 return;
   }
 
@@ -3835,7 +3833,7 @@ void SymbolFileDWARF::ParseAndAppendGlobalVariable(
 return;
   }
 
-  var_sp = ParseVariableDIECached(sc, die);
+  VariableSP var_sp = ParseVariableDIECached(sc, die);
   if (!var_sp)
 return;
 

``




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

2024-09-16 Thread 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:

I use `s_regs_for_args_count` in 2 different `ABISysV_riscv` methods, so I've 
decided to place it here. Maybe I can create a static global value in 
`ABISysV_riscv.cpp` instead.

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

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

2024-09-16 Thread via lldb-commits


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

>From 10d7addd0a86789e268189e00a825af27516323e 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   | 87 +--
 lldb/source/Plugins/ABI/RISCV/ABISysV_riscv.h |  3 +
 2 files changed, 83 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..24468838cbb821 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()
@@ -164,11 +167,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() > s_regs_for_args_count) {
+LLDB_LOG(log, "Function has {0} arguments, but only {1} are allowed!",
+ args.size(), s_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 +295,14 @@ bool ABISysV_riscv::PrepareTrivialCall(
   assert(prototype.getFunctionNumParams() == args.size());
 
   const size_t num_args = args.size();
-  const size_t regs_for_args_count = 8U;
   const size_t num_args_in_regs =
-  num_args > regs_for_args_count ?  regs_for_args_count : num_args;
+  num_args > s_regs_for_args_count ? s_regs_for_args_count : num_args;
 
   // Number of arguments passed on stack.
   size_t args_size = TotalArgsSizeInWords(m_is_rv64, args);
-  auto

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

2024-09-16 Thread via lldb-commits



@@ -164,11 +167,82 @@ 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,

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

2024-09-16 Thread via lldb-commits



@@ -164,11 +167,82 @@ 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) {
+  assert(log);
+  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() > s_regs_for_args_count) {
+LLDB_LOG(log, "Function has {0} arguments, but only {1} are allowed!",
+ args.size(), s_regs_for_args_count);
+return false;
+  }
+
+  // Write arguments to registers
+  for (auto &&[idx, arg] : enumerate(args)) {

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][intel-pt] Fix build error on conversion from llvm::Error to Status::FromError (PR #108719)

2024-09-16 Thread Sylvestre Ledru via lldb-commits


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

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

2024-09-16 Thread Michael Buch 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 =

Michael137 wrote:

yup i think that would be preferable

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/DWARF] Downgrade the "parent of variable is not CU" error (PR #108806)

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


https://github.com/Michael137 commented:

Seems reasonable to make this less spammy. Though is there a reason why we're 
not adding them to the manual index? Is this just something we didn't implement 
(yet)?

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

[Lldb-commits] [lldb] [lldb][test] Add a new __compressed_pair layout to libcxx simulator tests (PR #99012)

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


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

>From 8d0245dfccc607a4237fc94bbbfea646fa1a6887 Mon Sep 17 00:00:00 2001
From: Michael Buch 
Date: Wed, 10 Jul 2024 15:37:45 +0100
Subject: [PATCH 1/4] [WIP][lldb][test] Add a new __compressed_pair layout to
 libcxx simulator tests

---
 .../compressed_pair.h | 34 ++-
 .../TestDataFormatterLibcxxStringSimulator.py | 19 ++-
 .../libcxx-simulators/string/main.cpp | 33 +++---
 ...stDataFormatterLibcxxUniquePtrSimulator.py | 14 ++--
 .../libcxx-simulators/unique_ptr/main.cpp |  5 +++
 5 files changed, 81 insertions(+), 24 deletions(-)

diff --git 
a/lldb/packages/Python/lldbsuite/test/make/libcxx-simulators-common/compressed_pair.h
 
b/lldb/packages/Python/lldbsuite/test/make/libcxx-simulators-common/compressed_pair.h
index 026e7183ab27a0..f2c1b626bd46f7 100644
--- 
a/lldb/packages/Python/lldbsuite/test/make/libcxx-simulators-common/compressed_pair.h
+++ 
b/lldb/packages/Python/lldbsuite/test/make/libcxx-simulators-common/compressed_pair.h
@@ -7,7 +7,7 @@
 namespace std {
 namespace __lldb {
 
-// Post-c88580c layout
+#if COMPRESSED_PAIR_REV == 0 // Post-c88580c layout
 struct __value_init_tag {};
 struct __default_init_tag {};
 
@@ -52,6 +52,38 @@ class __compressed_pair : private 
__compressed_pair_elem<_T1, 0>,
 
   _T1 &first() { return static_cast<_Base1 &>(*this).__get(); }
 };
+#elif COMPRESSED_PAIR_REV == 1
+template  class __compressed_pair_padding {
+  char __padding_[(is_empty<_ToPad>::value && 
!__libcpp_is_final<_ToPad>::value)
+  ? 0
+  : sizeof(_ToPad) - __datasizeof(_ToPad)];
+};
+
+#define _LLDB_COMPRESSED_PAIR(T1, Initializer1, T2, Initializer2)  
\
+  [[__gnu__::__aligned__(alignof(T2))]] [[no_unique_address]] T1 Initializer1; 
\
+  [[no_unique_address]] __compressed_pair_padding __padding1_; 
\
+  [[no_unique_address]] T2 Initializer2;   
\
+  [[no_unique_address]] __compressed_pair_padding __padding2_;
+
+#define _LLDB_COMPRESSED_TRIPLE(T1, Initializer1, T2, Initializer2, T3,
\
+Initializer3)  
\
+  [[using __gnu__: __aligned__(alignof(T2)),   
\
+__aligned__(alignof(T3))]] [[no_unique_address]] T1 Initializer1;  
\
+  [[no_unique_address]] __compressed_pair_padding __padding1_; 
\
+  [[no_unique_address]] T2 Initializer2;   
\
+  [[no_unique_address]] __compressed_pair_padding __padding2_; 
\
+  [[no_unique_address]] T3 Initializer3;   
\
+  [[no_unique_address]] __compressed_pair_padding __padding3_;
+#elif COMPRESSED_PAIR_REV == 2
+#define _LLDB_COMPRESSED_PAIR(T1, Name1, T2, Name2)
\
+  [[no_unique_address]] T1 Name1;  
\
+  [[no_unique_address]] T2 Name2
+
+#define _LLDB_COMPRESSED_TRIPLE(T1, Name1, T2, Name2, T3, Name3)   
\
+  [[no_unique_address]] T1 Name1;  
\
+  [[no_unique_address]] T2 Name2;  
\
+  [[no_unique_address]] T3 Name3
+#endif
 } // namespace __lldb
 } // namespace std
 
diff --git 
a/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx-simulators/string/TestDataFormatterLibcxxStringSimulator.py
 
b/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx-simulators/string/TestDataFormatterLibcxxStringSimulator.py
index 98d2c7320003e4..afe6374e55a355 100644
--- 
a/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx-simulators/string/TestDataFormatterLibcxxStringSimulator.py
+++ 
b/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx-simulators/string/TestDataFormatterLibcxxStringSimulator.py
@@ -28,12 +28,13 @@ def _run_test(self, defines):
 
 for v in [None, "ALTERNATE_LAYOUT"]:
 for r in range(5):
-name = "test_r%d" % r
-defines = ["REVISION=%d" % r]
-if v:
-name += "_" + v
-defines += [v]
-f = functools.partialmethod(
-LibcxxStringDataFormatterSimulatorTestCase._run_test, defines
-)
-setattr(LibcxxStringDataFormatterSimulatorTestCase, name, f)
+for c in range(3):
+name = "test_r%d_c%d" % (r, c)
+defines = ["REVISION=%d" % r, "COMPRESSED_PAIR_REV=%d" % c]
+if v:
+name += "_" + v
+defines += [v]
+f = functools.partialmethod(
+LibcxxStringDataFormatterSimulatorTestCase._run_test, defines
+)
+setattr(LibcxxStringDataFormatterSimulatorTestCase, name, f)
diff --git 
a/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx-simulators/string/

[Lldb-commits] [lldb] 9548dbe - [lldb][test] Add TestNoUniqueAddress.py

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


Author: Michael Buch
Date: 2024-09-16T12:05:00+01:00
New Revision: 9548dbedbc1b2bfb130c91df54e8007acb81e1b0

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

LOG: [lldb][test] Add TestNoUniqueAddress.py

Tests that run expressions on record types with
`[[no_unique_address]]` fields.

Added: 
lldb/test/API/lang/cpp/no_unique_address/Makefile
lldb/test/API/lang/cpp/no_unique_address/TestNoUniqueAddress.py
lldb/test/API/lang/cpp/no_unique_address/main.cpp

Modified: 


Removed: 




diff  --git a/lldb/test/API/lang/cpp/no_unique_address/Makefile 
b/lldb/test/API/lang/cpp/no_unique_address/Makefile
new file mode 100644
index 00..8b20bcb050
--- /dev/null
+++ b/lldb/test/API/lang/cpp/no_unique_address/Makefile
@@ -0,0 +1,3 @@
+CXX_SOURCES := main.cpp
+
+include Makefile.rules

diff  --git a/lldb/test/API/lang/cpp/no_unique_address/TestNoUniqueAddress.py 
b/lldb/test/API/lang/cpp/no_unique_address/TestNoUniqueAddress.py
new file mode 100644
index 00..d16aaa14153fd7
--- /dev/null
+++ b/lldb/test/API/lang/cpp/no_unique_address/TestNoUniqueAddress.py
@@ -0,0 +1,67 @@
+"""
+Test that LLDB correctly handles fields
+marked with [[no_unique_address]].
+"""
+
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+
+class NoUniqueAddressTestCase(TestBase):
+def test(self):
+self.build()
+lldbutil.run_to_source_breakpoint(
+self, "return 0", lldb.SBFileSpec("main.cpp", False)
+)
+
+# Qualified/unqualified lookup to templates in namespace
+self.expect_expr(
+"b1",
+result_type="basic::Foo",
+result_children=[ValueCheck(name="a", type="Empty")],
+)
+
+self.expect_expr(
+"b2",
+result_type="bases::Foo",
+result_children=[
+ValueCheck(
+type="bases::B", children=[ValueCheck(name="x", 
type="Empty")]
+),
+ValueCheck(
+type="bases::A",
+children=[
+ValueCheck(name="c", type="long", value="1"),
+ValueCheck(name="d", type="long", value="2"),
+],
+),
+ValueCheck(
+type="bases::C", children=[ValueCheck(name="x", 
type="Empty")]
+),
+],
+)
+self.expect_expr(
+"b3",
+result_type="bases::Bar",
+result_children=[
+ValueCheck(
+type="bases::B", children=[ValueCheck(name="x", 
type="Empty")]
+),
+ValueCheck(
+type="bases::C", children=[ValueCheck(name="x", 
type="Empty")]
+),
+ValueCheck(
+type="bases::A",
+children=[
+ValueCheck(name="c", type="long", value="5"),
+ValueCheck(name="d", type="long", value="6"),
+],
+),
+],
+)
+
+self.expect("frame var b1")
+self.expect("frame var b2")
+self.expect("frame var b3")

diff  --git a/lldb/test/API/lang/cpp/no_unique_address/main.cpp 
b/lldb/test/API/lang/cpp/no_unique_address/main.cpp
new file mode 100644
index 00..424fa90859ceaa
--- /dev/null
+++ b/lldb/test/API/lang/cpp/no_unique_address/main.cpp
@@ -0,0 +1,35 @@
+struct Empty {};
+
+namespace basic {
+struct Foo {
+  [[no_unique_address]] Empty a;
+};
+} // namespace basic
+
+namespace bases {
+struct A {
+  long c, d;
+};
+
+struct B {
+  [[no_unique_address]] Empty x;
+};
+
+struct C {
+  [[no_unique_address]] Empty x;
+};
+
+struct Foo : B, A, C {};
+struct Bar : B, C, A {};
+} // namespace bases
+
+int main() {
+  basic::Foo b1;
+  bases::Foo b2;
+  bases::Bar b3;
+  b2.c = 1;
+  b2.d = 2;
+  b3.c = 5;
+  b3.d = 6;
+  return 0;
+}



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

[Lldb-commits] [lldb] [lldb/DWARF] Downgrade the "parent of variable is not CU" error (PR #108806)

2024-09-16 Thread Pavel Labath via lldb-commits


labath wrote:

Adding these to the manual index is very easy -- there just isn't a point in 
doing it (except maybe for consistency).

In case I wasn't clear: this warning/error appears in the compiler-generated 
indexes, because we find the variable in the name lookup -- and then ignore it.
For the manual index, the variable is simply not found, so there's nothing to 
ignore or warn about.

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

[Lldb-commits] [lldb] [lldb/DWARF] Downgrade the "parent of variable is not CU" error (PR #108806)

2024-09-16 Thread Pavel Labath via lldb-commits


labath wrote:

One more clarification :P

I think it would be reasonable for something like `target variable foo()::v` to 
return the static variable `v` in function `foo()`, and to make that work we 
might (depending on how exactly this is implemented) need to insert the 
variable into the manual index as well. However, we don't support such queries 
right now.

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

2024-09-16 Thread Pavel Labath via lldb-commits



@@ -1364,8 +1364,14 @@ void request_evaluate(const llvm::json::Object &request) 
{
   std::string expression = GetString(arguments, "expression").str();
   llvm::StringRef context = GetString(arguments, "context");
 
-  if (context == "repl" && g_dap.DetectExpressionContext(frame, expression) ==
-   ExpressionContext::Command) {
+  if (context == "repl" &&
+  (expression.empty() ?
+   g_dap.last_nonempty_var_expression.empty() :
+   g_dap.DetectExpressionContext(frame, expression) ==

labath wrote:

.. but note that the work that DetectExpressionContext does (looking up local 
variables) is relatively expensive, so we probably don't want to do it when 
it's not needed (when `context!="repl"`). 

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

[Lldb-commits] [lldb] [lldb/DWARF] Downgrade the "parent of variable is not CU" error (PR #108806)

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


Michael137 wrote:

Ahh thanks for the clarification. Makes sense.

Sounds like a situation where this would arise is:
```
struct Foo {
  static int bar;
};

int Foo::bar = 5;

int main() {
  static bool bar = false
  __builtin_debugtrap();
}
```

Doing `(lldb) target var bar` would produce this error. Which I agree doesn't 
seem right.

I guess the alternative would be to suppress the error message only if the 
parent is a `DW_TAG_subprogram`. But that wouldn't really be a complete check 
either since local variables wouldn't be distinguishable.

So LGTM.

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

[Lldb-commits] [lldb] [lldb/DWARF] Downgrade the "parent of variable is not CU" error (PR #108806)

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


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


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

[Lldb-commits] [lldb] [lldb/DWARF] Downgrade the "parent of variable is not CU" error (PR #108806)

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



@@ -3828,10 +3828,8 @@ void SymbolFileDWARF::ParseAndAppendGlobalVariable(
 break;
 
   default:
-GetObjectFile()->GetModule()->ReportError(
-"didn't find appropriate parent DIE for variable list for {0:x8} "
-"{1} ({2}).\n",
-die.GetID(), DW_TAG_value_to_name(die.Tag()), die.Tag());
+LLDB_LOG(GetLog(DWARFLog::Lookups),
+ "DIE {0:x8} is not a global variable - ignoring", die.GetID());

Michael137 wrote:

Nit: should we include the name/tag too? I could see it being useful

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

[Lldb-commits] [lldb] [lldb][test] Add a new __compressed_pair layout to libcxx simulator tests (PR #99012)

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


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

>From 8d0245dfccc607a4237fc94bbbfea646fa1a6887 Mon Sep 17 00:00:00 2001
From: Michael Buch 
Date: Wed, 10 Jul 2024 15:37:45 +0100
Subject: [PATCH 1/5] [WIP][lldb][test] Add a new __compressed_pair layout to
 libcxx simulator tests

---
 .../compressed_pair.h | 34 ++-
 .../TestDataFormatterLibcxxStringSimulator.py | 19 ++-
 .../libcxx-simulators/string/main.cpp | 33 +++---
 ...stDataFormatterLibcxxUniquePtrSimulator.py | 14 ++--
 .../libcxx-simulators/unique_ptr/main.cpp |  5 +++
 5 files changed, 81 insertions(+), 24 deletions(-)

diff --git 
a/lldb/packages/Python/lldbsuite/test/make/libcxx-simulators-common/compressed_pair.h
 
b/lldb/packages/Python/lldbsuite/test/make/libcxx-simulators-common/compressed_pair.h
index 026e7183ab27a0..f2c1b626bd46f7 100644
--- 
a/lldb/packages/Python/lldbsuite/test/make/libcxx-simulators-common/compressed_pair.h
+++ 
b/lldb/packages/Python/lldbsuite/test/make/libcxx-simulators-common/compressed_pair.h
@@ -7,7 +7,7 @@
 namespace std {
 namespace __lldb {
 
-// Post-c88580c layout
+#if COMPRESSED_PAIR_REV == 0 // Post-c88580c layout
 struct __value_init_tag {};
 struct __default_init_tag {};
 
@@ -52,6 +52,38 @@ class __compressed_pair : private 
__compressed_pair_elem<_T1, 0>,
 
   _T1 &first() { return static_cast<_Base1 &>(*this).__get(); }
 };
+#elif COMPRESSED_PAIR_REV == 1
+template  class __compressed_pair_padding {
+  char __padding_[(is_empty<_ToPad>::value && 
!__libcpp_is_final<_ToPad>::value)
+  ? 0
+  : sizeof(_ToPad) - __datasizeof(_ToPad)];
+};
+
+#define _LLDB_COMPRESSED_PAIR(T1, Initializer1, T2, Initializer2)  
\
+  [[__gnu__::__aligned__(alignof(T2))]] [[no_unique_address]] T1 Initializer1; 
\
+  [[no_unique_address]] __compressed_pair_padding __padding1_; 
\
+  [[no_unique_address]] T2 Initializer2;   
\
+  [[no_unique_address]] __compressed_pair_padding __padding2_;
+
+#define _LLDB_COMPRESSED_TRIPLE(T1, Initializer1, T2, Initializer2, T3,
\
+Initializer3)  
\
+  [[using __gnu__: __aligned__(alignof(T2)),   
\
+__aligned__(alignof(T3))]] [[no_unique_address]] T1 Initializer1;  
\
+  [[no_unique_address]] __compressed_pair_padding __padding1_; 
\
+  [[no_unique_address]] T2 Initializer2;   
\
+  [[no_unique_address]] __compressed_pair_padding __padding2_; 
\
+  [[no_unique_address]] T3 Initializer3;   
\
+  [[no_unique_address]] __compressed_pair_padding __padding3_;
+#elif COMPRESSED_PAIR_REV == 2
+#define _LLDB_COMPRESSED_PAIR(T1, Name1, T2, Name2)
\
+  [[no_unique_address]] T1 Name1;  
\
+  [[no_unique_address]] T2 Name2
+
+#define _LLDB_COMPRESSED_TRIPLE(T1, Name1, T2, Name2, T3, Name3)   
\
+  [[no_unique_address]] T1 Name1;  
\
+  [[no_unique_address]] T2 Name2;  
\
+  [[no_unique_address]] T3 Name3
+#endif
 } // namespace __lldb
 } // namespace std
 
diff --git 
a/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx-simulators/string/TestDataFormatterLibcxxStringSimulator.py
 
b/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx-simulators/string/TestDataFormatterLibcxxStringSimulator.py
index 98d2c7320003e4..afe6374e55a355 100644
--- 
a/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx-simulators/string/TestDataFormatterLibcxxStringSimulator.py
+++ 
b/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx-simulators/string/TestDataFormatterLibcxxStringSimulator.py
@@ -28,12 +28,13 @@ def _run_test(self, defines):
 
 for v in [None, "ALTERNATE_LAYOUT"]:
 for r in range(5):
-name = "test_r%d" % r
-defines = ["REVISION=%d" % r]
-if v:
-name += "_" + v
-defines += [v]
-f = functools.partialmethod(
-LibcxxStringDataFormatterSimulatorTestCase._run_test, defines
-)
-setattr(LibcxxStringDataFormatterSimulatorTestCase, name, f)
+for c in range(3):
+name = "test_r%d_c%d" % (r, c)
+defines = ["REVISION=%d" % r, "COMPRESSED_PAIR_REV=%d" % c]
+if v:
+name += "_" + v
+defines += [v]
+f = functools.partialmethod(
+LibcxxStringDataFormatterSimulatorTestCase._run_test, defines
+)
+setattr(LibcxxStringDataFormatterSimulatorTestCase, name, f)
diff --git 
a/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx-simulators/string/

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

2024-09-16 Thread via lldb-commits


dlav-sc wrote:

@JDevlieghere @jasonmolenda @labath @tedwoodward could you take another look, 
please.

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

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

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


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

>From 88b48a5df0153a44276f14872c48e10639dcb673 Mon Sep 17 00:00:00 2001
From: Adrian Vogelsgesang 
Date: Wed, 14 Aug 2024 11:52:40 +
Subject: [PATCH 1/9] [lldb-dap] Support inspecting memory

Adds support for the `readMemory` request which allows VS-Code to
inspect memory. Also, add `memoryReference` to variablesa and `evaluate`
responses, such that the binary view can be opened from the variables
view and from the "watch" pane.
---
 .../test/tools/lldb-dap/dap_server.py |  13 ++
 lldb/test/API/tools/lldb-dap/memory/Makefile  |   3 +
 .../tools/lldb-dap/memory/TestDAP_memory.py   | 135 +
 lldb/test/API/tools/lldb-dap/memory/main.cpp  |  10 +
 lldb/tools/lldb-dap/JSONUtils.cpp |  29 ++-
 lldb/tools/lldb-dap/JSONUtils.h   |   6 +
 lldb/tools/lldb-dap/lldb-dap.cpp  | 177 +-
 7 files changed, 367 insertions(+), 6 deletions(-)
 create mode 100644 lldb/test/API/tools/lldb-dap/memory/Makefile
 create mode 100644 lldb/test/API/tools/lldb-dap/memory/TestDAP_memory.py
 create mode 100644 lldb/test/API/tools/lldb-dap/memory/main.cpp

diff --git a/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py 
b/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
index c6417760f17a2b..78c0f6233413b6 100644
--- a/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
+++ b/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
@@ -691,6 +691,19 @@ def request_disassemble(
 for inst in instructions:
 self.disassembled_instructions[inst["address"]] = inst
 
+def request_read_memory(self, memoryReference, offset, count):
+args_dict = {
+"memoryReference": memoryReference,
+"offset": offset,
+"count": count,
+}
+command_dict = {
+"command": "readMemory",
+"type": "request",
+"arguments": args_dict,
+}
+return self.send_recv(command_dict)
+
 def request_evaluate(self, expression, frameIndex=0, threadId=None, 
context=None):
 stackFrame = self.get_stackFrame(frameIndex=frameIndex, 
threadId=threadId)
 if stackFrame is None:
diff --git a/lldb/test/API/tools/lldb-dap/memory/Makefile 
b/lldb/test/API/tools/lldb-dap/memory/Makefile
new file mode 100644
index 00..8b20bcb050
--- /dev/null
+++ b/lldb/test/API/tools/lldb-dap/memory/Makefile
@@ -0,0 +1,3 @@
+CXX_SOURCES := main.cpp
+
+include Makefile.rules
diff --git a/lldb/test/API/tools/lldb-dap/memory/TestDAP_memory.py 
b/lldb/test/API/tools/lldb-dap/memory/TestDAP_memory.py
new file mode 100644
index 00..f950d5eecda671
--- /dev/null
+++ b/lldb/test/API/tools/lldb-dap/memory/TestDAP_memory.py
@@ -0,0 +1,135 @@
+"""
+Test lldb-dap memory support
+"""
+
+from base64 import b64decode
+import dap_server
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+import lldbdap_testcase
+import os
+
+
+class TestDAP_memory(lldbdap_testcase.DAPTestCaseBase):
+def test_read_memory(self):
+"""
+Tests the 'read_memory' request
+"""
+program = self.getBuildArtifact("a.out")
+self.build_and_launch(program)
+source = "main.cpp"
+self.source_path = os.path.join(os.getcwd(), source)
+self.set_source_breakpoints(
+source,
+[line_number(source, "// Breakpoint")],
+)
+self.continue_to_next_stop()
+
+locals = {l["name"]: l for l in self.dap_server.get_local_variables()}
+rawptr_ref = locals["rawptr"]["memoryReference"]
+
+# We can read the complete string
+mem = self.dap_server.request_read_memory(rawptr_ref, 0, 5)["body"]
+self.assertEqual(mem["unreadableBytes"], 0)
+self.assertEqual(b64decode(mem["data"]), b"dead\0")
+
+# Use an offset
+mem = self.dap_server.request_read_memory(rawptr_ref, 2, 3)["body"]
+self.assertEqual(b64decode(mem["data"]), b"ad\0")
+
+# Use a negative offset
+mem = self.dap_server.request_read_memory(rawptr_ref, -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_read_memory(rawptr_ref, 0, 0)
+self.assertEqual(mem["success"], True)
+self.assertEqual(mem["body"]["data"], "")
+
+# Reads at offset 0x0 fail
+mem = self.dap_server.request_read_memory("0x0", 0, 6)
+self.assertEqual(mem["success"], False)
+self.assertTrue(mem["message"].startswith("Unable to read memory: "))
+
+def test_memory_refs_variables(self):
+"""
+Tests memory references for evaluate
+"""
+

[Lldb-commits] [lldb] 765e106 - [lldb][test] Add a new __compressed_pair layout to libcxx simulator tests (#99012)

2024-09-16 Thread via lldb-commits


Author: Michael Buch
Date: 2024-09-16T13:46:19+01:00
New Revision: 765e106fb1b0e0aeb1bba18dfd93bd28233bba2f

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

LOG: [lldb][test] Add a new __compressed_pair layout to libcxx simulator tests 
(#99012)

This is a follow-up to https://github.com/llvm/llvm-project/pull/98330
for the upcoming `__compressed_pair` refactor in
https://github.com/llvm/llvm-project/issues/93069

This patch just adds the 2 new copies of `_LIBCPP_COMPRESSED_PAIR`
layouts to the simulator tests.

Added: 


Modified: 

lldb/packages/Python/lldbsuite/test/make/libcxx-simulators-common/compressed_pair.h

lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx-simulators/string/TestDataFormatterLibcxxStringSimulator.py

lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx-simulators/string/main.cpp

lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx-simulators/unique_ptr/TestDataFormatterLibcxxUniquePtrSimulator.py

lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx-simulators/unique_ptr/main.cpp

Removed: 




diff  --git 
a/lldb/packages/Python/lldbsuite/test/make/libcxx-simulators-common/compressed_pair.h
 
b/lldb/packages/Python/lldbsuite/test/make/libcxx-simulators-common/compressed_pair.h
index 026e7183ab27a0..89eafcec0ea962 100644
--- 
a/lldb/packages/Python/lldbsuite/test/make/libcxx-simulators-common/compressed_pair.h
+++ 
b/lldb/packages/Python/lldbsuite/test/make/libcxx-simulators-common/compressed_pair.h
@@ -7,7 +7,7 @@
 namespace std {
 namespace __lldb {
 
-// Post-c88580c layout
+#if COMPRESSED_PAIR_REV == 0 // Post-c88580c layout
 struct __value_init_tag {};
 struct __default_init_tag {};
 
@@ -52,6 +52,53 @@ class __compressed_pair : private 
__compressed_pair_elem<_T1, 0>,
 
   _T1 &first() { return static_cast<_Base1 &>(*this).__get(); }
 };
+#elif COMPRESSED_PAIR_REV == 1
+// From libc++ datasizeof.h
+template  struct _FirstPaddingByte {
+  [[no_unique_address]] _Tp __v_;
+  char __first_padding_byte_;
+};
+
+template 
+inline const size_t __datasizeof_v =
+__builtin_offsetof(_FirstPaddingByte<_Tp>, __first_padding_byte_);
+
+template 
+struct __lldb_is_final : public integral_constant {};
+
+template  class __compressed_pair_padding {
+  char __padding_[((is_empty<_ToPad>::value &&
+!__lldb_is_final<_ToPad>::value) ||
+   is_reference<_ToPad>::value)
+  ? 0
+  : sizeof(_ToPad) - __datasizeof_v<_ToPad>];
+};
+
+#define _LLDB_COMPRESSED_PAIR(T1, Initializer1, T2, Initializer2)  
\
+  [[__gnu__::__aligned__(alignof(T2))]] [[no_unique_address]] T1 Initializer1; 
\
+  [[no_unique_address]] __compressed_pair_padding __padding1_; 
\
+  [[no_unique_address]] T2 Initializer2;   
\
+  [[no_unique_address]] __compressed_pair_padding __padding2_;
+
+#define _LLDB_COMPRESSED_TRIPLE(T1, Initializer1, T2, Initializer2, T3,
\
+Initializer3)  
\
+  [[using __gnu__: __aligned__(alignof(T2)),   
\
+__aligned__(alignof(T3))]] [[no_unique_address]] T1 Initializer1;  
\
+  [[no_unique_address]] __compressed_pair_padding __padding1_; 
\
+  [[no_unique_address]] T2 Initializer2;   
\
+  [[no_unique_address]] __compressed_pair_padding __padding2_; 
\
+  [[no_unique_address]] T3 Initializer3;   
\
+  [[no_unique_address]] __compressed_pair_padding __padding3_;
+#elif COMPRESSED_PAIR_REV == 2
+#define _LLDB_COMPRESSED_PAIR(T1, Name1, T2, Name2)
\
+  [[no_unique_address]] T1 Name1;  
\
+  [[no_unique_address]] T2 Name2
+
+#define _LLDB_COMPRESSED_TRIPLE(T1, Name1, T2, Name2, T3, Name3)   
\
+  [[no_unique_address]] T1 Name1;  
\
+  [[no_unique_address]] T2 Name2;  
\
+  [[no_unique_address]] T3 Name3
+#endif
 } // namespace __lldb
 } // namespace std
 

diff  --git 
a/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx-simulators/string/TestDataFormatterLibcxxStringSimulator.py
 
b/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx-simulators/string/TestDataFormatterLibcxxStringSimulator.py
index 98d2c7320003e4..afe6374e55a355 100644
--- 
a/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx-simulators/string/TestDataFormatterLibcxxStringSimulator.py
+++ 
b/lldb/test/API/functionalities/data-formatter/data-formatt

[Lldb-commits] [lldb] [lldb][test] Add a new __compressed_pair layout to libcxx simulator tests (PR #99012)

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


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

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

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


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

>From 88b48a5df0153a44276f14872c48e10639dcb673 Mon Sep 17 00:00:00 2001
From: Adrian Vogelsgesang 
Date: Wed, 14 Aug 2024 11:52:40 +
Subject: [PATCH 01/10] [lldb-dap] Support inspecting memory

Adds support for the `readMemory` request which allows VS-Code to
inspect memory. Also, add `memoryReference` to variablesa and `evaluate`
responses, such that the binary view can be opened from the variables
view and from the "watch" pane.
---
 .../test/tools/lldb-dap/dap_server.py |  13 ++
 lldb/test/API/tools/lldb-dap/memory/Makefile  |   3 +
 .../tools/lldb-dap/memory/TestDAP_memory.py   | 135 +
 lldb/test/API/tools/lldb-dap/memory/main.cpp  |  10 +
 lldb/tools/lldb-dap/JSONUtils.cpp |  29 ++-
 lldb/tools/lldb-dap/JSONUtils.h   |   6 +
 lldb/tools/lldb-dap/lldb-dap.cpp  | 177 +-
 7 files changed, 367 insertions(+), 6 deletions(-)
 create mode 100644 lldb/test/API/tools/lldb-dap/memory/Makefile
 create mode 100644 lldb/test/API/tools/lldb-dap/memory/TestDAP_memory.py
 create mode 100644 lldb/test/API/tools/lldb-dap/memory/main.cpp

diff --git a/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py 
b/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
index c6417760f17a2b..78c0f6233413b6 100644
--- a/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
+++ b/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
@@ -691,6 +691,19 @@ def request_disassemble(
 for inst in instructions:
 self.disassembled_instructions[inst["address"]] = inst
 
+def request_read_memory(self, memoryReference, offset, count):
+args_dict = {
+"memoryReference": memoryReference,
+"offset": offset,
+"count": count,
+}
+command_dict = {
+"command": "readMemory",
+"type": "request",
+"arguments": args_dict,
+}
+return self.send_recv(command_dict)
+
 def request_evaluate(self, expression, frameIndex=0, threadId=None, 
context=None):
 stackFrame = self.get_stackFrame(frameIndex=frameIndex, 
threadId=threadId)
 if stackFrame is None:
diff --git a/lldb/test/API/tools/lldb-dap/memory/Makefile 
b/lldb/test/API/tools/lldb-dap/memory/Makefile
new file mode 100644
index 00..8b20bcb050
--- /dev/null
+++ b/lldb/test/API/tools/lldb-dap/memory/Makefile
@@ -0,0 +1,3 @@
+CXX_SOURCES := main.cpp
+
+include Makefile.rules
diff --git a/lldb/test/API/tools/lldb-dap/memory/TestDAP_memory.py 
b/lldb/test/API/tools/lldb-dap/memory/TestDAP_memory.py
new file mode 100644
index 00..f950d5eecda671
--- /dev/null
+++ b/lldb/test/API/tools/lldb-dap/memory/TestDAP_memory.py
@@ -0,0 +1,135 @@
+"""
+Test lldb-dap memory support
+"""
+
+from base64 import b64decode
+import dap_server
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+import lldbdap_testcase
+import os
+
+
+class TestDAP_memory(lldbdap_testcase.DAPTestCaseBase):
+def test_read_memory(self):
+"""
+Tests the 'read_memory' request
+"""
+program = self.getBuildArtifact("a.out")
+self.build_and_launch(program)
+source = "main.cpp"
+self.source_path = os.path.join(os.getcwd(), source)
+self.set_source_breakpoints(
+source,
+[line_number(source, "// Breakpoint")],
+)
+self.continue_to_next_stop()
+
+locals = {l["name"]: l for l in self.dap_server.get_local_variables()}
+rawptr_ref = locals["rawptr"]["memoryReference"]
+
+# We can read the complete string
+mem = self.dap_server.request_read_memory(rawptr_ref, 0, 5)["body"]
+self.assertEqual(mem["unreadableBytes"], 0)
+self.assertEqual(b64decode(mem["data"]), b"dead\0")
+
+# Use an offset
+mem = self.dap_server.request_read_memory(rawptr_ref, 2, 3)["body"]
+self.assertEqual(b64decode(mem["data"]), b"ad\0")
+
+# Use a negative offset
+mem = self.dap_server.request_read_memory(rawptr_ref, -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_read_memory(rawptr_ref, 0, 0)
+self.assertEqual(mem["success"], True)
+self.assertEqual(mem["body"]["data"], "")
+
+# Reads at offset 0x0 fail
+mem = self.dap_server.request_read_memory("0x0", 0, 6)
+self.assertEqual(mem["success"], False)
+self.assertTrue(mem["message"].startswith("Unable to read memory: "))
+
+def test_memory_refs_variables(self):
+"""
+Tests memory references for evaluate
+"""
+

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

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


vogelsgesang wrote:

@clayborg the code is now up-to-date and ready for another review 🙂 

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] [clang] [clang-tools-extra] [lld] [lldb] [llvm] [mlir] [polly] [NFC] Add explicit #include llvm-config.h where its macros are used. (PR #106810)

2024-09-16 Thread Daniil Fukalov via lldb-commits


dfukalov wrote:

Gentle ping...

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

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

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


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

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

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

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

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

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

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

2024-09-16 Thread via lldb-commits


llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Michael Buch (Michael137)


Changes

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

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

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


7 Files Affected:

- (modified) lldb/source/Target/VerboseTrapFrameRecognizer.cpp (+26-1) 
- (added) lldb/test/Shell/Recognizer/Inputs/verbose_trap-in-stl-callback.cpp 
(+22) 
- (added) lldb/test/Shell/Recognizer/Inputs/verbose_trap-in-stl-nested.cpp 
(+21) 
- (added) lldb/test/Shell/Recognizer/Inputs/verbose_trap-in-stl.cpp (+17) 
- (added) lldb/test/Shell/Recognizer/verbose_trap-in-stl-callback.test (+13) 
- (added) lldb/test/Shell/Recognizer/verbose_trap-in-stl-nested.test (+13) 
- (added) lldb/test/Shell/Recognizer/verbose_trap-in-stl.test (+13) 


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

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

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


https://github.com/Michael137 edited 
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-dap] Add feature to remember last non-empty expression. (PR #107485)

2024-09-16 Thread via lldb-commits



@@ -1376,6 +1382,16 @@ void request_evaluate(const llvm::json::Object &request) 
{
 EmplaceSafeString(body, "result", result);
 body.try_emplace("variablesReference", (int64_t)0);
   } else {
+if (context == "repl") {
+  // If the expression is empty and the last expression was for a
+  // variable, set the expression to the previous expression (repeat the
+  // evaluation); otherwise save the current non-empty expression for the
+  // next (possibly empty) variable expression.
+  if (expression.empty())
+expression = g_dap.last_nonempty_var_expression;

cmtice wrote:

Your description of the behavior is not correct.   last_nonempty_var_expression 
is now being used for two purposes: It both holds the last non-empty var 
expression IF-AND-ONLY-IF the last expression was a var expression; or it 
indicates that the last expression was a command, by being empty itself. Note 
the very first thing we do, unconditionally, when processing a command is to 
clear this variable.

When we receive an empty expression, we check to see if the most recent 
non-empty expression was a command (test to see if last_nonempty_var_expression 
is empty). If it was a command, then we pass the empty expression to the 
command interpreter. If the most recent non-empty expression was a variable 
expression (i.e. last_nonempty_var_expression is NOT empty), then we treat the 
empty expression as a variable expression, re-evalulating the contents of 
last_nonempty_var_expression.

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

[Lldb-commits] [lldb] [lldb][intel-pt] Fix build error on conversion from llvm::Error to Status::FromError (PR #108719)

2024-09-16 Thread Walter Erquinigo via lldb-commits


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


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

[Lldb-commits] [lldb] [lldb][intel-pt] Fix build error on conversion from llvm::Error to Status::FromError (PR #108719)

2024-09-16 Thread Walter Erquinigo via lldb-commits



@@ -78,7 +78,7 @@ bool CommandObjectThreadTraceStartIntelPT::DoExecuteOnThreads(
 llvm::ArrayRef tids) {
   if (Error err = m_trace.Start(tids, m_options.m_ipt_trace_size,
 m_options.m_enable_tsc, 
m_options.m_psb_period))
-result.SetError(Status(std::move(err)));
+result.SetError(Status::FromError(std::move(err)));

walter-erquinigo wrote:

just make sure that you really need to invoke std::move. It's possible that the 
compiler can do that on its own and that you don't need the explicit std::move

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

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

2024-09-16 Thread Louis Dionne via lldb-commits


https://github.com/ldionne commented:

I'm not qualified to review the implementation, but I like the result!

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

2024-09-16 Thread via lldb-commits



@@ -1364,8 +1364,14 @@ void request_evaluate(const llvm::json::Object &request) 
{
   std::string expression = GetString(arguments, "expression").str();
   llvm::StringRef context = GetString(arguments, "context");
 
-  if (context == "repl" && g_dap.DetectExpressionContext(frame, expression) ==
-   ExpressionContext::Command) {
+  if (context == "repl" &&
+  (expression.empty() ?
+   g_dap.last_nonempty_var_expression.empty() :
+   g_dap.DetectExpressionContext(frame, expression) ==

cmtice wrote:

I've done the best compromise I can -- I've created a new variable, 
'repeat_last_command' to use in the if-condition, and tried to set up the 
if-condition to avoid unnecessary calls to DetectExpressionContext.

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

2024-09-16 Thread 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.

dlav-sc wrote:

GDB RSP supports 2 types of error response packets: `E xx` and `E.errtext` 
(https://sourceware.org/gdb/current/onlinedocs/gdb.html/Standard-Replies.html#Standard-Replies),
 so it looks like the ability to send error strings should be available for all 
targets by default.

Could you consider a couple of my questions about the matter, please?
1. Taking into account what I've said above, why do we need 
`QEnableErrorStrings`?
2. Is there any function like `SendErrorRespond`, which takes a error string 
and forms `E.errtext` packet? To be honest, I couldn't find something like this.

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][intel-pt] Fix build error on conversion from llvm::Error to Status::FromError (PR #108719)

2024-09-16 Thread via lldb-commits


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

>From 9f41e2a32f1800a9d98a749cf109d9a3072e2210 Mon Sep 17 00:00:00 2001
From: Wanyi Ye 
Date: Sat, 14 Sep 2024 14:23:01 -0700
Subject: [PATCH] [lldb][intel-pt] Fix build error on conversion from
 llvm::Error to Status::FromError

Summary: This introduced from upstream #107163

Test Plan: I can build
---
 .../Plugins/Trace/intel-pt/CommandObjectTraceStartIntelPT.cpp | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git 
a/lldb/source/Plugins/Trace/intel-pt/CommandObjectTraceStartIntelPT.cpp 
b/lldb/source/Plugins/Trace/intel-pt/CommandObjectTraceStartIntelPT.cpp
index 81f7c228561a6d..ea28c3251d7472 100644
--- a/lldb/source/Plugins/Trace/intel-pt/CommandObjectTraceStartIntelPT.cpp
+++ b/lldb/source/Plugins/Trace/intel-pt/CommandObjectTraceStartIntelPT.cpp
@@ -78,7 +78,7 @@ bool CommandObjectThreadTraceStartIntelPT::DoExecuteOnThreads(
 llvm::ArrayRef tids) {
   if (Error err = m_trace.Start(tids, m_options.m_ipt_trace_size,
 m_options.m_enable_tsc, 
m_options.m_psb_period))
-result.SetError(Status(std::move(err)));
+result.SetError(std::move(err));
   else
 result.SetStatus(eReturnStatusSuccessFinishResult);
 
@@ -164,7 +164,7 @@ void CommandObjectProcessTraceStartIntelPT::DoExecute(
   m_options.m_ipt_trace_size, m_options.m_process_buffer_size_limit,
   m_options.m_enable_tsc, m_options.m_psb_period,
   m_options.m_per_cpu_tracing, m_options.m_disable_cgroup_filtering))
-result.SetError(Status(std::move(err)));
+result.SetError(std::move(err));
   else
 result.SetStatus(eReturnStatusSuccessFinishResult);
 }

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

[Lldb-commits] [lldb] [lldb][intel-pt] Fix build error on conversion from llvm::Error to Status::FromError (PR #108719)

2024-09-16 Thread Jacob Lalonde via lldb-commits


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


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

2024-09-16 Thread via lldb-commits


cmtice wrote:

Ping? Anybody?

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

2024-09-16 Thread 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

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

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


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

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.

>From f0ffdc6f1d999dc3c774f1d42d03db286705c1b5 Mon Sep 17 00:00:00 2001
From: Adrian Vogelsgesang 
Date: Tue, 27 Aug 2024 17:34:11 +
Subject: [PATCH] [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 3651e52ed77a75..f48d65ee0e753b 100644
--- a/libcxx/docs/UserDocumentation.rst
+++ b/libcxx/docs/UserDocumentation.rst
@@ -343,6 +343,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:
   LibCXXFrameReco

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

2024-09-16 Thread via lldb-commits


llvmbot wrote:



@llvm/pr-subscribers-lldb

@llvm/pr-subscribers-libcxx

Author: Adrian Vogelsgesang (vogelsgesang)


Changes

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.

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


5 Files Affected:

- (modified) libcxx/docs/UserDocumentation.rst (+26) 
- (modified) 
lldb/source/Plugins/LanguageRuntime/CPlusPlus/CPPLanguageRuntime.cpp (+8-19) 
- (added) lldb/test/API/lang/cpp/libcxx-internals-recognizer/Makefile (+5) 
- (added) 
lldb/test/API/lang/cpp/libcxx-internals-recognizer/TestLibcxxInternalsRecognizer.py
 (+56) 
- (added) lldb/test/API/lang/cpp/libcxx-internals-recognizer/main.cpp (+86) 


``diff
diff --git a/libcxx/docs/UserDocumentation.rst 
b/libcxx/docs/UserDocumentation.rst
index 3651e52ed77a75..f48d65ee0e753b 100644
--- a/libcxx/docs/UserDocumentation.rst
+++ b/libcxx/docs/UserDocumentation.rst
@@ -343,6 +343,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.
-  R"(__function::.*::__call_impl)"},
-// internal implementation details of std::invoke
-//   std::__1::__invoke[abi:ne20]
-RegularExpression{
-  R"(^std::__[^:]*::)" // Namespace.
-  R"(__invoke)"},
-// internal implemen

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

2024-09-16 Thread via lldb-commits


github-actions[bot] wrote:




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



You can test this locally with the following command:


``bash
darker --check --diff -r 
6d3f6c2170dd60e86743c205e33ead2f455656b4...f0ffdc6f1d999dc3c774f1d42d03db286705c1b5
 
lldb/test/API/lang/cpp/libcxx-internals-recognizer/TestLibcxxInternalsRecognizer.py
``





View the diff from darker here.


``diff
--- TestLibcxxInternalsRecognizer.py2024-09-16 18:44:07.00 +
+++ TestLibcxxInternalsRecognizer.py2024-09-16 18:50:00.862835 +
@@ -21,18 +21,26 @@
 # which unfortunately means that there is no `std::ranges::sort`
 # stack frame, and `main` is the direct parent of `my_less_ranges`.
 "ranges_sort_less(int, int)": ["test_algorithms"],
 # `ranges::views::transform` internally uses `std::invoke`, and 
that
 # call also shows up in the stack trace
-"view_transform(int)": ["::invoke", "ranges::transform_view", 
"test_algorithms"],
+"view_transform(int)": [
+"::invoke",
+"ranges::transform_view",
+"test_algorithms",
+],
 # Various types of `invoke` calls
 "consume_number(int)": ["::invoke", "test_invoke"],
 "invoke_add(int, int)": ["::invoke", "test_invoke"],
 "Callable::member_function(int) const": ["::invoke", 
"test_invoke"],
 "Callable::operator()(int) const": ["::invoke", "test_invoke"],
 # Containers
-"MyKey::operator<(MyKey const&) const": ["less", "::emplace", 
"test_containers"],
+"MyKey::operator<(MyKey const&) const": [
+"less",
+"::emplace",
+"test_containers",
+],
 }
 stop_set = set()
 while process.GetState() != lldb.eStateExited:
 fn = thread.GetFrameAtIndex(0).GetFunctionName()
 stop_set.add(fn)

``




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] Fix some tests that fail with system libstdc++ (PR #106885)

2024-09-16 Thread Tobias Hieta via lldb-commits


tru wrote:

/cherry-pick adf44d5c3ea03569f019740e1140c3205810b3fa 
2bcab9ba7139cfa96c85433fa85b29c8a6d7008b

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

[Lldb-commits] [lldb] lldb: get lldb API tests working with newer Android NDKs (PR #106443)

2024-09-16 Thread Andrew Rogers via lldb-commits


andrurogerz wrote:

@labath there have been no additional comments; is there anyone specifically 
you'd like me to seek feedback from?

@JDevlieghere would you have a moment to take a look at this PR soon? I really 
appreciate it.

@compnerd FYI

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

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

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


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

Thanks for doing the modification. LGTM

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: get lldb API tests working with newer Android NDKs (PR #106443)

2024-09-16 Thread Saleem Abdulrasool via lldb-commits



@@ -1,81 +1,59 @@
 NDK_ROOT := $(shell dirname $(CC))/../../../../..
 
-ifeq "$(findstring 64, $(ARCH))" "64"
-   # lowest 64-bit API level
-   API_LEVEL := 21
-else ifeq "$(ARCH)" "i386"
-   # clone(2) declaration is present only since this api level
-   API_LEVEL := 17
+ifeq "$(HOST_OS)" "Linux"
+   HOST_TAG := linux-x86_64
+else ifeq "$(HOST_OS)" "Darwin"
+   HOST_TAG := darwin-x86_64
 else
-   # lowest supported 32-bit API level
-   API_LEVEL := 16
+   HOST_TAG := windows-x86_64
+endif
+
+TOOLCHAIN_ROOT := $(NDK_ROOT)/toolchains/llvm/prebuilt/$(HOST_TAG)
+TOOLCHAIN_SYSROOT := $(TOOLCHAIN_ROOT)/sysroot
+
+OBJCOPY ?= $(TOOLCHAIN_ROOT)/bin/llvm-objcopy
+ARCHIVER ?= $(TOOLCHAIN_ROOT)/bin/llvm-ar
+
+ifeq "$(wildcard $(TOOLCHAIN_SYSROOT)/.)" ""
+# Compiling test inferiors for Android requires an NDK with the unified
+# toolchain introduced in version r19.
+$(error "No unified toolchain sysroot found in $(NDK_ROOT). NDK must be r19 or 
later.")
 endif
 
 ifeq "$(ARCH)" "arm"
-   SYSROOT_ARCH := arm
-   STL_ARCH := armeabi-v7a
TRIPLE := armv7-none-linux-androideabi
ARCH_CFLAGS += -march=armv7-a -mfloat-abi=softfp -mfpu=vfpv3-d16 -marm
 else ifeq "$(ARCH)" "aarch64"
-   SYSROOT_ARCH := arm64
-   STL_ARCH := arm64-v8a
TRIPLE := aarch64-none-linux-android
 else ifeq "$(ARCH)" "i386"
-   SYSROOT_ARCH := x86
-   STL_ARCH := x86
TRIPLE := i686-none-linux-android
 else
-   SYSROOT_ARCH := $(ARCH)
-   STL_ARCH := $(ARCH)
TRIPLE := $(ARCH)-none-linux-android
 endif
 
-ifeq "$(findstring 86,$(ARCH))" "86"
-   TOOLCHAIN_DIR := $(STL_ARCH)-4.9
-else ifeq "$(ARCH)" "arm"
-   TOOLCHAIN_DIR := arm-linux-androideabi-4.9
-else
-   TOOLCHAIN_DIR := $(subst -none,,$(TRIPLE))-4.9
-endif
+# lowest 64-bit API level
+API_LEVEL := 21

compnerd wrote:

This is Android 5.0, Lollipop, which has ~99.6% adoption as per 
https://apilevels.com/. Additionally, this is from 2014, which is still 10 
years ago.

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

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

2024-09-16 Thread Louis Dionne via lldb-commits


https://github.com/ldionne commented:

This feels like a good idea, but I am also a bit scared of hiding too much 
stuff and making it difficult to figure out what's going wrong from a stack 
trace. It's not rational, I have no evidence to back this up and perhaps this 
is only fear of unknown.

Factually, the heuristic of using `__` makes sense to me since all 
implementation-detail functions start with `__`, and nothing in the public 
libc++ API starts with `__` (off the top of my head).

Overall, I think I like this patch but like I said I'm a bit scared of it being 
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] [lldb] 3acb1ea - [lldb-dap] Support inspecting memory (#104317)

2024-09-16 Thread via lldb-commits


Author: Adrian Vogelsgesang
Date: 2024-09-16T22:56:20+02:00
New Revision: 3acb1eac5eb6ef4e60dd64b7845615e076cc6a3e

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

LOG: [lldb-dap] Support inspecting memory (#104317)

Add support for the `readMemory` request which allows VS-Code to
inspect memory. Also, add `memoryReference` to variables and `evaluate`
responses, such that the binary view can be opened from the variables
view and from the "watch" pane.

Added: 
lldb/test/API/tools/lldb-dap/memory/Makefile
lldb/test/API/tools/lldb-dap/memory/TestDAP_memory.py
lldb/test/API/tools/lldb-dap/memory/main.cpp

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

Removed: 




diff  --git a/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py 
b/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
index c6417760f17a2b..d6a386975c8fb9 100644
--- a/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
+++ b/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
@@ -691,6 +691,19 @@ def request_disassemble(
 for inst in instructions:
 self.disassembled_instructions[inst["address"]] = inst
 
+def request_readMemory(self, memoryReference, offset, count):
+args_dict = {
+"memoryReference": memoryReference,
+"offset": offset,
+"count": count,
+}
+command_dict = {
+"command": "readMemory",
+"type": "request",
+"arguments": args_dict,
+}
+return self.send_recv(command_dict)
+
 def request_evaluate(self, expression, frameIndex=0, threadId=None, 
context=None):
 stackFrame = self.get_stackFrame(frameIndex=frameIndex, 
threadId=threadId)
 if stackFrame is None:

diff  --git a/lldb/test/API/tools/lldb-dap/memory/Makefile 
b/lldb/test/API/tools/lldb-dap/memory/Makefile
new file mode 100644
index 00..8b20bcb050
--- /dev/null
+++ b/lldb/test/API/tools/lldb-dap/memory/Makefile
@@ -0,0 +1,3 @@
+CXX_SOURCES := main.cpp
+
+include Makefile.rules

diff  --git a/lldb/test/API/tools/lldb-dap/memory/TestDAP_memory.py 
b/lldb/test/API/tools/lldb-dap/memory/TestDAP_memory.py
new file mode 100644
index 00..8bee70e50dcad9
--- /dev/null
+++ b/lldb/test/API/tools/lldb-dap/memory/TestDAP_memory.py
@@ -0,0 +1,116 @@
+"""
+Test lldb-dap memory support
+"""
+
+from base64 import b64decode
+import dap_server
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+import lldbdap_testcase
+import os
+
+
+class TestDAP_memory(lldbdap_testcase.DAPTestCaseBase):
+def test_memory_refs_variables(self):
+"""
+Tests memory references for evaluate
+"""
+program = self.getBuildArtifact("a.out")
+self.build_and_launch(program)
+source = "main.cpp"
+self.source_path = os.path.join(os.getcwd(), source)
+self.set_source_breakpoints(
+source,
+[line_number(source, "// Breakpoint")],
+)
+self.continue_to_next_stop()
+
+locals = {l["name"]: l for l in self.dap_server.get_local_variables()}
+
+# Pointers should have memory-references
+self.assertIn("memoryReference", locals["rawptr"].keys())
+# Non-pointers should also have memory-references
+self.assertIn("memoryReference", locals["not_a_ptr"].keys())
+
+def test_memory_refs_evaluate(self):
+"""
+Tests memory references for evaluate
+"""
+program = self.getBuildArtifact("a.out")
+self.build_and_launch(program)
+source = "main.cpp"
+self.source_path = os.path.join(os.getcwd(), source)
+self.set_source_breakpoints(
+source,
+[line_number(source, "// Breakpoint")],
+)
+self.continue_to_next_stop()
+
+self.assertIn(
+"memoryReference",
+self.dap_server.request_evaluate("rawptr")["body"].keys(),
+)
+
+def test_memory_refs_set_variable(self):
+"""
+Tests memory references for `setVariable`
+"""
+program = self.getBuildArtifact("a.out")
+self.build_and_launch(program)
+source = "main.cpp"
+self.source_path = os.path.join(os.getcwd(), source)
+self.set_source_breakpoints(
+source,
+[line_number(source, "// Breakpoint")],
+)
+self.continue_to_next_stop()
+
+ptr_value = self.get_local_as_int("rawptr")
+self.assertIn(
+"memoryReference",
+

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

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


https://github.com/vogelsgesang closed 
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] Change the implementation of Status to store an llvm::Error (NFC) (PR #106774)

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


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

>From 141b8cec8c266c7857c38e5da76ab538ac35c706 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 208acb43a0febb9195ee89a5ef17626ec639c6a9 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 --
 lldb/unittests/Utility/StatusTest.cpp |   8 +
 4 files changed, 266 insertions(+), 101 deletions(-)

diff --git a/lldb/include/lldb/Utility/Status.h 
b/lldb/include/lldb/Utility/Status.h
index 795c830b965173..64e193f8d84206 100644
--- a/lldb/include/lldb/Utility/Status.h
+++ b/lldb/include/lldb/Utility/Status.h
@@ -28,6 +28,67 @@ namespace lldb_private {
 
 const char *ExpressionResultAsCString(lldb::Express

[Lldb-commits] [lldb] [LLDB] Add AST node classes, functions, etc. for Data Inspection Lang… (PR #95738)

2024-09-16 Thread 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?

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][Minidump] Add a progress bar to minidump (PR #108309)

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


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


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

[Lldb-commits] [lldb] 0975e2a - [LLDB][Minidump] Add a progress bar to minidump (#108309)

2024-09-16 Thread via lldb-commits


Author: Jacob Lalonde
Date: 2024-09-16T15:13:35-07:00
New Revision: 0975e2ac58b6d62429d51df54911fb4d03dcda05

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

LOG: [LLDB][Minidump] Add a progress bar to minidump (#108309)

Added a progress tracker to Minidump file builders memory saving

Added: 


Modified: 
lldb/include/lldb/Target/CoreFileMemoryRanges.h
lldb/source/Plugins/ObjectFile/Minidump/MinidumpFileBuilder.cpp
lldb/source/Plugins/ObjectFile/Minidump/MinidumpFileBuilder.h

Removed: 




diff  --git a/lldb/include/lldb/Target/CoreFileMemoryRanges.h 
b/lldb/include/lldb/Target/CoreFileMemoryRanges.h
index 503ecd691e5948..0cc5433525ddc4 100644
--- a/lldb/include/lldb/Target/CoreFileMemoryRanges.h
+++ b/lldb/include/lldb/Target/CoreFileMemoryRanges.h
@@ -8,6 +8,7 @@
 
 #include "lldb/Utility/RangeMap.h"
 #include "lldb/Utility/Status.h"
+#include "lldb/Utility/StreamString.h"
 
 #include "llvm/ADT/AddressRanges.h"
 
@@ -35,6 +36,16 @@ struct CoreFileMemoryRange {
   return lldb_permissions < rhs.lldb_permissions;
 return false;
   }
+
+  std::string Dump() const {
+lldb_private::StreamString stream;
+stream << "[";
+stream.PutHex64(range.start());
+stream << '-';
+stream.PutHex64(range.end());
+stream << ")";
+return stream.GetString().str();
+  }
 };
 
 class CoreFileMemoryRanges

diff  --git a/lldb/source/Plugins/ObjectFile/Minidump/MinidumpFileBuilder.cpp 
b/lldb/source/Plugins/ObjectFile/Minidump/MinidumpFileBuilder.cpp
index ca22dacb2ba6c9..3f1e25f730a184 100644
--- a/lldb/source/Plugins/ObjectFile/Minidump/MinidumpFileBuilder.cpp
+++ b/lldb/source/Plugins/ObjectFile/Minidump/MinidumpFileBuilder.cpp
@@ -837,15 +837,17 @@ Status MinidumpFileBuilder::AddMemoryList() {
   error = m_process_sp->CalculateCoreFileSaveRanges(m_save_core_options,
 all_core_memory_ranges);
 
+  if (error.Fail())
+return error;
+
+  lldb_private::Progress progress("Saving Minidump File", "",
+  all_core_memory_ranges.GetSize());
   std::vector all_core_memory_vec;
   // Extract all the data into just a vector of data. So we can mutate this in
   // place.
   for (const auto &core_range : all_core_memory_ranges)
 all_core_memory_vec.push_back(core_range.data);
 
-  if (error.Fail())
-return error;
-
   // Start by saving all of the stacks and ensuring they fit under the 32b
   // limit.
   uint64_t total_size = GetCurrentDataEndOffset();
@@ -892,13 +894,13 @@ Status MinidumpFileBuilder::AddMemoryList() {
 }
   }
 
-  error = AddMemoryList_32(ranges_32);
+  error = AddMemoryList_32(ranges_32, progress);
   if (error.Fail())
 return error;
 
   // Add the remaining memory as a 64b range.
   if (!ranges_64.empty()) {
-error = AddMemoryList_64(ranges_64);
+error = AddMemoryList_64(ranges_64, progress);
 if (error.Fail())
   return error;
   }
@@ -972,8 +974,9 @@ GetLargestRangeSize(const std::vector 
&ranges) {
   return max_size;
 }
 
-Status MinidumpFileBuilder::AddMemoryList_32(
-std::vector &ranges) {
+Status
+MinidumpFileBuilder::AddMemoryList_32(std::vector &ranges,
+  Progress &progress) {
   std::vector descriptors;
   Status error;
   if (ranges.size() == 0)
@@ -996,6 +999,7 @@ Status MinidumpFileBuilder::AddMemoryList_32(
   region_index, ranges.size(), size, addr, addr + size);
 ++region_index;
 
+progress.Increment(1, "Adding Memory Range " + core_range.Dump());
 const size_t bytes_read =
 m_process_sp->ReadMemory(addr, data_up->GetBytes(), size, error);
 if (error.Fail() || bytes_read == 0) {
@@ -1049,8 +1053,9 @@ Status MinidumpFileBuilder::AddMemoryList_32(
   return error;
 }
 
-Status MinidumpFileBuilder::AddMemoryList_64(
-std::vector &ranges) {
+Status
+MinidumpFileBuilder::AddMemoryList_64(std::vector &ranges,
+  Progress &progress) {
   Status error;
   if (ranges.empty())
 return error;
@@ -,6 +1116,7 @@ Status MinidumpFileBuilder::AddMemoryList_64(
   region_index, ranges.size(), size, addr, addr + size);
 ++region_index;
 
+progress.Increment(1, "Adding Memory Range " + core_range.Dump());
 const size_t bytes_read =
 m_process_sp->ReadMemory(addr, data_up->GetBytes(), size, error);
 if (error.Fail()) {

diff  --git a/lldb/source/Plugins/ObjectFile/Minidump/MinidumpFileBuilder.h 
b/lldb/source/Plugins/ObjectFile/Minidump/MinidumpFileBuilder.h
index 72e5658718b3c4..d5eac9015ac422 100644
--- a/lldb/source/Plugins/ObjectFile/Minidump/MinidumpFileBuilder.h
+++ b/lldb/source/Plugins/ObjectFile/Minidump/MinidumpFileBuilder.h
@@ -23,6 +23,7 @@
 #include 
 #include

[Lldb-commits] [lldb] [LLDB][Minidump] Add a progress bar to minidump (PR #108309)

2024-09-16 Thread Jacob Lalonde via lldb-commits


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

[Lldb-commits] [lldb] [lldb] Support frame recognizer regexp on mangled names. (PR #105756)

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


vogelsgesang wrote:

@adrian-prantl Now that https://github.com/llvm/llvm-project/pull/105695 is 
merged, do you still want to open a follow-up pull request to change the 
assert-recognizer and the verbose-trap-recognizer to use `ePreferMangled`?

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

[Lldb-commits] [lldb] [lldb-dap] Provide `declarationLocation` for variables (PR #102928)

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


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


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

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

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


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

>From 34a856d47322cd35a7b568a335adbcd804f2302d Mon Sep 17 00:00:00 2001
From: Pavel Labath 
Date: Wed, 11 Sep 2024 10:35:37 +0200
Subject: [PATCH 1/3] [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 f89d0b6311d3c5c3a659d5ff6a5f733c32e57ad0 Mon Sep 17 00:00:00 2001
From: Adrian Prantl 
Date: Wed, 4 Sep 2024 12:50:37 -0700
Subject: [PATCH 2/3] [lldb] Change the implementation of Status to store an
 llvm::Error (NFC)

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

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

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

Implementation notes:

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

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

diff --git a/lldb/include/lldb/Utility/Status.h 
b/lldb/include/lldb/Utility/Status.h
index 795c830b965173..64e193f8d84206 100644
--- a/lldb/include/lldb/Utility/Status.h
+++ b/lldb/include/lldb/Utility/Status.h
@@ -28,6 +28,67 @@ namespace lldb_private {
 
 const char *ExpressionResultAsCString(lldb::Express

[Lldb-commits] [lldb] [lldb-dap] Provide `declarationLocation` for variables (PR #102928)

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


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

>From 7dfcc909b97efe61e3af8bb9468ddc973f19b52d Mon Sep 17 00:00:00 2001
From: Adrian Vogelsgesang 
Date: Sat, 10 Aug 2024 23:59:55 +
Subject: [PATCH] [lldb-dap] Implement declaration locations

This commit implements support for the "declaration location" recently
added by microsoft/debug-adapter-protocol#494 to the debug adapter
protocol.

For the `declarationLocationReference` we need a variable ID similar to
the the `variablesReference`. I decided to simply reuse the
`variablesReference` here and renamed `Variables::expandable_variables`
and friends accordingly. Given that almost all variables have a
declaration location, we now assign those variable ids to all variables.

While `declarationLocationReference` effectively supersedes
`$__lldb_extensions.declaration`, I did not remove this extension, yet,
since I assume that there are some closed-source extensions which rely
on it.

I tested this against VS-Code Insiders. However, VS-Code Insiders
currently only supports `valueLoctionReference` and not
`declarationLocationReference`, yet. Locally, I hence published
the declaration locations as value locations, and VS Code Insiders
navigated to the expected places. Looking forward to proper VS Code
support for `declarationLocationReference`.
---
 .../test/tools/lldb-dap/dap_server.py |  11 ++
 .../API/tools/lldb-dap/locations/Makefile |   3 +
 .../lldb-dap/locations/TestDAP_locations.py   |  40 +
 lldb/test/API/tools/lldb-dap/locations/main.c |   5 +
 lldb/tools/lldb-dap/DAP.cpp   |  17 +-
 lldb/tools/lldb-dap/DAP.h |  10 +-
 lldb/tools/lldb-dap/JSONUtils.cpp | 127 ---
 lldb/tools/lldb-dap/JSONUtils.h   |  31 ++--
 lldb/tools/lldb-dap/lldb-dap.cpp  | 146 +++---
 9 files changed, 288 insertions(+), 102 deletions(-)
 create mode 100644 lldb/test/API/tools/lldb-dap/locations/Makefile
 create mode 100644 lldb/test/API/tools/lldb-dap/locations/TestDAP_locations.py
 create mode 100644 lldb/test/API/tools/lldb-dap/locations/main.c

diff --git a/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py 
b/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
index d6a386975c8fb9..bbd701efa3a666 100644
--- a/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
+++ b/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
@@ -1109,6 +1109,17 @@ def request_setVariable(self, containingVarRef, name, 
value, id=None):
 }
 return self.send_recv(command_dict)
 
+def request_locations(self, locationReference):
+args_dict = {
+"locationReference": locationReference,
+}
+command_dict = {
+"command": "locations",
+"type": "request",
+"arguments": args_dict,
+}
+return self.send_recv(command_dict)
+
 def request_testGetTargetBreakpoints(self):
 """A request packet used in the LLDB test suite to get all currently
 set breakpoint infos for all breakpoints currently set in the
diff --git a/lldb/test/API/tools/lldb-dap/locations/Makefile 
b/lldb/test/API/tools/lldb-dap/locations/Makefile
new file mode 100644
index 00..10495940055b63
--- /dev/null
+++ b/lldb/test/API/tools/lldb-dap/locations/Makefile
@@ -0,0 +1,3 @@
+C_SOURCES := main.c
+
+include Makefile.rules
diff --git a/lldb/test/API/tools/lldb-dap/locations/TestDAP_locations.py 
b/lldb/test/API/tools/lldb-dap/locations/TestDAP_locations.py
new file mode 100644
index 00..76d938d3908492
--- /dev/null
+++ b/lldb/test/API/tools/lldb-dap/locations/TestDAP_locations.py
@@ -0,0 +1,40 @@
+"""
+Test lldb-dap locations request
+"""
+
+
+import dap_server
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+import lldbdap_testcase
+import os
+
+
+class TestDAP_locations(lldbdap_testcase.DAPTestCaseBase):
+@skipIfWindows
+def test_locations(self):
+"""
+Tests the 'locations' request.
+"""
+program = self.getBuildArtifact("a.out")
+self.build_and_launch(program)
+source = "main.c"
+self.source_path = os.path.join(os.getcwd(), source)
+self.set_source_breakpoints(
+source,
+[line_number(source, "// BREAK HERE")],
+)
+self.continue_to_next_stop()
+
+locals = {l["name"]: l for l in self.dap_server.get_local_variables()}
+
+# var1 has a declarationLocation but no valueLocation
+self.assertIn("declarationLocationReference", locals["var1"].keys())
+self.assertNotIn("valueLocationReference", locals["var1"].keys())
+loc_var1 = self.dap_server.request_locations(
+locals["var1"]["declarationLocationReference"]
+)
+self.assertTrue(loc_var1["success"])
+self.as

[Lldb-commits] [lldb] [lldb] Inline expression evaluator error visualization (PR #106470)

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


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

>From 34a856d47322cd35a7b568a335adbcd804f2302d Mon Sep 17 00:00:00 2001
From: Pavel Labath 
Date: Wed, 11 Sep 2024 10:35:37 +0200
Subject: [PATCH 1/4] [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 f89d0b6311d3c5c3a659d5ff6a5f733c32e57ad0 Mon Sep 17 00:00:00 2001
From: Adrian Prantl 
Date: Wed, 4 Sep 2024 12:50:37 -0700
Subject: [PATCH 2/4] [lldb] Change the implementation of Status to store an
 llvm::Error (NFC)

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

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

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

Implementation notes:

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

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

diff --git a/lldb/include/lldb/Utility/Status.h 
b/lldb/include/lldb/Utility/Status.h
index 795c830b965173..64e193f8d84206 100644
--- a/lldb/include/lldb/Utility/Status.h
+++ b/lldb/include/lldb/Utility/Status.h
@@ -28,6 +28,67 @@ namespace lldb_private {
 
 const char *ExpressionResultAsCString(lldb::Express

[Lldb-commits] [lldb] [lldb-dap] Provide `declarationLocation` for variables (PR #102928)

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


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

[Lldb-commits] [lldb] 0cc2cd7 - [lldb-dap] Provide `declarationLocation` for variables (#102928)

2024-09-16 Thread via lldb-commits


Author: Adrian Vogelsgesang
Date: 2024-09-17T02:18:52+02:00
New Revision: 0cc2cd781594aec741f7262df7a48d73a7d09a18

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

LOG: [lldb-dap] Provide `declarationLocation` for variables (#102928)

This commit implements support for the "declaration location" recently
added by microsoft/debug-adapter-protocol#494 to the debug adapter
protocol.

For the `declarationLocationReference` we need a variable ID similar to
the `variablesReference`. I decided to simply reuse the
`variablesReference` here and renamed `Variables::expandable_variables`
and friends accordingly. Given that almost all variables have a
declaration location, we now assign those variable ids to all variables.

While `declarationLocationReference` effectively supersedes
`$__lldb_extensions.declaration`, I did not remove this extension, yet,
since I assume that there are some closed-source extensions which rely
on it.

I tested this against VS-Code Insiders. However, VS-Code Insiders
currently only supports `valueLoctionReference` and not
`declarationLocationReference`, yet. Locally, I hence published the
declaration locations as value locations, and VS Code Insiders navigated
to the expected places. Looking forward to proper VS Code support for
`declarationLocationReference`.

Added: 
lldb/test/API/tools/lldb-dap/locations/Makefile
lldb/test/API/tools/lldb-dap/locations/TestDAP_locations.py
lldb/test/API/tools/lldb-dap/locations/main.c

Modified: 
lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
lldb/tools/lldb-dap/DAP.cpp
lldb/tools/lldb-dap/DAP.h
lldb/tools/lldb-dap/JSONUtils.cpp
lldb/tools/lldb-dap/JSONUtils.h
lldb/tools/lldb-dap/lldb-dap.cpp

Removed: 




diff  --git a/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py 
b/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
index d6a386975c8fb9..bbd701efa3a666 100644
--- a/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
+++ b/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
@@ -1109,6 +1109,17 @@ def request_setVariable(self, containingVarRef, name, 
value, id=None):
 }
 return self.send_recv(command_dict)
 
+def request_locations(self, locationReference):
+args_dict = {
+"locationReference": locationReference,
+}
+command_dict = {
+"command": "locations",
+"type": "request",
+"arguments": args_dict,
+}
+return self.send_recv(command_dict)
+
 def request_testGetTargetBreakpoints(self):
 """A request packet used in the LLDB test suite to get all currently
 set breakpoint infos for all breakpoints currently set in the

diff  --git a/lldb/test/API/tools/lldb-dap/locations/Makefile 
b/lldb/test/API/tools/lldb-dap/locations/Makefile
new file mode 100644
index 00..10495940055b63
--- /dev/null
+++ b/lldb/test/API/tools/lldb-dap/locations/Makefile
@@ -0,0 +1,3 @@
+C_SOURCES := main.c
+
+include Makefile.rules

diff  --git a/lldb/test/API/tools/lldb-dap/locations/TestDAP_locations.py 
b/lldb/test/API/tools/lldb-dap/locations/TestDAP_locations.py
new file mode 100644
index 00..76d938d3908492
--- /dev/null
+++ b/lldb/test/API/tools/lldb-dap/locations/TestDAP_locations.py
@@ -0,0 +1,40 @@
+"""
+Test lldb-dap locations request
+"""
+
+
+import dap_server
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+import lldbdap_testcase
+import os
+
+
+class TestDAP_locations(lldbdap_testcase.DAPTestCaseBase):
+@skipIfWindows
+def test_locations(self):
+"""
+Tests the 'locations' request.
+"""
+program = self.getBuildArtifact("a.out")
+self.build_and_launch(program)
+source = "main.c"
+self.source_path = os.path.join(os.getcwd(), source)
+self.set_source_breakpoints(
+source,
+[line_number(source, "// BREAK HERE")],
+)
+self.continue_to_next_stop()
+
+locals = {l["name"]: l for l in self.dap_server.get_local_variables()}
+
+# var1 has a declarationLocation but no valueLocation
+self.assertIn("declarationLocationReference", locals["var1"].keys())
+self.assertNotIn("valueLocationReference", locals["var1"].keys())
+loc_var1 = self.dap_server.request_locations(
+locals["var1"]["declarationLocationReference"]
+)
+self.assertTrue(loc_var1["success"])
+self.assertTrue(loc_var1["body"]["source"]["path"].endswith("main.c"))
+self.assertEqual(loc_var1["body"]["line"], 2)

diff  --git a/lldb/test/API/tools/lldb-dap/locations/main.c 
b/lldb/test/

[Lldb-commits] [lldb] [lldb-dap] Provide `declarationLocation` for variables (PR #102928)

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


llvm-ci wrote:

LLVM Buildbot has detected a new failure on builder `fuchsia-x86_64-linux` 
running on `fuchsia-debian-64-us-central1-a-1` while building `lldb` at step 4 
"annotate".

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


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

```
Step 4 (annotate) failure: 'python 
../llvm-zorg/zorg/buildbot/builders/annotated/fuchsia-linux.py ...' (failure)
...
[681/1327] Building CXX object 
unittests/ADT/CMakeFiles/ADTTests.dir/RewriteBufferTest.cpp.o
clang++: warning: optimization flag '-ffat-lto-objects' is not supported 
[-Wignored-optimization-argument]
[682/1327] Linking CXX executable bin/yaml2obj
[682/1327] Running lld test suite
llvm-lit: 
/var/lib/buildbot/fuchsia-x86_64-linux/llvm-project/llvm/utils/lit/lit/llvm/config.py:506:
 note: using ld.lld: 
/var/lib/buildbot/fuchsia-x86_64-linux/build/llvm-build-jsnop3cw/bin/ld.lld
llvm-lit: 
/var/lib/buildbot/fuchsia-x86_64-linux/llvm-project/llvm/utils/lit/lit/llvm/config.py:506:
 note: using lld-link: 
/var/lib/buildbot/fuchsia-x86_64-linux/build/llvm-build-jsnop3cw/bin/lld-link
llvm-lit: 
/var/lib/buildbot/fuchsia-x86_64-linux/llvm-project/llvm/utils/lit/lit/llvm/config.py:506:
 note: using ld64.lld: 
/var/lib/buildbot/fuchsia-x86_64-linux/build/llvm-build-jsnop3cw/bin/ld64.lld
llvm-lit: 
/var/lib/buildbot/fuchsia-x86_64-linux/llvm-project/llvm/utils/lit/lit/llvm/config.py:506:
 note: using wasm-ld: 
/var/lib/buildbot/fuchsia-x86_64-linux/build/llvm-build-jsnop3cw/bin/wasm-ld
-- Testing: 2982 tests, 60 workers --
Testing:  0.. 10
FAIL: lld :: ELF/aarch64-adrp-ldr-got.s (468 of 2982)
 TEST 'lld :: ELF/aarch64-adrp-ldr-got.s' FAILED 

Exit Code: 1

Command Output (stderr):
--
RUN: at line 2: rm -rf 
/var/lib/buildbot/fuchsia-x86_64-linux/build/llvm-build-jsnop3cw/tools/lld/test/ELF/Output/aarch64-adrp-ldr-got.s.tmp
 && split-file 
/var/lib/buildbot/fuchsia-x86_64-linux/llvm-project/lld/test/ELF/aarch64-adrp-ldr-got.s
 
/var/lib/buildbot/fuchsia-x86_64-linux/build/llvm-build-jsnop3cw/tools/lld/test/ELF/Output/aarch64-adrp-ldr-got.s.tmp
+ rm -rf 
/var/lib/buildbot/fuchsia-x86_64-linux/build/llvm-build-jsnop3cw/tools/lld/test/ELF/Output/aarch64-adrp-ldr-got.s.tmp
+ split-file 
/var/lib/buildbot/fuchsia-x86_64-linux/llvm-project/lld/test/ELF/aarch64-adrp-ldr-got.s
 
/var/lib/buildbot/fuchsia-x86_64-linux/build/llvm-build-jsnop3cw/tools/lld/test/ELF/Output/aarch64-adrp-ldr-got.s.tmp
RUN: at line 4: 
/var/lib/buildbot/fuchsia-x86_64-linux/build/llvm-build-jsnop3cw/bin/llvm-mc 
-filetype=obj -triple=aarch64 
/var/lib/buildbot/fuchsia-x86_64-linux/build/llvm-build-jsnop3cw/tools/lld/test/ELF/Output/aarch64-adrp-ldr-got.s.tmp/a.s
 -o 
/var/lib/buildbot/fuchsia-x86_64-linux/build/llvm-build-jsnop3cw/tools/lld/test/ELF/Output/aarch64-adrp-ldr-got.s.tmp/a.o
+ /var/lib/buildbot/fuchsia-x86_64-linux/build/llvm-build-jsnop3cw/bin/llvm-mc 
-filetype=obj -triple=aarch64 
/var/lib/buildbot/fuchsia-x86_64-linux/build/llvm-build-jsnop3cw/tools/lld/test/ELF/Output/aarch64-adrp-ldr-got.s.tmp/a.s
 -o 
/var/lib/buildbot/fuchsia-x86_64-linux/build/llvm-build-jsnop3cw/tools/lld/test/ELF/Output/aarch64-adrp-ldr-got.s.tmp/a.o
RUN: at line 5: 
/var/lib/buildbot/fuchsia-x86_64-linux/build/llvm-build-jsnop3cw/bin/llvm-mc 
-filetype=obj -triple=aarch64 
/var/lib/buildbot/fuchsia-x86_64-linux/build/llvm-build-jsnop3cw/tools/lld/test/ELF/Output/aarch64-adrp-ldr-got.s.tmp/unpaired.s
 -o 
/var/lib/buildbot/fuchsia-x86_64-linux/build/llvm-build-jsnop3cw/tools/lld/test/ELF/Output/aarch64-adrp-ldr-got.s.tmp/unpaired.o
+ /var/lib/buildbot/fuchsia-x86_64-linux/build/llvm-build-jsnop3cw/bin/llvm-mc 
-filetype=obj -triple=aarch64 
/var/lib/buildbot/fuchsia-x86_64-linux/build/llvm-build-jsnop3cw/tools/lld/test/ELF/Output/aarch64-adrp-ldr-got.s.tmp/unpaired.s
 -o 
/var/lib/buildbot/fuchsia-x86_64-linux/build/llvm-build-jsnop3cw/tools/lld/test/ELF/Output/aarch64-adrp-ldr-got.s.tmp/unpaired.o
RUN: at line 6: 
/var/lib/buildbot/fuchsia-x86_64-linux/build/llvm-build-jsnop3cw/bin/llvm-mc 
-filetype=obj -triple=aarch64 
/var/lib/buildbot/fuchsia-x86_64-linux/build/llvm-build-jsnop3cw/tools/lld/test/ELF/Output/aarch64-adrp-ldr-got.s.tmp/lone-ldr.s
 -o 
/var/lib/buildbot/fuchsia-x86_64-linux/build/llvm-build-jsnop3cw/tools/lld/test/ELF/Output/aarch64-adrp-ldr-got.s.tmp/lone-ldr.o
+ /var/lib/buildbot/fuchsia-x86_64-linux/build/llvm-build-jsnop3cw/bin/llvm-mc 
-filetype=obj -triple=aarch64 
/var/lib/buildbot/fuchsia-x86_64-linux/build/llvm-build-jsnop3cw/tools/lld/test/ELF/Output/aarch64-adrp-ldr-got.s.tmp/lone-ldr.s
 -o 
/var/lib/buildbot/fuchsia-x86_64-linux/build/llvm-build-jsnop3cw/tools/lld/test/ELF/Output/aarch64-adrp-ldr-got.s.tmp/lone-ldr.o
RUN: at line 8: 
/var/lib/buildbot/fuchsia-x86_64-linux/build/llvm-build-jsnop3cw/bin/ld.lld 
/var/lib/buildbot/fuchsia-x86_64-linux/build/llvm-build-jsnop3cw/tools/lld/test/ELF/Output/aarch64-adrp-ldr-got.s.tmp/a.o
 -T 
/var/

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

2024-09-16 Thread via lldb-commits


https://github.com/jeffreytan81 created 
https://github.com/llvm/llvm-project/pull/108907

## Context
We have a customer reporting scenario that expanding "this" pointer for a 
non-trivial class method context takes more than **70~90 seconds**. This is a 
linux target with .debug_names index table enabled and split dwarf dwo files. 

Profiling shows the majority of the bottleneck is spent in 
`SymbolFileDWARF::FindTypes()` and `SymbolFileDWARF:: FindNamespace()` two 
functions searching types/namespaces in .debug_names index table with base 
name, then parsing/loading the underlying dwo files which can be very slow. 

## Context
This PR improves `SymbolFileDWARF::FindTypes()` and `SymbolFileDWARF:: 
FindNamespace()` by using the newly added parent chain in .debug_names. 

>From 6e84ab9a14e63c58e1facdbf9a695c093882b37b Mon Sep 17 00:00:00 2001
From: jeffreytan81 
Date: Mon, 19 Aug 2024 10:57:35 -0700
Subject: [PATCH 1/4] Fix StartDebuggingRequestHandler/ReplModeRequestHandler
 in lldb-dap

---
 lldb/tools/lldb-dap/DAP.h| 2 --
 lldb/tools/lldb-dap/lldb-dap.cpp | 4 ++--
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/lldb/tools/lldb-dap/DAP.h b/lldb/tools/lldb-dap/DAP.h
index 57562a14983519..7828272aa15a7d 100644
--- a/lldb/tools/lldb-dap/DAP.h
+++ b/lldb/tools/lldb-dap/DAP.h
@@ -192,8 +192,6 @@ struct DAP {
   std::mutex call_mutex;
   std::map
   inflight_reverse_requests;
-  StartDebuggingRequestHandler start_debugging_request_handler;
-  ReplModeRequestHandler repl_mode_request_handler;
   ReplMode repl_mode;
   std::string command_escape_prefix = "`";
   lldb::SBFormat frame_format;
diff --git a/lldb/tools/lldb-dap/lldb-dap.cpp b/lldb/tools/lldb-dap/lldb-dap.cpp
index ea84f31aec3a6c..f50a6c17310739 100644
--- a/lldb/tools/lldb-dap/lldb-dap.cpp
+++ b/lldb/tools/lldb-dap/lldb-dap.cpp
@@ -1627,12 +1627,12 @@ void request_initialize(const llvm::json::Object 
&request) {
   "lldb-dap", "Commands for managing lldb-dap.");
   if (GetBoolean(arguments, "supportsStartDebuggingRequest", false)) {
 cmd.AddCommand(
-"startDebugging", &g_dap.start_debugging_request_handler,
+"startDebugging", new StartDebuggingRequestHandler(),
 "Sends a startDebugging request from the debug adapter to the client "
 "to start a child debug session of the same type as the caller.");
   }
   cmd.AddCommand(
-  "repl-mode", &g_dap.repl_mode_request_handler,
+  "repl-mode", new ReplModeRequestHandler(),
   "Get or set the repl behavior of lldb-dap evaluation requests.");
 
   g_dap.progress_event_thread = std::thread(ProgressEventThreadFunction);

>From 30e8b1870004ae6ca9319680f6ef16e173415026 Mon Sep 17 00:00:00 2001
From: jeffreytan81 
Date: Mon, 16 Sep 2024 12:02:48 -0700
Subject: [PATCH 2/4] Improve type/namespace lookup using parent chain

---
 .../Plugins/SymbolFile/DWARF/DWARFIndex.cpp   |  59 ++
 .../Plugins/SymbolFile/DWARF/DWARFIndex.h |  22 ++
 .../SymbolFile/DWARF/DebugNamesDWARFIndex.cpp | 168 +--
 .../SymbolFile/DWARF/DebugNamesDWARFIndex.h   |  29 +++
 .../SymbolFile/DWARF/SymbolFileDWARF.cpp  | 192 +++---
 .../SymbolFile/DWARF/SymbolFileDWARF.h|   2 +
 6 files changed, 385 insertions(+), 87 deletions(-)

diff --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFIndex.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFIndex.cpp
index eafddbad03f57b..7bdea4eae4529b 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFIndex.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFIndex.cpp
@@ -126,3 +126,62 @@ bool DWARFIndex::GetFullyQualifiedTypeImpl(
 return callback(die);
   return true;
 }
+
+void DWARFIndex::GetNamespacesWithParents(
+ConstString name, llvm::ArrayRef parent_names,
+llvm::function_ref callback) {
+  GetNamespaces(name, [&](DWARFDIE die) {
+return ProcessDieMatchParentNames(name, parent_names, die, callback);
+  });
+}
+
+void DWARFIndex::GetTypesWithParents(
+ConstString name, llvm::ArrayRef parent_names,
+llvm::function_ref callback) {
+  GetTypes(name, [&](DWARFDIE die) {
+return ProcessDieMatchParentNames(name, parent_names, die, callback);
+  });
+}
+
+bool DWARFIndex::ProcessDieMatchParentNames(
+ConstString name, llvm::ArrayRef query_parent_names,
+DWARFDIE die, llvm::function_ref callback) {
+  std::vector type_context =
+  die.GetTypeLookupContext();
+  if (type_context.empty()) {
+// If both type_context and query_parent_names and empty we have a match.
+// Otherwise, this one does not match and we keep on searching. 
+if (query_parent_names.empty())
+  return callback(die);
+return true;
+  }
+
+  // Type lookup context includes the current DIE as the last element.
+  // so revert it for easy matching.
+  std::reverse(type_context.begin(), type_context.end());
+
+  // type_context includes the name of the current DIE while query_parent_names
+  // doesn't. So start check from index 1 for dwarf_decl_ctx.
+  uint32_t i =

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

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


jasonmolenda wrote:

Thanks so much for putting together the patch for this.  Yeah enabling these 
registers only when the thread flavor is available is not that simple, and I 
don't think the consequence of including them with zero values in all cases is 
bad one.  Most general users will not be aware of what these registers indicate 
and ignore the 0's, and those people who are working on code where they are 
important, will see values for them, it seems fine to me.  I played around on 
an intel mac and the only side effect was that you'll get an error message if 
you try to modify one of the new registers when the thread state is not 
supported -- not a big surprise.  (`DNBArchImplX86_64::SetRegisterValue` will 
return an error if the full_state flavor was unavailable earlier in the debug 
session)

Do you have the permissions to merge this PR yourself?  I can do it if not.

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

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

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


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


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

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

2024-09-16 Thread 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] Improve type and namespace lookup using parent chain (PR #108907)

2024-09-16 Thread via lldb-commits


https://github.com/jeffreytan81 updated 
https://github.com/llvm/llvm-project/pull/108907

>From 6e84ab9a14e63c58e1facdbf9a695c093882b37b Mon Sep 17 00:00:00 2001
From: jeffreytan81 
Date: Mon, 19 Aug 2024 10:57:35 -0700
Subject: [PATCH 1/5] Fix StartDebuggingRequestHandler/ReplModeRequestHandler
 in lldb-dap

---
 lldb/tools/lldb-dap/DAP.h| 2 --
 lldb/tools/lldb-dap/lldb-dap.cpp | 4 ++--
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/lldb/tools/lldb-dap/DAP.h b/lldb/tools/lldb-dap/DAP.h
index 57562a14983519..7828272aa15a7d 100644
--- a/lldb/tools/lldb-dap/DAP.h
+++ b/lldb/tools/lldb-dap/DAP.h
@@ -192,8 +192,6 @@ struct DAP {
   std::mutex call_mutex;
   std::map
   inflight_reverse_requests;
-  StartDebuggingRequestHandler start_debugging_request_handler;
-  ReplModeRequestHandler repl_mode_request_handler;
   ReplMode repl_mode;
   std::string command_escape_prefix = "`";
   lldb::SBFormat frame_format;
diff --git a/lldb/tools/lldb-dap/lldb-dap.cpp b/lldb/tools/lldb-dap/lldb-dap.cpp
index ea84f31aec3a6c..f50a6c17310739 100644
--- a/lldb/tools/lldb-dap/lldb-dap.cpp
+++ b/lldb/tools/lldb-dap/lldb-dap.cpp
@@ -1627,12 +1627,12 @@ void request_initialize(const llvm::json::Object 
&request) {
   "lldb-dap", "Commands for managing lldb-dap.");
   if (GetBoolean(arguments, "supportsStartDebuggingRequest", false)) {
 cmd.AddCommand(
-"startDebugging", &g_dap.start_debugging_request_handler,
+"startDebugging", new StartDebuggingRequestHandler(),
 "Sends a startDebugging request from the debug adapter to the client "
 "to start a child debug session of the same type as the caller.");
   }
   cmd.AddCommand(
-  "repl-mode", &g_dap.repl_mode_request_handler,
+  "repl-mode", new ReplModeRequestHandler(),
   "Get or set the repl behavior of lldb-dap evaluation requests.");
 
   g_dap.progress_event_thread = std::thread(ProgressEventThreadFunction);

>From 30e8b1870004ae6ca9319680f6ef16e173415026 Mon Sep 17 00:00:00 2001
From: jeffreytan81 
Date: Mon, 16 Sep 2024 12:02:48 -0700
Subject: [PATCH 2/5] Improve type/namespace lookup using parent chain

---
 .../Plugins/SymbolFile/DWARF/DWARFIndex.cpp   |  59 ++
 .../Plugins/SymbolFile/DWARF/DWARFIndex.h |  22 ++
 .../SymbolFile/DWARF/DebugNamesDWARFIndex.cpp | 168 +--
 .../SymbolFile/DWARF/DebugNamesDWARFIndex.h   |  29 +++
 .../SymbolFile/DWARF/SymbolFileDWARF.cpp  | 192 +++---
 .../SymbolFile/DWARF/SymbolFileDWARF.h|   2 +
 6 files changed, 385 insertions(+), 87 deletions(-)

diff --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFIndex.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFIndex.cpp
index eafddbad03f57b..7bdea4eae4529b 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFIndex.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFIndex.cpp
@@ -126,3 +126,62 @@ bool DWARFIndex::GetFullyQualifiedTypeImpl(
 return callback(die);
   return true;
 }
+
+void DWARFIndex::GetNamespacesWithParents(
+ConstString name, llvm::ArrayRef parent_names,
+llvm::function_ref callback) {
+  GetNamespaces(name, [&](DWARFDIE die) {
+return ProcessDieMatchParentNames(name, parent_names, die, callback);
+  });
+}
+
+void DWARFIndex::GetTypesWithParents(
+ConstString name, llvm::ArrayRef parent_names,
+llvm::function_ref callback) {
+  GetTypes(name, [&](DWARFDIE die) {
+return ProcessDieMatchParentNames(name, parent_names, die, callback);
+  });
+}
+
+bool DWARFIndex::ProcessDieMatchParentNames(
+ConstString name, llvm::ArrayRef query_parent_names,
+DWARFDIE die, llvm::function_ref callback) {
+  std::vector type_context =
+  die.GetTypeLookupContext();
+  if (type_context.empty()) {
+// If both type_context and query_parent_names and empty we have a match.
+// Otherwise, this one does not match and we keep on searching. 
+if (query_parent_names.empty())
+  return callback(die);
+return true;
+  }
+
+  // Type lookup context includes the current DIE as the last element.
+  // so revert it for easy matching.
+  std::reverse(type_context.begin(), type_context.end());
+
+  // type_context includes the name of the current DIE while query_parent_names
+  // doesn't. So start check from index 1 for dwarf_decl_ctx.
+  uint32_t i = 1, j = 0;
+  while (i < type_context.size() && j < query_parent_names.size()) {
+// If type_context[i] has no name, skip it.
+// e.g. this can happen for anonymous namespaces.
+if (type_context[i].name.IsNull() || type_context[i].name.IsEmpty()) {
+  ++i;
+  continue;
+}
+// If the name doesn't match, skip it.
+// e.g. this can happen for inline namespaces.
+if (query_parent_names[j] != type_context[i].name) {
+  ++i;
+  continue;
+}
+++i;
+++j;
+  }
+  // If not all query_parent_names were found in type_context.
+  // This die does not meet the criteria, try next one.
+  if (j != query_parent_names.size())
+return true;
+

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

2024-09-16 Thread via lldb-commits


https://github.com/jeffreytan81 ready_for_review 
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] Improve type and namespace lookup using parent chain (PR #108907)

2024-09-16 Thread via lldb-commits


llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: None (jeffreytan81)


Changes

## Context
We have a customer reporting scenario that expanding "this" pointer for a 
non-trivial class method context takes more than **70~90 seconds**. This is a 
linux target with .debug_names index table enabled and using split dwarf dwo 
files to avoid debug info overflow.

Profiling shows the majority of the bottleneck is spent in 
`SymbolFileDWARF::FindTypes()` and `SymbolFileDWARF:: FindNamespace()` two 
functions searching types/namespaces in .debug_names index table with base 
name, then parsing/loading the underlying dwo files which can be very slow. 

## Summary
This PR improves `SymbolFileDWARF::FindTypes()` and 
`SymbolFileDWARF::FindNamespace()` by using the newly added parent chain 
`DW_IDX_parent` in .debug_names. The proposal is originally discussed in [this 
RFC](https://discourse.llvm.org/t/rfc-improve-dwarf-5-debug-names-type-lookup-parsing-speed/74151).
 

This PR also implements a new algorithm in 
`DebugNamesDWARFIndex::SameAsEntryATName()` that can greatly avoid parsing the 
dwo files.

## Implementation
To leverage parent chain for `SymbolFileDWARF::FindTypes` and 
`SymbolFileDWARF:: FindNamespace`, the PR adds two new APIs 
`GetTypesWithParents` and `GetNamespacesWithParents` in `DWARFIndex` base 
class. These two APIs are performing the same semantics as 
`GetTypes/GetNamespaces` with extra filtering if `parent_names` parameter is 
not empty. Since only filtering is performed, the callback to all the callsites 
are not changed. A default implementation in DWARFIndex class is implemented to 
parse type context from each base name matched DIE. In `DebugNameDWARFIndex` 
override, it uses parent chain to perform much faster searching. 

Unlike `GetFullyQualifiedType` API which is the first one consuming 
`DW_IDX_parent` parent chain, these two new APIs do not perform exact matching, 
other than partial subset matching for the type/namespace queries. This is 
required to support anonymous/inline namespace queries from client. For 
example, users may ask for `NS1::NS2::NS3::Foo` while index table's parent 
chain may contain `NS1::inline_NS2::NS3::Foo` which would fail the exact 
matching. 

Another optimization performed is inside 
`DebugNamesDWARFIndex::SameAsEntryATName()`. The old implementation uses 
`GetNonSkeletonUnit()` which triggers parsing/loading of underlying dwo files 
which proves to be very expensive which we want to avoid. The new 
implementation tries to avoid touching dwo as much as possible. There are two 
ideas: 
1. Build ` NameEntry>` mapping table (built lazily 
as needed apparently), then we can query check the name of the parent entry.
2. Searching the name the entry tries to match from current `NameIndex`, then 
check if the parent entry can be found from the name entry. 

Per my testing/profiling, the 1) does not seem to improve wall-time because the 
cost to build the mapping table can be high. 2) has proved to be very fast. 

## Performance result
* [The other landed PR](https://github.com/llvm/llvm-project/pull/108414) 
reduces user's scenario wall-time from 70s => 50s 
* Using `GetTypesWithParents/GetNamespacesWithParents` reduces 50s => 13s
* Using the new algorithm to avoid touching dwo files in 
`DebugNamesDWARFIndex::SameAsEntryATName()` reduces 13s => 1.4s

Overall, these changes reduce from **70s => 1.4s**




---

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


6 Files Affected:

- (modified) lldb/source/Plugins/SymbolFile/DWARF/DWARFIndex.cpp (+59) 
- (modified) lldb/source/Plugins/SymbolFile/DWARF/DWARFIndex.h (+22) 
- (modified) lldb/source/Plugins/SymbolFile/DWARF/DebugNamesDWARFIndex.cpp 
(+151-14) 
- (modified) lldb/source/Plugins/SymbolFile/DWARF/DebugNamesDWARFIndex.h (+30) 
- (modified) lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp (+107-73) 
- (modified) lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h (+2) 


``diff
diff --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFIndex.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFIndex.cpp
index eafddbad03f57b..3101b1e137fbf3 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFIndex.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFIndex.cpp
@@ -126,3 +126,62 @@ bool DWARFIndex::GetFullyQualifiedTypeImpl(
 return callback(die);
   return true;
 }
+
+void DWARFIndex::GetNamespacesWithParents(
+ConstString name, llvm::ArrayRef parent_names,
+llvm::function_ref callback) {
+  GetNamespaces(name, [&](DWARFDIE die) {
+return ProcessDieMatchParentNames(name, parent_names, die, callback);
+  });
+}
+
+void DWARFIndex::GetTypesWithParents(
+ConstString name, llvm::ArrayRef parent_names,
+llvm::function_ref callback) {
+  GetTypes(name, [&](DWARFDIE die) {
+return ProcessDieMatchParentNames(name, parent_names, die, callback);
+  });
+}
+
+bool DWARFIndex::ProcessDieMatc

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

2024-09-16 Thread 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: get lldb API tests working with newer Android NDKs (PR #106443)

2024-09-16 Thread Saleem Abdulrasool via lldb-commits


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


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

[Lldb-commits] [lldb] [lldb-dap] Provide `declarationLocation` for variables (PR #102928)

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


vogelsgesang wrote:

The above test failure above is in `lld`, not `lldb`. I don't see how this 
could have been caused by my change to `lldb-dap`

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

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

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


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

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

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

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

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

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

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

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

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


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

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

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


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

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

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

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

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

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

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

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

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


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

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

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


vogelsgesang wrote:

Now that #102928 landed, this commit is also ready for review

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

88 matches

Mail list logo