date:20250203

[Lldb-commits] [lldb] [lldb] Make ValueObjectDynamicValue::UpdateValue() point to a host b… (PR #125143)

2025-02-03 Thread Augusto Noronha via lldb-commits


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

>From 0c22a94214e97146b2592b77ac96255bdee47b0f Mon Sep 17 00:00:00 2001
From: Augusto Noronha 
Date: Thu, 30 Jan 2025 16:33:09 -0800
Subject: [PATCH 1/2] [lldb] Make ValueObjectDynamicValue::UpdateValue() point
 to  a host buffer

ValueObjectDynamicValue::UpdateValue() assumes that the dynamic type
found by GetDynamicTypeAndAddress() would return an address in the
inferior.  This commit makes it so it can deal with being passed a
host address instead.

This is needed downstream by the Swift fork.

rdar://143357274
---
 lldb/include/lldb/Target/LanguageRuntime.h|  4 +++-
 .../ValueObject/ValueObjectDynamicValue.cpp   | 24 ++-
 2 files changed, 21 insertions(+), 7 deletions(-)

diff --git a/lldb/include/lldb/Target/LanguageRuntime.h 
b/lldb/include/lldb/Target/LanguageRuntime.h
index 4a0214b04e235e..08db8a17a67e69 100644
--- a/lldb/include/lldb/Target/LanguageRuntime.h
+++ b/lldb/include/lldb/Target/LanguageRuntime.h
@@ -105,7 +105,9 @@ class LanguageRuntime : public Runtime, public 
PluginInterface {
 "language doesn't support getting vtable information");
   }
 
-  // this call should return true if it could set the name and/or the type
+  // This call should return true if it could set the name and/or the type.
+  // address can be either a legitimate address on the inferior, or an address
+  // in lldb, if value_type == HostAddress.
   virtual bool GetDynamicTypeAndAddress(ValueObject &in_value,
 lldb::DynamicValueType use_dynamic,
 TypeAndOrName &class_type_or_name,
diff --git a/lldb/source/ValueObject/ValueObjectDynamicValue.cpp 
b/lldb/source/ValueObject/ValueObjectDynamicValue.cpp
index 588c644bbfd07b..10a5a9d0b76919 100644
--- a/lldb/source/ValueObject/ValueObjectDynamicValue.cpp
+++ b/lldb/source/ValueObject/ValueObjectDynamicValue.cpp
@@ -239,11 +239,19 @@ bool ValueObjectDynamicValue::UpdateValue() {
 if (m_address.IsValid())
   SetValueDidChange(true);
 
-// We've moved, so we should be fine...
-m_address = dynamic_address;
-lldb::TargetSP target_sp(GetTargetSP());
-lldb::addr_t load_address = m_address.GetLoadAddress(target_sp.get());
-m_value.GetScalar() = load_address;
+// If we found a host address, point to the buffer in host memory.
+// Later on this function will copy the buffer over.
+if (value_type == Value::ValueType::HostAddress) {
+  m_value.GetScalar() = dynamic_address.GetOffset();
+  m_address = LLDB_INVALID_ADDRESS;
+} else {
+  // Otherwise we have a legitimate address on the target. Point to the 
load
+  // address.
+  m_address = dynamic_address;
+  lldb::TargetSP target_sp(GetTargetSP());
+  lldb::addr_t load_address = m_address.GetLoadAddress(target_sp.get());
+  m_value.GetScalar() = load_address;
+}
   }
 
   if (runtime)
@@ -258,7 +266,11 @@ bool ValueObjectDynamicValue::UpdateValue() {
 LLDB_LOGF(log, "[%s %p] has a new dynamic type %s", GetName().GetCString(),
   static_cast(this), GetTypeName().GetCString());
 
-  if (m_address.IsValid() && m_dynamic_type_info) {
+  // m_address could be invalid but we could still have a local buffer
+  // containing the dynamic value.
+  if ((m_address.IsValid() ||
+   m_value.GetValueType() == Value::ValueType::HostAddress) &&
+  m_dynamic_type_info) {
 // The variable value is in the Scalar value inside the m_value. We can
 // point our m_data right to it.
 m_error = m_value.GetValueAsData(&exe_ctx, m_data, GetModule().get());

>From 64eb2c0365daf780a0e372c0fcbd9e4023c6a518 Mon Sep 17 00:00:00 2001
From: Augusto Noronha 
Date: Mon, 3 Feb 2025 11:23:41 -0800
Subject: [PATCH 2/2] Added a new local_buffer parameter to
 GetDynamicTypeAndAddress

---
 lldb/include/lldb/Target/LanguageRuntime.h   | 16 
 lldb/include/lldb/ValueObject/ValueObject.h  | 12 
 .../ItaniumABI/ItaniumABILanguageRuntime.cpp |  2 +-
 .../ItaniumABI/ItaniumABILanguageRuntime.h   |  4 ++--
 .../ObjC/AppleObjCRuntime/AppleObjCRuntime.cpp   |  2 +-
 .../ObjC/AppleObjCRuntime/AppleObjCRuntime.h |  4 ++--
 .../ObjC/AppleObjCRuntime/AppleObjCRuntimeV1.cpp |  2 +-
 .../ObjC/AppleObjCRuntime/AppleObjCRuntimeV1.h   |  4 ++--
 .../ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp |  2 +-
 .../ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.h   |  4 ++--
 .../GNUstepObjCRuntime/GNUstepObjCRuntime.cpp|  2 +-
 .../ObjC/GNUstepObjCRuntime/GNUstepObjCRuntime.h |  4 ++--
 lldb/source/ValueObject/ValueObject.cpp  | 16 
 .../ValueObject/ValueObjectDynamicValue.cpp  | 13 +++--
 14 files changed, 58 insertions(+), 29 deletions(-)

diff --git a/lldb/include/lldb/Target/LanguageRuntime.h 
b/lldb/include/lldb/Target/LanguageRuntime.h
index 08db8a17a67e69..da7b4801be6691 100644
--- a/lldb/include/lldb/Targ

[Lldb-commits] [lldb] a3321ea - [LLDB][Documentation] Add a doc string to sbprocess to show MemoryRegions is iterable (#125557)

2025-02-03 Thread via lldb-commits


Author: Jacob Lalonde
Date: 2025-02-03T11:26:03-08:00
New Revision: a3321ea5d60f10ee1abe03fa95b08095ced61c76

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

LOG: [LLDB][Documentation] Add a doc string to sbprocess to show MemoryRegions 
is iterable (#125557)

My colleague, @lukejriddle made the SBMemoryRegionList object iterable
in #117358. This isn't documented anywhere and so I added a blurb about
it to SBProcess.

Added: 


Modified: 
lldb/bindings/interface/SBProcessDocstrings.i

Removed: 




diff  --git a/lldb/bindings/interface/SBProcessDocstrings.i 
b/lldb/bindings/interface/SBProcessDocstrings.i
index 1b98a79e4f6d36..b5b22052a60944 100644
--- a/lldb/bindings/interface/SBProcessDocstrings.i
+++ b/lldb/bindings/interface/SBProcessDocstrings.i
@@ -258,3 +258,14 @@ SBProcess supports thread iteration. For example (from 
test/lldbutil.py), ::
 Deallocates the block of memory (previously allocated using
 AllocateMemory) given in the argument."
 ) lldb::SBProcess::DeallocateMemory;
+
+%feature("docstring", "
+Get a list of all the memory regions associated with this process.
+```
+readable_regions = []
+for region in process.GetMemoryRegions():
+if region.IsReadable():
+readable_regions.append(region)
+```
+"
+) lldb::SBProcess::GetMemoryRegions;



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

[Lldb-commits] [lldb] [LLDB][Documentation] Add a doc string to sbprocess to show MemoryRegions is iterable (PR #125557)

2025-02-03 Thread Jacob Lalonde via lldb-commits


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

[Lldb-commits] [lldb] [lldb] correct event when removing all watchpoints (PR #125312)

2025-02-03 Thread Jonas Devlieghere via lldb-commits


JDevlieghere wrote:

@puremourning Let me know if you need someone to press the Merge button for 
you. 

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

[Lldb-commits] [lldb] [lldb] Implement bidirectional access for backing<->backed thread relationship (PR #125300)

2025-02-03 Thread Felipe de Azevedo Piovezan via lldb-commits


felipepiovezan wrote:

Turns out github has been stuck for ours without picking up my pushed fixup 
commit :/ 
https://github.com/user-attachments/assets/ef97e7b5-acd2-4812-a258-f3030615d51c";
 />


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

[Lldb-commits] [lldb] [lldb] Make ValueObjectDynamicValue::UpdateValue() point to a host b… (PR #125143)

2025-02-03 Thread Augusto Noronha via lldb-commits


augusto2112 wrote:

Jim I updated the PR.

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

[Lldb-commits] [lldb] [lldb] Make ValueObjectDynamicValue::UpdateValue() point to a host b… (PR #125143)

2025-02-03 Thread via lldb-commits


jimingham wrote:

What are the ownership rules for that reference to bytes that you are passing 
out?  Who's keeping it alive and for how long?

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

[Lldb-commits] [lldb] [lldb] Implement bidirectional access for backing<->backed thread relationship (PR #125300)

2025-02-03 Thread Felipe de Azevedo Piovezan via lldb-commits


felipepiovezan wrote:

> Reference in new issue



> This creates a shared_pointer loop between the two objects, which doesn't 
> sound like a good design. Maybe one of the pointers ought to be weak?

great catch!, I'll fix that

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

[Lldb-commits] [lldb] [lldb] Support CommandInterpreter print callbacks (PR #125006)

2025-02-03 Thread Pavel Labath via lldb-commits


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

Thanks for the explanation. I understand what you mean now. The feature sounds 
cool, and the implementation sort of makes sense (sort of, because the 
HandleCommand idea is still "sort of" running around my head, but I do see how 
it could be very difficult to achieve that with it).

I do have my doubts about embedding the command string into the return object, 
but it sounds like the thought had occurred to at least two of you 
independently, so if you all think that's the best direction, then I guess I'm 
outvoted.

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

[Lldb-commits] [lldb] e269c2b - [lldb] Show value for libcxx and libstdcxx summary and remove pointer value in libcxx container summary (#125294)

2025-02-03 Thread via lldb-commits


Author: Zequan Wu
Date: 2025-02-03T14:34:20-05:00
New Revision: e269c2b5fa592498984cc381914bc65da377b08d

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

LOG: [lldb] Show value for libcxx and libstdcxx summary and remove pointer 
value in libcxx container summary (#125294)

This has two changes:
1. Set show value for libcxx and libstdcxx summary provider. This will
print the pointer value for both pointer type and reference type.
2. Remove pointer value printing in libcxx container summary.

Discussion:

https://discourse.llvm.org/t/lldb-hides-raw-pointer-value-for-libcxx-and-libstdcxx-pointer-types-in-summary-string/84226

Added: 


Modified: 
lldb/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp
lldb/source/Plugins/Language/CPlusPlus/LibCxx.cpp

lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/deque/TestDataFormatterLibcxxDeque.py

lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/span/TestDataFormatterLibcxxSpan.py

lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/variant/TestDataFormatterLibcxxVariant.py

lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/vector/TestDataFormatterLibcxxVector.py

lldb/test/API/functionalities/data-formatter/data-formatter-stl/libstdcpp/variant/TestDataFormatterLibStdcxxVariant.py

Removed: 




diff  --git a/lldb/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp 
b/lldb/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp
index 2bf574e97768ec..4b045d12ad4947 100644
--- a/lldb/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp
+++ b/lldb/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp
@@ -641,7 +641,7 @@ static void LoadLibCxxFormatters(lldb::TypeCategoryImplSP 
cpp_category_sp) {
   .SetSkipPointers(false)
   .SetSkipReferences(false)
   .SetDontShowChildren(true)
-  .SetDontShowValue(true)
+  .SetDontShowValue(false)
   .SetShowMembersOneLiner(false)
   .SetHideItemNames(false);
 
@@ -1204,7 +1204,7 @@ static void 
LoadLibStdcppFormatters(lldb::TypeCategoryImplSP cpp_category_sp) {
   .SetSkipPointers(false)
   .SetSkipReferences(false)
   .SetDontShowChildren(true)
-  .SetDontShowValue(true)
+  .SetDontShowValue(false)
   .SetShowMembersOneLiner(false)
   .SetHideItemNames(false);
 

diff  --git a/lldb/source/Plugins/Language/CPlusPlus/LibCxx.cpp 
b/lldb/source/Plugins/Language/CPlusPlus/LibCxx.cpp
index 6d0ccdbbe4a71d..2aa8fdba706348 100644
--- a/lldb/source/Plugins/Language/CPlusPlus/LibCxx.cpp
+++ b/lldb/source/Plugins/Language/CPlusPlus/LibCxx.cpp
@@ -430,12 +430,6 @@ size_t 
lldb_private::formatters::LibcxxUniquePtrSyntheticFrontEnd::
 
 bool lldb_private::formatters::LibcxxContainerSummaryProvider(
 ValueObject &valobj, Stream &stream, const TypeSummaryOptions &options) {
-  if (valobj.IsPointerType()) {
-uint64_t value = valobj.GetValueAsUnsigned(0);
-if (!value)
-  return false;
-stream.Printf("0x%016" PRIx64 " ", value);
-  }
   return FormatEntity::FormatStringRef("size=${svar%#}", stream, nullptr,
nullptr, nullptr, &valobj, false, 
false);
 }

diff  --git 
a/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/deque/TestDataFormatterLibcxxDeque.py
 
b/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/deque/TestDataFormatterLibcxxDeque.py
index 3596b546be306a..ece1e4f5f049bb 100644
--- 
a/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/deque/TestDataFormatterLibcxxDeque.py
+++ 
b/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/deque/TestDataFormatterLibcxxDeque.py
@@ -9,22 +9,27 @@
 
 
 class LibcxxDequeDataFormatterTestCase(TestBase):
-def check_numbers(self, var_name):
+def check_numbers(self, var_name, show_ptr=False):
+patterns = []
+substrs = [
+"[0] = 1",
+"[1] = 12",
+"[2] = 123",
+"[3] = 1234",
+"[4] = 12345",
+"[5] = 123456",
+"[6] = 1234567",
+"}",
+]
+if show_ptr:
+patterns = [var_name + " = 0x.* size=7"]
+else:
+substrs.insert(0, var_name + " = size=7")
 self.expect(
 "frame variable " + var_name,
-substrs=[
-var_name + " = size=7",
-"[0] = 1",
-"[1] = 12",
-"[2] = 123",
-"[3] = 1234",
-"[4] = 12345",
-"[5] = 123456",
-"[6] = 1234567",
-"}",
-],
+patterns=patterns,
+substrs=substrs,
 )
-
 self.ex

[Lldb-commits] [lldb] [lldb] Implement bidirectional access for backing<->backed thread relationship (PR #125300)

2025-02-03 Thread Felipe de Azevedo Piovezan via lldb-commits


https://github.com/felipepiovezan updated 
https://github.com/llvm/llvm-project/pull/125300

>From 0c9d9ed5b1aa78f397e95c894def54ee627bea62 Mon Sep 17 00:00:00 2001
From: Felipe de Azevedo Piovezan 
Date: Fri, 31 Jan 2025 12:07:45 -0800
Subject: [PATCH 1/4] [lldb] Implement bidirectional access for
 backing<->backed thread relationship

This enables finding the backed thread from the backing thread without
going through the thread list, and it will be useful for subsequent
commits.
---
 lldb/include/lldb/Target/Thread.h | 15 +++
 lldb/include/lldb/Target/ThreadList.h |  2 --
 .../source/Plugins/Process/Utility/ThreadMemory.h |  7 ++-
 .../Process/gdb-remote/ProcessGDBRemote.cpp   |  2 +-
 lldb/source/Target/ThreadList.cpp | 14 --
 5 files changed, 22 insertions(+), 18 deletions(-)

diff --git a/lldb/include/lldb/Target/Thread.h 
b/lldb/include/lldb/Target/Thread.h
index ef66fa11574db9..d5fe33586fa3cf 100644
--- a/lldb/include/lldb/Target/Thread.h
+++ b/lldb/include/lldb/Target/Thread.h
@@ -470,6 +470,18 @@ class Thread : public std::enable_shared_from_this,
 
   virtual void ClearStackFrames();
 
+  /// Derived classes implementing SetBackingThread should use this to provide
+  /// bidirectional access to the Backing-Backed relationship.
+  void SetBackedThread(Thread &backed_thread) {
+assert(backed_thread.GetBackingThread().get() == this);
+m_backed_thread = backed_thread.shared_from_this();
+  }
+
+  void ClearBackedThread() { m_backed_thread.reset(); }
+
+  /// Returns the thread that is backed by this thread, if any.
+  lldb::ThreadSP GetBackedThread() const { return m_backed_thread; }
+
   virtual bool SetBackingThread(const lldb::ThreadSP &thread_sp) {
 return false;
   }
@@ -1349,6 +1361,9 @@ class Thread : public 
std::enable_shared_from_this,
   LazyBool m_override_should_notify;
   mutable std::unique_ptr m_null_plan_stack_up;
 
+  /// The Thread backed by this thread, if any.
+  lldb::ThreadSP m_backed_thread;
+
 private:
   bool m_extended_info_fetched; // Have we tried to retrieve the 
m_extended_info
 // for this thread?
diff --git a/lldb/include/lldb/Target/ThreadList.h 
b/lldb/include/lldb/Target/ThreadList.h
index f931bb83a8ceaf..bca01f5fe2083e 100644
--- a/lldb/include/lldb/Target/ThreadList.h
+++ b/lldb/include/lldb/Target/ThreadList.h
@@ -101,8 +101,6 @@ class ThreadList : public ThreadCollection {
 
   lldb::ThreadSP GetThreadSPForThreadPtr(Thread *thread_ptr);
 
-  lldb::ThreadSP GetBackingThread(const lldb::ThreadSP &real_thread);
-
   bool ShouldStop(Event *event_ptr);
 
   Vote ShouldReportStop(Event *event_ptr);
diff --git a/lldb/source/Plugins/Process/Utility/ThreadMemory.h 
b/lldb/source/Plugins/Process/Utility/ThreadMemory.h
index d124f5780ea9bd..1e309671e85c65 100644
--- a/lldb/source/Plugins/Process/Utility/ThreadMemory.h
+++ b/lldb/source/Plugins/Process/Utility/ThreadMemory.h
@@ -72,12 +72,17 @@ class ThreadMemory : public lldb_private::Thread {
 
   void ClearStackFrames() override;
 
-  void ClearBackingThread() override { m_backing_thread_sp.reset(); }
+  void ClearBackingThread() override {
+if (m_backing_thread_sp)
+  m_backing_thread_sp->ClearBackedThread();
+m_backing_thread_sp.reset();
+  }
 
   bool SetBackingThread(const lldb::ThreadSP &thread_sp) override {
 // printf ("Thread 0x%llx is being backed by thread 0x%llx\n", GetID(),
 // thread_sp->GetID());
 m_backing_thread_sp = thread_sp;
+thread_sp->SetBackedThread(*this);
 return (bool)thread_sp;
   }
 
diff --git a/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp 
b/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
index 21a0fa283644d6..3f34ea2930a66a 100644
--- a/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
+++ b/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
@@ -1728,7 +1728,7 @@ ThreadSP ProcessGDBRemote::SetThreadStopInfo(
 thread_sp->SetStopInfo(StopInfoSP());
 // If there's a memory thread backed by this thread, we need to use it to
 // calculate StopInfo.
-if (ThreadSP memory_thread_sp = m_thread_list.GetBackingThread(thread_sp))
+if (ThreadSP memory_thread_sp = thread_sp->GetBackedThread())
   thread_sp = memory_thread_sp;
 
 if (exc_type != 0) {
diff --git a/lldb/source/Target/ThreadList.cpp 
b/lldb/source/Target/ThreadList.cpp
index 6cbef330bf4888..c0440d82fd1ffc 100644
--- a/lldb/source/Target/ThreadList.cpp
+++ b/lldb/source/Target/ThreadList.cpp
@@ -191,20 +191,6 @@ ThreadSP ThreadList::GetThreadSPForThreadPtr(Thread 
*thread_ptr) {
   return thread_sp;
 }
 
-ThreadSP ThreadList::GetBackingThread(const ThreadSP &real_thread) {
-  std::lock_guard guard(GetMutex());
-
-  ThreadSP thread_sp;
-  const uint32_t num_threads = m_threads.size();
-  for (uint32_t idx = 0; idx < num_threads; ++idx) {
-if (m_threads[idx]->GetBackingThread() == real_thread) {
-  thread_sp = m_

[Lldb-commits] [lldb] [llvm] [lldb-dap] Support column breakpoints (PR #125347)

2025-02-03 Thread Adrian Vogelsgesang via lldb-commits


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

>From 88134b8e891008715ca8ea90e809cac04f5b60f5 Mon Sep 17 00:00:00 2001
From: Adrian Vogelsgesang 
Date: Sat, 16 Nov 2024 19:01:12 +0100
Subject: [PATCH 1/3] [lldb-dap] Support column breakpoints (#113787)

This commit adds support for column breakpoints to lldb-dap.

To do so, support for the `breakpointLocations` request was
added. To find all available breakpoint positions, we iterate over
the line table.

The `setBreakpoints` request already forwarded the column correctly to
`SBTarget::BreakpointCreateByLocation`. However, `SourceBreakpointMap`
did not keep track of multiple breakpoints in the same line. To do so,
the `SourceBreakpointMap` is now indexed by line+column instead of by
line only.

See http://jonasdevlieghere.com/post/lldb-column-breakpoints/ for a
high-level introduction to column breakpoints.
---
 .../test/tools/lldb-dap/dap_server.py |  38 +++-
 .../test/tools/lldb-dap/lldbdap_testcase.py   |   3 +-
 .../API/tools/lldb-dap/breakpoint/Makefile|   2 +-
 .../breakpoint/TestDAP_breakpointLocations.py |  85 
 .../breakpoint/TestDAP_setBreakpoints.py  | 170 +--
 lldb/tools/lldb-dap/DAP.h |   3 +-
 lldb/tools/lldb-dap/lldb-dap.cpp  | 199 +-
 7 files changed, 418 insertions(+), 82 deletions(-)
 create mode 100644 
lldb/test/API/tools/lldb-dap/breakpoint/TestDAP_breakpointLocations.py

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 c29992ce9c7848e..043d82e2e2c7d14 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
@@ -612,6 +612,28 @@ def request_attach(
 command_dict = {"command": "attach", "type": "request", "arguments": 
args_dict}
 return self.send_recv(command_dict)
 
+def request_breakpointLocations(
+self, file_path, line, end_line=None, column=None, end_column=None
+):
+(dir, base) = os.path.split(file_path)
+source_dict = {"name": base, "path": file_path}
+args_dict = {}
+args_dict["source"] = source_dict
+if line is not None:
+args_dict["line"] = line
+if end_line is not None:
+args_dict["endLine"] = end_line
+if column is not None:
+args_dict["column"] = column
+if end_column is not None:
+args_dict["endColumn"] = end_column
+command_dict = {
+"command": "breakpointLocations",
+"type": "request",
+"arguments": args_dict,
+}
+return self.send_recv(command_dict)
+
 def request_configurationDone(self):
 command_dict = {
 "command": "configurationDone",
@@ -851,6 +873,8 @@ def request_next(self, threadId, granularity="statement"):
 def request_stepIn(self, threadId, targetId, granularity="statement"):
 if self.exit_status is not None:
 raise ValueError("request_stepIn called after process exited")
+if threadId is None:
+threadId = self.get_thread_id()
 args_dict = {
 "threadId": threadId,
 "targetId": targetId,
@@ -911,18 +935,14 @@ def request_setBreakpoints(self, file_path, line_array, 
data=None):
 breakpoint_data = data[i]
 bp = {"line": line}
 if breakpoint_data is not None:
-if "condition" in breakpoint_data and 
breakpoint_data["condition"]:
+if breakpoint_data.get("condition"):
 bp["condition"] = breakpoint_data["condition"]
-if (
-"hitCondition" in breakpoint_data
-and breakpoint_data["hitCondition"]
-):
+if breakpoint_data.get("hitCondition"):
 bp["hitCondition"] = breakpoint_data["hitCondition"]
-if (
-"logMessage" in breakpoint_data
-and breakpoint_data["logMessage"]
-):
+if breakpoint_data.get("logMessage"):
 bp["logMessage"] = breakpoint_data["logMessage"]
+if breakpoint_data.get("column"):
+bp["column"] = breakpoint_data["column"]
 breakpoints.append(bp)
 args_dict["breakpoints"] = breakpoints
 
diff --git 
a/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/lldbdap_testcase.py 
b/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/lldbdap_testcase.py
index a25466f07fa557f..34e9b96dbcc3f52 100644
--- a/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/lldbdap_testcase.py
+++ b/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/lldbdap_testcase.py
@@ -238,9 +23

[Lldb-commits] [lldb] 8e6fa15 - [lldb-dap] Support column breakpoints (#125347)

2025-02-03 Thread via lldb-commits


Author: Adrian Vogelsgesang
Date: 2025-02-04T01:23:28+01:00
New Revision: 8e6fa15bc3e8a41553ffdc7fbd3d00285a250962

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

LOG: [lldb-dap] Support column breakpoints (#125347)

This commit adds support for column breakpoints to lldb-dap

To do so, support for the `breakpointLocations` request was
added. To find all available breakpoint positions, we iterate over
the line table.

The `setBreakpoints` request already forwarded the column correctly to
`SBTarget::BreakpointCreateByLocation`. However, `SourceBreakpointMap`
did not keep track of multiple breakpoints in the same line. To do so,
the `SourceBreakpointMap` is now indexed by line+column instead of by
line only.

This was previously submitted as #113787, but got reverted due to
failures on ARM and macOS. This second attempt has less strict test
case expectations. Also, I added a release note.

Added: 
lldb/test/API/tools/lldb-dap/breakpoint/TestDAP_breakpointLocations.py

Modified: 
lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
lldb/packages/Python/lldbsuite/test/tools/lldb-dap/lldbdap_testcase.py
lldb/test/API/tools/lldb-dap/breakpoint/Makefile
lldb/test/API/tools/lldb-dap/breakpoint/TestDAP_setBreakpoints.py
lldb/tools/lldb-dap/DAP.h
lldb/tools/lldb-dap/lldb-dap.cpp
llvm/docs/ReleaseNotes.md

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 c29992ce9c7848..043d82e2e2c7d1 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
@@ -612,6 +612,28 @@ def request_attach(
 command_dict = {"command": "attach", "type": "request", "arguments": 
args_dict}
 return self.send_recv(command_dict)
 
+def request_breakpointLocations(
+self, file_path, line, end_line=None, column=None, end_column=None
+):
+(dir, base) = os.path.split(file_path)
+source_dict = {"name": base, "path": file_path}
+args_dict = {}
+args_dict["source"] = source_dict
+if line is not None:
+args_dict["line"] = line
+if end_line is not None:
+args_dict["endLine"] = end_line
+if column is not None:
+args_dict["column"] = column
+if end_column is not None:
+args_dict["endColumn"] = end_column
+command_dict = {
+"command": "breakpointLocations",
+"type": "request",
+"arguments": args_dict,
+}
+return self.send_recv(command_dict)
+
 def request_configurationDone(self):
 command_dict = {
 "command": "configurationDone",
@@ -851,6 +873,8 @@ def request_next(self, threadId, granularity="statement"):
 def request_stepIn(self, threadId, targetId, granularity="statement"):
 if self.exit_status is not None:
 raise ValueError("request_stepIn called after process exited")
+if threadId is None:
+threadId = self.get_thread_id()
 args_dict = {
 "threadId": threadId,
 "targetId": targetId,
@@ -911,18 +935,14 @@ def request_setBreakpoints(self, file_path, line_array, 
data=None):
 breakpoint_data = data[i]
 bp = {"line": line}
 if breakpoint_data is not None:
-if "condition" in breakpoint_data and 
breakpoint_data["condition"]:
+if breakpoint_data.get("condition"):
 bp["condition"] = breakpoint_data["condition"]
-if (
-"hitCondition" in breakpoint_data
-and breakpoint_data["hitCondition"]
-):
+if breakpoint_data.get("hitCondition"):
 bp["hitCondition"] = breakpoint_data["hitCondition"]
-if (
-"logMessage" in breakpoint_data
-and breakpoint_data["logMessage"]
-):
+if breakpoint_data.get("logMessage"):
 bp["logMessage"] = breakpoint_data["logMessage"]
+if breakpoint_data.get("column"):
+bp["column"] = breakpoint_data["column"]
 breakpoints.append(bp)
 args_dict["breakpoints"] = breakpoints
 

diff  --git 
a/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/lldbdap_testcase.py 
b/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/lldbdap_testcase.py
index a25466f07fa557..34e9b96dbcc3f5 100644
--- a/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/lld

[Lldb-commits] [lldb] [llvm] [lldb-dap] Support column breakpoints (PR #125347)

2025-02-03 Thread Adrian Vogelsgesang via lldb-commits


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

[Lldb-commits] [lldb] [LLDB] Add Lexer (with tests) for DIL (Data Inspection Language). (PR #123521)

2025-02-03 Thread via lldb-commits



@@ -0,0 +1,131 @@
+//===-- DILLexer.h --*- C++ 
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef LLDB_VALUEOBJECT_DILLEXER_H_
+#define LLDB_VALUEOBJECT_DILLEXER_H_
+
+#include "llvm/ADT/StringRef.h"
+#include "llvm/ADT/iterator_range.h"
+#include "llvm/Support/Error.h"
+#include 
+#include 
+#include 
+#include 
+#include 
+
+namespace lldb_private::dil {
+
+/// Class defining the tokens generated by the DIL lexer and used by the
+/// DIL parser.
+class Token {
+public:
+  enum Kind {
+coloncolon,
+eof,
+identifier,
+l_paren,
+r_paren,
+unknown,

cmtice wrote:

I've just thought of an alternative implementation I think I can use that will 
make this work. :-) I'll test that and if it works I'll get rid of the 
'unknown' token type.

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

[Lldb-commits] [lldb] [LLDB] Add Lexer (with tests) for DIL (Data Inspection Language). (PR #123521)

2025-02-03 Thread via lldb-commits



@@ -0,0 +1,131 @@
+//===-- DILLexer.h --*- C++ 
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef LLDB_VALUEOBJECT_DILLEXER_H_
+#define LLDB_VALUEOBJECT_DILLEXER_H_
+
+#include "llvm/ADT/StringRef.h"
+#include "llvm/ADT/iterator_range.h"
+#include "llvm/Support/Error.h"
+#include 
+#include 
+#include 
+#include 
+#include 
+
+namespace lldb_private::dil {
+
+/// Class defining the tokens generated by the DIL lexer and used by the
+/// DIL parser.
+class Token {
+public:
+  enum Kind {
+coloncolon,
+eof,
+identifier,
+l_paren,
+r_paren,
+unknown,
+  };
+
+  Token(Kind kind, std::string spelling, uint32_t start)
+  : m_kind(kind), m_spelling(spelling), m_start_pos(start) {}
+
+  Kind GetKind() const { return m_kind; }
+
+  std::string GetSpelling() const { return m_spelling; }
+
+  bool Is(Kind kind) const { return m_kind == kind; }
+
+  bool IsNot(Kind kind) const { return m_kind != kind; }
+
+  bool IsOneOf(Kind kind1, Kind kind2) const { return Is(kind1) || Is(kind2); }
+
+  template  bool IsOneOf(Kind kind, Ts... Ks) const {
+return Is(kind) || IsOneOf(Ks...);
+  }
+
+  uint32_t GetLocation() const { return m_start_pos; }
+
+  static llvm::StringRef GetTokenName(Kind kind);
+
+private:
+  Kind m_kind;
+  std::string m_spelling;
+  uint32_t m_start_pos; // within entire expression string
+};
+
+/// Class for doing the simple lexing required by DIL.
+class DILLexer {
+public:
+  /// Lexes all the tokens in expr and calls the private constructor
+  /// with the lexed tokens.
+  static llvm::Expected Create(llvm::StringRef expr);
+
+  /// Return the current token to be handled by the DIL parser.
+  const Token &GetCurrentToken() { return m_lexed_tokens[m_tokens_idx]; }
+
+  /// Advance the current token position by N.
+  void Advance(uint32_t N = 1) {
+// UINT_MAX means uninitialized, no "current" position, so move to start.
+if (m_tokens_idx == UINT_MAX)

cmtice wrote:

Ok; the alternative I mentioned above should make this work too (fingers 
crossed).

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

[Lldb-commits] [lldb] [LLDB] Add Lexer (with tests) for DIL (Data Inspection Language). (PR #123521)

2025-02-03 Thread via lldb-commits



@@ -0,0 +1,132 @@
+//===-- DILLexer.cpp 
--===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+// This implements the recursive descent parser for the Data Inspection
+// Language (DIL), and its helper functions, which will eventually underlie the
+// 'frame variable' command. The language that this parser recognizes is
+// described in lldb/docs/dil-expr-lang.ebnf
+//
+//===--===//
+
+#include "lldb/ValueObject/DILLexer.h"
+#include "lldb/Utility/Status.h"
+#include "llvm/ADT/StringSwitch.h"
+
+namespace lldb_private::dil {
+
+llvm::StringRef Token::GetTokenName(Kind kind) {
+  switch (kind) {
+  case Kind::coloncolon:
+return "coloncolon";
+  case Kind::eof:
+return "eof";
+  case Kind::identifier:
+return "identifier";
+  case Kind::l_paren:
+return "l_paren";
+  case Kind::r_paren:
+return "r_paren";
+  case Kind::unknown:
+return "unknown";
+  }
+}
+
+static bool IsLetter(char c) {
+  return ('a' <= c && c <= 'z') || ('A' <= c && c <= 'Z');
+}
+
+static bool IsDigit(char c) { return '0' <= c && c <= '9'; }
+
+// A word starts with a letter, underscore, or dollar sign, followed by
+// letters ('a'..'z','A'..'Z'), digits ('0'..'9'), and/or  underscores.
+static std::optional IsWord(llvm::StringRef expr,
+ llvm::StringRef &remainder) {
+  llvm::StringRef::iterator cur_pos = expr.end() - remainder.size();
+  llvm::StringRef::iterator start = cur_pos;
+  bool dollar_start = false;
+
+  // Must not start with a digit.
+  if (cur_pos == expr.end() || IsDigit(*cur_pos))
+return std::nullopt;
+
+  // First character *may* be a '$', for a register name or convenience
+  // variable.
+  if (*cur_pos == '$') {
+dollar_start = true;
+++cur_pos;
+  }
+
+  // Contains only letters, digits or underscores
+  for (; cur_pos != expr.end(); ++cur_pos) {
+char c = *cur_pos;
+if (!IsLetter(c) && !IsDigit(c) && c != '_')
+  break;
+  }
+
+  // If first char is '$', make sure there's at least one mare char, or it's
+  // invalid.
+  if (dollar_start && (cur_pos - start <= 1)) {
+cur_pos = start;
+return std::nullopt;
+  }
+
+  if (cur_pos == start)
+return std::nullopt;
+
+  llvm::StringRef word = expr.substr(start - expr.begin(), cur_pos - start);
+  if (remainder.consume_front(word))
+return word;
+
+  return std::nullopt;
+}
+
+llvm::Expected DILLexer::Create(llvm::StringRef expr) {
+  std::vector tokens;
+  llvm::StringRef remainder = expr;
+  do {
+if (llvm::Expected t = Lex(expr, remainder)) {
+  tokens.push_back(std::move(*t));
+} else {
+  return t.takeError();
+}
+  } while (tokens.back().GetKind() != Token::eof);
+  return DILLexer(expr, std::move(tokens));
+}
+
+llvm::Expected DILLexer::Lex(llvm::StringRef expr,
+llvm::StringRef &remainder) {
+  // Skip over whitespace (spaces).
+  remainder = remainder.ltrim();
+  llvm::StringRef::iterator cur_pos = expr.end() - remainder.size();

cmtice wrote:

"Both stringrefs are pointers to the same underlying string" -- I did not know 
that.  SO...there's a string (const char *) in memory, that both StringRefs 
point to, and updating the StringRefs never updates the underlying memory 
contents?  Hm...it would be nice if there was documentation somewhere that made 
this clear (the doxygen stuff does NOT).  Thanks for the explanation & 
clarification.

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

[Lldb-commits] [lldb] [LLDB][Documentation] Add a doc string to sbprocess to show MemoryRegions is iterable (PR #125557)

2025-02-03 Thread Jacob Lalonde via lldb-commits


https://github.com/Jlalond created 
https://github.com/llvm/llvm-project/pull/125557

My colleague, @lukejriddle made the SBMemoryRegionList object iterable in 
#117358. This isn't documented anywhere and so I added a blurb about it to 
SBProcess.

>From 9abe2bf9c55ecfb56ed7e46ddbdaa998be6e6fc7 Mon Sep 17 00:00:00 2001
From: Jacob Lalonde 
Date: Mon, 3 Feb 2025 10:59:25 -0800
Subject: [PATCH] Add a doc string to sbprocess to show MemoryRegions is
 iterable

---
 lldb/bindings/interface/SBProcessDocstrings.i | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/lldb/bindings/interface/SBProcessDocstrings.i 
b/lldb/bindings/interface/SBProcessDocstrings.i
index 1b98a79e4f6d36..b5b22052a60944 100644
--- a/lldb/bindings/interface/SBProcessDocstrings.i
+++ b/lldb/bindings/interface/SBProcessDocstrings.i
@@ -258,3 +258,14 @@ SBProcess supports thread iteration. For example (from 
test/lldbutil.py), ::
 Deallocates the block of memory (previously allocated using
 AllocateMemory) given in the argument."
 ) lldb::SBProcess::DeallocateMemory;
+
+%feature("docstring", "
+Get a list of all the memory regions associated with this process.
+```
+readable_regions = []
+for region in process.GetMemoryRegions():
+if region.IsReadable():
+readable_regions.append(region)
+```
+"
+) lldb::SBProcess::GetMemoryRegions;

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

[Lldb-commits] [lldb] [LLDB][Documentation] Add a doc string to sbprocess to show MemoryRegions is iterable (PR #125557)

2025-02-03 Thread Jacob Lalonde via lldb-commits


Jlalond wrote:

@JDevlieghere You think I should also update the summary of the 
SBMemoryRegionList type to note it's iterable?

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

[Lldb-commits] [lldb] [LLDB][Documentation] Add a doc string to sbprocess to show MemoryRegions is iterable (PR #125557)

2025-02-03 Thread via lldb-commits


llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Jacob Lalonde (Jlalond)


Changes

My colleague, @lukejriddle made the SBMemoryRegionList object iterable 
in #117358. This isn't documented anywhere and so I added a blurb about 
it to SBProcess.

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


1 Files Affected:

- (modified) lldb/bindings/interface/SBProcessDocstrings.i (+11) 


``diff
diff --git a/lldb/bindings/interface/SBProcessDocstrings.i 
b/lldb/bindings/interface/SBProcessDocstrings.i
index 1b98a79e4f6d36..b5b22052a60944 100644
--- a/lldb/bindings/interface/SBProcessDocstrings.i
+++ b/lldb/bindings/interface/SBProcessDocstrings.i
@@ -258,3 +258,14 @@ SBProcess supports thread iteration. For example (from 
test/lldbutil.py), ::
 Deallocates the block of memory (previously allocated using
 AllocateMemory) given in the argument."
 ) lldb::SBProcess::DeallocateMemory;
+
+%feature("docstring", "
+Get a list of all the memory regions associated with this process.
+```
+readable_regions = []
+for region in process.GetMemoryRegions():
+if region.IsReadable():
+readable_regions.append(region)
+```
+"
+) lldb::SBProcess::GetMemoryRegions;

``




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

[Lldb-commits] [lldb] [LLDB][Documentation] Add a doc string to sbprocess to show MemoryRegions is iterable (PR #125557)

2025-02-03 Thread Jonas Devlieghere via lldb-commits


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

LGTM!

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

[Lldb-commits] [lldb] [LLDB][Save Core Options] Custom ranges should follow the same safety checks as everyone else (PR #125323)

2025-02-03 Thread Greg Clayton via lldb-commits


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

This is ok for now, but we need to find the bug in lldb-server that causes 
`qMemoryRegionInfo` to fail and return a `$#00` which means unsupported and 
causes all future `qMemoryRegionInfo` to fail.

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

[Lldb-commits] [lldb] [llvm] [lldb-dap] Support column breakpoints (PR #125347)

2025-02-03 Thread Adrian Vogelsgesang via lldb-commits


vogelsgesang wrote:

@Michael137 Do you know if there is any way I could manually trigger the 
lldb-aarch64-ubuntu and the MacOS CI before merging this, to get CI feedback 
before merging this?

Also, from what I can tell, all test failures in Buildkite seem to be due to 
Bolt and unrelated to my PR. Is it safe to merge despite those failures? Or 
could they hide actual LLDB issues potentially introduced by my commit?

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

[Lldb-commits] [lldb] [lldb] Store the command in the CommandReturnObject (PR #125132)

2025-02-03 Thread Jonas Devlieghere via lldb-commits


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

>From ac8fe96328ce8e6d49bac5288278b853ecc2d65d Mon Sep 17 00:00:00 2001
From: Jonas Devlieghere 
Date: Mon, 3 Feb 2025 14:15:21 -0800
Subject: [PATCH] [lldb] Store the command in the CommandReturnObject

As suggested in #125006. Depending on which PR lands first, I'll update
TestCommandInterepterPrintCallback.py to check that the
CommandReturnObject passed to the callback has the correct command.
---
 lldb/include/lldb/API/SBCommandReturnObject.h   |  2 ++
 .../lldb/Interpreter/CommandReturnObject.h  |  8 
 lldb/source/API/SBCommandReturnObject.cpp   |  7 +++
 lldb/source/Interpreter/CommandInterpreter.cpp  | 10 ++
 .../TestSBCommandReturnObject.py| 17 +
 5 files changed, 40 insertions(+), 4 deletions(-)
 create mode 100644 
lldb/test/API/python_api/commandreturnobject/TestSBCommandReturnObject.py

diff --git a/lldb/include/lldb/API/SBCommandReturnObject.h 
b/lldb/include/lldb/API/SBCommandReturnObject.h
index e8e20a3f3016b82..4096c5bafdcfc90 100644
--- a/lldb/include/lldb/API/SBCommandReturnObject.h
+++ b/lldb/include/lldb/API/SBCommandReturnObject.h
@@ -42,6 +42,8 @@ class LLDB_API SBCommandReturnObject {
 
   bool IsValid() const;
 
+  const char *GetCommand();
+
   const char *GetOutput();
 
   const char *GetError();
diff --git a/lldb/include/lldb/Interpreter/CommandReturnObject.h 
b/lldb/include/lldb/Interpreter/CommandReturnObject.h
index f96da34889a3245..803bcd76995ede4 100644
--- a/lldb/include/lldb/Interpreter/CommandReturnObject.h
+++ b/lldb/include/lldb/Interpreter/CommandReturnObject.h
@@ -31,6 +31,12 @@ class CommandReturnObject {
 
   ~CommandReturnObject() = default;
 
+  /// Get the command as the user typed it. Empty string if commands were run 
on
+  /// behalf of lldb.
+  const std::string &GetCommand() const { return m_command; }
+
+  void SetCommand(std::string command) { m_command = std::move(command); }
+
   /// Format any inline diagnostics with an indentation of \c indent.
   std::string GetInlineDiagnosticString(unsigned indent) const;
 
@@ -182,6 +188,8 @@ class CommandReturnObject {
 private:
   enum { eStreamStringIndex = 0, eImmediateStreamIndex = 1 };
 
+  std::string m_command;
+
   StreamTee m_out_stream;
   StreamTee m_err_stream;
   std::vector m_diagnostics;
diff --git a/lldb/source/API/SBCommandReturnObject.cpp 
b/lldb/source/API/SBCommandReturnObject.cpp
index 9df8aa48b993664..6f54581e64ef419 100644
--- a/lldb/source/API/SBCommandReturnObject.cpp
+++ b/lldb/source/API/SBCommandReturnObject.cpp
@@ -84,6 +84,13 @@ SBCommandReturnObject::operator bool() const {
   return true;
 }
 
+const char *SBCommandReturnObject::GetCommand() {
+  LLDB_INSTRUMENT_VA(this);
+
+  ConstString output(ref().GetCommand());
+  return output.AsCString(/*value_if_empty*/ "");
+}
+
 const char *SBCommandReturnObject::GetOutput() {
   LLDB_INSTRUMENT_VA(this);
 
diff --git a/lldb/source/Interpreter/CommandInterpreter.cpp 
b/lldb/source/Interpreter/CommandInterpreter.cpp
index 4869b811f99e712..8398226da109617 100644
--- a/lldb/source/Interpreter/CommandInterpreter.cpp
+++ b/lldb/source/Interpreter/CommandInterpreter.cpp
@@ -1887,12 +1887,13 @@ bool CommandInterpreter::HandleCommand(const char 
*command_line,
   std::string real_original_command_string(command_string);
 
   Log *log = GetLog(LLDBLog::Commands);
-  llvm::PrettyStackTraceFormat stack_trace("HandleCommand(command = \"%s\")",
-   command_line);
-
   LLDB_LOGF(log, "Processing command: %s", command_line);
   LLDB_SCOPED_TIMERF("Processing command: %s.", command_line);
 
+  // Set the command in the CommandReturnObject here so that it's there even if
+  // the command is interrupted.
+  result.SetCommand(command_line);
+
   if (INTERRUPT_REQUESTED(GetDebugger(), "Interrupted initiating command")) {
 result.AppendError("... Interrupted");
 return false;
@@ -2644,7 +2645,8 @@ void CommandInterpreter::HandleCommands(
   (uint64_t)idx, cmd, error_msg);
 m_debugger.SetAsyncExecution(old_async_execution);
 return;
-  } else if (options.GetPrintResults()) {
+  }
+  if (options.GetPrintResults()) {
 result.AppendMessageWithFormatv("Command #{0} '{1}' failed with {2}",
 (uint64_t)idx + 1, cmd, error_msg);
   }
diff --git 
a/lldb/test/API/python_api/commandreturnobject/TestSBCommandReturnObject.py 
b/lldb/test/API/python_api/commandreturnobject/TestSBCommandReturnObject.py
new file mode 100644
index 000..b0d0b7a8dfe4e72
--- /dev/null
+++ b/lldb/test/API/python_api/commandreturnobject/TestSBCommandReturnObject.py
@@ -0,0 +1,17 @@
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+
+class SBCommandReturnObjectTest(TestBase):
+NO_DEBUG_INFO_T

[Lldb-commits] [lldb] [llvm] [lldb-dap] Support column breakpoints (PR #125347)

2025-02-03 Thread Michael Buch via lldb-commits

Michael137 wrote:

> @Michael137 Do you know if there is any way I could manually trigger the 
> lldb-aarch64-ubuntu and the MacOS CI before merging this, to get CI feedback 
> before merging this?
> 
> Also, from what I can tell, all test failures in Buildkite seem to be due to 
> Bolt and unrelated to my PR. Is it safe to merge despite those failures? Or 
> could they hide actual LLDB issues potentially introduced by my commit?

There's currently no way to trigger the macOS CI unfortunately. Based on the CI 
`monolithic-linux.sh` invocation it looks like it does run `check-lldb`. If you 
download the whole log and search for `lldb-api ::`/`lldb-shell ::`/`lldb-unit 
::`, you'll see that they passed

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

[Lldb-commits] [lldb] [llvm] [lldb-dap] Support column breakpoints (PR #125347)

2025-02-03 Thread Michael Buch via lldb-commits


Michael137 wrote:

Feels a bit silly that we ran all LLVM/Clang/etc. tests just because you 
amended the LLVM release notes

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

[Lldb-commits] [lldb] [lldb] Make ValueObjectDynamicValue::UpdateValue() point to a host b… (PR #125143)

2025-02-03 Thread via lldb-commits


jimingham wrote:



> On Feb 3, 2025, at 3:48 PM, Augusto Noronha ***@***.***> wrote:
> 
> 
> What are the ownership rules for that reference to bytes that you are passing 
> out? Who's keeping it alive and for how long?
> 
> Since ValueObjectDynamicValue::UpdateValue immediately copies the buffer over 
> I don't think that's a big concern...
> 
> I could change ArrayRef to an actual buffer that owns the data, but I think 
> that would be a bit wasteful since UpdateValue always copies it anyway.
> 
> Or are you asking me to clarify in the documentation that callers have to 
> copy out the data if they want to own it?
> 
The latter.  

Jim


> —
> Reply to this email directly, view it on GitHub 
> , 
> or unsubscribe 
> .
> You are receiving this because your review was requested.
> 



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

[Lldb-commits] [lldb] [lldb] Make ValueObjectDynamicValue::UpdateValue() point to a host b… (PR #125143)

2025-02-03 Thread Augusto Noronha via lldb-commits

augusto2112 wrote:

> What are the ownership rules for that reference to bytes that you are passing 
> out? Who's keeping it alive and for how long?

Since `ValueObjectDynamicValue::UpdateValue` immediately copies the buffer over 
I don't think that's a big concern...

I could change `ArrayRef` to an actual buffer that owns the data, but I think 
that would be a bit wasteful since `UpdateValue` always copies it anyway.

Or are you asking me to clarify in the documentation that callers have to copy 
out the data if they want to own it?

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

[Lldb-commits] [lldb] ce7bca7 - [LLDB][Save Core Options] Custom ranges should follow the same safety checks as everyone else (#125323)

2025-02-03 Thread via lldb-commits


Author: Jacob Lalonde
Date: 2025-02-03T19:22:01-08:00
New Revision: ce7bca76917e6b72615f0f7f90a6e35e681b0d16

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

LOG: [LLDB][Save Core Options] Custom ranges should follow the same safety 
checks as everyone else (#125323)

I encountered a `qMemoryRegionInfo not supported` error when capturing a
Minidump. This was surprising, and I started looking around I found
@jasonmolenda's fix in #115963 and then realized I was not validated
anything from the custom ranges.

Added: 


Modified: 
lldb/source/Target/Process.cpp

lldb/test/API/functionalities/process_save_core_minidump/TestProcessSaveCoreMinidump.py

Removed: 




diff  --git a/lldb/source/Target/Process.cpp b/lldb/source/Target/Process.cpp
index 89731f798deda8..428f8519b72fd5 100644
--- a/lldb/source/Target/Process.cpp
+++ b/lldb/source/Target/Process.cpp
@@ -6677,11 +6677,8 @@ static void GetUserSpecifiedCoreFileSaveRanges(Process 
&process,
 
   for (const auto &range : regions) {
 auto entry = option_ranges.FindEntryThatContains(range.GetRange());
-if (entry) {
-  ranges.Append(range.GetRange().GetRangeBase(),
-range.GetRange().GetByteSize(),
-CreateCoreFileMemoryRange(range));
-}
+if (entry)
+  AddRegion(range, true, ranges);
   }
 }
 

diff  --git 
a/lldb/test/API/functionalities/process_save_core_minidump/TestProcessSaveCoreMinidump.py
 
b/lldb/test/API/functionalities/process_save_core_minidump/TestProcessSaveCoreMinidump.py
index 808de687e6ea2e..c2152640c425ce 100644
--- 
a/lldb/test/API/functionalities/process_save_core_minidump/TestProcessSaveCoreMinidump.py
+++ 
b/lldb/test/API/functionalities/process_save_core_minidump/TestProcessSaveCoreMinidump.py
@@ -636,3 +636,42 @@ def minidump_saves_fs_base_region(self):
 self.assertTrue(self.dbg.DeleteTarget(target))
 if os.path.isfile(tls_file):
 os.unlink(tls_file)
+
+@skipUnlessPlatform(["linux"])
+@skipUnlessArch("x86_64")
+def test_invalid_custom_regions_not_included(self):
+options = lldb.SBSaveCoreOptions()
+self.build()
+exe = self.getBuildArtifact("a.out")
+output_file = self.getBuildArtifact("no_empty_regions.dmp")
+try:
+target = self.dbg.CreateTarget(exe)
+process = target.LaunchSimple(
+None, None, self.get_process_working_directory()
+)
+self.assertState(process.GetState(), lldb.eStateStopped)
+options.SetPluginName("minidump")
+options.SetOutputFile(lldb.SBFileSpec(output_file))
+options.SetStyle(lldb.eSaveCoreCustomOnly)
+region_one = lldb.SBMemoryRegionInfo()
+process.GetMemoryRegions().GetMemoryRegionAtIndex(0, region_one)
+options.AddMemoryRegionToSave(region_one)
+empty_region = lldb.SBMemoryRegionInfo(
+"empty region", 0x0, 0x0, 3, True, False
+)
+options.AddMemoryRegionToSave(empty_region)
+region_with_no_permissions = lldb.SBMemoryRegionInfo(
+"no permissions", 0x2AAA, 0x2BBB, 0, True, False
+)
+options.AddMemoryRegionToSave(region_with_no_permissions)
+error = process.SaveCore(options)
+self.assertTrue(error.Success(), error.GetCString())
+core_target = self.dbg.CreateTarget(None)
+core_process = core_target.LoadCore(output_file)
+self.assertNotIn(
+region_with_no_permissions, core_process.GetMemoryRegions()
+)
+self.assertNotIn(empty_region, core_process.GetMemoryRegions())
+finally:
+if os.path.isfile(output_file):
+os.unlink(output_file)



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

[Lldb-commits] [lldb] [LLDB][Save Core Options] Custom ranges should follow the same safety checks as everyone else (PR #125323)

2025-02-03 Thread Jacob Lalonde via lldb-commits


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

[Lldb-commits] [lldb] [LLDB] Add Lexer (with tests) for DIL (Data Inspection Language). (PR #123521)

2025-02-03 Thread via lldb-commits


cmtice wrote:

I've addressed all the remaining review comments (I think). Hopefully this is 
ready for approval now? :-)

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

[Lldb-commits] [lldb] [lldb] correct event when removing all watchpoints (PR #125312)

2025-02-03 Thread Ben Jackson via lldb-commits


puremourning wrote:

> @puremourning Let me know if you need someone to press the Merge button for 
> you. 

Yes please. I don't have commit rights. 

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

[Lldb-commits] [lldb] 90a51a4 - [lldb] Implement bidirectional access for backing<->backed thread relationship (#125300)

2025-02-03 Thread via lldb-commits


Author: Felipe de Azevedo Piovezan
Date: 2025-02-03T13:40:57-08:00
New Revision: 90a51a443a2fc900e514279fa6ea8882c48b10fa

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

LOG: [lldb] Implement bidirectional access for backing<->backed thread 
relationship (#125300)

This enables finding the backed thread from the backing thread without
going through the thread list, and it will be useful for subsequent
commits.

Added: 


Modified: 
lldb/include/lldb/Target/Thread.h
lldb/include/lldb/Target/ThreadList.h
lldb/source/Plugins/Process/Utility/ThreadMemory.h
lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
lldb/source/Target/ThreadList.cpp

Removed: 




diff  --git a/lldb/include/lldb/Target/Thread.h 
b/lldb/include/lldb/Target/Thread.h
index ef66fa11574db9..9749fd8d575a1c 100644
--- a/lldb/include/lldb/Target/Thread.h
+++ b/lldb/include/lldb/Target/Thread.h
@@ -470,6 +470,26 @@ class Thread : public std::enable_shared_from_this,
 
   virtual void ClearStackFrames();
 
+  /// Sets the thread that is backed by this thread.
+  /// If backed_thread.GetBackedThread() is null, this method also calls
+  /// backed_thread.SetBackingThread(this).
+  /// If backed_thread.GetBackedThread() is non-null, asserts that it is equal
+  /// to `this`.
+  void SetBackedThread(Thread &backed_thread) {
+m_backed_thread = backed_thread.shared_from_this();
+
+// Ensure the bidrectional relationship is preserved.
+Thread *backing_thread = backed_thread.GetBackingThread().get();
+assert(backing_thread == nullptr || backing_thread == this);
+if (backing_thread == nullptr)
+  backed_thread.SetBackingThread(shared_from_this());
+  }
+
+  void ClearBackedThread() { m_backed_thread.reset(); }
+
+  /// Returns the thread that is backed by this thread, if any.
+  lldb::ThreadSP GetBackedThread() const { return m_backed_thread.lock(); }
+
   virtual bool SetBackingThread(const lldb::ThreadSP &thread_sp) {
 return false;
   }
@@ -1349,6 +1369,9 @@ class Thread : public 
std::enable_shared_from_this,
   LazyBool m_override_should_notify;
   mutable std::unique_ptr m_null_plan_stack_up;
 
+  /// The Thread backed by this thread, if any.
+  lldb::ThreadWP m_backed_thread;
+
 private:
   bool m_extended_info_fetched; // Have we tried to retrieve the 
m_extended_info
 // for this thread?

diff  --git a/lldb/include/lldb/Target/ThreadList.h 
b/lldb/include/lldb/Target/ThreadList.h
index f931bb83a8ceaf..bca01f5fe2083e 100644
--- a/lldb/include/lldb/Target/ThreadList.h
+++ b/lldb/include/lldb/Target/ThreadList.h
@@ -101,8 +101,6 @@ class ThreadList : public ThreadCollection {
 
   lldb::ThreadSP GetThreadSPForThreadPtr(Thread *thread_ptr);
 
-  lldb::ThreadSP GetBackingThread(const lldb::ThreadSP &real_thread);
-
   bool ShouldStop(Event *event_ptr);
 
   Vote ShouldReportStop(Event *event_ptr);

diff  --git a/lldb/source/Plugins/Process/Utility/ThreadMemory.h 
b/lldb/source/Plugins/Process/Utility/ThreadMemory.h
index d124f5780ea9bd..1e309671e85c65 100644
--- a/lldb/source/Plugins/Process/Utility/ThreadMemory.h
+++ b/lldb/source/Plugins/Process/Utility/ThreadMemory.h
@@ -72,12 +72,17 @@ class ThreadMemory : public lldb_private::Thread {
 
   void ClearStackFrames() override;
 
-  void ClearBackingThread() override { m_backing_thread_sp.reset(); }
+  void ClearBackingThread() override {
+if (m_backing_thread_sp)
+  m_backing_thread_sp->ClearBackedThread();
+m_backing_thread_sp.reset();
+  }
 
   bool SetBackingThread(const lldb::ThreadSP &thread_sp) override {
 // printf ("Thread 0x%llx is being backed by thread 0x%llx\n", GetID(),
 // thread_sp->GetID());
 m_backing_thread_sp = thread_sp;
+thread_sp->SetBackedThread(*this);
 return (bool)thread_sp;
   }
 

diff  --git a/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp 
b/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
index 21a0fa283644d6..3f34ea2930a66a 100644
--- a/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
+++ b/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
@@ -1728,7 +1728,7 @@ ThreadSP ProcessGDBRemote::SetThreadStopInfo(
 thread_sp->SetStopInfo(StopInfoSP());
 // If there's a memory thread backed by this thread, we need to use it to
 // calculate StopInfo.
-if (ThreadSP memory_thread_sp = m_thread_list.GetBackingThread(thread_sp))
+if (ThreadSP memory_thread_sp = thread_sp->GetBackedThread())
   thread_sp = memory_thread_sp;
 
 if (exc_type != 0) {

diff  --git a/lldb/source/Target/ThreadList.cpp 
b/lldb/source/Target/ThreadList.cpp
index 6cbef330bf4888..c0440d82fd1ffc 100644
--- a/lldb/source/Target/ThreadList.cpp
+++ b/lldb/source/Target/ThreadList.cpp
@@ -191,20 +

[Lldb-commits] [lldb] [lldb] Implement bidirectional access for backing<->backed thread relationship (PR #125300)

2025-02-03 Thread Felipe de Azevedo Piovezan via lldb-commits


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

[Lldb-commits] [lldb] [lldb] Improve isolation between Process plugins and OS plugins (PR #125302)

2025-02-03 Thread Felipe de Azevedo Piovezan via lldb-commits


https://github.com/felipepiovezan updated 
https://github.com/llvm/llvm-project/pull/125302

>From a2c624aad7e1fd931bba98f2086732bda5059ef7 Mon Sep 17 00:00:00 2001
From: Felipe de Azevedo Piovezan 
Date: Fri, 31 Jan 2025 12:28:45 -0800
Subject: [PATCH] [lldb] Improve isolation between Process plugins and OS
 plugins

Generally speaking, process plugins (e.g. ProcessGDBRemote) should not
be aware of OS plugin threads. However, ProcessGDBRemote attempts to
check for the existence of OS threads when calculating stop info.
When OS threads are present, it sets the stop info directly on the OS
plugin thread and leaves the ThreadGDBRemote without a StopInfo.

This is problematic for a few reasons:

1. No other process plugins do this, as they shouldn't. They should set
the stop info for their own process threads, and let the abstractions
built on top propagate StopInfos.

2. This conflicts with the expectations of ThreadMemory, which checks
for the backing threads's info, and then attempts to propagate it (in
the future, it should probably ask the plugin itself too...). We see
this happening in the code below. The `if` condition will not trigger,
because `backing_stop_info_sp` will be null (remember, ProcessGDB remote
is ignoring its own threads), and then this method returns false.

```
bool ThreadMemory::CalculateStopInfo() {
...
  lldb::StopInfoSP backing_stop_info_sp(
  m_backing_thread_sp->GetPrivateStopInfo());
  if (backing_stop_info_sp &&
  backing_stop_info_sp->IsValidForOperatingSystemThread(*this)) {
backing_stop_info_sp->SetThread(shared_from_this());
```

```
Thread::GetPrivateStopInfo
...
if (!CalculateStopInfo())
  SetStopInfo(StopInfoSP());
```

To solve this, we change ProcessGDB remote so that it does the
principled thing: it now only sets the stop info of its own threads.
This change by itself breaks the tests TestPythonOSPlugin.py and
TestOSPluginStepping.py and probably explains why ProcessGDB had
originally "violated" this isolation of layers.

To make this work, BreakpointSites must be aware of BackingThreads when
answering the question: "Is this breakpoint valid for this thread?".
Why? Breakpoints are created on top of the OS threads (that's what the
user sees), but breakpoints are hit by process threads. In the presence
of OS threads, a TID-specific breakpoint is valid for a process thread
if it is backing an OS thread with that TID.
---
 lldb/source/Breakpoint/BreakpointSite.cpp |  3 +
 .../Process/gdb-remote/ProcessGDBRemote.cpp   |  4 --
 lldb/unittests/OperatingSystem/CMakeLists.txt | 21 +++
 .../OperatingSystem/OperatingSystemPlugin.h   | 59 +++
 .../TestThreadSpecificBreakpoints.cpp | 10 
 5 files changed, 93 insertions(+), 4 deletions(-)
 create mode 100644 lldb/unittests/OperatingSystem/CMakeLists.txt
 create mode 100644 lldb/unittests/OperatingSystem/OperatingSystemPlugin.h
 create mode 100644 
lldb/unittests/OperatingSystem/TestThreadSpecificBreakpoints.cpp

diff --git a/lldb/source/Breakpoint/BreakpointSite.cpp 
b/lldb/source/Breakpoint/BreakpointSite.cpp
index 9700a57d3346e0..8b964c5711468c 100644
--- a/lldb/source/Breakpoint/BreakpointSite.cpp
+++ b/lldb/source/Breakpoint/BreakpointSite.cpp
@@ -12,6 +12,7 @@
 
 #include "lldb/Breakpoint/Breakpoint.h"
 #include "lldb/Breakpoint/BreakpointLocation.h"
+#include "lldb/Target/Thread.h"
 #include "lldb/Utility/Stream.h"
 
 using namespace lldb;
@@ -161,6 +162,8 @@ BreakpointLocationSP 
BreakpointSite::GetConstituentAtIndex(size_t index) {
 
 bool BreakpointSite::ValidForThisThread(Thread &thread) {
   std::lock_guard guard(m_constituents_mutex);
+  if (ThreadSP backed_thread = thread.GetBackedThread())
+return m_constituents.ValidForThisThread(*backed_thread);
   return m_constituents.ValidForThisThread(thread);
 }
 
diff --git a/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp 
b/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
index 3f34ea2930a66a..07b4470d061918 100644
--- a/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
+++ b/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
@@ -1726,10 +1726,6 @@ ThreadSP ProcessGDBRemote::SetThreadStopInfo(
 
   if (!thread_sp->StopInfoIsUpToDate()) {
 thread_sp->SetStopInfo(StopInfoSP());
-// If there's a memory thread backed by this thread, we need to use it to
-// calculate StopInfo.
-if (ThreadSP memory_thread_sp = thread_sp->GetBackedThread())
-  thread_sp = memory_thread_sp;
 
 if (exc_type != 0) {
   // For thread plan async interrupt, creating stop info on the
diff --git a/lldb/unittests/OperatingSystem/CMakeLists.txt 
b/lldb/unittests/OperatingSystem/CMakeLists.txt
new file mode 100644
index 00..ae810f37b05774
--- /dev/null
+++ b/lldb/unittests/OperatingSystem/CMakeLists.txt
@@ -0,0 +1,21 @@
+add_lldb_unittest(ProcessGdbRemoteTests
+  GDBRemoteClientBaseTest.cpp
+  GDBRemoteCommunicationClientTest.cpp
+  GDBRemoteCommunicationServe

[Lldb-commits] [lldb] [lldb] Improve isolation between Process plugins and OS plugins (PR #125302)

2025-02-03 Thread Felipe de Azevedo Piovezan via lldb-commits


felipepiovezan wrote:

Rebased

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

[Lldb-commits] [lldb] [lldb] Store the command in the CommandReturnObject (PR #125132)

2025-02-03 Thread via lldb-commits


jimingham wrote:

One way to make the intent of the command string in the return object clear is 
to ONLY set it after we've called HandleCommand (or HandleCommands).  That way 
it's explicitly NOT meant to help execute the command - after all, commands 
really should NOT be operating on the un-alias-resolved forms of their 
commands.  Then the intent will be clear.  We could even call the API 
`GetOriginalCommandString` to make it doubly clear.

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

[Lldb-commits] [lldb] [LLDB] Add Lexer (with tests) for DIL (Data Inspection Language). (PR #123521)

2025-02-03 Thread via lldb-commits



@@ -0,0 +1,192 @@
+//===-- DILLexerTests.cpp ===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "lldb/ValueObject/DILLexer.h"
+#include "llvm/ADT/StringRef.h"
+#include "llvm/Testing/Support/Error.h"
+#include "gtest/gtest.h"
+#include 
+
+using llvm::StringRef;
+
+std::vector>
+ExtractTokenData(lldb_private::dil::DILLexer &lexer) {
+  std::vector> data;
+  if (lexer.NumLexedTokens() == 0)
+return data;
+
+  lexer.ResetTokenIdx(UINT_MAX);
+  do {
+lexer.Advance();
+lldb_private::dil::Token tok = lexer.GetCurrentToken();
+data.push_back(std::make_pair(tok.GetKind(), tok.GetSpelling()));
+  } while (data.back().first != lldb_private::dil::Token::eof);
+  return data;
+}
+
+TEST(DILLexerTests, SimpleTest) {
+  StringRef input_expr("simple_var");
+  uint32_t tok_len = 10;
+  llvm::Expected maybe_lexer =
+  lldb_private::dil::DILLexer::Create(input_expr);
+  ASSERT_THAT_EXPECTED(maybe_lexer, llvm::Succeeded());
+  lldb_private::dil::DILLexer lexer(*maybe_lexer);
+  lldb_private::dil::Token token =
+  lldb_private::dil::Token(lldb_private::dil::Token::unknown, "", 0);
+  EXPECT_EQ(token.GetKind(), lldb_private::dil::Token::unknown);
+
+  lexer.Advance();
+  token = lexer.GetCurrentToken();
+  EXPECT_EQ(token.GetKind(), lldb_private::dil::Token::identifier);
+  EXPECT_EQ(token.GetSpelling(), "simple_var");
+  EXPECT_EQ(token.GetSpelling().size(), tok_len);
+  lexer.Advance();
+  token = lexer.GetCurrentToken();
+  EXPECT_EQ(token.GetKind(), lldb_private::dil::Token::eof);
+}
+
+TEST(DILLexerTests, TokenKindTest) {
+  StringRef input_expr("namespace");
+  llvm::Expected maybe_lexer =
+  lldb_private::dil::DILLexer::Create(input_expr);
+  ASSERT_THAT_EXPECTED(maybe_lexer, llvm::Succeeded());
+  lldb_private::dil::DILLexer lexer(*maybe_lexer);
+  lldb_private::dil::Token token =
+  lldb_private::dil::Token(lldb_private::dil::Token::unknown, "", 0);
+  lexer.Advance();
+  token = lexer.GetCurrentToken();
+
+  EXPECT_TRUE(token.Is(lldb_private::dil::Token::identifier));
+  EXPECT_FALSE(token.Is(lldb_private::dil::Token::l_paren));
+  EXPECT_TRUE(token.IsOneOf(lldb_private::dil::Token::eof,
+lldb_private::dil::Token::identifier));
+  EXPECT_FALSE(token.IsOneOf(
+  lldb_private::dil::Token::l_paren, lldb_private::dil::Token::r_paren,
+  lldb_private::dil::Token::coloncolon, lldb_private::dil::Token::eof));
+}
+
+TEST(DILLexerTests, LookAheadTest) {
+  StringRef input_expr("(anonymous namespace)::some_var");
+  llvm::Expected maybe_lexer =
+  lldb_private::dil::DILLexer::Create(input_expr);
+  ASSERT_THAT_EXPECTED(maybe_lexer, llvm::Succeeded());
+  lldb_private::dil::DILLexer lexer(*maybe_lexer);
+  lldb_private::dil::Token token =
+  lldb_private::dil::Token(lldb_private::dil::Token::unknown, "", 0);
+  uint32_t expect_loc = 23;
+  lexer.Advance();
+  token = lexer.GetCurrentToken();
+
+  // Current token is '('; check the next 4 tokens, to make
+  // sure they are the identifier 'anonymous', the identifier 'namespace'
+  // ')' and '::', in that order.
+  EXPECT_EQ(token.GetKind(), lldb_private::dil::Token::l_paren);
+  EXPECT_EQ(lexer.LookAhead(1).GetKind(), 
lldb_private::dil::Token::identifier);
+  EXPECT_EQ(lexer.LookAhead(1).GetSpelling(), "anonymous");
+  EXPECT_EQ(lexer.LookAhead(2).GetKind(), 
lldb_private::dil::Token::identifier);
+  EXPECT_EQ(lexer.LookAhead(2).GetSpelling(), "namespace");
+  EXPECT_EQ(lexer.LookAhead(3).GetKind(), lldb_private::dil::Token::r_paren);
+  EXPECT_EQ(lexer.LookAhead(4).GetKind(), 
lldb_private::dil::Token::coloncolon);
+
+  // Our current index should still be 0, as we only looked ahead; we are still
+  // officially on the '('.
+  EXPECT_EQ(lexer.GetCurrentTokenIdx(), (uint32_t)0);
+
+  // Accept the 'lookahead', so our current token is '::', which has the index
+  // 4 in our vector of tokens (which starts at zero).
+  lexer.Advance(4);
+  token = lexer.GetCurrentToken();
+  EXPECT_EQ(token.GetKind(), lldb_private::dil::Token::coloncolon);
+  EXPECT_EQ(lexer.GetCurrentTokenIdx(), (uint32_t)4);
+
+  lexer.Advance();
+  token = lexer.GetCurrentToken();
+  EXPECT_EQ(token.GetKind(), lldb_private::dil::Token::identifier);
+  EXPECT_EQ(token.GetSpelling(), "some_var");
+  EXPECT_EQ(lexer.GetCurrentTokenIdx(), (uint32_t)5);
+  // Verify we've advanced our position counter (lexing location) in the
+  // input 23 characters (the length of '(anonymous namespace)::'.
+  EXPECT_EQ(token.GetLocation(), expect_loc);
+
+  lexer.Advance();
+  token = lexer.GetCurrentToken();
+  EXPECT_EQ(token.GetKind(), lldb_private::dil::Token::eof);
+}
+
+TEST(DILLexerTests, MultiTokenLexTest) {
+  StringRef inpu

[Lldb-commits] [lldb] [LLDB] Add Lexer (with tests) for DIL (Data Inspection Language). (PR #123521)

2025-02-03 Thread via lldb-commits


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

[Lldb-commits] [lldb] [llvm] [lldb-dap] Support column breakpoints (PR #125347)

2025-02-03 Thread Adrian Vogelsgesang via lldb-commits

vogelsgesang wrote:

> share more about the differences between the these cases and the actual logic 
> between this patch and the previous attempt?

There are 3 separate commits in this PR. The first PR is literally the same as 
the originally reverted one. 
The other two commits show the additional differences. 
https://github.com/llvm/llvm-project/pull/125347/commits/76af5fcec7f7287ddebea937ad81c66e171a61f6
 is the most relevant change

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

[Lldb-commits] [lldb] [lldb] correct event when removing all watchpoints (PR #125312)

2025-02-03 Thread Greg Clayton via lldb-commits


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

Thanks for fixing this!

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

[Lldb-commits] [lldb] c26bb4f - [lldb] correct event when removing all watchpoints (#125312)

2025-02-03 Thread via lldb-commits


Author: Ben Jackson
Date: 2025-02-03T14:39:43-08:00
New Revision: c26bb4f095120ff4741b6530b6b3c0ac5a7dacad

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

LOG: [lldb] correct event when removing all watchpoints (#125312)

LLDB: correct event when removing all watchpoints

Previously we incorrectly checked for a "breakpoint changed" event
listener removing all watchpoints (e.g. via
SBTarget::DeleteAllWatchpoints()), although we would emit a "watchpoint
changed" event if there were a listener for 'breakpoint changed'.

This meant that we might not emit a "watchpoint changed" event if there
was a listener for this event.

Correct it to check for the "watchpoint changed" event.


---


Updated regression tests which were also incorrectly peeking for the
wrong event type. The 'remove' action actually triggers 2 events which
the test didn't allow, so I updated it to allow specifically what was
requested.

The test fails (expectedly) at the line following "DeleteAllWatchpoints"
prior to this patch, and passes after.

Added: 


Modified: 
lldb/source/Breakpoint/WatchpointList.cpp
lldb/test/API/commands/watchpoints/watchpoint_events/TestWatchpointEvents.py

Removed: 




diff  --git a/lldb/source/Breakpoint/WatchpointList.cpp 
b/lldb/source/Breakpoint/WatchpointList.cpp
index f7564483e6f1fcd..57369b76c03aff0 100644
--- a/lldb/source/Breakpoint/WatchpointList.cpp
+++ b/lldb/source/Breakpoint/WatchpointList.cpp
@@ -236,7 +236,7 @@ void WatchpointList::RemoveAll(bool notify) {
   wp_collection::iterator pos, end = m_watchpoints.end();
   for (pos = m_watchpoints.begin(); pos != end; ++pos) {
 if ((*pos)->GetTarget().EventTypeHasListeners(
-Target::eBroadcastBitBreakpointChanged)) {
+Target::eBroadcastBitWatchpointChanged)) {
   auto data_sp = std::make_shared(
   eWatchpointEventTypeRemoved, *pos);
   (*pos)->GetTarget().BroadcastEvent(

diff  --git 
a/lldb/test/API/commands/watchpoints/watchpoint_events/TestWatchpointEvents.py 
b/lldb/test/API/commands/watchpoints/watchpoint_events/TestWatchpointEvents.py
index 726a9d93c29d460..6e05cf06204a7d5 100644
--- 
a/lldb/test/API/commands/watchpoints/watchpoint_events/TestWatchpointEvents.py
+++ 
b/lldb/test/API/commands/watchpoints/watchpoint_events/TestWatchpointEvents.py
@@ -82,27 +82,45 @@ def test_with_python_api(self):
 'make sure watchpoint condition is "' + condition + '"',
 )
 
-def GetWatchpointEvent(self, event_type):
-# We added a watchpoint so we should get a watchpoint added event.
-event = lldb.SBEvent()
-success = self.listener.WaitForEvent(1, event)
-self.assertTrue(success, "Successfully got watchpoint event")
-self.assertTrue(
-lldb.SBWatchpoint.EventIsWatchpointEvent(event),
-"Event is a watchpoint event.",
+target.DeleteWatchpoint(local_watch.GetID())
+self.GetWatchpointEvent(
+lldb.eWatchpointEventTypeDisabled, lldb.eWatchpointEventTypeRemoved
 )
-found_type = lldb.SBWatchpoint.GetWatchpointEventTypeFromEvent(event)
-self.assertEqual(
-found_type,
-event_type,
-"Event is not correct type, expected: %d, found: %d"
-% (event_type, found_type),
+
+# Re-create it so that we can check DeleteAllWatchpoints
+local_watch = local_var.Watch(True, False, True, error)
+if not error.Success():
+self.fail(
+"Failed to make watchpoint for local_var: %s" % 
(error.GetCString())
+)
+self.GetWatchpointEvent(lldb.eWatchpointEventTypeAdded)
+target.DeleteAllWatchpoints()
+self.GetWatchpointEvent(
+lldb.eWatchpointEventTypeDisabled, lldb.eWatchpointEventTypeRemoved
 )
+
+def GetWatchpointEvent(self, *event_types):
+# We added a watchpoint so we should get a watchpoint added event.
+event = lldb.SBEvent()
+for event_type in event_types:
+success = self.listener.WaitForEvent(1, event)
+self.assertTrue(success, "Successfully got watchpoint event")
+self.assertTrue(
+lldb.SBWatchpoint.EventIsWatchpointEvent(event),
+"Event is a watchpoint event.",
+)
+found_type = 
lldb.SBWatchpoint.GetWatchpointEventTypeFromEvent(event)
+self.assertEqual(
+found_type,
+event_type,
+"Event is not correct type, expected: %d, found: %d"
+% (event_type, found_type),
+)
 # There shouldn't be another event waiting around:
 found_event = self.listener

[Lldb-commits] [lldb] [lldb] correct event when removing all watchpoints (PR #125312)

2025-02-03 Thread Jonas Devlieghere via lldb-commits


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

[Lldb-commits] [lldb] [lldb] Store the command in the CommandReturnObject (PR #125132)

2025-02-03 Thread Jonas Devlieghere via lldb-commits


JDevlieghere wrote:

Rebased and implemented @jimingham's latest suggestion. 

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

[Lldb-commits] [lldb] [llvm] [lldb-dap] Support column breakpoints (PR #125347)

2025-02-03 Thread Michael Buch via lldb-commits

Michael137 wrote:

> > There's currently no way to trigger the macOS CI unfortunately.
> 
> Is a manual trigger possible for the `lldb-aarch64-ubuntu` build? Or is it 
> same as for the macOS CI?

Not sure tbh. You can re-run failed runs, but not sure if you can trigger 
specific test-suites to run. I'd suggest you just merge this since the LLDB 
linux tests passed

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

[Lldb-commits] [lldb] [lldb] Make ValueObjectDynamicValue::UpdateValue() point to a host b… (PR #125143)

2025-02-03 Thread via lldb-commits


jimingham wrote:

Is there's no way to test this with the languages supported by the upstream 
lldb?

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

[Lldb-commits] [lldb] [lldb] Store the command in the CommandReturnObject (PR #125132)

2025-02-03 Thread via lldb-commits



@@ -42,6 +42,8 @@ class LLDB_API SBCommandReturnObject {
 
   bool IsValid() const;
 
+  const char *GetCommand();

jimingham wrote:

The docs currently in CommandReturnObject.h should certainly be here (or in 
both places)...

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

[Lldb-commits] [lldb] [lldb] Store the command in the CommandReturnObject (PR #125132)

2025-02-03 Thread via lldb-commits


jimingham wrote:

Other that the comment comment, LGTM.

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

[Lldb-commits] [lldb] [lldb] Store the command in the CommandReturnObject (PR #125132)

2025-02-03 Thread Jonas Devlieghere via lldb-commits


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

>From ac8fe96328ce8e6d49bac5288278b853ecc2d65d Mon Sep 17 00:00:00 2001
From: Jonas Devlieghere 
Date: Mon, 3 Feb 2025 14:15:21 -0800
Subject: [PATCH 1/2] [lldb] Store the command in the CommandReturnObject

As suggested in #125006. Depending on which PR lands first, I'll update
TestCommandInterepterPrintCallback.py to check that the
CommandReturnObject passed to the callback has the correct command.
---
 lldb/include/lldb/API/SBCommandReturnObject.h   |  2 ++
 .../lldb/Interpreter/CommandReturnObject.h  |  8 
 lldb/source/API/SBCommandReturnObject.cpp   |  7 +++
 lldb/source/Interpreter/CommandInterpreter.cpp  | 10 ++
 .../TestSBCommandReturnObject.py| 17 +
 5 files changed, 40 insertions(+), 4 deletions(-)
 create mode 100644 
lldb/test/API/python_api/commandreturnobject/TestSBCommandReturnObject.py

diff --git a/lldb/include/lldb/API/SBCommandReturnObject.h 
b/lldb/include/lldb/API/SBCommandReturnObject.h
index e8e20a3f3016b8..4096c5bafdcfc9 100644
--- a/lldb/include/lldb/API/SBCommandReturnObject.h
+++ b/lldb/include/lldb/API/SBCommandReturnObject.h
@@ -42,6 +42,8 @@ class LLDB_API SBCommandReturnObject {
 
   bool IsValid() const;
 
+  const char *GetCommand();
+
   const char *GetOutput();
 
   const char *GetError();
diff --git a/lldb/include/lldb/Interpreter/CommandReturnObject.h 
b/lldb/include/lldb/Interpreter/CommandReturnObject.h
index f96da34889a324..803bcd76995ede 100644
--- a/lldb/include/lldb/Interpreter/CommandReturnObject.h
+++ b/lldb/include/lldb/Interpreter/CommandReturnObject.h
@@ -31,6 +31,12 @@ class CommandReturnObject {
 
   ~CommandReturnObject() = default;
 
+  /// Get the command as the user typed it. Empty string if commands were run 
on
+  /// behalf of lldb.
+  const std::string &GetCommand() const { return m_command; }
+
+  void SetCommand(std::string command) { m_command = std::move(command); }
+
   /// Format any inline diagnostics with an indentation of \c indent.
   std::string GetInlineDiagnosticString(unsigned indent) const;
 
@@ -182,6 +188,8 @@ class CommandReturnObject {
 private:
   enum { eStreamStringIndex = 0, eImmediateStreamIndex = 1 };
 
+  std::string m_command;
+
   StreamTee m_out_stream;
   StreamTee m_err_stream;
   std::vector m_diagnostics;
diff --git a/lldb/source/API/SBCommandReturnObject.cpp 
b/lldb/source/API/SBCommandReturnObject.cpp
index 9df8aa48b99366..6f54581e64ef41 100644
--- a/lldb/source/API/SBCommandReturnObject.cpp
+++ b/lldb/source/API/SBCommandReturnObject.cpp
@@ -84,6 +84,13 @@ SBCommandReturnObject::operator bool() const {
   return true;
 }
 
+const char *SBCommandReturnObject::GetCommand() {
+  LLDB_INSTRUMENT_VA(this);
+
+  ConstString output(ref().GetCommand());
+  return output.AsCString(/*value_if_empty*/ "");
+}
+
 const char *SBCommandReturnObject::GetOutput() {
   LLDB_INSTRUMENT_VA(this);
 
diff --git a/lldb/source/Interpreter/CommandInterpreter.cpp 
b/lldb/source/Interpreter/CommandInterpreter.cpp
index 4869b811f99e71..8398226da10961 100644
--- a/lldb/source/Interpreter/CommandInterpreter.cpp
+++ b/lldb/source/Interpreter/CommandInterpreter.cpp
@@ -1887,12 +1887,13 @@ bool CommandInterpreter::HandleCommand(const char 
*command_line,
   std::string real_original_command_string(command_string);
 
   Log *log = GetLog(LLDBLog::Commands);
-  llvm::PrettyStackTraceFormat stack_trace("HandleCommand(command = \"%s\")",
-   command_line);
-
   LLDB_LOGF(log, "Processing command: %s", command_line);
   LLDB_SCOPED_TIMERF("Processing command: %s.", command_line);
 
+  // Set the command in the CommandReturnObject here so that it's there even if
+  // the command is interrupted.
+  result.SetCommand(command_line);
+
   if (INTERRUPT_REQUESTED(GetDebugger(), "Interrupted initiating command")) {
 result.AppendError("... Interrupted");
 return false;
@@ -2644,7 +2645,8 @@ void CommandInterpreter::HandleCommands(
   (uint64_t)idx, cmd, error_msg);
 m_debugger.SetAsyncExecution(old_async_execution);
 return;
-  } else if (options.GetPrintResults()) {
+  }
+  if (options.GetPrintResults()) {
 result.AppendMessageWithFormatv("Command #{0} '{1}' failed with {2}",
 (uint64_t)idx + 1, cmd, error_msg);
   }
diff --git 
a/lldb/test/API/python_api/commandreturnobject/TestSBCommandReturnObject.py 
b/lldb/test/API/python_api/commandreturnobject/TestSBCommandReturnObject.py
new file mode 100644
index 00..b0d0b7a8dfe4e7
--- /dev/null
+++ b/lldb/test/API/python_api/commandreturnobject/TestSBCommandReturnObject.py
@@ -0,0 +1,17 @@
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+
+class SBCommandReturnObjectTest(TestBase):
+NO_DEBUG_INFO_TESTCAS

[Lldb-commits] [lldb] [llvm] [lldb-dap] Support column breakpoints (PR #125347)

2025-02-03 Thread Adrian Vogelsgesang via lldb-commits


vogelsgesang wrote:

> There's currently no way to trigger the macOS CI unfortunately.

Is a manual trigger possible for the `lldb-aarch64-ubuntu` build? Or is it same 
as for the macOS CI?

Is another round of "merge, pray, revert" our only option here, or is there 
anything else I can do to merge this with more confidence?

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

[Lldb-commits] [lldb] [lldb] Store the command in the CommandReturnObject (PR #125132)

2025-02-03 Thread via lldb-commits


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

LGTM

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

[Lldb-commits] [lldb] [llvm] [lldb-dap] Support column breakpoints (PR #125347)

2025-02-03 Thread LLVM Continuous Integration via lldb-commits


llvm-ci wrote:

LLVM Buildbot has detected a new failure on builder `clang-aarch64-quick` 
running on `linaro-clang-aarch64-quick` while building `lldb,llvm` at step 5 
"ninja check 1".

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


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

```
Step 5 (ninja check 1) failure: stage 1 checked (failure)
 TEST 'Clangd Unit Tests :: ./ClangdTests/22/160' FAILED 

Script(shard):
--
GTEST_OUTPUT=json:/home/tcwg-buildbot/worker/clang-aarch64-quick/stage1/tools/clang/tools/extra/clangd/unittests/./ClangdTests-Clangd
 Unit Tests-1276915-22-160.json GTEST_SHUFFLE=0 GTEST_TOTAL_SHARDS=160 
GTEST_SHARD_INDEX=22 
/home/tcwg-buildbot/worker/clang-aarch64-quick/stage1/tools/clang/tools/extra/clangd/unittests/./ClangdTests
--

Note: This is test shard 23 of 160.
[==] Running 8 tests from 8 test suites.
[--] Global test environment set-up.
[--] 1 test from BackgroundIndexRebuilderTest
[ RUN  ] BackgroundIndexRebuilderTest.IndexingTUs
BackgroundIndex: building version 1 after indexing enough files
BackgroundIndex: serving version 1 (6932 bytes)
BackgroundIndex: building version 2 after indexing enough files
BackgroundIndex: serving version 2 (6964 bytes)
[   OK ] BackgroundIndexRebuilderTest.IndexingTUs (0 ms)
[--] 1 test from BackgroundIndexRebuilderTest (0 ms total)

[--] 1 test from CompletionTest
[ RUN  ] CompletionTest.ObjectiveCProtocolFromIndexSpeculation
ASTWorker building file /clangd-test/Foo.m version null with command 
[/clangd-test]
clang -ffreestanding /clangd-test/Foo.m
Driver produced command: cc1 -cc1 -triple aarch64-unknown-linux-gnu 
-fsyntax-only -disable-free -clear-ast-before-backend -main-file-name Foo.m 
-mrelocation-model pic -pic-level 2 -pic-is-pie -mframe-pointer=non-leaf 
-fmath-errno -ffp-contract=on -fno-rounding-math -mconstructor-aliases 
-ffreestanding -enable-tlsdesc -target-cpu generic -target-feature +v8a 
-target-feature +fp-armv8 -target-feature +neon -target-abi aapcs 
-debugger-tuning=gdb -fdebug-compilation-dir=/clangd-test 
-fcoverage-compilation-dir=/clangd-test -resource-dir lib/clang/21 
-internal-isystem lib/clang/21/include -internal-isystem /usr/local/include 
-internal-externc-isystem /include -internal-externc-isystem /usr/include 
-ferror-limit 19 -fno-signed-char -fgnuc-version=4.2.1 -fskip-odr-check-in-gmf 
-fobjc-runtime=gcc -fobjc-encode-cxx-class-template-spec -fobjc-exceptions 
-no-round-trip-args -target-feature -fmv -faddrsig -x objective-c 
/clangd-test/Foo.m
Building first preamble for /clangd-test/Foo.m version null
Built preamble of size 712288 for file /clangd-test/Foo.m version null in 10.04 
seconds
not idle after addDocument
UNREACHABLE executed at 
../llvm/clang-tools-extra/clangd/unittests/SyncAPI.cpp:22!
 #0 0xd71ae918 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) 
(/home/tcwg-buildbot/worker/clang-aarch64-quick/stage1/tools/clang/tools/extra/clangd/unittests/./ClangdTests+0x101d918)
 #1 0xd71ac920 llvm::sys::RunSignalHandlers() 
(/home/tcwg-buildbot/worker/clang-aarch64-quick/stage1/tools/clang/tools/extra/clangd/unittests/./ClangdTests+0x101b920)
 #2 0xd71af064 SignalHandler(int) Signals.cpp:0:0
 #3 0xabd1d598 (linux-vdso.so.1+0x598)
 #4 0xab87f200 __pthread_kill_implementation 
./nptl/./nptl/pthread_kill.c:44:76
 #5 0xab83a67c gsignal ./signal/../sysdeps/posix/raise.c:27:6
 #6 0xab827130 abort ./stdlib/./stdlib/abort.c:81:7
 #7 0xd715c6d8 llvm::RTTIRoot::anchor() 
(/home/tcwg-buildbot/worker/clang-aarch64-quick/stage1/tools/clang/tools/extra/clangd/unittests/./ClangdTests+0xfcb6d8)
 #8 0xd70168a4 
clang::clangd::runCodeComplete(clang::clangd::ClangdServer&, llvm::StringRef, 
clang::clangd::Position, clang::clangd::CodeCompleteOptions) 
(/home/tcwg-buildbot/worker/clang-aarch64-quick/stage1/tools/clang/tools/extra/clangd/unittests/./ClangdTests+0xe858a4)
 #9 0xd6c394a0 clang::clangd::(anonymous 
namespace)::CompletionTest_ObjectiveCProtocolFromIndexSpeculation_Test::TestBody()
 CodeCompleteTests.cpp:0:0
#10 0xd720a064 testing::Test::Run() 
(/home/tcwg-buildbot/worker/clang-aarch64-quick/stage1/tools/clang/tools/extra/clangd/unittests/./ClangdTests+0x1079064)
#11 0xd720b320 testing::TestInfo::Run() 
(/home/tcwg-buildbot/worker/clang-aarch64-quick/stage1/tools/clang/tools/extra/clangd/unittests/./ClangdTests+0x107a320)
#12 0xd720befc testing::TestSuite::Run() 
(/home/tcwg-buildbot/worker/clang-aarch64-quick/stage1/tools/clang/tools/extra/clangd/unittests/./ClangdTests+0x107aefc)
#13 0xd721bf04 testing::internal::UnitTestImpl::RunAllTests() 
(/home/tcwg-buildbot/worker/clang-aarch64-quick/stage1/tools/clang/tools/extra/clangd/unittests/./ClangdTests+0x108af04)
#14 0xd721b86c testing::UnitTest::Run() 
(/home/tcwg-buildbot/worker/clang-aarch64-

[Lldb-commits] [lldb] [lldb] Make ValueObjectDynamicValue::UpdateValue() point to a host b… (PR #125143)

2025-02-03 Thread Augusto Noronha via lldb-commits


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

>From 0c22a94214e97146b2592b77ac96255bdee47b0f Mon Sep 17 00:00:00 2001
From: Augusto Noronha 
Date: Thu, 30 Jan 2025 16:33:09 -0800
Subject: [PATCH 1/4] [lldb] Make ValueObjectDynamicValue::UpdateValue() point
 to  a host buffer

ValueObjectDynamicValue::UpdateValue() assumes that the dynamic type
found by GetDynamicTypeAndAddress() would return an address in the
inferior.  This commit makes it so it can deal with being passed a
host address instead.

This is needed downstream by the Swift fork.

rdar://143357274
---
 lldb/include/lldb/Target/LanguageRuntime.h|  4 +++-
 .../ValueObject/ValueObjectDynamicValue.cpp   | 24 ++-
 2 files changed, 21 insertions(+), 7 deletions(-)

diff --git a/lldb/include/lldb/Target/LanguageRuntime.h 
b/lldb/include/lldb/Target/LanguageRuntime.h
index 4a0214b04e235e..08db8a17a67e69 100644
--- a/lldb/include/lldb/Target/LanguageRuntime.h
+++ b/lldb/include/lldb/Target/LanguageRuntime.h
@@ -105,7 +105,9 @@ class LanguageRuntime : public Runtime, public 
PluginInterface {
 "language doesn't support getting vtable information");
   }
 
-  // this call should return true if it could set the name and/or the type
+  // This call should return true if it could set the name and/or the type.
+  // address can be either a legitimate address on the inferior, or an address
+  // in lldb, if value_type == HostAddress.
   virtual bool GetDynamicTypeAndAddress(ValueObject &in_value,
 lldb::DynamicValueType use_dynamic,
 TypeAndOrName &class_type_or_name,
diff --git a/lldb/source/ValueObject/ValueObjectDynamicValue.cpp 
b/lldb/source/ValueObject/ValueObjectDynamicValue.cpp
index 588c644bbfd07b..10a5a9d0b76919 100644
--- a/lldb/source/ValueObject/ValueObjectDynamicValue.cpp
+++ b/lldb/source/ValueObject/ValueObjectDynamicValue.cpp
@@ -239,11 +239,19 @@ bool ValueObjectDynamicValue::UpdateValue() {
 if (m_address.IsValid())
   SetValueDidChange(true);
 
-// We've moved, so we should be fine...
-m_address = dynamic_address;
-lldb::TargetSP target_sp(GetTargetSP());
-lldb::addr_t load_address = m_address.GetLoadAddress(target_sp.get());
-m_value.GetScalar() = load_address;
+// If we found a host address, point to the buffer in host memory.
+// Later on this function will copy the buffer over.
+if (value_type == Value::ValueType::HostAddress) {
+  m_value.GetScalar() = dynamic_address.GetOffset();
+  m_address = LLDB_INVALID_ADDRESS;
+} else {
+  // Otherwise we have a legitimate address on the target. Point to the 
load
+  // address.
+  m_address = dynamic_address;
+  lldb::TargetSP target_sp(GetTargetSP());
+  lldb::addr_t load_address = m_address.GetLoadAddress(target_sp.get());
+  m_value.GetScalar() = load_address;
+}
   }
 
   if (runtime)
@@ -258,7 +266,11 @@ bool ValueObjectDynamicValue::UpdateValue() {
 LLDB_LOGF(log, "[%s %p] has a new dynamic type %s", GetName().GetCString(),
   static_cast(this), GetTypeName().GetCString());
 
-  if (m_address.IsValid() && m_dynamic_type_info) {
+  // m_address could be invalid but we could still have a local buffer
+  // containing the dynamic value.
+  if ((m_address.IsValid() ||
+   m_value.GetValueType() == Value::ValueType::HostAddress) &&
+  m_dynamic_type_info) {
 // The variable value is in the Scalar value inside the m_value. We can
 // point our m_data right to it.
 m_error = m_value.GetValueAsData(&exe_ctx, m_data, GetModule().get());

>From 64eb2c0365daf780a0e372c0fcbd9e4023c6a518 Mon Sep 17 00:00:00 2001
From: Augusto Noronha 
Date: Mon, 3 Feb 2025 11:23:41 -0800
Subject: [PATCH 2/4] Added a new local_buffer parameter to
 GetDynamicTypeAndAddress

---
 lldb/include/lldb/Target/LanguageRuntime.h   | 16 
 lldb/include/lldb/ValueObject/ValueObject.h  | 12 
 .../ItaniumABI/ItaniumABILanguageRuntime.cpp |  2 +-
 .../ItaniumABI/ItaniumABILanguageRuntime.h   |  4 ++--
 .../ObjC/AppleObjCRuntime/AppleObjCRuntime.cpp   |  2 +-
 .../ObjC/AppleObjCRuntime/AppleObjCRuntime.h |  4 ++--
 .../ObjC/AppleObjCRuntime/AppleObjCRuntimeV1.cpp |  2 +-
 .../ObjC/AppleObjCRuntime/AppleObjCRuntimeV1.h   |  4 ++--
 .../ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp |  2 +-
 .../ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.h   |  4 ++--
 .../GNUstepObjCRuntime/GNUstepObjCRuntime.cpp|  2 +-
 .../ObjC/GNUstepObjCRuntime/GNUstepObjCRuntime.h |  4 ++--
 lldb/source/ValueObject/ValueObject.cpp  | 16 
 .../ValueObject/ValueObjectDynamicValue.cpp  | 13 +++--
 14 files changed, 58 insertions(+), 29 deletions(-)

diff --git a/lldb/include/lldb/Target/LanguageRuntime.h 
b/lldb/include/lldb/Target/LanguageRuntime.h
index 08db8a17a67e69..da7b4801be6691 100644
--- a/lldb/include/lldb/Targ

[Lldb-commits] [lldb] [lldb] Make ValueObjectDynamicValue::UpdateValue() point to a host b… (PR #125143)

2025-02-03 Thread via lldb-commits


github-actions[bot] wrote:




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



You can test this locally with the following command:


``bash
git-clang-format --diff 6a05beeb2bed366f7e6e0056a758c6f8d385fdde 
c6d65f18c647a06a4df9e36b766dce3edeaa4006 --extensions h,cpp -- 
lldb/include/lldb/Target/LanguageRuntime.h 
lldb/include/lldb/ValueObject/ValueObject.h 
lldb/source/Plugins/LanguageRuntime/CPlusPlus/ItaniumABI/ItaniumABILanguageRuntime.cpp
 
lldb/source/Plugins/LanguageRuntime/CPlusPlus/ItaniumABI/ItaniumABILanguageRuntime.h
 lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntime.cpp 
lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntime.h 
lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV1.cpp
 lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV1.h 
lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp
 lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.h 
lldb/source/Plugins/LanguageRuntime/ObjC/GNUstepObjCRuntime/GNUstepObjCRuntime.cpp
 
lldb/source/Plugins/LanguageRuntime/ObjC/GNUstepObjCRuntime/GNUstepObjCRuntime.h
 lldb/source/ValueObject/ValueObject.cpp 
lldb/source/ValueObject/ValueObjectDynamicValue.cpp
``





View the diff from clang-format here.


``diff
diff --git a/lldb/include/lldb/Target/LanguageRuntime.h 
b/lldb/include/lldb/Target/LanguageRuntime.h
index 4af3e0e5d8..f9ae2dc589 100644
--- a/lldb/include/lldb/Target/LanguageRuntime.h
+++ b/lldb/include/lldb/Target/LanguageRuntime.h
@@ -108,9 +108,9 @@ public:
   /// This call should return true if it could set the name and/or the type
   /// Sets address to the address of the dynamic type if value_type is set to
   /// a file or load address. Sets local_buffer to a buffer containing the data
-  /// of the dynamic type if value_type is set to a host address. Callers 
should 
+  /// of the dynamic type if value_type is set to a host address. Callers 
should
   /// copy local_buffer over into their own buffer if they want to keep the 
data
-  ///alive.
+  /// alive.
   virtual bool GetDynamicTypeAndAddress(
   ValueObject &in_value, lldb::DynamicValueType use_dynamic,
   TypeAndOrName &class_type_or_name, Address &address,

``




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

[Lldb-commits] [lldb] [lldb] Make ValueObjectDynamicValue::UpdateValue() point to a host b… (PR #125143)

2025-02-03 Thread Augusto Noronha via lldb-commits


augusto2112 wrote:

Unfortunately I wasn't able to construct a test case that would trigger this 
with upstream lldb.

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

[Lldb-commits] [lldb] [lldb] Show value for libcxx and libstdcxx summary and remove pointer value in libcxx container summary (PR #125294)

2025-02-03 Thread Zequan Wu via lldb-commits


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

[Lldb-commits] [lldb] 79e804b - [lldb] Improve isolation between Process plugins and OS plugins (#125302)

2025-02-03 Thread via lldb-commits


Author: Felipe de Azevedo Piovezan
Date: 2025-02-03T14:54:51-08:00
New Revision: 79e804b478aafdb9f543c66c1cc9cca6908d6b8f

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

LOG: [lldb] Improve isolation between Process plugins and OS plugins (#125302)

Generally speaking, process plugins (e.g. ProcessGDBRemote) should not
be aware of OS plugin threads. However, ProcessGDBRemote attempts to
check for the existence of OS threads when calculating stop info. When
OS threads are present, it sets the stop info directly on the OS plugin
thread and leaves the ThreadGDBRemote without a StopInfo.

This is problematic for a few reasons:

1. No other process plugins do this, as they shouldn't. They should set
the stop info for their own process threads, and let the abstractions
built on top propagate StopInfos.

2. This conflicts with the expectations of ThreadMemory, which checks
for the backing threads's info, and then attempts to propagate it (in
the future, it should probably ask the plugin itself too...). We see
this happening in the code below. The `if` condition will not trigger,
because `backing_stop_info_sp` will be null (remember, ProcessGDB remote
is ignoring its own threads), and then this method returns false.

```
bool ThreadMemory::CalculateStopInfo() {
...
  lldb::StopInfoSP backing_stop_info_sp(
  m_backing_thread_sp->GetPrivateStopInfo());
  if (backing_stop_info_sp &&
  backing_stop_info_sp->IsValidForOperatingSystemThread(*this)) {
backing_stop_info_sp->SetThread(shared_from_this());
```

```
Thread::GetPrivateStopInfo
...
if (!CalculateStopInfo())
  SetStopInfo(StopInfoSP());
```

To solve this, we change ProcessGDB remote so that it does the
principled thing: it now only sets the stop info of its own threads.
This change by itself breaks the tests TestPythonOSPlugin.py and
TestOSPluginStepping.py and probably explains why ProcessGDB had
originally "violated" this isolation of layers.

To make this work, BreakpointSites must be aware of BackingThreads when
answering the question: "Is this breakpoint valid for this thread?".
Why? Breakpoints are created on top of the OS threads (that's what the
user sees), but breakpoints are hit by process threads. In the presence
of OS threads, a TID-specific breakpoint is valid for a process thread
if it is backing an OS thread with that TID.

Added: 
lldb/unittests/OperatingSystem/CMakeLists.txt
lldb/unittests/OperatingSystem/OperatingSystemPlugin.h
lldb/unittests/OperatingSystem/TestThreadSpecificBreakpoints.cpp

Modified: 
lldb/source/Breakpoint/BreakpointSite.cpp
lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp

Removed: 




diff  --git a/lldb/source/Breakpoint/BreakpointSite.cpp 
b/lldb/source/Breakpoint/BreakpointSite.cpp
index 9700a57d3346e0b..8b964c5711468ca 100644
--- a/lldb/source/Breakpoint/BreakpointSite.cpp
+++ b/lldb/source/Breakpoint/BreakpointSite.cpp
@@ -12,6 +12,7 @@
 
 #include "lldb/Breakpoint/Breakpoint.h"
 #include "lldb/Breakpoint/BreakpointLocation.h"
+#include "lldb/Target/Thread.h"
 #include "lldb/Utility/Stream.h"
 
 using namespace lldb;
@@ -161,6 +162,8 @@ BreakpointLocationSP 
BreakpointSite::GetConstituentAtIndex(size_t index) {
 
 bool BreakpointSite::ValidForThisThread(Thread &thread) {
   std::lock_guard guard(m_constituents_mutex);
+  if (ThreadSP backed_thread = thread.GetBackedThread())
+return m_constituents.ValidForThisThread(*backed_thread);
   return m_constituents.ValidForThisThread(thread);
 }
 

diff  --git a/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp 
b/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
index 3f34ea2930a66a0..07b4470d0619180 100644
--- a/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
+++ b/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
@@ -1726,10 +1726,6 @@ ThreadSP ProcessGDBRemote::SetThreadStopInfo(
 
   if (!thread_sp->StopInfoIsUpToDate()) {
 thread_sp->SetStopInfo(StopInfoSP());
-// If there's a memory thread backed by this thread, we need to use it to
-// calculate StopInfo.
-if (ThreadSP memory_thread_sp = thread_sp->GetBackedThread())
-  thread_sp = memory_thread_sp;
 
 if (exc_type != 0) {
   // For thread plan async interrupt, creating stop info on the

diff  --git a/lldb/unittests/OperatingSystem/CMakeLists.txt 
b/lldb/unittests/OperatingSystem/CMakeLists.txt
new file mode 100644
index 000..ae810f37b057747
--- /dev/null
+++ b/lldb/unittests/OperatingSystem/CMakeLists.txt
@@ -0,0 +1,21 @@
+add_lldb_unittest(ProcessGdbRemoteTests
+  GDBRemoteClientBaseTest.cpp
+  GDBRemoteCommunicationClientTest.cpp
+  GDBRemoteCommunicationServerLLGSTest.cpp
+  GDBRemoteCommunicationServerTest.cpp
+  GDBRemoteCommunicationTest.cpp
+

[Lldb-commits] [lldb] [lldb] Improve isolation between Process plugins and OS plugins (PR #125302)

2025-02-03 Thread Felipe de Azevedo Piovezan via lldb-commits


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

[Lldb-commits] [lldb] [llvm] [lldb-dap] Support column breakpoints (PR #125347)

2025-02-03 Thread Walter Erquinigo via lldb-commits


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

Thanks!!

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

[Lldb-commits] [lldb] [lldb] Implement bidirectional access for backing<->backed thread relationship (PR #125300)

2025-02-03 Thread Felipe de Azevedo Piovezan via lldb-commits


felipepiovezan wrote:

Forcing push seems to have made it work

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

[Lldb-commits] [lldb] [lldb] Store the command in the CommandReturnObject (PR #125132)

2025-02-03 Thread Pavel Labath via lldb-commits


https://github.com/labath commented:

This idea has bothered me from the beginning, but I didn't want to say 
anything, as it was mostly just a feeling. After seeing this patch, I think I 
can put some words behind it.

The thing I don't like about this patch is the repetition/redundancy it 
creates. Like, you first create the CommandReturnObject, give it the command 
it's hold the result of. Then, you pass that object into HandleCommand, but 
that's not all you give it -- the function takes the string of the command, 
again.

It's not the end of the world, but I think it's unfortunate, and while it works 
nice for your current use case, I don't think it makes that much sense for 
other usages. For example, if the `CommandReturnObject` had always contained 
the command part, would the signature of a python command still be `def 
cmd(debugger, command, result, dict):`, or would we have expected the command 
to retrieve it from the result object?

It's hard to say, but what I think we can say is that if you make your current 
callback take the "command" and the "result of that command" as two separate 
arguments, then it will at least be consistent with the signature above.

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

[Lldb-commits] [lldb] [LLDB] Add Lexer (with tests) for DIL (Data Inspection Language). (PR #123521)

2025-02-03 Thread Pavel Labath via lldb-commits



@@ -0,0 +1,131 @@
+//===-- DILLexer.h --*- C++ 
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef LLDB_VALUEOBJECT_DILLEXER_H_
+#define LLDB_VALUEOBJECT_DILLEXER_H_
+
+#include "llvm/ADT/StringRef.h"
+#include "llvm/ADT/iterator_range.h"
+#include "llvm/Support/Error.h"
+#include 
+#include 
+#include 
+#include 
+#include 
+
+namespace lldb_private::dil {
+
+/// Class defining the tokens generated by the DIL lexer and used by the
+/// DIL parser.
+class Token {
+public:
+  enum Kind {
+coloncolon,
+eof,
+identifier,
+l_paren,
+r_paren,
+unknown,
+  };
+
+  Token(Kind kind, std::string spelling, uint32_t start)
+  : m_kind(kind), m_spelling(spelling), m_start_pos(start) {}
+
+  Kind GetKind() const { return m_kind; }
+
+  std::string GetSpelling() const { return m_spelling; }
+
+  bool Is(Kind kind) const { return m_kind == kind; }
+
+  bool IsNot(Kind kind) const { return m_kind != kind; }
+
+  bool IsOneOf(Kind kind1, Kind kind2) const { return Is(kind1) || Is(kind2); }
+
+  template  bool IsOneOf(Kind kind, Ts... Ks) const {
+return Is(kind) || IsOneOf(Ks...);
+  }
+
+  uint32_t GetLocation() const { return m_start_pos; }
+
+  static llvm::StringRef GetTokenName(Kind kind);
+
+private:
+  Kind m_kind;
+  std::string m_spelling;
+  uint32_t m_start_pos; // within entire expression string
+};
+
+/// Class for doing the simple lexing required by DIL.
+class DILLexer {
+public:
+  /// Lexes all the tokens in expr and calls the private constructor
+  /// with the lexed tokens.
+  static llvm::Expected Create(llvm::StringRef expr);
+
+  /// Return the current token to be handled by the DIL parser.
+  const Token &GetCurrentToken() { return m_lexed_tokens[m_tokens_idx]; }
+
+  /// Advance the current token position by N.
+  void Advance(uint32_t N = 1) {
+// UINT_MAX means uninitialized, no "current" position, so move to start.
+if (m_tokens_idx == UINT_MAX)

labath wrote:

And why is that the case? I don't find this argument particularly convincing. 
All it does is create a weird "before the first token" state, which you have to 
account for both in the implementation of the lexer functions and in the 
functions that use that. I think things would be much simpler if you could just 
always assume that the lexer has a valid "current" position, and I think that's 
basically we have the eof pseudo-token. If there was some value in having a 
"before-the first token" state, then i think it'd be better to have a `bof` 
pseudo-token to match that (but I doubt that's the case).

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

[Lldb-commits] [lldb] [LLDB] Add Lexer (with tests) for DIL (Data Inspection Language). (PR #123521)

2025-02-03 Thread Pavel Labath via lldb-commits



@@ -0,0 +1,131 @@
+//===-- DILLexer.h --*- C++ 
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef LLDB_VALUEOBJECT_DILLEXER_H_
+#define LLDB_VALUEOBJECT_DILLEXER_H_
+
+#include "llvm/ADT/StringRef.h"
+#include "llvm/ADT/iterator_range.h"
+#include "llvm/Support/Error.h"
+#include 
+#include 
+#include 
+#include 
+#include 
+
+namespace lldb_private::dil {
+
+/// Class defining the tokens generated by the DIL lexer and used by the
+/// DIL parser.
+class Token {
+public:
+  enum Kind {
+coloncolon,
+eof,
+identifier,
+l_paren,
+r_paren,
+unknown,

labath wrote:

Maybe that variable should be `optional` then? Though I'm not sure why 
it's needed as things could just call `lexer.GetCurrentToken()` instead. In 
either case, I'd like to remove this from this patch as its not needed here. If 
it turns out to be the best solution to the parsers needs, we can add the extra 
type then.

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

[Lldb-commits] [lldb] 5c065f0 - [lldb][Windows] Fix build with MSVC compiler broken by (#108072)

2025-02-03 Thread Muhammad Omair Javaid via lldb-commits


Author: Muhammad Omair Javaid
Date: 2025-02-03T15:17:08+05:00
New Revision: 5c065f01cee5dfca28d703983d0ebefa65128e09

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

LOG: [lldb][Windows] Fix build with MSVC compiler broken by (#108072)

This patch fixes LLDB Windows build with MSVC compiler. MSVC deletes
the default constructor due to virtual inheritance rules. Explicitly
define the default constructor in NativeRegisterContextWindows to
ensure constructibility.

Added: 


Modified: 
lldb/source/Plugins/Process/Windows/Common/NativeRegisterContextWindows.h

Removed: 




diff  --git 
a/lldb/source/Plugins/Process/Windows/Common/NativeRegisterContextWindows.h 
b/lldb/source/Plugins/Process/Windows/Common/NativeRegisterContextWindows.h
index 0f9e37dbd9f527..2b71f639d562e9 100644
--- a/lldb/source/Plugins/Process/Windows/Common/NativeRegisterContextWindows.h
+++ b/lldb/source/Plugins/Process/Windows/Common/NativeRegisterContextWindows.h
@@ -24,6 +24,10 @@ class NativeRegisterContextWindows
   CreateHostNativeRegisterContextWindows(const ArchSpec &target_arch,
  NativeThreadProtocol &native_thread);
 
+  // MSVC compiler deletes the default constructor due to virtual inheritance.
+  // Explicitly defining it ensures the class remains constructible.
+  NativeRegisterContextWindows() {}
+
 protected:
   lldb::thread_t GetThreadHandle() const;
 };



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

[Lldb-commits] [lldb] [LLDB] Add Lexer (with tests) for DIL (Data Inspection Language). (PR #123521)

2025-02-03 Thread Pavel Labath via lldb-commits



@@ -0,0 +1,132 @@
+//===-- DILLexer.cpp 
--===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+// This implements the recursive descent parser for the Data Inspection
+// Language (DIL), and its helper functions, which will eventually underlie the
+// 'frame variable' command. The language that this parser recognizes is
+// described in lldb/docs/dil-expr-lang.ebnf
+//
+//===--===//
+
+#include "lldb/ValueObject/DILLexer.h"
+#include "lldb/Utility/Status.h"
+#include "llvm/ADT/StringSwitch.h"
+
+namespace lldb_private::dil {
+
+llvm::StringRef Token::GetTokenName(Kind kind) {
+  switch (kind) {
+  case Kind::coloncolon:
+return "coloncolon";
+  case Kind::eof:
+return "eof";
+  case Kind::identifier:
+return "identifier";
+  case Kind::l_paren:
+return "l_paren";
+  case Kind::r_paren:
+return "r_paren";
+  case Kind::unknown:
+return "unknown";
+  }
+}
+
+static bool IsLetter(char c) {
+  return ('a' <= c && c <= 'z') || ('A' <= c && c <= 'Z');
+}
+
+static bool IsDigit(char c) { return '0' <= c && c <= '9'; }
+
+// A word starts with a letter, underscore, or dollar sign, followed by
+// letters ('a'..'z','A'..'Z'), digits ('0'..'9'), and/or  underscores.
+static std::optional IsWord(llvm::StringRef expr,
+ llvm::StringRef &remainder) {
+  llvm::StringRef::iterator cur_pos = expr.end() - remainder.size();
+  llvm::StringRef::iterator start = cur_pos;
+  bool dollar_start = false;
+
+  // Must not start with a digit.
+  if (cur_pos == expr.end() || IsDigit(*cur_pos))
+return std::nullopt;
+
+  // First character *may* be a '$', for a register name or convenience
+  // variable.
+  if (*cur_pos == '$') {
+dollar_start = true;
+++cur_pos;
+  }
+
+  // Contains only letters, digits or underscores
+  for (; cur_pos != expr.end(); ++cur_pos) {
+char c = *cur_pos;
+if (!IsLetter(c) && !IsDigit(c) && c != '_')
+  break;
+  }
+
+  // If first char is '$', make sure there's at least one mare char, or it's
+  // invalid.
+  if (dollar_start && (cur_pos - start <= 1)) {
+cur_pos = start;
+return std::nullopt;
+  }
+
+  if (cur_pos == start)
+return std::nullopt;
+
+  llvm::StringRef word = expr.substr(start - expr.begin(), cur_pos - start);
+  if (remainder.consume_front(word))
+return word;
+
+  return std::nullopt;
+}
+
+llvm::Expected DILLexer::Create(llvm::StringRef expr) {
+  std::vector tokens;
+  llvm::StringRef remainder = expr;
+  do {
+if (llvm::Expected t = Lex(expr, remainder)) {
+  tokens.push_back(std::move(*t));
+} else {
+  return t.takeError();
+}
+  } while (tokens.back().GetKind() != Token::eof);
+  return DILLexer(expr, std::move(tokens));
+}
+
+llvm::Expected DILLexer::Lex(llvm::StringRef expr,
+llvm::StringRef &remainder) {
+  // Skip over whitespace (spaces).
+  remainder = remainder.ltrim();
+  llvm::StringRef::iterator cur_pos = expr.end() - remainder.size();

labath wrote:

But that's the same thing. Both stringrefs are just pointers to the same 
underlying string. `StringRef::iterator` is just a fancy name for `const char 
*`.  Would it look better to you if this was written as `const char *cur_pos = 
remainder.data();` ?

Or even better, since this is only used constructing the `position` value below 
(I'm ignoring the check below), you can just drop this and construct position 
directly as `remainder.data()-expr.data()`

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

[Lldb-commits] [lldb] [LLDB] Add Lexer (with tests) for DIL (Data Inspection Language). (PR #123521)

2025-02-03 Thread Pavel Labath via lldb-commits



@@ -0,0 +1,132 @@
+//===-- DILLexer.cpp 
--===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+// This implements the recursive descent parser for the Data Inspection
+// Language (DIL), and its helper functions, which will eventually underlie the
+// 'frame variable' command. The language that this parser recognizes is
+// described in lldb/docs/dil-expr-lang.ebnf
+//
+//===--===//
+
+#include "lldb/ValueObject/DILLexer.h"
+#include "lldb/Utility/Status.h"
+#include "llvm/ADT/StringSwitch.h"
+
+namespace lldb_private::dil {
+
+llvm::StringRef Token::GetTokenName(Kind kind) {
+  switch (kind) {
+  case Kind::coloncolon:
+return "coloncolon";
+  case Kind::eof:
+return "eof";
+  case Kind::identifier:
+return "identifier";
+  case Kind::l_paren:
+return "l_paren";
+  case Kind::r_paren:
+return "r_paren";
+  case Kind::unknown:
+return "unknown";
+  }
+}
+
+static bool IsLetter(char c) {
+  return ('a' <= c && c <= 'z') || ('A' <= c && c <= 'Z');
+}
+
+static bool IsDigit(char c) { return '0' <= c && c <= '9'; }
+
+// A word starts with a letter, underscore, or dollar sign, followed by
+// letters ('a'..'z','A'..'Z'), digits ('0'..'9'), and/or  underscores.
+static std::optional IsWord(llvm::StringRef expr,
+ llvm::StringRef &remainder) {
+  llvm::StringRef::iterator cur_pos = expr.end() - remainder.size();
+  llvm::StringRef::iterator start = cur_pos;
+  bool dollar_start = false;
+
+  // Must not start with a digit.
+  if (cur_pos == expr.end() || IsDigit(*cur_pos))
+return std::nullopt;
+
+  // First character *may* be a '$', for a register name or convenience
+  // variable.
+  if (*cur_pos == '$') {
+dollar_start = true;
+++cur_pos;
+  }
+
+  // Contains only letters, digits or underscores
+  for (; cur_pos != expr.end(); ++cur_pos) {
+char c = *cur_pos;
+if (!IsLetter(c) && !IsDigit(c) && c != '_')
+  break;
+  }
+
+  // If first char is '$', make sure there's at least one mare char, or it's
+  // invalid.
+  if (dollar_start && (cur_pos - start <= 1)) {
+cur_pos = start;
+return std::nullopt;
+  }
+
+  if (cur_pos == start)
+return std::nullopt;
+
+  llvm::StringRef word = expr.substr(start - expr.begin(), cur_pos - start);
+  if (remainder.consume_front(word))
+return word;
+
+  return std::nullopt;
+}
+
+llvm::Expected DILLexer::Create(llvm::StringRef expr) {
+  std::vector tokens;
+  llvm::StringRef remainder = expr;
+  do {
+if (llvm::Expected t = Lex(expr, remainder)) {
+  tokens.push_back(std::move(*t));
+} else {
+  return t.takeError();
+}
+  } while (tokens.back().GetKind() != Token::eof);
+  return DILLexer(expr, std::move(tokens));
+}
+
+llvm::Expected DILLexer::Lex(llvm::StringRef expr,
+llvm::StringRef &remainder) {
+  // Skip over whitespace (spaces).
+  remainder = remainder.ltrim();
+  llvm::StringRef::iterator cur_pos = expr.end() - remainder.size();
+
+  // Check to see if we've reached the end of our input string.
+  if (remainder.empty() || cur_pos == expr.end())

labath wrote:

When I see code like this I start to wonder whether there's an edge case I'm 
missing. Defensive checks *may* make sense on some external API which is called 
from a bunch of places, but here we're talking about a private function that's 
only called from a single place. At best that deserves an assertion (you could 
e.g. say `assert(expr.end() == remainder.end())` at the beginning of the 
function.

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

[Lldb-commits] [lldb] [LLDB] Add Lexer (with tests) for DIL (Data Inspection Language). (PR #123521)

2025-02-03 Thread Pavel Labath via lldb-commits



@@ -0,0 +1,192 @@
+//===-- DILLexerTests.cpp ===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "lldb/ValueObject/DILLexer.h"
+#include "llvm/ADT/StringRef.h"
+#include "llvm/Testing/Support/Error.h"
+#include "gtest/gtest.h"
+#include 
+
+using llvm::StringRef;
+
+std::vector>
+ExtractTokenData(lldb_private::dil::DILLexer &lexer) {
+  std::vector> data;
+  if (lexer.NumLexedTokens() == 0)
+return data;
+
+  lexer.ResetTokenIdx(UINT_MAX);
+  do {
+lexer.Advance();
+lldb_private::dil::Token tok = lexer.GetCurrentToken();
+data.push_back(std::make_pair(tok.GetKind(), tok.GetSpelling()));
+  } while (data.back().first != lldb_private::dil::Token::eof);
+  return data;
+}
+
+TEST(DILLexerTests, SimpleTest) {
+  StringRef input_expr("simple_var");
+  uint32_t tok_len = 10;
+  llvm::Expected maybe_lexer =
+  lldb_private::dil::DILLexer::Create(input_expr);
+  ASSERT_THAT_EXPECTED(maybe_lexer, llvm::Succeeded());
+  lldb_private::dil::DILLexer lexer(*maybe_lexer);
+  lldb_private::dil::Token token =
+  lldb_private::dil::Token(lldb_private::dil::Token::unknown, "", 0);
+  EXPECT_EQ(token.GetKind(), lldb_private::dil::Token::unknown);
+
+  lexer.Advance();
+  token = lexer.GetCurrentToken();
+  EXPECT_EQ(token.GetKind(), lldb_private::dil::Token::identifier);
+  EXPECT_EQ(token.GetSpelling(), "simple_var");
+  EXPECT_EQ(token.GetSpelling().size(), tok_len);
+  lexer.Advance();
+  token = lexer.GetCurrentToken();
+  EXPECT_EQ(token.GetKind(), lldb_private::dil::Token::eof);
+}
+
+TEST(DILLexerTests, TokenKindTest) {
+  StringRef input_expr("namespace");
+  llvm::Expected maybe_lexer =
+  lldb_private::dil::DILLexer::Create(input_expr);
+  ASSERT_THAT_EXPECTED(maybe_lexer, llvm::Succeeded());
+  lldb_private::dil::DILLexer lexer(*maybe_lexer);
+  lldb_private::dil::Token token =
+  lldb_private::dil::Token(lldb_private::dil::Token::unknown, "", 0);
+  lexer.Advance();
+  token = lexer.GetCurrentToken();
+
+  EXPECT_TRUE(token.Is(lldb_private::dil::Token::identifier));
+  EXPECT_FALSE(token.Is(lldb_private::dil::Token::l_paren));
+  EXPECT_TRUE(token.IsOneOf(lldb_private::dil::Token::eof,
+lldb_private::dil::Token::identifier));
+  EXPECT_FALSE(token.IsOneOf(
+  lldb_private::dil::Token::l_paren, lldb_private::dil::Token::r_paren,
+  lldb_private::dil::Token::coloncolon, lldb_private::dil::Token::eof));
+}
+
+TEST(DILLexerTests, LookAheadTest) {
+  StringRef input_expr("(anonymous namespace)::some_var");
+  llvm::Expected maybe_lexer =
+  lldb_private::dil::DILLexer::Create(input_expr);
+  ASSERT_THAT_EXPECTED(maybe_lexer, llvm::Succeeded());
+  lldb_private::dil::DILLexer lexer(*maybe_lexer);
+  lldb_private::dil::Token token =
+  lldb_private::dil::Token(lldb_private::dil::Token::unknown, "", 0);
+  uint32_t expect_loc = 23;
+  lexer.Advance();
+  token = lexer.GetCurrentToken();
+
+  // Current token is '('; check the next 4 tokens, to make
+  // sure they are the identifier 'anonymous', the identifier 'namespace'
+  // ')' and '::', in that order.
+  EXPECT_EQ(token.GetKind(), lldb_private::dil::Token::l_paren);
+  EXPECT_EQ(lexer.LookAhead(1).GetKind(), 
lldb_private::dil::Token::identifier);
+  EXPECT_EQ(lexer.LookAhead(1).GetSpelling(), "anonymous");
+  EXPECT_EQ(lexer.LookAhead(2).GetKind(), 
lldb_private::dil::Token::identifier);
+  EXPECT_EQ(lexer.LookAhead(2).GetSpelling(), "namespace");
+  EXPECT_EQ(lexer.LookAhead(3).GetKind(), lldb_private::dil::Token::r_paren);
+  EXPECT_EQ(lexer.LookAhead(4).GetKind(), 
lldb_private::dil::Token::coloncolon);
+
+  // Our current index should still be 0, as we only looked ahead; we are still
+  // officially on the '('.
+  EXPECT_EQ(lexer.GetCurrentTokenIdx(), (uint32_t)0);
+
+  // Accept the 'lookahead', so our current token is '::', which has the index
+  // 4 in our vector of tokens (which starts at zero).
+  lexer.Advance(4);
+  token = lexer.GetCurrentToken();
+  EXPECT_EQ(token.GetKind(), lldb_private::dil::Token::coloncolon);
+  EXPECT_EQ(lexer.GetCurrentTokenIdx(), (uint32_t)4);
+
+  lexer.Advance();
+  token = lexer.GetCurrentToken();
+  EXPECT_EQ(token.GetKind(), lldb_private::dil::Token::identifier);
+  EXPECT_EQ(token.GetSpelling(), "some_var");
+  EXPECT_EQ(lexer.GetCurrentTokenIdx(), (uint32_t)5);
+  // Verify we've advanced our position counter (lexing location) in the
+  // input 23 characters (the length of '(anonymous namespace)::'.
+  EXPECT_EQ(token.GetLocation(), expect_loc);
+
+  lexer.Advance();
+  token = lexer.GetCurrentToken();
+  EXPECT_EQ(token.GetKind(), lldb_private::dil::Token::eof);
+}
+
+TEST(DILLexerTests, MultiTokenLexTest) {
+  StringRef inpu

[Lldb-commits] [lldb] [LLDB] Add Lexer (with tests) for DIL (Data Inspection Language). (PR #123521)

2025-02-03 Thread Pavel Labath via lldb-commits



@@ -0,0 +1,132 @@
+//===-- DILLexer.cpp 
--===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+// This implements the recursive descent parser for the Data Inspection
+// Language (DIL), and its helper functions, which will eventually underlie the
+// 'frame variable' command. The language that this parser recognizes is
+// described in lldb/docs/dil-expr-lang.ebnf
+//
+//===--===//
+
+#include "lldb/ValueObject/DILLexer.h"
+#include "lldb/Utility/Status.h"
+#include "llvm/ADT/StringSwitch.h"
+
+namespace lldb_private::dil {
+
+llvm::StringRef Token::GetTokenName(Kind kind) {
+  switch (kind) {
+  case Kind::coloncolon:
+return "coloncolon";
+  case Kind::eof:
+return "eof";
+  case Kind::identifier:
+return "identifier";
+  case Kind::l_paren:
+return "l_paren";
+  case Kind::r_paren:
+return "r_paren";
+  case Kind::unknown:
+return "unknown";
+  }
+}
+
+static bool IsLetter(char c) {
+  return ('a' <= c && c <= 'z') || ('A' <= c && c <= 'Z');
+}
+
+static bool IsDigit(char c) { return '0' <= c && c <= '9'; }
+
+// A word starts with a letter, underscore, or dollar sign, followed by
+// letters ('a'..'z','A'..'Z'), digits ('0'..'9'), and/or  underscores.
+static std::optional IsWord(llvm::StringRef expr,
+ llvm::StringRef &remainder) {
+  llvm::StringRef::iterator cur_pos = expr.end() - remainder.size();
+  llvm::StringRef::iterator start = cur_pos;
+  bool dollar_start = false;
+
+  // Must not start with a digit.
+  if (cur_pos == expr.end() || IsDigit(*cur_pos))
+return std::nullopt;
+
+  // First character *may* be a '$', for a register name or convenience
+  // variable.
+  if (*cur_pos == '$') {
+dollar_start = true;
+++cur_pos;
+  }
+
+  // Contains only letters, digits or underscores
+  for (; cur_pos != expr.end(); ++cur_pos) {
+char c = *cur_pos;
+if (!IsLetter(c) && !IsDigit(c) && c != '_')
+  break;
+  }
+
+  // If first char is '$', make sure there's at least one mare char, or it's
+  // invalid.
+  if (dollar_start && (cur_pos - start <= 1)) {
+cur_pos = start;
+return std::nullopt;
+  }
+
+  if (cur_pos == start)
+return std::nullopt;
+
+  llvm::StringRef word = expr.substr(start - expr.begin(), cur_pos - start);
+  if (remainder.consume_front(word))
+return word;
+
+  return std::nullopt;

labath wrote:

The key thing to realize here is that a StringRef is just a fancy name for a 
`pair`. On its own, it doesn't make anything valid. It's 
only valid as long as the string it points to is valid. And the same goes for 
the validity pointers you get from the StringRef. This is just a pointer to the 
parsed string, which will remain valid for as long as that string is around -- 
regardless of what happens to the StringRef.

That said, I realized a different problem with this code. It will end up 
modifying the remainder even in the failure case. So here's a slightly 
different version which avoids that. This one isn't completely equivalent, as 
I've dropped the requirement on the positioning of the dollar sign, but that's 
something I very strongly believe we should do anyway.

```
StringRef candidate = remainder.take_while([](char c) { return IsDigit(c) || 
IsLetter(c) || c=='_' || c=='$'; });
if (candidate.empty() || IsDigit(candidate[0]))
  return std::nullopt;
remainder.drop_front(candidate.size());
return candidate;
```

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

[Lldb-commits] [lldb] [LLDB] Add Lexer (with tests) for DIL (Data Inspection Language). (PR #123521)

2025-02-03 Thread Pavel Labath via lldb-commits



@@ -0,0 +1,192 @@
+//===-- DILLexerTests.cpp ===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "lldb/ValueObject/DILLexer.h"
+#include "llvm/ADT/StringRef.h"
+#include "llvm/Testing/Support/Error.h"
+#include "gtest/gtest.h"
+#include 
+
+using llvm::StringRef;
+
+std::vector>
+ExtractTokenData(lldb_private::dil::DILLexer &lexer) {
+  std::vector> data;
+  if (lexer.NumLexedTokens() == 0)
+return data;
+
+  lexer.ResetTokenIdx(UINT_MAX);
+  do {
+lexer.Advance();
+lldb_private::dil::Token tok = lexer.GetCurrentToken();
+data.push_back(std::make_pair(tok.GetKind(), tok.GetSpelling()));
+  } while (data.back().first != lldb_private::dil::Token::eof);
+  return data;
+}
+
+TEST(DILLexerTests, SimpleTest) {
+  StringRef input_expr("simple_var");
+  uint32_t tok_len = 10;
+  llvm::Expected maybe_lexer =
+  lldb_private::dil::DILLexer::Create(input_expr);
+  ASSERT_THAT_EXPECTED(maybe_lexer, llvm::Succeeded());
+  lldb_private::dil::DILLexer lexer(*maybe_lexer);
+  lldb_private::dil::Token token =
+  lldb_private::dil::Token(lldb_private::dil::Token::unknown, "", 0);
+  EXPECT_EQ(token.GetKind(), lldb_private::dil::Token::unknown);
+
+  lexer.Advance();
+  token = lexer.GetCurrentToken();
+  EXPECT_EQ(token.GetKind(), lldb_private::dil::Token::identifier);
+  EXPECT_EQ(token.GetSpelling(), "simple_var");
+  EXPECT_EQ(token.GetSpelling().size(), tok_len);
+  lexer.Advance();
+  token = lexer.GetCurrentToken();
+  EXPECT_EQ(token.GetKind(), lldb_private::dil::Token::eof);
+}
+
+TEST(DILLexerTests, TokenKindTest) {
+  StringRef input_expr("namespace");
+  llvm::Expected maybe_lexer =
+  lldb_private::dil::DILLexer::Create(input_expr);
+  ASSERT_THAT_EXPECTED(maybe_lexer, llvm::Succeeded());
+  lldb_private::dil::DILLexer lexer(*maybe_lexer);
+  lldb_private::dil::Token token =
+  lldb_private::dil::Token(lldb_private::dil::Token::unknown, "", 0);
+  lexer.Advance();
+  token = lexer.GetCurrentToken();
+
+  EXPECT_TRUE(token.Is(lldb_private::dil::Token::identifier));
+  EXPECT_FALSE(token.Is(lldb_private::dil::Token::l_paren));
+  EXPECT_TRUE(token.IsOneOf(lldb_private::dil::Token::eof,
+lldb_private::dil::Token::identifier));
+  EXPECT_FALSE(token.IsOneOf(
+  lldb_private::dil::Token::l_paren, lldb_private::dil::Token::r_paren,
+  lldb_private::dil::Token::coloncolon, lldb_private::dil::Token::eof));
+}
+
+TEST(DILLexerTests, LookAheadTest) {
+  StringRef input_expr("(anonymous namespace)::some_var");
+  llvm::Expected maybe_lexer =
+  lldb_private::dil::DILLexer::Create(input_expr);
+  ASSERT_THAT_EXPECTED(maybe_lexer, llvm::Succeeded());
+  lldb_private::dil::DILLexer lexer(*maybe_lexer);
+  lldb_private::dil::Token token =
+  lldb_private::dil::Token(lldb_private::dil::Token::unknown, "", 0);
+  uint32_t expect_loc = 23;
+  lexer.Advance();
+  token = lexer.GetCurrentToken();
+
+  // Current token is '('; check the next 4 tokens, to make
+  // sure they are the identifier 'anonymous', the identifier 'namespace'
+  // ')' and '::', in that order.
+  EXPECT_EQ(token.GetKind(), lldb_private::dil::Token::l_paren);
+  EXPECT_EQ(lexer.LookAhead(1).GetKind(), 
lldb_private::dil::Token::identifier);
+  EXPECT_EQ(lexer.LookAhead(1).GetSpelling(), "anonymous");
+  EXPECT_EQ(lexer.LookAhead(2).GetKind(), 
lldb_private::dil::Token::identifier);
+  EXPECT_EQ(lexer.LookAhead(2).GetSpelling(), "namespace");
+  EXPECT_EQ(lexer.LookAhead(3).GetKind(), lldb_private::dil::Token::r_paren);
+  EXPECT_EQ(lexer.LookAhead(4).GetKind(), 
lldb_private::dil::Token::coloncolon);
+
+  // Our current index should still be 0, as we only looked ahead; we are still
+  // officially on the '('.
+  EXPECT_EQ(lexer.GetCurrentTokenIdx(), (uint32_t)0);
+
+  // Accept the 'lookahead', so our current token is '::', which has the index
+  // 4 in our vector of tokens (which starts at zero).
+  lexer.Advance(4);
+  token = lexer.GetCurrentToken();
+  EXPECT_EQ(token.GetKind(), lldb_private::dil::Token::coloncolon);
+  EXPECT_EQ(lexer.GetCurrentTokenIdx(), (uint32_t)4);
+
+  lexer.Advance();
+  token = lexer.GetCurrentToken();
+  EXPECT_EQ(token.GetKind(), lldb_private::dil::Token::identifier);
+  EXPECT_EQ(token.GetSpelling(), "some_var");
+  EXPECT_EQ(lexer.GetCurrentTokenIdx(), (uint32_t)5);
+  // Verify we've advanced our position counter (lexing location) in the
+  // input 23 characters (the length of '(anonymous namespace)::'.
+  EXPECT_EQ(token.GetLocation(), expect_loc);
+
+  lexer.Advance();
+  token = lexer.GetCurrentToken();
+  EXPECT_EQ(token.GetKind(), lldb_private::dil::Token::eof);
+}
+
+TEST(DILLexerTests, MultiTokenLexTest) {
+  StringRef inpu

[Lldb-commits] [lldb] [LLDB] Add Lexer (with tests) for DIL (Data Inspection Language). (PR #123521)

2025-02-03 Thread Pavel Labath via lldb-commits



@@ -0,0 +1,192 @@
+//===-- DILLexerTests.cpp ===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "lldb/ValueObject/DILLexer.h"
+#include "llvm/ADT/StringRef.h"
+#include "llvm/Testing/Support/Error.h"
+#include "gtest/gtest.h"
+#include 
+
+using llvm::StringRef;
+
+std::vector>
+ExtractTokenData(lldb_private::dil::DILLexer &lexer) {
+  std::vector> data;
+  if (lexer.NumLexedTokens() == 0)
+return data;
+
+  lexer.ResetTokenIdx(UINT_MAX);
+  do {
+lexer.Advance();
+lldb_private::dil::Token tok = lexer.GetCurrentToken();
+data.push_back(std::make_pair(tok.GetKind(), tok.GetSpelling()));
+  } while (data.back().first != lldb_private::dil::Token::eof);
+  return data;
+}
+
+TEST(DILLexerTests, SimpleTest) {
+  StringRef input_expr("simple_var");
+  uint32_t tok_len = 10;
+  llvm::Expected maybe_lexer =
+  lldb_private::dil::DILLexer::Create(input_expr);
+  ASSERT_THAT_EXPECTED(maybe_lexer, llvm::Succeeded());
+  lldb_private::dil::DILLexer lexer(*maybe_lexer);
+  lldb_private::dil::Token token =
+  lldb_private::dil::Token(lldb_private::dil::Token::unknown, "", 0);
+  EXPECT_EQ(token.GetKind(), lldb_private::dil::Token::unknown);
+
+  lexer.Advance();
+  token = lexer.GetCurrentToken();
+  EXPECT_EQ(token.GetKind(), lldb_private::dil::Token::identifier);
+  EXPECT_EQ(token.GetSpelling(), "simple_var");
+  EXPECT_EQ(token.GetSpelling().size(), tok_len);
+  lexer.Advance();
+  token = lexer.GetCurrentToken();
+  EXPECT_EQ(token.GetKind(), lldb_private::dil::Token::eof);
+}
+
+TEST(DILLexerTests, TokenKindTest) {
+  StringRef input_expr("namespace");
+  llvm::Expected maybe_lexer =
+  lldb_private::dil::DILLexer::Create(input_expr);
+  ASSERT_THAT_EXPECTED(maybe_lexer, llvm::Succeeded());
+  lldb_private::dil::DILLexer lexer(*maybe_lexer);
+  lldb_private::dil::Token token =
+  lldb_private::dil::Token(lldb_private::dil::Token::unknown, "", 0);
+  lexer.Advance();
+  token = lexer.GetCurrentToken();
+
+  EXPECT_TRUE(token.Is(lldb_private::dil::Token::identifier));
+  EXPECT_FALSE(token.Is(lldb_private::dil::Token::l_paren));
+  EXPECT_TRUE(token.IsOneOf(lldb_private::dil::Token::eof,
+lldb_private::dil::Token::identifier));
+  EXPECT_FALSE(token.IsOneOf(
+  lldb_private::dil::Token::l_paren, lldb_private::dil::Token::r_paren,
+  lldb_private::dil::Token::coloncolon, lldb_private::dil::Token::eof));
+}
+
+TEST(DILLexerTests, LookAheadTest) {
+  StringRef input_expr("(anonymous namespace)::some_var");
+  llvm::Expected maybe_lexer =
+  lldb_private::dil::DILLexer::Create(input_expr);
+  ASSERT_THAT_EXPECTED(maybe_lexer, llvm::Succeeded());
+  lldb_private::dil::DILLexer lexer(*maybe_lexer);
+  lldb_private::dil::Token token =
+  lldb_private::dil::Token(lldb_private::dil::Token::unknown, "", 0);
+  uint32_t expect_loc = 23;
+  lexer.Advance();
+  token = lexer.GetCurrentToken();
+
+  // Current token is '('; check the next 4 tokens, to make
+  // sure they are the identifier 'anonymous', the identifier 'namespace'
+  // ')' and '::', in that order.
+  EXPECT_EQ(token.GetKind(), lldb_private::dil::Token::l_paren);
+  EXPECT_EQ(lexer.LookAhead(1).GetKind(), 
lldb_private::dil::Token::identifier);
+  EXPECT_EQ(lexer.LookAhead(1).GetSpelling(), "anonymous");
+  EXPECT_EQ(lexer.LookAhead(2).GetKind(), 
lldb_private::dil::Token::identifier);
+  EXPECT_EQ(lexer.LookAhead(2).GetSpelling(), "namespace");
+  EXPECT_EQ(lexer.LookAhead(3).GetKind(), lldb_private::dil::Token::r_paren);
+  EXPECT_EQ(lexer.LookAhead(4).GetKind(), 
lldb_private::dil::Token::coloncolon);
+
+  // Our current index should still be 0, as we only looked ahead; we are still
+  // officially on the '('.
+  EXPECT_EQ(lexer.GetCurrentTokenIdx(), (uint32_t)0);
+
+  // Accept the 'lookahead', so our current token is '::', which has the index
+  // 4 in our vector of tokens (which starts at zero).
+  lexer.Advance(4);
+  token = lexer.GetCurrentToken();
+  EXPECT_EQ(token.GetKind(), lldb_private::dil::Token::coloncolon);
+  EXPECT_EQ(lexer.GetCurrentTokenIdx(), (uint32_t)4);
+
+  lexer.Advance();
+  token = lexer.GetCurrentToken();
+  EXPECT_EQ(token.GetKind(), lldb_private::dil::Token::identifier);
+  EXPECT_EQ(token.GetSpelling(), "some_var");
+  EXPECT_EQ(lexer.GetCurrentTokenIdx(), (uint32_t)5);
+  // Verify we've advanced our position counter (lexing location) in the
+  // input 23 characters (the length of '(anonymous namespace)::'.
+  EXPECT_EQ(token.GetLocation(), expect_loc);
+
+  lexer.Advance();
+  token = lexer.GetCurrentToken();
+  EXPECT_EQ(token.GetKind(), lldb_private::dil::Token::eof);
+}
+
+TEST(DILLexerTests, MultiTokenLexTest) {
+  StringRef inpu

[Lldb-commits] [lldb] [lldb] Show value for libcxx and libstdcxx summary and remove pointer value in libcxx container summary (PR #125294)

2025-02-03 Thread Pavel Labath via lldb-commits


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


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

[Lldb-commits] [lldb] [lldb] Show value for libcxx and libstdcxx summary and remove pointer value in libcxx container summary (PR #125294)

2025-02-03 Thread Pavel Labath via lldb-commits



@@ -172,7 +172,4 @@ def test_ref_and_ptr(self):
 
 # The pointer should just show the right number of elements:
 
-ptrAddr = self.findVariable("ptr").GetValue()
-self.expect_expr(
-"ptr", result_type="std::span *", 
result_summary=f"{ptrAddr} size=5"
-)
+self.expect("frame variable ptr", patterns=["ptr = 0x.*", " size=5"])

labath wrote:

That makes sense, but you can still use `expect_expr` to match this. You just 
need to say `result_summary=re.compile("your_pattern")`

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

[Lldb-commits] [lldb] [lldb] Show value for libcxx and libstdcxx summary and remove pointer value in libcxx container summary (PR #125294)

2025-02-03 Thread Pavel Labath via lldb-commits



@@ -10,22 +10,37 @@
 
 
 class LibcxxVectorDataFormatterTestCase(TestBase):
-def check_numbers(self, var_name):
-self.expect(
-"frame variable " + var_name,
-substrs=[
-var_name + " = size=7",
-"[0] = 1",
-"[1] = 12",
-"[2] = 123",
-"[3] = 1234",
-"[4] = 12345",
-"[5] = 123456",
-"[6] = 1234567",
-"}",
-],
-)
-
+def check_numbers(self, var_name, show_ptr=False):
+if show_ptr:
+self.expect(
+"frame variable " + var_name,
+patterns=[var_name + " = 0x.* size=7"],

labath wrote:

Insteand of repeating the whole expectation, I think it'd be better to just 
temp variable for the "expected summary string", and conditionalize just its 
value.

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

[Lldb-commits] [lldb] f99e6df - [lldb][TypeSystemClang] Pass around enum value as uint64_t (#125244)

2025-02-03 Thread via lldb-commits


Author: Michael Buch
Date: 2025-02-03T09:07:40Z
New Revision: f99e6df1415fa825b8329b381a23cd9c58d6edd4

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

LOG: [lldb][TypeSystemClang] Pass around enum value as uint64_t (#125244)

The `DWARFASTParserClang` reads enum values as `int64_t`s regardless of
the enumerators signedness. Then we pass it to
`AddEnumerationValueToEnumerationType` and only then do we create an
`APSInt` from it. However, there are other places where we read/pass
around the enum value as unsigned. This patch makes sure we consistently
use the same integer type for the enum value and let `APSInt` take care
of signedness. This shouldn't have any observable effect.

Added: 


Modified: 
lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
lldb/source/Plugins/SymbolFile/PDB/PDBASTParser.cpp
lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.h

Removed: 




diff  --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
index dca193fc11b552..05625925d7cae3 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
@@ -2321,8 +2321,7 @@ size_t DWARFASTParserClang::ParseChildEnumerators(
   continue;
 
 const char *name = nullptr;
-bool got_value = false;
-int64_t enum_value = 0;
+std::optional enum_value;
 Declaration decl;
 
 for (size_t i = 0; i < attributes.Size(); ++i) {
@@ -2331,7 +2330,6 @@ size_t DWARFASTParserClang::ParseChildEnumerators(
   if (attributes.ExtractFormValueAtIndex(i, form_value)) {
 switch (attr) {
 case DW_AT_const_value:
-  got_value = true;
   if (is_signed)
 enum_value = form_value.Signed();
   else
@@ -2360,9 +2358,9 @@ size_t DWARFASTParserClang::ParseChildEnumerators(
   }
 }
 
-if (name && name[0] && got_value) {
+if (name && name[0] && enum_value) {
   m_ast.AddEnumerationValueToEnumerationType(
-  clang_type, decl, name, enum_value, enumerator_byte_size * 8);
+  clang_type, decl, name, *enum_value, enumerator_byte_size * 8);
   ++enumerators_added;
 }
   }

diff  --git a/lldb/source/Plugins/SymbolFile/PDB/PDBASTParser.cpp 
b/lldb/source/Plugins/SymbolFile/PDB/PDBASTParser.cpp
index 990bacd89bf346..c6dd72e22fb4c1 100644
--- a/lldb/source/Plugins/SymbolFile/PDB/PDBASTParser.cpp
+++ b/lldb/source/Plugins/SymbolFile/PDB/PDBASTParser.cpp
@@ -1155,7 +1155,7 @@ bool PDBASTParser::AddEnumValue(CompilerType enum_type,
   Variant v = enum_value.getValue();
   std::string name =
   std::string(MSVCUndecoratedNameParser::DropScope(enum_value.getName()));
-  int64_t raw_value;
+  uint64_t raw_value;
   switch (v.Type) {
   case PDB_VariantType::Int8:
 raw_value = v.Value.Int8;

diff  --git a/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp 
b/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
index cb246fde976c2f..1da8fbe0bcd6dd 100644
--- a/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
+++ b/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
@@ -8541,12 +8541,10 @@ clang::EnumConstantDecl 
*TypeSystemClang::AddEnumerationValueToEnumerationType(
 
 clang::EnumConstantDecl *TypeSystemClang::AddEnumerationValueToEnumerationType(
 const CompilerType &enum_type, const Declaration &decl, const char *name,
-int64_t enum_value, uint32_t enum_value_bit_size) {
-  CompilerType underlying_type = GetEnumerationIntegerType(enum_type);
-  bool is_signed = false;
-  underlying_type.IsIntegerType(is_signed);
-
-  llvm::APSInt value(enum_value_bit_size, !is_signed);
+uint64_t enum_value, uint32_t enum_value_bit_size) {
+  assert(enum_type.IsEnumerationType());
+  llvm::APSInt value(enum_value_bit_size,
+ !enum_type.IsEnumerationIntegerTypeSigned());
   value = enum_value;
 
   return AddEnumerationValueToEnumerationType(enum_type, decl, name, value);

diff  --git a/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.h 
b/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.h
index 83f954270e3093..e70ad4c2973a5c 100644
--- a/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.h
+++ b/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.h
@@ -1040,7 +1040,7 @@ class TypeSystemClang : public TypeSystem {
   // Modifying Enumeration types
   clang::EnumConstantDecl *AddEnumerationValueToEnumerationType(
   const CompilerType &enum_type, const Declaration &decl, const char *name,
-  int64_t enum_value, uint32_t enum_value_bit_size);
+  uint64_t enum_value, uint32_t enum_value_bit_size);
   clang::EnumConstantDecl *AddEnumerat

[Lldb-commits] [lldb] [lldb][TypeSystemClang] Pass around enum value as uint64_t (PR #125244)

2025-02-03 Thread Michael Buch via lldb-commits


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

[Lldb-commits] [lldb] [lldb][Docs] Expand remote testing instructions (PR #122694)

2025-02-03 Thread David Spickett via lldb-commits


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

[Lldb-commits] [lldb] 5d738b2 - [lldb][Docs] Expand remote testing instructions (#122694)

2025-02-03 Thread via lldb-commits


Author: David Spickett
Date: 2025-02-03T09:10:20Z
New Revision: 5d738b2be051bf800445fb21df6de163af35695f

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

LOG: [lldb][Docs] Expand remote testing instructions (#122694)

There's a lot of fiddly bits to get right here, so I've added a more
complete example and explained why you might choose one method over
another.

I thought about adding this to the qemu testing page, as that's what we
(Linaro) use this for mostly, but it applies to any remote system
whether hardware or simulator.

Added: 


Modified: 
lldb/docs/resources/test.rst

Removed: 




diff  --git a/lldb/docs/resources/test.rst b/lldb/docs/resources/test.rst
index 5f1bd0d5738305..1272aeeeb969e3 100644
--- a/lldb/docs/resources/test.rst
+++ b/lldb/docs/resources/test.rst
@@ -586,24 +586,60 @@ To run a specific test, pass a filter, for example:
 Running the Test Suite Remotely
 ```
 
-Running the test-suite remotely is similar to the process of running a local
-test suite, but there are two things to have in mind:
-
-1. You must have the lldb-server running on the remote system, ready to accept
-   multiple connections. For more information on how to setup remote debugging
-   see the Remote debugging page.
-2. You must tell the test-suite how to connect to the remote system. This is
-   achieved using the ``LLDB_TEST_PLATFORM_URL``, 
``LLDB_TEST_PLATFORM_WORKING_DIR``
-   flags to cmake, and ``--platform-name`` parameter to ``dotest.py``.
-   These parameters correspond to the platform select and platform connect
-   LLDB commands. You will usually also need to specify the compiler and
-   architecture for the remote system.
-3. Remote Shell tests execution is currently supported only for Linux target
-   platform. It's triggered when ``LLDB_TEST_SYSROOT`` is provided for building
-   test sources. It can be disabled by setting 
``LLDB_TEST_SHELL_DISABLE_REMOTE=On``.
-   Shell tests are not guaranteed to pass against remote target if the compiler
-   being used is other than Clang.
+1. Run lldb-server on the remote system, so that it can accept multiple 
connections.
+   This is called "platform" mode:
 
+   ::
+
+  lldb-server platform --server --listen 0.0.0.0: --gdbserver-port 

+
+   Assuming that ``port A`` and ``port B`` on the remote system can be reached
+   from your host system. If your remote system is a simulator on your host 
machine,
+   you may need to forward these ports to the host when you start the 
simulator.
+
+   For more information on how to setup remote debugging see 
:doc:`/use/remote`.
+
+2. Tell the test-suite how to connect to the remote system. This is done using 
the
+   ``LLDB_TEST_PLATFORM_URL`` and ``LLDB_TEST_PLATFORM_WORKING_DIR`` flags of 
CMake,
+   or the ``--platform-name``, ``--platform-url`` and 
``--platform-working-dir``
+   parameters of ``dotest.py``. These parameters are passed on to the 
``platform select``
+   and ``platform connect`` LLDB commands when the tests are run.
+
+   You will usually need to specify the compiler and architecture for the
+   remote system. This is done with CMake options ``LLDB_TEST_COMPILER`` and
+   ``LLDB_TEST_ARCH``, or the ``dotest.py`` options ``--compiler`` and 
``--arch``.
+
+   .. note::
+  Even in cases where the two systems are the same architecture and run the
+  same operating system, there may be version 
diff erences between the two
+  which require you to use a 
diff erent compiler version for remote testing.
+
+   For example, to run tests using ``dotest.py`` on a remote AArch64 Linux 
system
+   you might run:
+
+   ::
+
+  ./bin/lldb-dotest --platform-name remote-linux --arch aarch64 --compiler 
aarch64-none-linux-gnu-gcc --platform-url connect://: 
--platform-working-dir /tmp/test_lldb -p .py
+
+   This is the equivalent of:
+
+  * ``LLDB_TEST_ARCH`` = ``aarch64``
+  * ``LLDB_TEST_COMPILER`` = ``aarch64-none-linux-gnu-gcc``
+  * ``LLDB_TEST_PLATFORM_URL`` = ``connect://:``
+  * ``LLDB_TEST_PLATFORM_WORKING_DIR`` = ``/tmp/test_lldb``
+
+   Setting these values using CMake allows you to run ``ninja check-lldb`` to 
run
+   tests on the remote system.
+
+   If you have a host build that you sometimes check on a remote system, but 
otherwise
+   test on the host, adding arguments to ``dotest.py`` manually is easier.
+
+.. note::
+   Remote Shell test execution is currently supported only for Linux targets.
+   It is enabled when ``LLDB_TEST_SYSROOT`` is set. Remote Shell testing can
+   be disabled by setting ``LLDB_TEST_SHELL_DISABLE_REMOTE=On``. Shell tests
+   are not guaranteed to pass against remote target if the test compiler is not
+   Clang.
 
 Running tests in QEMU System Emulation Environment
 ``

[Lldb-commits] [lldb] [lldb] Implement bidirectional access for backing<->backed thread relationship (PR #125300)

2025-02-03 Thread Pavel Labath via lldb-commits


labath wrote:

This creates a shared_pointer loop between the two objects, which doesn't sound 
like a good design. Maybe one of the pointers ought to be weak?

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

[Lldb-commits] [lldb] [LLDB][Save Core Options] Custom ranges should follow the same safety checks as everyone else (PR #125323)

2025-02-03 Thread Jacob Lalonde via lldb-commits


https://github.com/Jlalond updated 
https://github.com/llvm/llvm-project/pull/125323

>From 973117aaa1d1bffe5a10a8c87edafec91dcd51bd Mon Sep 17 00:00:00 2001
From: Jacob Lalonde 
Date: Fri, 31 Jan 2025 17:37:46 -0800
Subject: [PATCH 1/2] Have custom ranges go through the same safety checks as
 everything else, to avoid empty ranges, or ranges with no permissions

---
 lldb/source/Target/Process.cpp | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/lldb/source/Target/Process.cpp b/lldb/source/Target/Process.cpp
index 89731f798deda8..428f8519b72fd5 100644
--- a/lldb/source/Target/Process.cpp
+++ b/lldb/source/Target/Process.cpp
@@ -6677,11 +6677,8 @@ static void GetUserSpecifiedCoreFileSaveRanges(Process 
&process,
 
   for (const auto &range : regions) {
 auto entry = option_ranges.FindEntryThatContains(range.GetRange());
-if (entry) {
-  ranges.Append(range.GetRange().GetRangeBase(),
-range.GetRange().GetByteSize(),
-CreateCoreFileMemoryRange(range));
-}
+if (entry)
+  AddRegion(range, true, ranges);
   }
 }
 

>From 8bbb150ad7c7ed044d7ca30c745734938263b2d3 Mon Sep 17 00:00:00 2001
From: Jacob Lalonde 
Date: Mon, 3 Feb 2025 10:23:22 -0800
Subject: [PATCH 2/2] Add a new test case

---
 .../TestProcessSaveCoreMinidump.py| 33 +++
 1 file changed, 33 insertions(+)

diff --git 
a/lldb/test/API/functionalities/process_save_core_minidump/TestProcessSaveCoreMinidump.py
 
b/lldb/test/API/functionalities/process_save_core_minidump/TestProcessSaveCoreMinidump.py
index 808de687e6ea2e..2ce8251da3d07c 100644
--- 
a/lldb/test/API/functionalities/process_save_core_minidump/TestProcessSaveCoreMinidump.py
+++ 
b/lldb/test/API/functionalities/process_save_core_minidump/TestProcessSaveCoreMinidump.py
@@ -636,3 +636,36 @@ def minidump_saves_fs_base_region(self):
 self.assertTrue(self.dbg.DeleteTarget(target))
 if os.path.isfile(tls_file):
 os.unlink(tls_file)
+
+@skipUnlessPlatform(["linux"])
+@skipUnlessArch("x86_64")
+def test_invalid_custom_regions_not_included(self):
+options = lldb.SBSaveCoreOptions()
+self.build()
+exe = self.getBuildArtifact("a.out")
+output_file = self.getBuildArtifact("no_empty_regions.dmp")
+try:
+target = self.dbg.CreateTarget(exe)
+process = target.LaunchSimple(
+None, None, self.get_process_working_directory()
+)
+self.assertState(process.GetState(), lldb.eStateStopped)
+options.SetPluginName("minidump")
+options.SetOutputFile(lldb.SBFileSpec(output_file))
+options.SetStyle(lldb.eSaveCoreCustomOnly)
+region_one = lldb.SBMemoryRegionInfo()
+process.GetMemoryRegions().GetMemoryRegionAtIndex(0, region_one)
+options.AddMemoryRegionToSave(region_one)
+empty_region = lldb.SBMemoryRegionInfo("empty region", 0x0, 0x0, 
3, True, False)
+options.AddMemoryRegionToSave(empty_region)
+region_with_no_permissions = lldb.SBMemoryRegionInfo("no 
permissions", 0x2AAA, 0x2BBB, 0, True, False)
+options.AddMemoryRegionToSave(region_with_no_permissions)
+error = process.SaveCore(options)
+self.assertTrue(error.Success(), error.GetCString())
+core_target = self.dbg.CreateTarget(None)
+core_process = core_target.LoadCore(output_file)
+self.assertNotIn(region_with_no_permissions, 
core_process.GetMemoryRegions())
+self.assertNotIn(empty_region, core_process.GetMemoryRegions())
+finally:
+if os.path.isfile(output_file):
+os.unlink(output_file)

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

[Lldb-commits] [lldb] [lldb] Show value for libcxx and libstdcxx summary and remove pointer value in libcxx container summary (PR #125294)

2025-02-03 Thread Zequan Wu via lldb-commits


https://github.com/ZequanWu updated 
https://github.com/llvm/llvm-project/pull/125294

>From bbecf2f990c1fdf8ed993c3bba4c68212ebb299c Mon Sep 17 00:00:00 2001
From: Zequan Wu 
Date: Fri, 31 Jan 2025 13:05:14 -0800
Subject: [PATCH 1/4] [lldb] Show value for libcxx and libstdcxx summary and
 remove pointer value in libcxx container summary

---
 .../Language/CPlusPlus/CPlusPlusLanguage.cpp  |  4 +-
 .../Plugins/Language/CPlusPlus/LibCxx.cpp |  6 ---
 .../deque/TestDataFormatterLibcxxDeque.py | 49 ---
 .../span/TestDataFormatterLibcxxSpan.py   |  5 +-
 .../variant/TestDataFormatterLibcxxVariant.py |  2 +-
 .../vector/TestDataFormatterLibcxxVector.py   | 49 ---
 .../TestDataFormatterLibStdcxxVariant.py  |  2 +-
 7 files changed, 69 insertions(+), 48 deletions(-)

diff --git a/lldb/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp 
b/lldb/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp
index 2bf574e97768ec..4b045d12ad4947 100644
--- a/lldb/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp
+++ b/lldb/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp
@@ -641,7 +641,7 @@ static void LoadLibCxxFormatters(lldb::TypeCategoryImplSP 
cpp_category_sp) {
   .SetSkipPointers(false)
   .SetSkipReferences(false)
   .SetDontShowChildren(true)
-  .SetDontShowValue(true)
+  .SetDontShowValue(false)
   .SetShowMembersOneLiner(false)
   .SetHideItemNames(false);
 
@@ -1204,7 +1204,7 @@ static void 
LoadLibStdcppFormatters(lldb::TypeCategoryImplSP cpp_category_sp) {
   .SetSkipPointers(false)
   .SetSkipReferences(false)
   .SetDontShowChildren(true)
-  .SetDontShowValue(true)
+  .SetDontShowValue(false)
   .SetShowMembersOneLiner(false)
   .SetHideItemNames(false);
 
diff --git a/lldb/source/Plugins/Language/CPlusPlus/LibCxx.cpp 
b/lldb/source/Plugins/Language/CPlusPlus/LibCxx.cpp
index 6d0ccdbbe4a71d..2aa8fdba706348 100644
--- a/lldb/source/Plugins/Language/CPlusPlus/LibCxx.cpp
+++ b/lldb/source/Plugins/Language/CPlusPlus/LibCxx.cpp
@@ -430,12 +430,6 @@ size_t 
lldb_private::formatters::LibcxxUniquePtrSyntheticFrontEnd::
 
 bool lldb_private::formatters::LibcxxContainerSummaryProvider(
 ValueObject &valobj, Stream &stream, const TypeSummaryOptions &options) {
-  if (valobj.IsPointerType()) {
-uint64_t value = valobj.GetValueAsUnsigned(0);
-if (!value)
-  return false;
-stream.Printf("0x%016" PRIx64 " ", value);
-  }
   return FormatEntity::FormatStringRef("size=${svar%#}", stream, nullptr,
nullptr, nullptr, &valobj, false, 
false);
 }
diff --git 
a/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/deque/TestDataFormatterLibcxxDeque.py
 
b/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/deque/TestDataFormatterLibcxxDeque.py
index 3596b546be306a..8f8af60d4e9728 100644
--- 
a/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/deque/TestDataFormatterLibcxxDeque.py
+++ 
b/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/deque/TestDataFormatterLibcxxDeque.py
@@ -9,22 +9,37 @@
 
 
 class LibcxxDequeDataFormatterTestCase(TestBase):
-def check_numbers(self, var_name):
-self.expect(
-"frame variable " + var_name,
-substrs=[
-var_name + " = size=7",
-"[0] = 1",
-"[1] = 12",
-"[2] = 123",
-"[3] = 1234",
-"[4] = 12345",
-"[5] = 123456",
-"[6] = 1234567",
-"}",
-],
-)
-
+def check_numbers(self, var_name, show_ptr = False):
+if show_ptr:
+self.expect(
+"frame variable " + var_name,
+patterns=[var_name + " = 0x.* size=7"],
+substrs=[
+"[0] = 1",
+"[1] = 12",
+"[2] = 123",
+"[3] = 1234",
+"[4] = 12345",
+"[5] = 123456",
+"[6] = 1234567",
+"}",
+],
+)
+else:
+self.expect(
+"frame variable " + var_name,
+substrs=[
+var_name + " = size=7",
+"[0] = 1",
+"[1] = 12",
+"[2] = 123",
+"[3] = 1234",
+"[4] = 12345",
+"[5] = 123456",
+"[6] = 1234567",
+"}",
+],
+)
 self.expect_expr(
 var_name,
 result_summary="size=7",
@@ -75,7 +90,7 @@ def test_ref_and_ptr(self):
 )
 
 # The reference should display the same was as the value did
-self.check_numbers("ref")
+self.check_numbers("ref", True)
 
 # The pointer sh

[Lldb-commits] [lldb] [lldb] Support CommandInterpreter print callbacks (PR #125006)

2025-02-03 Thread Jonas Devlieghere via lldb-commits

JDevlieghere wrote:

> I do have my doubts about embedding the command string into the return 
> object, but it sounds like the thought had occurred to at least two of you 
> independently, so if you all think that's the best direction, then I guess 
> I'm outvoted.

I don't feel strongly about storing the command in the `CommandReturnObject`. 
It seemed like the natural place to put it and it wouldn't *pollute* the 
callback signature. I have nothing against passing in the command but I'd be 
worried that there might be other things needed in the future and I really 
don't want to have two callbacks. We could solve it by passing in an object but 
that needs to be bridged through the SB API which seems overkill for what I'm 
trying to do today. 

Anyway, let's continue the discussion in #125132. We just branched for the 20.x 
release so we have plenty of time to refine the callback API if needed. If 
anyone (else) sees this and thinks about adopting it, this is your warning that 
it might change :-).  

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

[Lldb-commits] [lldb] [LLDB][Save Core Options] Custom ranges should follow the same safety checks as everyone else (PR #125323)

2025-02-03 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 
6a97897d5c159a52975bac19ac22c7913672c549...8bbb150ad7c7ed044d7ca30c745734938263b2d3
 
lldb/test/API/functionalities/process_save_core_minidump/TestProcessSaveCoreMinidump.py
``





View the diff from darker here.


``diff
--- TestProcessSaveCoreMinidump.py  2025-02-03 18:44:39.00 +
+++ TestProcessSaveCoreMinidump.py  2025-02-03 18:53:56.546684 +
@@ -654,18 +654,24 @@
 options.SetOutputFile(lldb.SBFileSpec(output_file))
 options.SetStyle(lldb.eSaveCoreCustomOnly)
 region_one = lldb.SBMemoryRegionInfo()
 process.GetMemoryRegions().GetMemoryRegionAtIndex(0, region_one)
 options.AddMemoryRegionToSave(region_one)
-empty_region = lldb.SBMemoryRegionInfo("empty region", 0x0, 0x0, 
3, True, False)
+empty_region = lldb.SBMemoryRegionInfo(
+"empty region", 0x0, 0x0, 3, True, False
+)
 options.AddMemoryRegionToSave(empty_region)
-region_with_no_permissions = lldb.SBMemoryRegionInfo("no 
permissions", 0x2AAA, 0x2BBB, 0, True, False)
+region_with_no_permissions = lldb.SBMemoryRegionInfo(
+"no permissions", 0x2AAA, 0x2BBB, 0, True, False
+)
 options.AddMemoryRegionToSave(region_with_no_permissions)
 error = process.SaveCore(options)
 self.assertTrue(error.Success(), error.GetCString())
 core_target = self.dbg.CreateTarget(None)
 core_process = core_target.LoadCore(output_file)
-self.assertNotIn(region_with_no_permissions, 
core_process.GetMemoryRegions())
+self.assertNotIn(
+region_with_no_permissions, core_process.GetMemoryRegions()
+)
 self.assertNotIn(empty_region, core_process.GetMemoryRegions())
 finally:
 if os.path.isfile(output_file):
 os.unlink(output_file)

``




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

[Lldb-commits] [lldb] [LLDB][Save Core Options] Custom ranges should follow the same safety checks as everyone else (PR #125323)

2025-02-03 Thread Jacob Lalonde via lldb-commits


https://github.com/Jlalond updated 
https://github.com/llvm/llvm-project/pull/125323

>From 973117aaa1d1bffe5a10a8c87edafec91dcd51bd Mon Sep 17 00:00:00 2001
From: Jacob Lalonde 
Date: Fri, 31 Jan 2025 17:37:46 -0800
Subject: [PATCH 1/3] Have custom ranges go through the same safety checks as
 everything else, to avoid empty ranges, or ranges with no permissions

---
 lldb/source/Target/Process.cpp | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/lldb/source/Target/Process.cpp b/lldb/source/Target/Process.cpp
index 89731f798deda88..428f8519b72fd51 100644
--- a/lldb/source/Target/Process.cpp
+++ b/lldb/source/Target/Process.cpp
@@ -6677,11 +6677,8 @@ static void GetUserSpecifiedCoreFileSaveRanges(Process 
&process,
 
   for (const auto &range : regions) {
 auto entry = option_ranges.FindEntryThatContains(range.GetRange());
-if (entry) {
-  ranges.Append(range.GetRange().GetRangeBase(),
-range.GetRange().GetByteSize(),
-CreateCoreFileMemoryRange(range));
-}
+if (entry)
+  AddRegion(range, true, ranges);
   }
 }
 

>From 8bbb150ad7c7ed044d7ca30c745734938263b2d3 Mon Sep 17 00:00:00 2001
From: Jacob Lalonde 
Date: Mon, 3 Feb 2025 10:23:22 -0800
Subject: [PATCH 2/3] Add a new test case

---
 .../TestProcessSaveCoreMinidump.py| 33 +++
 1 file changed, 33 insertions(+)

diff --git 
a/lldb/test/API/functionalities/process_save_core_minidump/TestProcessSaveCoreMinidump.py
 
b/lldb/test/API/functionalities/process_save_core_minidump/TestProcessSaveCoreMinidump.py
index 808de687e6ea2e7..2ce8251da3d07cf 100644
--- 
a/lldb/test/API/functionalities/process_save_core_minidump/TestProcessSaveCoreMinidump.py
+++ 
b/lldb/test/API/functionalities/process_save_core_minidump/TestProcessSaveCoreMinidump.py
@@ -636,3 +636,36 @@ def minidump_saves_fs_base_region(self):
 self.assertTrue(self.dbg.DeleteTarget(target))
 if os.path.isfile(tls_file):
 os.unlink(tls_file)
+
+@skipUnlessPlatform(["linux"])
+@skipUnlessArch("x86_64")
+def test_invalid_custom_regions_not_included(self):
+options = lldb.SBSaveCoreOptions()
+self.build()
+exe = self.getBuildArtifact("a.out")
+output_file = self.getBuildArtifact("no_empty_regions.dmp")
+try:
+target = self.dbg.CreateTarget(exe)
+process = target.LaunchSimple(
+None, None, self.get_process_working_directory()
+)
+self.assertState(process.GetState(), lldb.eStateStopped)
+options.SetPluginName("minidump")
+options.SetOutputFile(lldb.SBFileSpec(output_file))
+options.SetStyle(lldb.eSaveCoreCustomOnly)
+region_one = lldb.SBMemoryRegionInfo()
+process.GetMemoryRegions().GetMemoryRegionAtIndex(0, region_one)
+options.AddMemoryRegionToSave(region_one)
+empty_region = lldb.SBMemoryRegionInfo("empty region", 0x0, 0x0, 
3, True, False)
+options.AddMemoryRegionToSave(empty_region)
+region_with_no_permissions = lldb.SBMemoryRegionInfo("no 
permissions", 0x2AAA, 0x2BBB, 0, True, False)
+options.AddMemoryRegionToSave(region_with_no_permissions)
+error = process.SaveCore(options)
+self.assertTrue(error.Success(), error.GetCString())
+core_target = self.dbg.CreateTarget(None)
+core_process = core_target.LoadCore(output_file)
+self.assertNotIn(region_with_no_permissions, 
core_process.GetMemoryRegions())
+self.assertNotIn(empty_region, core_process.GetMemoryRegions())
+finally:
+if os.path.isfile(output_file):
+os.unlink(output_file)

>From c9ae55ac562769b5301f1d54843b8a1f178a8e0c Mon Sep 17 00:00:00 2001
From: Jacob Lalonde 
Date: Mon, 3 Feb 2025 10:56:36 -0800
Subject: [PATCH 3/3] Run python formatter

---
 .../TestProcessSaveCoreMinidump.py   | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git 
a/lldb/test/API/functionalities/process_save_core_minidump/TestProcessSaveCoreMinidump.py
 
b/lldb/test/API/functionalities/process_save_core_minidump/TestProcessSaveCoreMinidump.py
index 2ce8251da3d07cf..c2152640c425cee 100644
--- 
a/lldb/test/API/functionalities/process_save_core_minidump/TestProcessSaveCoreMinidump.py
+++ 
b/lldb/test/API/functionalities/process_save_core_minidump/TestProcessSaveCoreMinidump.py
@@ -656,15 +656,21 @@ def test_invalid_custom_regions_not_included(self):
 region_one = lldb.SBMemoryRegionInfo()
 process.GetMemoryRegions().GetMemoryRegionAtIndex(0, region_one)
 options.AddMemoryRegionToSave(region_one)
-empty_region = lldb.SBMemoryRegionInfo("empty region", 0x0, 0x0, 
3, True, False)
+empty_region = lldb.SBMemoryRegionInfo(
+"empty region", 0x0, 0x0, 3, True, False
+

[Lldb-commits] [lldb] [LLDB] Add Lexer (with tests) for DIL (Data Inspection Language). (PR #123521)

2025-02-03 Thread Andy Hippo via lldb-commits


werat wrote:

I went through the thread to understand the current consensus and I see various 
nice ideas flying around. Let me try to summarize the requirements and the 
current status quo.

* DIL should support synthetic children, whose names can be arbitrary in 
general case, even `a+b*c`
* A common synthetic name is `[0]`, which is used for children of vectors/maps 
and people want to write `print vec[0]`
  *  `frame variable` supports this by having special support for `[]` 
"expressions"
* We want DIL to be easy & convenient to use in most (simple) cases, but also 
to be able to support complicated cases and it doesn't have to be _super_ 
convenient for those

Possible behaviour for DIL:

* Make the definition of `identifier` in Lexer to roughly match C or similar
* Introduce escaping of identifiers, e.g. with backticks
  * The expression ``foo->`a*b.c`+1`` is parsed as approx 
`foo.GetChildWithName("a*b.c") + 1`
* Add special support for `[]` in the parser
  * The expression ``foo.`[1]` `` is parsed as `foo.GetChildWithName("[1]")`
  * The expression `foo[1]` tries the following:
* `foo.GetChildWithName("1")`
* `foo.GetChildWithName("[1]")`
* `foo.GetChildAtIndex(1)`
  * The expression `foo["bar"]` tries:
* `foo.GetChildWithName("bar")`
* `foo.GetChildWithName("[bar]")`
  * The expression `foo[]` -- `expr` is evaluated and treated as cases 
above. If the result of `expr` is not a number or a string -- produce an error

For cases where the `GetChildWithName( "1" / "[1]" )` and `GetChildAtIndex(1)` 
produce different valid results we could shows a warning/error to make it clear 
to the user that there's some ambiguity. IMO this would be an improvement over 
the current situation where `print` and `expr` simply produce different results.


This way all typical cases work as expected by users and more or less match the 
current behaviour of frame variable. It's still possible to access synthetic 
children with any names, but it requires knowledge about the escaping.


Does this sound like a reasonable approach?

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

[Lldb-commits] [lldb] [llvm] [lldb-dap] Support column breakpoints (PR #125347)

2025-02-03 Thread Walter Erquinigo via lldb-commits


https://github.com/walter-erquinigo commented:

This LGTM, but before merging, could you share more about the differences 
between the these cases and the actual logic between this patch and the 
previous attempt? 

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

[Lldb-commits] [lldb] [llvm] [lldb-dap] Support column breakpoints (PR #125347)

2025-02-03 Thread Walter Erquinigo via lldb-commits


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

[Lldb-commits] [lldb] [llvm] [lldb-dap] Support column breakpoints (PR #125347)

2025-02-03 Thread Walter Erquinigo via lldb-commits



@@ -140,6 +140,10 @@ Changes to LLDB
   Therefore current implementation allows only 1 watchpoint, as tested with
   Windows 11 on the Microsoft SQ2 and Snapdragon Elite X platforms.
 
+### Changes to lldb-dap
+
+* Breakpoints can now be set for specific columns within a line

walter-erquinigo wrote:

add a final period

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

[Lldb-commits] [lldb] [lldb] Store the command in the CommandReturnObject (PR #125132)

2025-02-03 Thread via lldb-commits


jimingham wrote:

> This idea has bothered me from the beginning, but I didn't want to say 
> anything, as it was mostly just a feeling. After seeing this patch, I think I 
> can put some words behind it.
> 
> The thing I don't like about this patch is the repetition/redundancy it 
> creates. Like, you first create the CommandReturnObject, give it the command 
> it's hold the result of. Then, you pass that object into HandleCommand, but 
> that's not all you give it -- the function takes the string of the command, 
> again.
> 
> It's not the end of the world, but I think it's unfortunate, and while it 
> works nice for your current use case, I don't think it makes that much sense 
> for other usages. For example, if the `CommandReturnObject` had always 
> contained the command part, would the signature of a python command still be 
> `def cmd(debugger, command, result, dict):`, or would we have expected the 
> command to retrieve it from the result object?
> 
> It's hard to say, but what I think we can say is that if you make your 
> current callback take the "command" and the "result of that command" as two 
> separate arguments, then it will at least be consistent with the signature 
> above.

One difference here is that what we're putting in the command is the command as 
the user typed it.  That isn't what we pass to the command - the command gets 
the result after alias substitution.  Also, though I was late providing it in 
the future when possible we really want command writers to use the parsed form 
for everything but raw commands.  So that's even further from the raw string 
we're adding to the SBCommandReturnObject.  The string we're putting in there 
is really only useful for logging.

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

[Lldb-commits] [lldb] [LLDB] Add Lexer (with tests) for DIL (Data Inspection Language). (PR #123521)

2025-02-03 Thread Pavel Labath via lldb-commits

labath wrote:

Thanks for the summary Andy.

> I went through the thread to understand the current consensus and I see 
> various nice ideas flying around. Let me try to summarize the requirements 
> and the current status quo.
> 
>   * DIL should support synthetic children, whose names can be arbitrary in 
> general case, even `a+b*c`
> 
>* A common synthetic name is `[0]`, which is used for children of 
> vectors/maps and people want to write `print vec[0]`
>   
>  * `frame variable` supports this by having special support for `[]` 
> "expressions"
> 
>* We want DIL to be easy & convenient to use in most (simple) cases, but 
> also to be able to support complicated cases and it doesn't have to be 
> _super_ convenient for those

SGTM

> Possible behaviour for DIL:
> 
>   * Make the definition of `identifier` in Lexer to roughly match C or similar
> 
>   * Introduce escaping of identifiers, e.g. with backticks
>   
> * The expression `` foo->`a*b.c`+1 `` is parsed as approx 
> `foo.GetChildWithName("a*b.c") + 1`

I already spoke at length about identifier names. Quoting of fancy names SGTM. 
I don't think its relevant for this patch (lexing), but since you're also 
mentioning the wider syntax of the language, I want to mention that there's 
also another kind of disambiguation to consider. Forcing a string to be treated 
as an identifier is one thing. Another question is forcing an identifier to be 
treated as a specific kind of entity. For example, if there's a variable and a 
type with the same name, can we say which one we mean? Or can we say we want to 
see the value of a global variable `foo` in a specific compile unit? Or in an 
outer scope that's shadowed by another variable?

We don't exactly support that right now, but e.g. `target variable foo` will 
print *all* global variables with that names. That gets trickier with a more 
complicated parser, because how do you print the result of `global1+global2` if 
there are multiple candidates for each name

> 
> * Add special support for `[]` in the parser
>   
>   * The expression `` foo.`[1]`  `` is parsed as 
> `foo.GetChildWithName("[1]")`
>   * The expression `foo[1]` tries the following:
> 
> * `foo.GetChildWithName("1")`
> * `foo.GetChildWithName("[1]")`
> * `foo.GetChildAtIndex(1)`

I'd go with just the second option because I'd like to avoid ambiguities and 
fallbacks. I think that's more or less the status quo, at least for the types 
with child providers. We'd need some special handling for C pointers and 
arrays, but that's also what we already have

>   * The expression `foo["bar"]` tries:
> 
> * `foo.GetChildWithName("bar")`
> * `foo.GetChildWithName("[bar]")`
>   * The expression `foo[]` -- `expr` is evaluated and treated as 
> cases above. If the result of `expr` is not a number or a string -- produce 
> an error

I think this is an interesting idea whose usefulness mainly depends on what 
kind of string operations we have in the language. If there's no way to 
construct strings, then I don't think it's very useful. You could write things 
like `some_variable[another_variable]`, but I don't think that's going to be 
useful because for static types (e.g. C structs) you're unlikely to have a 
variable with a value that contains the name of a field, and for types with 
synthetic children the names of the children are not going to have any relation 
to the way it's seen by the code (map is still going to have a 
child called `[0]`).

Overall I'd leave this out for the time being because it doesn't impact parsing 
or lexing, just how some (currently invalid) syntax trees can be interpreted.

> For cases where the `GetChildWithName( "1" / "[1]" )` and 
> `GetChildAtIndex(1)` produce different valid results we could shows a 
> warning/error to make it clear to the user that there's some ambiguity. IMO 
> this would be an improvement over the current situation where `print` and 
> `expr` simply produce different results.

I'm not sure how this is going to help. I assume you're referring to the 
`map` scenario. In this case, the map object is not going to have a 
child called `"1"`, even if it happens to contain a key with the value `1`. 
(Depending on the other keys, the name of the child containing it could be 
`"[0]"`, `"[1]"`, or `"[47]"`). Or are you proposing to change that?

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

[Lldb-commits] [lldb] [lldb] Fix Block::GetRangeIndexContainingAddress for discontinuous functions (PR #124931)

2025-02-03 Thread David Spickett via lldb-commits


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

[Lldb-commits] [lldb] [lldb] Fix Block::GetRangeIndexContainingAddress for discontinuous functions (PR #124931)

2025-02-03 Thread David Spickett via lldb-commits


https://github.com/DavidSpickett commented:

I've looked at this a couple of times and on a general level, it seems fine, 
but all the address vs. file address stuff is confusing to me. I'm just 
guessing what each one is really.

So I have added some questions about that, maybe I'll be able to approve after 
those, or Jason can appear, whichever comes first.

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

[Lldb-commits] [lldb] [lldb] Fix Block::GetRangeIndexContainingAddress for discontinuous functions (PR #124931)

2025-02-03 Thread David Spickett via lldb-commits



@@ -243,25 +243,15 @@ bool Block::GetRangeContainingAddress(const Address &addr,
   AddressRange &range) {
   Function *function = CalculateSymbolContextFunction();
   if (function) {
-const AddressRange &func_range = function->GetAddressRange();
-if (addr.GetModule() == func_range.GetBaseAddress().GetModule()) {
-  const addr_t file_addr = addr.GetFileAddress();
-  const addr_t func_file_addr =
-  func_range.GetBaseAddress().GetFileAddress();
-  if (file_addr >= func_file_addr &&
-  file_addr < func_file_addr + func_range.GetByteSize()) {
-addr_t offset = file_addr - func_file_addr;
-
-const Range *range_ptr = m_ranges.FindEntryThatContains(offset);
-
-if (range_ptr) {
-  range.GetBaseAddress() =
-  Address(func_file_addr + range_ptr->GetRangeBase(),
-  addr.GetModule()->GetSectionList());
-  range.SetByteSize(range_ptr->GetByteSize());
-  return true;
-}
-  }
+if (uint32_t idx = GetRangeIndexContainingAddress(addr);
+idx != UINT32_MAX) {
+  const Range *range_ptr = m_ranges.GetEntryAtIndex(idx);
+  assert(range_ptr);
+
+  range.GetBaseAddress() = function->GetAddress();
+  range.GetBaseAddress().Slide(range_ptr->GetRangeBase());

DavidSpickett wrote:

`function->GetAddress()` returns the address relative to the start of the 
range, then you slide that address up to get the absolute address of the 
function, right?

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

[Lldb-commits] [lldb] [lldb] Fix Block::GetRangeIndexContainingAddress for discontinuous functions (PR #124931)

2025-02-03 Thread David Spickett via lldb-commits



@@ -6,15 +6,22 @@
 
 # CHECK: Found 1 function(s).
 # CHECK: foo: [input.o[0x0-0xe), input.o[0x14-0x1c)]
-# CHECK-NEXT: input.o[0x0]: cmpl   $0x0, %edi
-# CHECK-NEXT: input.o[0x3]: je 0x14
-# CHECK-NEXT: input.o[0x5]: jmp0x7
-# CHECK-NEXT: input.o[0x7]: callq  0xe
-# CHECK-NEXT: input.o[0xc]: jmp0x1b
+# CHECK-NEXT: input.o[0x0]: callq  0xe
+# CHECK-NEXT: input.o[0x5]: jmp0x1b
+# CHECK-NEXT: input.o[0x7]: cmpl   $0x0, %edi
+# CHECK-NEXT: input.o[0xa]: je 0x14
+# CHECK-NEXT: input.o[0xc]: jmp0x0
 # CHECK-EMPTY:
 # CHECK-NEXT: input.o[0x14]: callq  0x19
 # CHECK-NEXT: input.o[0x19]: jmp0x1b
 # CHECK-NEXT: input.o[0x1b]: retq
+# CHECK-NEXT: offset 0x00 => index 0
+# CHECK-NEXT: offset 0x0c => index 0
+# CHECK-NEXT: offset 0x0e => index 
+# CHECK-NEXT: offset 0x13 => index 
+# CHECK-NEXT: offset 0x14 => index 1
+# CHECK-NEXT: offset 0x1b => index 1
+# CHECK-NEXT: offset 0x1c => index 

DavidSpickett wrote:

I have zero idea what's going on here.

You moved foo.__part.1 before foo, presumably because that would give you the 
wrong answers if it weren't for the changes you made elsewhere?

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

[Lldb-commits] [lldb] [llvm] [lldb] Extended if conditions to support alias names for registers (PR #124475)

2025-02-03 Thread David Spickett via lldb-commits



@@ -0,0 +1,38 @@
+# REQUIRES: native && target-riscv64
+# RUN: %clangxx_host -fomit-frame-pointer %p/Inputs/riscv64-gp-read.cpp -o %t

DavidSpickett wrote:

I'm guessing that `-fomit-frame-pointer` is to stop code after the inline asm 
generating save/restore routines, but if you were to stop during the inline 
asm, this wouldn't be needed.

You could add something like "brk \n\t" to the end and lldb will stop there, it 
won't know who put the breakpoint in but that doesn't matter here. brk is the 
AArch64 mnemonic I think but look around you'll find the RISC-V one somewhere 
"software breakpoint" is the term you want to find.

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

[Lldb-commits] [lldb] [LLDB] Add Lexer (with tests) for DIL (Data Inspection Language). (PR #123521)

2025-02-03 Thread via lldb-commits


jimingham wrote:



> On Feb 2, 2025, at 9:49 PM, cmtice ***@***.***> wrote:
> 
> 
> Apart from the (mainly stylistic) inline comments, the biggest problem I see 
> is that the definition of an identifier is still too narrow. The restriction 
> on the dollar sign is completely unnecessary as C will let you put that 
> anywhere . And it doesn't allow any 
> non-ascii characters.
> 
> I really think this should be based on an deny- rather than an allow-list. 
> Any character we don't claim for ourselves should be fair game for an 
> identifier. If someone manages to enter the backspace character (\x7f) into 
> the expression, then so be it.
> 
> The question of "identifiers" starting with digits is interesting. 
> Personally, I think it'd be fine to reject those (and require the 
> currenly-vapourware quoting syntax), because I suspect you want to accept 
> number suffixes, and I think it'd be confusing to explain why 123x is a valid 
> identifier but 123u is not, but I suspect some might have a different opinion.
> 
> We could continue discussing that here, or we could accept everything here, 
> and postpone this discussion for the patch which starts parsing numbers. Up 
> to you..
> 
> To the best of my knowledge, all the languages that we want to support have 
> roughly the same definition of what a valid identifier is: a letter or 
> underscore, followed by a sequence of letters, digits and underscores, where 
> 'letters' are defined as 'a..z' and 'A..Z'. The one's I've been able to check 
> do not allow arbitrary characters in their identifiers. So that's what I 
> implemented (acknowledging that I currently only recognize ascii at the 
> moment, and fully plan to add utf8 support in the future). I added the 
> ability to recognize the '$' at the front specifically to allow DIL users to 
> ask about registers and LLDB convenience variables, which (to the best of my 
> knowledge) allow '$' only in the first position, and not all by itself.
> 

> I am not sure I see that benefits of expanding what DIL recognizes as a valid 
> identifier beyond what the languages LLDB supports recognize? Am I missing 
> something? Or (this is quite possible) have I misunderstood the definition of 
> what's a valid identifier for some language we want to support?
> 
> Since we definitely want to support lexing/parsing of numbers, I do not think 
> it's a good idea for DIL to also allow identifiers to start with numbers.
> 

I agree here.  We definitely will need to support UTF-8 characters, all the hip 
new languages use that character set.  But allowing initial digits makes 
parsing sufficiently hard I don't think it likely there will be languages we 
need to support that do that.  Can somebody even think of a language that 
allows this?

Jim

> —
> Reply to this email directly, view it on GitHub 
> , 
> or unsubscribe 
> .
> You are receiving this because you were mentioned.
> 



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

[Lldb-commits] [lldb] [lldb-dap] Refactoring lldb-dap port listening mode to allow multiple connections. (PR #116392)

2025-02-03 Thread John Harrison via lldb-commits


https://github.com/ashgti updated 
https://github.com/llvm/llvm-project/pull/116392

>From 88a8522f1b29b2ff392974322acdb722b7e00b70 Mon Sep 17 00:00:00 2001
From: John Harrison 
Date: Tue, 28 Jan 2025 12:39:38 -0800
Subject: [PATCH] [lldb-dap] Refactoring lldb-dap port listening mode to allow
 multiple connections.

This adjusts the lldb-dap listening mode to accept multiple clients.
Each client initializes a new instance of DAP and an associated 
`lldb::SBDebugger` instance.

The listening mode is configured with the `--connection` option and supports 
listening on a port or a unix socket on supported platforms.
---
 .../test/tools/lldb-dap/dap_server.py |  74 -
 .../test/tools/lldb-dap/lldbdap_testcase.py   |   6 +-
 lldb/test/API/tools/lldb-dap/server/Makefile  |   3 +
 .../tools/lldb-dap/server/TestDAP_server.py   |  77 +
 lldb/test/API/tools/lldb-dap/server/main.c|  10 +
 lldb/test/Shell/DAP/TestOptions.test  |   4 +-
 lldb/tools/lldb-dap/DAP.cpp   |  18 +-
 lldb/tools/lldb-dap/DAP.h |   6 +-
 lldb/tools/lldb-dap/DAPForward.h  |   2 +
 lldb/tools/lldb-dap/Options.td|  22 +-
 lldb/tools/lldb-dap/lldb-dap.cpp  | 283 +++---
 11 files changed, 358 insertions(+), 147 deletions(-)
 create mode 100644 lldb/test/API/tools/lldb-dap/server/Makefile
 create mode 100644 lldb/test/API/tools/lldb-dap/server/TestDAP_server.py
 create mode 100644 lldb/test/API/tools/lldb-dap/server/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 c29992ce9c7848..6d765e10236733 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
@@ -903,7 +903,7 @@ def request_setBreakpoints(self, file_path, line_array, 
data=None):
 "sourceModified": False,
 }
 if line_array is not None:
-args_dict["lines"] = "%s" % line_array
+args_dict["lines"] = line_array
 breakpoints = []
 for i, line in enumerate(line_array):
 breakpoint_data = None
@@ -1150,11 +1150,12 @@ def request_setInstructionBreakpoints(self, 
memory_reference=[]):
 }
 return self.send_recv(command_dict)
 
+
 class DebugAdaptorServer(DebugCommunication):
 def __init__(
 self,
 executable=None,
-port=None,
+connection=None,
 init_commands=[],
 log_file=None,
 env=None,
@@ -1167,21 +1168,62 @@ def __init__(
 
 if log_file:
 adaptor_env["LLDBDAP_LOG"] = log_file
+args = [executable]
+
+if connection is not None:
+args.append("--connection")
+args.append(connection)
+
 self.process = subprocess.Popen(
-[executable],
+args,
 stdin=subprocess.PIPE,
 stdout=subprocess.PIPE,
 stderr=subprocess.PIPE,
 env=adaptor_env,
 )
+
+if connection is not None:
+# If the process was also launched, parse the connection from the
+# resolved connection. For example, if the connection
+# `connection://localhost:0` was specified then the OS would pick a
+# random port for listening and lldb-dap would print the listening
+# port to stdout.
+if self.process is not None:
+# lldb-dap will print the listening address once the listener 
is
+# made to stdout. The listener is formatted like
+# `connection://host:port` or `unix-connection:///path`.
+expected_prefix = "Listening for: "
+out = self.process.stdout.readline().decode()
+if not out.startswith(expected_prefix):
+self.process.kill()
+raise ValueError(
+"lldb-dap failed to print listening address, expected 
'{}', got '{}'".format(
+expected_prefix, out
+)
+)
+
+# If the listener expanded into multiple addresses, use the 
first.
+connection = (
+
out.removeprefix(expected_prefix).rstrip("\r\n").split(",", 1)[0]
+)
+
+scheme, address = connection.split("://")
+if scheme == "unix-connect":  # unix-connect:///path
+s = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM)
+s.connect(address)
+elif scheme == "connection":  # connection://[host]:port
+host, port = address.rsplit(":", 1)
+# create_connection with try both ipv4 and ipv6.
+s = socket.create_connection((host.strip("[]"), int(port)))
+

[Lldb-commits] [lldb] [lldb-dap] Refactoring lldb-dap port listening mode to allow multiple connections. (PR #116392)

2025-02-03 Thread John Harrison via lldb-commits

ashgti wrote:

> Overall, I like the StreamDescriptor changes, but I fear this patch is 
> starting to lose focus again. Could you separate the refactor into a separate 
> PR?

Reverted those changes, I kept running into clang (Xcode 16.0 release of clang) 
crashes compiling lldb-dap for some reason with the existing StreamDescriptor 
and the `OnAccept` callback with the `MainLoop` object. This version is working 
for me now and not crashing the compiler.

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

[Lldb-commits] [lldb] [LLDB] Add Lexer (with tests) for DIL (Data Inspection Language). (PR #123521)

2025-02-03 Thread via lldb-commits


jimingham wrote:

> > To the best of my knowledge, all the languages that we want to support have 
> > roughly the same definition of what a valid identifier is: a letter or 
> > underscore, followed by a sequence of letters, digits and underscores, 
> > where 'letters' are defined as 'a..z' and 'A..Z'. The one's I've been able 
> > to check do not allow arbitrary characters in their identifiers. So that's 
> > what I implemented (acknowledging that I currently only recognize ascii at 
> > the moment, and fully plan to add utf8 support in the future). I added the 
> > ability to recognize the '$' at the front specifically to allow DIL users 
> > to ask about registers and LLDB convenience variables, which (to the best 
> > of my knowledge) allow '$' only in the first position, and not all by 
> > itself.
> 
> I don't know how you were checking that, but I'm certain that's not the case. 
> I [already gave you](https://godbolt.org/z/o7qbfeWve) an example of C code 
> which contradicts all of these (note that there can be difference between 
> what's considered a valid identifier by the specification of a language, and 
> what an actual compiler for that language will accept). And I'm not even 
> mentioning all of the names that can be constructed by synthetic child 
> providers.
> 
> You say you want to add utf-8 support. How do you intend to do that? Do you 
> want to enumerate all of the supported characters in each language? Check 
> which language supports variable names in Klingon? Some of the rules can be 
> really obscure. For example, Java accepts £ (`\xA3`) as a variable name, but 
> not © (`\xa9`). I'm sure they had some reason to choose that, but I'd rather 
> not have to find that out.
> 
> OTOH, if you just accept all of the high-bit ascii values as valid 
> characters, then you can support utf8 with a single line of code. And you're 
> not regressing anything because that's exactly what the current 
> implementation does.
> 
> I don't think this list has to be set in stone. For example, `frame variable` 
> currently accepts `@` as a variable name. I believe you don't have any plans 
> for that operator, so I'd just stick to that. If we can come up with some 
> fancy use for it (maybe as an escape character?), then I'm certainly open to 
> changing its classification.
> 
> > I am not sure I see that benefits of expanding what DIL recognizes as a 
> > valid identifier beyond what the languages LLDB supports recognize?
> 
> For me the main benefits are:
> 
> * simplicity of the implementation
> * being able to express a wide range of variable names, even for languages we 
> don't support right now
> * matching status quo
> 
> That said, I would like to hear what you think are the benefits of _not_ 
> recognizing wider set of identifier values. And I'm not talking about names 
> like `123foo` (it sounds like there's consensus to ban those). I'm thinking 
> more of names like `$`, `foo$`, `💩`, etc.

There's one small area that our desire to parse the widest range of identifiers 
comes into conflict with, namely the "persistent variable" namespace.  For the 
C family of languages, we reserve the initial `$` for this purpose, for swift 
(where `$1` etc. were already taken) we use `$R` as the namespace identifier.  
This doesn't matter for the DIL at present, because `frame var` and the like 
don't have access to the persistent variables, but I don't think in the long 
run that's desirable.  But it looks like to get that right generally we would 
have to figure out the language of the identifier which we don't want to do.  
I'm not sure how to finesse this (other than to keep not allowing access to 
persistent variables in the DIL...)

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

[Lldb-commits] [lldb] [lldb] Improve isolation between Process plugins and OS plugins (PR #125302)

2025-02-03 Thread Med Ismail Bennani via lldb-commits


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

LGTM!

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

[Lldb-commits] [lldb] [LLDB] Add Lexer (with tests) for DIL (Data Inspection Language). (PR #123521)

2025-02-03 Thread Pavel Labath via lldb-commits

labath wrote:

> To the best of my knowledge, all the languages that we want to support have 
> roughly the same definition of what a valid identifier is: a letter or 
> underscore, followed by a sequence of letters, digits and underscores, where 
> 'letters' are defined as 'a..z' and 'A..Z'. The one's I've been able to check 
> do not allow arbitrary characters in their identifiers. So that's what I 
> implemented (acknowledging that I currently only recognize ascii at the 
> moment, and fully plan to add utf8 support in the future). I added the 
> ability to recognize the '$' at the front specifically to allow DIL users to 
> ask about registers and LLDB convenience variables, which (to the best of my 
> knowledge) allow '$' only in the first position, and not all by itself.

I don't know how you were checking that, but I'm certain that's not the case. I 
[already gave you](https://godbolt.org/z/o7qbfeWve) an example of C code which 
contradicts all of these (note that there can be difference between what's 
considered a valid identifier by the specification of a language, and what an 
actual compiler for that language will accept). And I'm not even mentioning all 
of the names that can be constructed by synthetic child providers.

You say you want to add utf-8 support. How do you intend to do that? Do you 
want to enumerate all of the supported characters in each language? Check which 
language supports variable names in Klingon? Some of the rules can be really 
obscure. For example, Java accepts £ (`\xA3`) as a variable name, but not © 
(`\xa9`). I'm sure they had some reason to choose that, but I'd rather not have 
to find that out.

OTOH, if you just accept all of the high-bit ascii values as valid characters, 
then you can support utf8 with a single line of code. And you're not regressing 
anything because that's exactly what the current implementation does.

I don't think this list has to be set in stone. For example, `frame variable` 
currently accepts `@` as a variable name. I believe you don't have any plans 
for that operator, so I'd just stick to that. If we can come up with some fancy 
use for it (maybe as an escape character?), then I'm certainly open to changing 
its classification.

> I am not sure I see that benefits of expanding what DIL recognizes as a valid 
> identifier beyond what the languages LLDB supports recognize?

For me the main benefits are:
- simplicity of the implementation
- being able to express a wide range of variable names, even for languages we 
don't support right now
- matching status quo

That said, I would like to hear what you think are the benefits of *not* 
recognizing wider set of identifier values. And I'm not talking about names 
like `123foo` (it sounds like there's consensus to ban those). I'm thinking 
more of names like `$`, `foo$`, `💩`, etc. 

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

1 2 >

1 - 100 of 108 matches

Mail list logo