[Lldb-commits] [lldb] [lldb][DataFormatter] Format libstdc++ unique_ptr like we do libc++ (PR #146909)

2025-07-04 Thread Pavel Labath via lldb-commits 

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

Looks good. Just noting I'm kind of surprised that these pointers have a 
weak_count of 1. I see it's a preexisting issue, and it may make sense if you 
know the implementation, but as a user, I'm surprised.

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

[Lldb-commits] [lldb] [lldb] Pass address expression command args through FixAnyAddress (PR #147011)

2025-07-04 Thread David Spickett via lldb-commits 


@@ -44,6 +43,8 @@ def test_armv7_corefile(self):
 self.assertTrue(exception.IsValid())
 self.assertEqual(exception.GetValueAsUnsigned(), 0x3F5C)
 
+self.expect("x/4bx $sp-1", substrs=["0x000d", "0xff 0x00 0x01 
0x02"])

DavidSpickett wrote:

Comment to explain this magic.

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

[Lldb-commits] [lldb] [lldb] Pass address expression command args through FixAnyAddress (PR #147011)

2025-07-04 Thread David Spickett via lldb-commits 

https://github.com/DavidSpickett commented:

I agree with the change, FixAnyAddress uses whatever is the least destructive 
fix.

Jonas should look over the core file bit, I don't know much about MachO.

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

[Lldb-commits] [lldb] [LLDB] Fix Incorrect offset for Memory64 RVA in Minidump (+ Testing changes) (PR #146777)

2025-07-04 Thread Pavel Labath via lldb-commits 

labath wrote:

> This removes the need to pass flags (which is not a design decision I like 
> but I didn't see many alternatives). @labath any opposition to putting 
> everything in mem64?

I don't have an opinion on that. I'm not currently involved in minidumps.

What I am not excited about is the idea of creating stringly-typed forever 
stable API for the purpose of testing a fix like this. As for alternatives, an 
"obvious" one is a unit tests. If you manage (I think it should be possible) 
instantiate the minidump writer with a mock process, then you can call any API 
you want, such as one that writes a 64-bit region (but still pass it a small 
memory block).

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

[Lldb-commits] [lldb] a89e232 - [lldb][DataFormatter] Format libstdc++ unique_ptr like we do libc++ (#146909)

2025-07-04 Thread via lldb-commits 

Author: Michael Buch
Date: 2025-07-04T09:18:24+01:00
New Revision: a89e232058a29260eb9bfe77b862715ce875f962

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

LOG: [lldb][DataFormatter] Format libstdc++ unique_ptr like we do libc++ 
(#146909)

The only difference is that with libc++ the summary string contains the
derefernced pointer value. With libstdc++ we currently display the
pointer itself, which seems redundant. E.g.,
```
(std::unique_ptr) iup = 0x5556d2b0 {
  pointer = 0x5556d2b0
}
(std::unique_ptr >) sup = 0x5556d2d0 {
  pointer = "foobar"
}
```

This patch moves the logic into a common helper that's shared between
the libc++ and libstdc++ formatters.

After this patch we can combine the libc++ and libstdc++ API tests (see
https://github.com/llvm/llvm-project/pull/146740).

Added: 


Modified: 
lldb/include/lldb/DataFormatters/FormattersHelpers.h
lldb/source/DataFormatters/FormattersHelpers.cpp
lldb/source/Plugins/Language/CPlusPlus/LibCxx.cpp
lldb/source/Plugins/Language/CPlusPlus/LibStdcppUniquePointer.cpp

lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/shared_ptr/TestDataFormatterLibcxxSharedPtr.py

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

lldb/test/API/functionalities/data-formatter/data-formatter-stl/libstdcpp/unique_ptr/TestDataFormatterStdUniquePtr.py

Removed: 




diff  --git a/lldb/include/lldb/DataFormatters/FormattersHelpers.h 
b/lldb/include/lldb/DataFormatters/FormattersHelpers.h
index 42699d0a0b1b1..97d367afc65d7 100644
--- a/lldb/include/lldb/DataFormatters/FormattersHelpers.h
+++ b/lldb/include/lldb/DataFormatters/FormattersHelpers.h
@@ -55,6 +55,11 @@ void AddFilter(TypeCategoryImpl::SharedPointer category_sp,
 
 std::optional ExtractIndexFromString(const char *item_name);
 
+/// Prints the summary for the pointer value of a C++
+/// std::unique_ptr/std::shared_ptr/std::weak_ptr.
+void DumpCxxSmartPtrPointerSummary(Stream &stream, ValueObject &ptr,
+   const TypeSummaryOptions &options);
+
 Address GetArrayAddressOrPointerValue(ValueObject &valobj);
 
 time_t GetOSXEpoch();

diff  --git a/lldb/source/DataFormatters/FormattersHelpers.cpp 
b/lldb/source/DataFormatters/FormattersHelpers.cpp
index d7b058d91c4a3..81c76b06fc47a 100644
--- a/lldb/source/DataFormatters/FormattersHelpers.cpp
+++ b/lldb/source/DataFormatters/FormattersHelpers.cpp
@@ -126,3 +126,22 @@ 
lldb_private::formatters::GetArrayAddressOrPointerValue(ValueObject &valobj) {
 
   return data_addr.address;
 }
+
+void lldb_private::formatters::DumpCxxSmartPtrPointerSummary(
+Stream &stream, ValueObject &ptr, const TypeSummaryOptions &options) {
+  if (ptr.GetValueAsUnsigned(0) == 0) {
+stream.Printf("nullptr");
+return;
+  }
+
+  Status error;
+  ValueObjectSP pointee_sp = ptr.Dereference(error);
+  if (!pointee_sp || !error.Success())
+return;
+
+  if (!pointee_sp->DumpPrintableRepresentation(
+  stream, ValueObject::eValueObjectRepresentationStyleSummary,
+  lldb::eFormatInvalid,
+  ValueObject::PrintableRepresentationSpecialCases::eDisable, false))
+stream.Printf("ptr = 0x%" PRIx64, ptr.GetValueAsUnsigned(0));
+}

diff  --git a/lldb/source/Plugins/Language/CPlusPlus/LibCxx.cpp 
b/lldb/source/Plugins/Language/CPlusPlus/LibCxx.cpp
index 7143089209dd3..009586f525282 100644
--- a/lldb/source/Plugins/Language/CPlusPlus/LibCxx.cpp
+++ b/lldb/source/Plugins/Language/CPlusPlus/LibCxx.cpp
@@ -157,39 +157,38 @@ bool 
lldb_private::formatters::LibcxxSmartPointerSummaryProvider(
   ValueObjectSP valobj_sp(valobj.GetNonSyntheticValue());
   if (!valobj_sp)
 return false;
-  ValueObjectSP ptr_sp(valobj_sp->GetChildMemberWithName("__ptr_"));
-  ValueObjectSP count_sp(
-  valobj_sp->GetChildAtNamePath({"__cntrl_", "__shared_owners_"}));
-  ValueObjectSP weakcount_sp(
-  valobj_sp->GetChildAtNamePath({"__cntrl_", "__shared_weak_owners_"}));
 
-  if (!ptr_sp)
+  ValueObjectSP ptr_sp(valobj_sp->GetChildMemberWithName("__ptr_"));
+  ValueObjectSP ctrl_sp(valobj_sp->GetChildMemberWithName("__cntrl_"));
+  if (!ctrl_sp || !ptr_sp)
 return false;
 
-  if (ptr_sp->GetValueAsUnsigned(0) == 0) {
-stream.Printf("nullptr");
+  DumpCxxSmartPtrPointerSummary(stream, *ptr_sp, options);
+
+  bool success;
+  uint64_t ctrl_addr = ctrl_sp->GetValueAsUnsigned(0, &success);
+  // Empty control field. We're done.
+  if (!success || ctrl_addr == 0)
 return true;
-  } else {
-bool print_pointee = false;
-Status error;
-ValueObjectSP pointee_sp = ptr_sp->Dereference(error);
-if (pointee_sp && error.Success()) {
-  if (pointee_sp->DumpPrintableRepresentation(
-  stream, ValueObject::eValue

[Lldb-commits] [lldb] [lldb][DataFormatter] Format libstdc++ unique_ptr like we do libc++ (PR #146909)

2025-07-04 Thread Michael Buch via lldb-commits 

Michael137 wrote:

> Looks good. Just noting I'm kind of surprised that these pointers have a 
> weak_count of 1. I see it's a preexisting issue, and it may make sense if you 
> know the implementation, but as a user, I'm surprised.

Yea the counts confused me a bit. I'll have a look at that separately.

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

[Lldb-commits] [lldb] [lldb][DataFormatter] Format libstdc++ unique_ptr like we do libc++ (PR #146909)

2025-07-04 Thread Michael Buch via lldb-commits 

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

[Lldb-commits] [lldb] [lldb][mcp] Skip MCPUnixSocketCommandTestCase if remote (PR #146807)

2025-07-04 Thread Pavel Labath via lldb-commits 

labath wrote:

It cannot. However, the MCP connection is done locally (on the machine running 
lldb). You could argue `@skipIfRemote` is still a good thing because remote 
testing is not useful here (you could use the protocol to drive a remote debug 
session, but for most purposes the two sessions should behave the same way and 
this is hardly the right way to test that), but checking the host os is still 
the right thing to do.

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

[Lldb-commits] [lldb] [lldb][RPC] Upstream RPC server interface emitters (PR #138032)

2025-07-04 Thread David Spickett via lldb-commits 


@@ -0,0 +1,15 @@
+# Disabling until the lldb-rpc-gen tool lands.
+UNSUPPORTED: system-windows, system-linux, system-darwin

DavidSpickett wrote:

That's fine with me.

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

[Lldb-commits] [lldb] [lldb] Pass address expression command args through FixAnyAddress (PR #147011)

2025-07-04 Thread Jason Molenda via lldb-commits 

https://github.com/jasonmolenda created 
https://github.com/llvm/llvm-project/pull/147011

Commands that take an address expression/address through the 
OptionArgParser::ToAddress method, which has filtered this user-specified 
address through one of the Process Fix methods to clear non-addressable bits 
(MTE, PAC, top byte ignore, etc).  We don't know what class of address this is, 
IMEM or DMEM, but this method is passing the addresses through 
Process::FixCodeAddress, and on at least one target, FixCodeAddress clears low 
bits which are invalid for instructions.

Correct this to use FixAnyAddress, which doesn't make alignment assumptions.

The actual issue found was by people debugging on a 32-bit ARM Cortex-M part, 
who tried to do a memory read from an odd address, and lldb returned results 
starting at the next lower even address.

rdar://154885727

>From bf1838f4676bab0f7c998d3dbb03b6b593103335 Mon Sep 17 00:00:00 2001
From: Jason Molenda 
Date: Fri, 4 Jul 2025 00:11:30 -0700
Subject: [PATCH] [lldb] Pass address expression command args through
 FixAnyAddress

Commands that take an address expression/address through the
OptionArgParser::ToAddress method, which has filtered this
user-specified address through one of the Process Fix methods to
clear non-addressable bits (MTE, PAC, top byte ignore, etc).  We
don't know what class of address this is, IMEM or DMEM, but this
method is passing the addresses through Process::FixCodeAddress,
and on at least one target, FixCodeAddress clears low bits which
are invalid for instructions.

Correct this to use FixAnyAddress, which doesn't make alignment
assumptions.

The actual issue found was by people debugging on a 32-bit ARM
Cortex-M part, who tried to do a memory read from an odd address,
and lldb returned results starting at the next lower even address.

rdar://154885727
---
 lldb/source/Interpreter/OptionArgParser.cpp   |  3 +-
 .../TestArmMachoCorefileRegctx.py |  3 +-
 .../create-arm-corefiles.cpp  | 63 ---
 3 files changed, 58 insertions(+), 11 deletions(-)

diff --git a/lldb/source/Interpreter/OptionArgParser.cpp 
b/lldb/source/Interpreter/OptionArgParser.cpp
index 2d393a57452ee..616f6e3dc8820 100644
--- a/lldb/source/Interpreter/OptionArgParser.cpp
+++ b/lldb/source/Interpreter/OptionArgParser.cpp
@@ -175,8 +175,7 @@ lldb::addr_t OptionArgParser::ToAddress(const 
ExecutionContext *exe_ctx,
   lldb::addr_t addr = *maybe_addr;
 
   if (Process *process = exe_ctx->GetProcessPtr())
-if (ABISP abi_sp = process->GetABI())
-  addr = abi_sp->FixCodeAddress(addr);
+addr = process->FixAnyAddress(addr);
 
   return addr;
 }
diff --git 
a/lldb/test/API/macosx/arm-corefile-regctx/TestArmMachoCorefileRegctx.py 
b/lldb/test/API/macosx/arm-corefile-regctx/TestArmMachoCorefileRegctx.py
index 4190ea3ac3318..8e34a292e4d5e 100644
--- a/lldb/test/API/macosx/arm-corefile-regctx/TestArmMachoCorefileRegctx.py
+++ b/lldb/test/API/macosx/arm-corefile-regctx/TestArmMachoCorefileRegctx.py
@@ -1,6 +1,5 @@
 """Test that Mach-O armv7/arm64 corefile register contexts are read by lldb."""
 
-
 import os
 import re
 import subprocess
@@ -44,6 +43,8 @@ def test_armv7_corefile(self):
 self.assertTrue(exception.IsValid())
 self.assertEqual(exception.GetValueAsUnsigned(), 0x3F5C)
 
+self.expect("x/4bx $sp-1", substrs=["0x000d", "0xff 0x00 0x01 
0x02"])
+
 def test_arm64_corefile(self):
 ### Create corefile
 retcode = call(self.create_corefile + " arm64 " + self.corefile, 
shell=True)
diff --git a/lldb/test/API/macosx/arm-corefile-regctx/create-arm-corefiles.cpp 
b/lldb/test/API/macosx/arm-corefile-regctx/create-arm-corefiles.cpp
index 5517a2397ae52..2bcc48497bdc4 100644
--- a/lldb/test/API/macosx/arm-corefile-regctx/create-arm-corefiles.cpp
+++ b/lldb/test/API/macosx/arm-corefile-regctx/create-arm-corefiles.cpp
@@ -10,15 +10,30 @@
 // only defines the ARM register context constants when building on
 // an arm system.  We're creating fake corefiles, and might be
 // creating them on an intel system.
+#ifndef ARM_THREAD_STATE
 #define ARM_THREAD_STATE 1
+#endif
+#ifndef ARM_THREAD_STATE_COUNT
 #define ARM_THREAD_STATE_COUNT 17
+#endif
+#ifndef ARM_EXCEPTION_STATE
 #define ARM_EXCEPTION_STATE 3
+#endif
+#ifndef ARM_EXCEPTION_STATE_COUNT
 #define ARM_EXCEPTION_STATE_COUNT 3
+#endif
+#ifndef ARM_THREAD_STATE64
 #define ARM_THREAD_STATE64 6
+#endif
+#ifndef ARM_THREAD_STATE64_COUNT
 #define ARM_THREAD_STATE64_COUNT 68
+#endif
+#ifndef ARM_EXCEPTION_STATE64
 #define ARM_EXCEPTION_STATE64 7
+#endif
+#ifndef ARM_EXCEPTION_STATE64_COUNT
 #define ARM_EXCEPTION_STATE64_COUNT 4
-
+#endif
 
 union uint32_buf {
   uint8_t bytebuf[4];
@@ -129,6 +144,24 @@ std::vector arm64_lc_thread_load_command() {
   return data;
 }
 
+std::vector lc_segment(uint32_t fileoff) {
+  std::vector data;
+  add_uint32(data, LC_SEGMENT); // segment_command.cmd
+  add_uint32(data, sizeof(struct segmen

[Lldb-commits] [lldb] [lldb] Pass address expression command args through FixAnyAddress (PR #147011)

2025-07-04 Thread Jason Molenda via lldb-commits 

https://github.com/jasonmolenda updated 
https://github.com/llvm/llvm-project/pull/147011

>From bf1838f4676bab0f7c998d3dbb03b6b593103335 Mon Sep 17 00:00:00 2001
From: Jason Molenda 
Date: Fri, 4 Jul 2025 00:11:30 -0700
Subject: [PATCH] [lldb] Pass address expression command args through
 FixAnyAddress

Commands that take an address expression/address through the
OptionArgParser::ToAddress method, which has filtered this
user-specified address through one of the Process Fix methods to
clear non-addressable bits (MTE, PAC, top byte ignore, etc).  We
don't know what class of address this is, IMEM or DMEM, but this
method is passing the addresses through Process::FixCodeAddress,
and on at least one target, FixCodeAddress clears low bits which
are invalid for instructions.

Correct this to use FixAnyAddress, which doesn't make alignment
assumptions.

The actual issue found was by people debugging on a 32-bit ARM
Cortex-M part, who tried to do a memory read from an odd address,
and lldb returned results starting at the next lower even address.

rdar://154885727
---
 lldb/source/Interpreter/OptionArgParser.cpp   |  3 +-
 .../TestArmMachoCorefileRegctx.py |  3 +-
 .../create-arm-corefiles.cpp  | 63 ---
 3 files changed, 58 insertions(+), 11 deletions(-)

diff --git a/lldb/source/Interpreter/OptionArgParser.cpp 
b/lldb/source/Interpreter/OptionArgParser.cpp
index 2d393a57452ee..616f6e3dc8820 100644
--- a/lldb/source/Interpreter/OptionArgParser.cpp
+++ b/lldb/source/Interpreter/OptionArgParser.cpp
@@ -175,8 +175,7 @@ lldb::addr_t OptionArgParser::ToAddress(const 
ExecutionContext *exe_ctx,
   lldb::addr_t addr = *maybe_addr;
 
   if (Process *process = exe_ctx->GetProcessPtr())
-if (ABISP abi_sp = process->GetABI())
-  addr = abi_sp->FixCodeAddress(addr);
+addr = process->FixAnyAddress(addr);
 
   return addr;
 }
diff --git 
a/lldb/test/API/macosx/arm-corefile-regctx/TestArmMachoCorefileRegctx.py 
b/lldb/test/API/macosx/arm-corefile-regctx/TestArmMachoCorefileRegctx.py
index 4190ea3ac3318..8e34a292e4d5e 100644
--- a/lldb/test/API/macosx/arm-corefile-regctx/TestArmMachoCorefileRegctx.py
+++ b/lldb/test/API/macosx/arm-corefile-regctx/TestArmMachoCorefileRegctx.py
@@ -1,6 +1,5 @@
 """Test that Mach-O armv7/arm64 corefile register contexts are read by lldb."""
 
-
 import os
 import re
 import subprocess
@@ -44,6 +43,8 @@ def test_armv7_corefile(self):
 self.assertTrue(exception.IsValid())
 self.assertEqual(exception.GetValueAsUnsigned(), 0x3F5C)
 
+self.expect("x/4bx $sp-1", substrs=["0x000d", "0xff 0x00 0x01 
0x02"])
+
 def test_arm64_corefile(self):
 ### Create corefile
 retcode = call(self.create_corefile + " arm64 " + self.corefile, 
shell=True)
diff --git a/lldb/test/API/macosx/arm-corefile-regctx/create-arm-corefiles.cpp 
b/lldb/test/API/macosx/arm-corefile-regctx/create-arm-corefiles.cpp
index 5517a2397ae52..2bcc48497bdc4 100644
--- a/lldb/test/API/macosx/arm-corefile-regctx/create-arm-corefiles.cpp
+++ b/lldb/test/API/macosx/arm-corefile-regctx/create-arm-corefiles.cpp
@@ -10,15 +10,30 @@
 // only defines the ARM register context constants when building on
 // an arm system.  We're creating fake corefiles, and might be
 // creating them on an intel system.
+#ifndef ARM_THREAD_STATE
 #define ARM_THREAD_STATE 1
+#endif
+#ifndef ARM_THREAD_STATE_COUNT
 #define ARM_THREAD_STATE_COUNT 17
+#endif
+#ifndef ARM_EXCEPTION_STATE
 #define ARM_EXCEPTION_STATE 3
+#endif
+#ifndef ARM_EXCEPTION_STATE_COUNT
 #define ARM_EXCEPTION_STATE_COUNT 3
+#endif
+#ifndef ARM_THREAD_STATE64
 #define ARM_THREAD_STATE64 6
+#endif
+#ifndef ARM_THREAD_STATE64_COUNT
 #define ARM_THREAD_STATE64_COUNT 68
+#endif
+#ifndef ARM_EXCEPTION_STATE64
 #define ARM_EXCEPTION_STATE64 7
+#endif
+#ifndef ARM_EXCEPTION_STATE64_COUNT
 #define ARM_EXCEPTION_STATE64_COUNT 4
-
+#endif
 
 union uint32_buf {
   uint8_t bytebuf[4];
@@ -129,6 +144,24 @@ std::vector arm64_lc_thread_load_command() {
   return data;
 }
 
+std::vector lc_segment(uint32_t fileoff) {
+  std::vector data;
+  add_uint32(data, LC_SEGMENT); // segment_command.cmd
+  add_uint32(data, sizeof(struct segment_command)); // segment_command.cmdsize
+  for (int i = 0; i < 16; i++)
+data.push_back(0);// segment_command.segname[16]
+  add_uint32(data, 0x000e - 512); // segment_command.vmaddr
+  add_uint32(data, 1024); // segment_command.vmsize
+  add_uint32(data, fileoff);  // segment_command.fileoff
+  add_uint32(data, 1024); // segment_command.filesize
+  add_uint32(data, 3);// segment_command.maxprot
+  add_uint32(data, 3);// segment_command.initprot
+  add_uint32(data, 0);// segment_command.nsects
+  add_uint32(data, 0);// segment_command.flags
+
+  return data;
+}
+
 enum arch { unspecified, armv7, arm64 };
 
 int main(int argc, char **argv) {
@@ -157,

[Lldb-commits] [lldb] [lldb] Pass address expression command args through FixAnyAddress (PR #147011)

2025-07-04 Thread via lldb-commits 

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Jason Molenda (jasonmolenda)


Changes

Commands that take an address expression/address through the 
OptionArgParser::ToAddress method, which has filtered this user-specified 
address through one of the Process Fix methods to clear non-addressable bits 
(MTE, PAC, top byte ignore, etc).  We don't know what class of address this is, 
IMEM or DMEM, but this method is passing the addresses through 
Process::FixCodeAddress, and on at least one target, FixCodeAddress clears low 
bits which are invalid for instructions.

Correct this to use FixAnyAddress, which doesn't make alignment assumptions.

The actual issue found was by people debugging on a 32-bit ARM Cortex-M part, 
who tried to do a memory read from an odd address, and lldb returned results 
starting at the next lower even address.

rdar://154885727

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


3 Files Affected:

- (modified) lldb/source/Interpreter/OptionArgParser.cpp (+1-2) 
- (modified) 
lldb/test/API/macosx/arm-corefile-regctx/TestArmMachoCorefileRegctx.py (+2-1) 
- (modified) lldb/test/API/macosx/arm-corefile-regctx/create-arm-corefiles.cpp 
(+55-8) 


``diff
diff --git a/lldb/source/Interpreter/OptionArgParser.cpp 
b/lldb/source/Interpreter/OptionArgParser.cpp
index 2d393a57452ee..616f6e3dc8820 100644
--- a/lldb/source/Interpreter/OptionArgParser.cpp
+++ b/lldb/source/Interpreter/OptionArgParser.cpp
@@ -175,8 +175,7 @@ lldb::addr_t OptionArgParser::ToAddress(const 
ExecutionContext *exe_ctx,
   lldb::addr_t addr = *maybe_addr;
 
   if (Process *process = exe_ctx->GetProcessPtr())
-if (ABISP abi_sp = process->GetABI())
-  addr = abi_sp->FixCodeAddress(addr);
+addr = process->FixAnyAddress(addr);
 
   return addr;
 }
diff --git 
a/lldb/test/API/macosx/arm-corefile-regctx/TestArmMachoCorefileRegctx.py 
b/lldb/test/API/macosx/arm-corefile-regctx/TestArmMachoCorefileRegctx.py
index 4190ea3ac3318..8e34a292e4d5e 100644
--- a/lldb/test/API/macosx/arm-corefile-regctx/TestArmMachoCorefileRegctx.py
+++ b/lldb/test/API/macosx/arm-corefile-regctx/TestArmMachoCorefileRegctx.py
@@ -1,6 +1,5 @@
 """Test that Mach-O armv7/arm64 corefile register contexts are read by lldb."""
 
-
 import os
 import re
 import subprocess
@@ -44,6 +43,8 @@ def test_armv7_corefile(self):
 self.assertTrue(exception.IsValid())
 self.assertEqual(exception.GetValueAsUnsigned(), 0x3F5C)
 
+self.expect("x/4bx $sp-1", substrs=["0x000d", "0xff 0x00 0x01 
0x02"])
+
 def test_arm64_corefile(self):
 ### Create corefile
 retcode = call(self.create_corefile + " arm64 " + self.corefile, 
shell=True)
diff --git a/lldb/test/API/macosx/arm-corefile-regctx/create-arm-corefiles.cpp 
b/lldb/test/API/macosx/arm-corefile-regctx/create-arm-corefiles.cpp
index 5517a2397ae52..2bcc48497bdc4 100644
--- a/lldb/test/API/macosx/arm-corefile-regctx/create-arm-corefiles.cpp
+++ b/lldb/test/API/macosx/arm-corefile-regctx/create-arm-corefiles.cpp
@@ -10,15 +10,30 @@
 // only defines the ARM register context constants when building on
 // an arm system.  We're creating fake corefiles, and might be
 // creating them on an intel system.
+#ifndef ARM_THREAD_STATE
 #define ARM_THREAD_STATE 1
+#endif
+#ifndef ARM_THREAD_STATE_COUNT
 #define ARM_THREAD_STATE_COUNT 17
+#endif
+#ifndef ARM_EXCEPTION_STATE
 #define ARM_EXCEPTION_STATE 3
+#endif
+#ifndef ARM_EXCEPTION_STATE_COUNT
 #define ARM_EXCEPTION_STATE_COUNT 3
+#endif
+#ifndef ARM_THREAD_STATE64
 #define ARM_THREAD_STATE64 6
+#endif
+#ifndef ARM_THREAD_STATE64_COUNT
 #define ARM_THREAD_STATE64_COUNT 68
+#endif
+#ifndef ARM_EXCEPTION_STATE64
 #define ARM_EXCEPTION_STATE64 7
+#endif
+#ifndef ARM_EXCEPTION_STATE64_COUNT
 #define ARM_EXCEPTION_STATE64_COUNT 4
-
+#endif
 
 union uint32_buf {
   uint8_t bytebuf[4];
@@ -129,6 +144,24 @@ std::vector arm64_lc_thread_load_command() {
   return data;
 }
 
+std::vector lc_segment(uint32_t fileoff) {
+  std::vector data;
+  add_uint32(data, LC_SEGMENT); // segment_command.cmd
+  add_uint32(data, sizeof(struct segment_command)); // segment_command.cmdsize
+  for (int i = 0; i < 16; i++)
+data.push_back(0);// segment_command.segname[16]
+  add_uint32(data, 0x000e - 512); // segment_command.vmaddr
+  add_uint32(data, 1024); // segment_command.vmsize
+  add_uint32(data, fileoff);  // segment_command.fileoff
+  add_uint32(data, 1024); // segment_command.filesize
+  add_uint32(data, 3);// segment_command.maxprot
+  add_uint32(data, 3);// segment_command.initprot
+  add_uint32(data, 0);// segment_command.nsects
+  add_uint32(data, 0);// segment_command.flags
+
+  return data;
+}
+
 enum arch { unspecified, armv7, arm64 };
 
 int main(int argc, char **argv) {
@@ -157,10 +190,12 @@ int main(int argc, char **argv) {
 
   // First add all the load commands

[Lldb-commits] [lldb] [lldb] Pass address expression command args through FixAnyAddress (PR #147011)

2025-07-04 Thread Jason Molenda via lldb-commits 

jasonmolenda wrote:

I can't imagine which 32-bit arm hater made this kind of change originally.

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

[Lldb-commits] [lldb] [lldb] Pass address expression command args through FixAnyAddress (PR #147011)

2025-07-04 Thread Jason Molenda via lldb-commits 

jasonmolenda wrote:

I didn't have a solid way to test this except rely on the arm-ubuntu bot, so I 
enhanced a random armv7 mach-o corefile creator tool I wrote ages ago to add a 
memory segment, and try to read from an odd address to confirm that it behaves 
correctly, but this test will only run on macos.

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

[Lldb-commits] [lldb] [lldb] Pass address expression command args through FixAnyAddress (PR #147011)

2025-07-04 Thread Jason Molenda via lldb-commits 

jasonmolenda wrote:

FTR armv7 has one of the few FixCodeAddress methods that actually clears the 
low bits, because the low bit is sometimes used to indicate arm/thumb processor 
state of functions.

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

[Lldb-commits] [lldb] [lldb-dap] Improving 'variables' hover requests. (PR #146773)

2025-07-04 Thread Pavel Labath via lldb-commits 

labath wrote:

> > the request will be expression="char*foo", which won't evaluate correctly 
> > in lldb.
> 
> We could search starting from the back for the first occurrence of either "&" 
> or "*". I think `llvm::StringRef::find_last_of()` does this.

That's rather specific to C. In Swift for instance, the variable name comes 
before the type (`var i:Int`).

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

[Lldb-commits] [lldb] d74c9ef - [lldb][test] Skip TestFrameVarDILGlobalVariableLookup.py on older AArch64 macOS version

2025-07-04 Thread Michael Buch via lldb-commits 

Author: Michael Buch
Date: 2025-07-04T09:32:21+01:00
New Revision: d74c9ef8370c9310452859ff876a2a5d8b8f7ad5

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

LOG: [lldb][test] Skip TestFrameVarDILGlobalVariableLookup.py on older AArch64 
macOS version

Currently failing on the arm64 macOS CI with:
```
06:59:37  Traceback (most recent call last):
06:59:37File 
"/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-sanitized/llvm-project/lldb/test/API/commands/frame/var-dil/basics/GlobalVariableLookup/TestFrameVarDILGlobalVariableLookup.py",
 line 47, in test_frame_var
06:59:37  self.expect_var_path("ExtStruct::static_inline", value="16")
06:59:37File 
"/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-sanitized/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py",
 line 2589, in expect_var_path
06:59:37  value_check.check_value(self, eval_result, str(eval_result))
06:59:37File 
"/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-sanitized/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py",
 line 301, in check_value
06:59:37  test_base.assertSuccess(val.GetError())
06:59:37File 
"/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-sanitized/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py",
 line 2597, in assertSuccess
06:59:37  self.fail(self._formatMessage(msg, "'{}' is not 
success".format(error)))
06:59:37  AssertionError: ':1:1: use of undeclared 
identifier 'ExtStruct::static_inline'
06:59:37 1 | ExtStruct::static_inline
06:59:37   | ^' is not success
06:59:37  
Config=arm64-/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-sanitized/lldb-build/bin/clang
06:59:37  --
06:59:37  Ran 1 test in 2.322s
06:59:37
```

Can't repro this locally so skipping on older macOS versions that the CI
is running.

Added: 


Modified: 

lldb/test/API/commands/frame/var-dil/basics/GlobalVariableLookup/TestFrameVarDILGlobalVariableLookup.py

Removed: 




diff  --git 
a/lldb/test/API/commands/frame/var-dil/basics/GlobalVariableLookup/TestFrameVarDILGlobalVariableLookup.py
 
b/lldb/test/API/commands/frame/var-dil/basics/GlobalVariableLookup/TestFrameVarDILGlobalVariableLookup.py
index 8a8f068c19466..9cb166e3d0dc1 100644
--- 
a/lldb/test/API/commands/frame/var-dil/basics/GlobalVariableLookup/TestFrameVarDILGlobalVariableLookup.py
+++ 
b/lldb/test/API/commands/frame/var-dil/basics/GlobalVariableLookup/TestFrameVarDILGlobalVariableLookup.py
@@ -18,6 +18,7 @@ class TestFrameVarDILGlobalVariableLookup(TestBase):
 # each debug info format.
 NO_DEBUG_INFO_TESTCASE = True
 
+@skipIf(macos_version=["<", "15.0"], archs=["arm64", "arm64e"])
 def test_frame_var(self):
 self.build()
 lldbutil.run_to_source_breakpoint(



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

[Lldb-commits] [lldb] [LLDB] Optimize identifier lookup in DIL (PR #146094)

2025-07-04 Thread Ilia Kuklin via lldb-commits 

kuilpd wrote:

Alright, thank you!

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

[Lldb-commits] [lldb] [lldb] Adding pipe support to lldb_private::MainLoopWindows. (PR #145621)

2025-07-04 Thread Dmitry Vasilyev via lldb-commits 

slydiman wrote:

The test lldb-unit::HostTests.exe/MainLoopTest/NoSpuriousPipeReads is flaky on 
Windows.
Please fix it.

https://lab.llvm.org/buildbot/#/builders/211/builds/231
https://lab.llvm.org/buildbot/#/builders/197/builds/6659


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

[Lldb-commits] [lldb] [lldb] Update the String table offset based on the DWARF format (PR #147054)

2025-07-04 Thread Adrian Vogelsgesang via lldb-commits 

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

[Lldb-commits] [lldb] [lldb] Update the String table offset based on the DWARF format (PR #147054)

2025-07-04 Thread David Spickett via lldb-commits 

DavidSpickett wrote:

This is the relevant part of the standard, correct?

```
7.5.5 Classes and Forms

18 • stroffsetsptr
19 This is an offset into the .debug_str_offsets section
20 (DW_FORM_sec_offset). It consists of an offset from the beginning of the
21 .debug_str_offsets section to the beginning of the string offsets
22 information for the referencing entity. It is relocatable in a relocatable 
object
23 file, and relocated in an executable or shared object file. In the 32-bit
24 DWARF format, this offset is a 4-byte unsigned value; in the 64-bit DWARF
25 format, it is an 8-byte unsigned value (see Section 7.4 on page 196).
```
(https://dwarfstd.org/doc/DWARF5.pdf)

I see also "7.4 32-Bit and 64-Bit DWARF Formats", is there anything else in 
there we need to handle? (I don't know enough to guess the effects of getting 
those wrong)

I'm also going to run the test suite and see what fails. The baseline is 
dwarf32:
```
LLDB_TEST_USER_ARGS  -E;\"-gdwarf32\"


Failed Tests (5):
  lldb-api :: commands/frame/language/TestGuessLanguage.py
  lldb-api :: functionalities/multiple-slides/TestMultipleSlides.py
  lldb-api :: functionalities/step-avoids-no-debug/TestStepNoDebug.py
  lldb-api :: lang/c/conflicting-symbol/TestConflictingSymbol.py
  lldb-api :: lang/cpp/incomplete-types/members/TestCppIncompleteTypeMembers.py
```
All of these manipulate debug info flags, so this is expected.

Now DWARF64 current main branch:
```
LLDB_TEST_USER_ARGS  -E;\"-gdwarf64\"

Total Discovered Tests: 33363
  Skipped  : 1 (0.00%)
  Unsupported  :   518 (1.55%)
  Passed   : 32273 (96.73%)
  Expectedly Failed:31 (0.09%)
  Unresolved   :12 (0.04%)
  Timed Out: 1 (0.00%)
  Failed   :   527 (1.58%)
```
A lot of failures, and I had to kill some tests. Could be the way I'm passing 
the argument, but if so, I'd expect more failures in the baseline.

Running tests on your PR right now.

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

[Lldb-commits] [lldb] [lldb] Update the String table offset based on the DWARF format (PR #147054)

2025-07-04 Thread David Spickett via lldb-commits 

DavidSpickett wrote:

DWARF64, with this PR branch:
```
Total Discovered Tests: 33363
  Skipped  : 1 (0.00%)
  Unsupported  :   518 (1.55%)
  Passed   : 32716 (98.06%)
  Expectedly Failed:31 (0.09%)
  Unresolved   : 3 (0.01%)
  Failed   :94 (0.28%)
```
And I did not need to kill any tests.

So thats...  433 fewer tests failing and 9 fewer tests unresolved, +443 passes.

A common error message I see is:
```
error: a.out Failed to extract range list table at offset 0x0014: 
.debug_rnglists table at offset 0x8 has too small length (0x4) to contain a 
complete header
```
And by searching that error message I found:
```
const std::optional &
DWARFUnit::GetRnglistTable() {
  if (GetVersion() >= 5 && !m_rnglist_table_done) {
m_rnglist_table_done = true;
if (auto table_or_error =
ParseListTableHeader(
GetRnglistData().GetAsLLVMDWARF(), m_ranges_base, DWARF32))
  m_rnglist_table = std::move(table_or_error.get());
else
  GetSymbolFileDWARF().GetObjectFile()->GetModule()->ReportError(
  "Failed to extract range list table at offset {0:x16}: {1}",
  m_ranges_base, toString(table_or_error.takeError()).c_str());
  }
  return m_rnglist_table;
}
```
So this is your next thing to fix :)

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

[Lldb-commits] [lldb] [lldb] Update the String table offset based on the DWARF format (PR #147054)

2025-07-04 Thread David Spickett via lldb-commits 

DavidSpickett wrote:

> Could use a test case.

But I too still want a targeted test case for this. Especially given that no 
one is going to be running a DWARF64 buildbot any time soon.

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

[Lldb-commits] [lldb] [lldb] Update the String table offset based on the DWARF format (PR #147054)

2025-07-04 Thread David Spickett via lldb-commits 

DavidSpickett wrote:

> And by searching that error message I found:

Hacking that to be DWARF64 gets more tests passing:
```
Total Discovered Tests: 33363
  Skipped  : 1 (0.00%)
  Unsupported  :   518 (1.55%)
  Passed   : 32696 (98.00%)
  Expectedly Failed:31 (0.09%)
  Unresolved   : 2 (0.01%)
  Failed   :   115 (0.34%)
```
I suggest you look in lldb's source for any uses of the DWARF32 symbol, I bet 
we've done this elsewhere too.

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

[Lldb-commits] [lldb] [lldb][Formatter] Consolidate libstdc++ and libc++ unique_ptr formatter tests into generic test (PR #147031)

2025-07-04 Thread Michael Buch via lldb-commits 

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

The libc++ test was a subset of the tests in libstdc++. This test moves the 
libc++ test into `generic` and somne additional test-cases from `libstdc++` 
(specifically the recursive unique_ptr case). It turns out the libstdc++ 
formatter supports dereferencing using the "object" or "obj" names. We could 
either drop those from the tests or support the same for libc++. I took the 
latter approach but don't have strong opinions on this.

Split out from https://github.com/llvm/llvm-project/pull/146740

>From afa00be16641075f71bb7ce15e568ecb3b126719 Mon Sep 17 00:00:00 2001
From: Michael Buch 
Date: Thu, 3 Jul 2025 15:41:44 +0100
Subject: [PATCH] [lldb][Formatter] Consolidate libstdc++ and libc++ unique_ptr
 formatter tests into generic test

The libc++ test was a subset of the tests in libstdc++. This test moves
the libc++ test into `generic` and somne additional test-cases from `libstdc++`
(specifically the recursive unique_ptr case). It turns out the libstdc++
formatter supports dereferencing using the "object" or "obj" names. We
could either drop those from the tests or support the same for libc++. I
took the latter approach but don't have strong opinions on this.

Split out from https://github.com/llvm/llvm-project/pull/146740
---
 .../Plugins/Language/CPlusPlus/LibCxx.cpp |   2 +-
 .../{libcxx => generic}/unique_ptr/Makefile   |   2 -
 .../TestDataFormatterStdUniquePtr.py} |  71 +-
 .../{libcxx => generic}/unique_ptr/main.cpp   |  17 ++-
 .../libstdcpp/unique_ptr/Makefile |   5 -
 .../TestDataFormatterStdUniquePtr.py  | 134 --
 .../TestDataFormatterInvalidStdUniquePtr.py   |   4 -
 .../libstdcpp/unique_ptr/invalid/main.cpp |  11 --
 .../libstdcpp/unique_ptr/main.cpp |  35 -
 9 files changed, 82 insertions(+), 199 deletions(-)
 rename lldb/test/API/functionalities/data-formatter/data-formatter-stl/{libcxx 
=> generic}/unique_ptr/Makefile (92%)
 rename 
lldb/test/API/functionalities/data-formatter/data-formatter-stl/{libcxx/unique_ptr/TestDataFormatterLibcxxUniquePtr.py
 => generic/unique_ptr/TestDataFormatterStdUniquePtr.py} (64%)
 rename lldb/test/API/functionalities/data-formatter/data-formatter-stl/{libcxx 
=> generic}/unique_ptr/main.cpp (74%)
 delete mode 100644 
lldb/test/API/functionalities/data-formatter/data-formatter-stl/libstdcpp/unique_ptr/Makefile
 delete mode 100644 
lldb/test/API/functionalities/data-formatter/data-formatter-stl/libstdcpp/unique_ptr/TestDataFormatterStdUniquePtr.py
 delete mode 100644 
lldb/test/API/functionalities/data-formatter/data-formatter-stl/libstdcpp/unique_ptr/invalid/TestDataFormatterInvalidStdUniquePtr.py
 delete mode 100644 
lldb/test/API/functionalities/data-formatter/data-formatter-stl/libstdcpp/unique_ptr/invalid/main.cpp
 delete mode 100644 
lldb/test/API/functionalities/data-formatter/data-formatter-stl/libstdcpp/unique_ptr/main.cpp

diff --git a/lldb/source/Plugins/Language/CPlusPlus/LibCxx.cpp 
b/lldb/source/Plugins/Language/CPlusPlus/LibCxx.cpp
index 009586f525282..51e43b2f62a1e 100644
--- a/lldb/source/Plugins/Language/CPlusPlus/LibCxx.cpp
+++ b/lldb/source/Plugins/Language/CPlusPlus/LibCxx.cpp
@@ -399,7 +399,7 @@ lldb_private::formatters::LibcxxUniquePtrSyntheticFrontEnd::
 return 0;
   if (name == "deleter")
 return 1;
-  if (name == "$$dereference$$")
+  if (name == "obj" || name == "object" || name == "$$dereference$$")
 return 2;
   return llvm::createStringError("Type has no child named '%s'",
  name.AsCString());
diff --git 
a/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/unique_ptr/Makefile
 
b/lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/unique_ptr/Makefile
similarity index 92%
rename from 
lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/unique_ptr/Makefile
rename to 
lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/unique_ptr/Makefile
index c1c8b4a2a0a53..ece665a0fd5b7 100644
--- 
a/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/unique_ptr/Makefile
+++ 
b/lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/unique_ptr/Makefile
@@ -1,7 +1,5 @@
 CXX_SOURCES := main.cpp
 
-USE_LIBCPP := 1
-
 # We need debug info tuning for lldb in order to emit the preferred name for
 # std::string. See https://reviews.llvm.org/D145803.
 CXXFLAGS_EXTRAS := -std=c++14 -glldb
diff --git 
a/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/unique_ptr/TestDataFormatterLibcxxUniquePtr.py
 
b/lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/unique_ptr/TestDataFormatterStdUniquePtr.py
similarity index 64%
rename from 
lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/unique_ptr/TestDataFormatterLibcxxUniquePtr.py
rename to 
lldb/test/API/functionalities/data-for

[Lldb-commits] [lldb] [lldb][Formatter] Consolidate libstdc++ and libc++ unique_ptr formatter tests into generic test (PR #147031)

2025-07-04 Thread via lldb-commits 

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Michael Buch (Michael137)


Changes

The libc++ test was a subset of the tests in libstdc++. This test moves the 
libc++ test into `generic` and somne additional test-cases from `libstdc++` 
(specifically the recursive unique_ptr case). It turns out the libstdc++ 
formatter supports dereferencing using the "object" or "obj" names. We could 
either drop those from the tests or support the same for libc++. I took the 
latter approach but don't have strong opinions on this.

Split out from https://github.com/llvm/llvm-project/pull/146740

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


9 Files Affected:

- (modified) lldb/source/Plugins/Language/CPlusPlus/LibCxx.cpp (+1-1) 
- (renamed) 
lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/unique_ptr/Makefile
 (-2) 
- (renamed) 
lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/unique_ptr/TestDataFormatterStdUniquePtr.py
 (+66-5) 
- (renamed) 
lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/unique_ptr/main.cpp
 (+15-2) 
- (removed) 
lldb/test/API/functionalities/data-formatter/data-formatter-stl/libstdcpp/unique_ptr/Makefile
 (-5) 
- (removed) 
lldb/test/API/functionalities/data-formatter/data-formatter-stl/libstdcpp/unique_ptr/TestDataFormatterStdUniquePtr.py
 (-134) 
- (removed) 
lldb/test/API/functionalities/data-formatter/data-formatter-stl/libstdcpp/unique_ptr/invalid/TestDataFormatterInvalidStdUniquePtr.py
 (-4) 
- (removed) 
lldb/test/API/functionalities/data-formatter/data-formatter-stl/libstdcpp/unique_ptr/invalid/main.cpp
 (-11) 
- (removed) 
lldb/test/API/functionalities/data-formatter/data-formatter-stl/libstdcpp/unique_ptr/main.cpp
 (-35) 


``diff
diff --git a/lldb/source/Plugins/Language/CPlusPlus/LibCxx.cpp 
b/lldb/source/Plugins/Language/CPlusPlus/LibCxx.cpp
index 009586f525282..51e43b2f62a1e 100644
--- a/lldb/source/Plugins/Language/CPlusPlus/LibCxx.cpp
+++ b/lldb/source/Plugins/Language/CPlusPlus/LibCxx.cpp
@@ -399,7 +399,7 @@ lldb_private::formatters::LibcxxUniquePtrSyntheticFrontEnd::
 return 0;
   if (name == "deleter")
 return 1;
-  if (name == "$$dereference$$")
+  if (name == "obj" || name == "object" || name == "$$dereference$$")
 return 2;
   return llvm::createStringError("Type has no child named '%s'",
  name.AsCString());
diff --git 
a/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/unique_ptr/Makefile
 
b/lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/unique_ptr/Makefile
similarity index 92%
rename from 
lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/unique_ptr/Makefile
rename to 
lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/unique_ptr/Makefile
index c1c8b4a2a0a53..ece665a0fd5b7 100644
--- 
a/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/unique_ptr/Makefile
+++ 
b/lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/unique_ptr/Makefile
@@ -1,7 +1,5 @@
 CXX_SOURCES := main.cpp
 
-USE_LIBCPP := 1
-
 # We need debug info tuning for lldb in order to emit the preferred name for
 # std::string. See https://reviews.llvm.org/D145803.
 CXXFLAGS_EXTRAS := -std=c++14 -glldb
diff --git 
a/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/unique_ptr/TestDataFormatterLibcxxUniquePtr.py
 
b/lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/unique_ptr/TestDataFormatterStdUniquePtr.py
similarity index 64%
rename from 
lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/unique_ptr/TestDataFormatterLibcxxUniquePtr.py
rename to 
lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/unique_ptr/TestDataFormatterStdUniquePtr.py
index 25a1cd82a4baa..57e1ea9f234f8 100644
--- 
a/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/unique_ptr/TestDataFormatterLibcxxUniquePtr.py
+++ 
b/lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/unique_ptr/TestDataFormatterStdUniquePtr.py
@@ -1,8 +1,7 @@
 """
-Test lldb data formatter for libc++ std::unique_ptr.
+Test lldb data formatter for std::unique_ptr.
 """
 
-
 import lldb
 from lldbsuite.test.decorators import *
 from lldbsuite.test.lldbtest import *
@@ -32,10 +31,8 @@ def make_expected_basic_string_ptr(self) -> str:
 "std::default_delete, std::allocator > > >"
 )
 
-@add_test_categories(["libc++"])
-def test_unique_ptr_variables(self):
+def do_test(self):
 """Test `frame variable` output for `std::unique_ptr` types."""
-self.build()
 
 lldbutil.run_to_source_breakpoint(
 self, "// break here", lldb.SBFileSpec("main.cpp")
@@ -121,3 +118,67 @@ def test_unique_ptr_variables(self):
 self.expect_var_path("ptr_node->next->value", value="2")
 self.expect_var_path("(*ptr_node).

[Lldb-commits] [lldb] [lldb][AArch64][Linux] Show MTE store only setting in mte_ctrl (PR #145033)

2025-07-04 Thread David Spickett via lldb-commits 

https://github.com/DavidSpickett updated 
https://github.com/llvm/llvm-project/pull/145033

>From ba8fcf4ef14e25b8a628b994988d6a67bdbea7df Mon Sep 17 00:00:00 2001
From: David Spickett 
Date: Thu, 19 Jun 2025 10:43:48 +
Subject: [PATCH 1/3] [lldb][AArch64] Add HWCAP3 to register field detection

This will be used to detect the presence of Arm's new Memory
Tagging store only checking feature.

This commit just adds the plubming to get that value into
the detection function.

FreeBSD has not allocated a number for HWCAP3 and already
has AT_ARGV defined as 29. So instead of attempting to read
from FreeBSD processes, I've explictly passed nullopt.

We don't want to be reading some other entry accidentally.

If/when FreeBSD adds HWCAP3 we can handle it like we do for
AUXV_FREEBSD_AT_HWCAP.

No extra tests here, those will be coming with the next
change for MTE support.
---
 .../NativeRegisterContextFreeBSD_arm64.cpp|  3 +-
 .../NativeRegisterContextLinux_arm64.cpp  |  5 ++-
 .../Plugins/Process/Utility/AuxVector.cpp |  1 +
 .../Plugins/Process/Utility/AuxVector.h   |  1 +
 .../Utility/RegisterFlagsDetector_arm64.cpp   | 36 +--
 .../Utility/RegisterFlagsDetector_arm64.h | 25 -
 .../RegisterContextPOSIXCore_arm64.cpp| 13 ---
 7 files changed, 59 insertions(+), 25 deletions(-)

diff --git 
a/lldb/source/Plugins/Process/FreeBSD/NativeRegisterContextFreeBSD_arm64.cpp 
b/lldb/source/Plugins/Process/FreeBSD/NativeRegisterContextFreeBSD_arm64.cpp
index 7adc00622ec2d..d21dac221aa22 100644
--- a/lldb/source/Plugins/Process/FreeBSD/NativeRegisterContextFreeBSD_arm64.cpp
+++ b/lldb/source/Plugins/Process/FreeBSD/NativeRegisterContextFreeBSD_arm64.cpp
@@ -44,7 +44,8 @@ 
NativeRegisterContextFreeBSD::CreateHostNativeRegisterContextFreeBSD(
 NativeProcessFreeBSD &process = native_thread.GetProcess();
 g_register_flags_detector.DetectFields(
 process.GetAuxValue(AuxVector::AUXV_FREEBSD_AT_HWCAP).value_or(0),
-process.GetAuxValue(AuxVector::AUXV_AT_HWCAP2).value_or(0));
+process.GetAuxValue(AuxVector::AUXV_AT_HWCAP2).value_or(0),
+/*hwcap3=*/0);
   }
 
   return new NativeRegisterContextFreeBSD_arm64(target_arch, native_thread);
diff --git 
a/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp 
b/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp
index 884c7d4b9e359..b1c7421bef8d5 100644
--- a/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp
+++ b/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp
@@ -162,10 +162,13 @@ 
NativeRegisterContextLinux::CreateHostNativeRegisterContextLinux(
 
 opt_regsets.Set(RegisterInfoPOSIX_arm64::eRegsetMaskTLS);
 
+std::optional auxv_at_hwcap3 =
+process.GetAuxValue(AuxVector::AUXV_AT_HWCAP3);
 std::lock_guard lock(g_register_flags_detector_mutex);
 if (!g_register_flags_detector.HasDetected())
   g_register_flags_detector.DetectFields(auxv_at_hwcap.value_or(0),
- auxv_at_hwcap2.value_or(0));
+ auxv_at_hwcap2.value_or(0),
+ auxv_at_hwcap3.value_or(0));
 
 auto register_info_up =
 std::make_unique(target_arch, opt_regsets);
diff --git a/lldb/source/Plugins/Process/Utility/AuxVector.cpp 
b/lldb/source/Plugins/Process/Utility/AuxVector.cpp
index f495ffb1924e7..50500a8593e1d 100644
--- a/lldb/source/Plugins/Process/Utility/AuxVector.cpp
+++ b/lldb/source/Plugins/Process/Utility/AuxVector.cpp
@@ -84,6 +84,7 @@ const char *AuxVector::GetEntryName(EntryType type) const {
 case ENTRY_NAME(AUXV_AT_BASE_PLATFORM);  break;
 case ENTRY_NAME(AUXV_AT_RANDOM); break;
 case ENTRY_NAME(AUXV_AT_HWCAP2); break;
+case ENTRY_NAME(AUXV_AT_HWCAP3); break;
 case ENTRY_NAME(AUXV_AT_EXECFN); break;
 case ENTRY_NAME(AUXV_AT_SYSINFO);break;
 case ENTRY_NAME(AUXV_AT_SYSINFO_EHDR);   break;
diff --git a/lldb/source/Plugins/Process/Utility/AuxVector.h 
b/lldb/source/Plugins/Process/Utility/AuxVector.h
index 2670b34f6b0af..7733e0ffc6832 100644
--- a/lldb/source/Plugins/Process/Utility/AuxVector.h
+++ b/lldb/source/Plugins/Process/Utility/AuxVector.h
@@ -57,6 +57,7 @@ class AuxVector {
 AUXV_AT_BASE_PLATFORM = 24, ///< String identifying real platforms.
 AUXV_AT_RANDOM = 25,///< Address of 16 random bytes.
 AUXV_AT_HWCAP2 = 26,///< Extension of AT_HWCAP.
+AUXV_AT_HWCAP3 = 29,///< Extension of AT_HWCAP.
 AUXV_AT_EXECFN = 31,///< Filename of executable.
 AUXV_AT_SYSINFO = 32, ///< Pointer to the global system page used for 
system
   /// calls and other nice things.
diff --git 
a/lldb/source/Plugins/Process/Utility/RegisterFlagsDetector_arm64.cpp 
b/lldb/source/Plugins/Process/Utility/RegisterFlagsDetector_arm64.cpp
index 042940b7dff

[Lldb-commits] [lldb] [lldb] Fix race condition in Process::WaitForProcessToStop() (PR #144919)

2025-07-04 Thread Pavel Labath via lldb-commits 

https://github.com/labath commented:

Looks good, but you should add a unit test for the moving functionality. You 
know, things like: queue, some events, hijack them, make sure they're received 
at the new listener, and vice versa.

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

[Lldb-commits] [lldb] [lldb] Update the String table offset based on the DWARF format (PR #147054)

2025-07-04 Thread Hemang Gadhavi via lldb-commits 

https://github.com/HemangGadhavi created 
https://github.com/llvm/llvm-project/pull/147054

This PR is updating the string table offset (DW_AT_str_offsets_base which is 
introduces in `DWARF5`) based on the DWARF format, as per the DWARF 
specification, For the 32-bit DWARF format, each offset is 4 bytes long; for 
the 64-bit DWARF format, each offset is 8 bytes long.


>From 4ae4d0ab6ba44317e00dced8f247341ec9930c2c Mon Sep 17 00:00:00 2001
From: HemangGadhavi 
Date: Fri, 4 Jul 2025 09:28:30 -0400
Subject: [PATCH] [lldb] Updated the String table offset based on the DWARF
 format

---
 lldb/source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp
index f216ab13e8936..daaa4eca6f198 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp
@@ -1077,7 +1077,8 @@ uint32_t DWARFUnit::GetHeaderByteSize() const { return 
m_header.getSize(); }
 
 std::optional
 DWARFUnit::GetStringOffsetSectionItem(uint32_t index) const {
-  lldb::offset_t offset = GetStrOffsetsBase() + index * 4;
+  lldb::offset_t offset =
+  GetStrOffsetsBase() + index * m_header.getDwarfOffsetByteSize();
   return m_dwarf.GetDWARFContext().getOrLoadStrOffsetsData().GetU32(&offset);
 }
 

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

[Lldb-commits] [lldb] [lldb] Update the String table offset based on the DWARF format (PR #147054)

2025-07-04 Thread via lldb-commits 

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Hemang Gadhavi (HemangGadhavi)


Changes

This PR is updating the string table offset (DW_AT_str_offsets_base which is 
introduces in `DWARF5`) based on the DWARF format, as per the DWARF 
specification, For the 32-bit DWARF format, each offset is 4 bytes long; for 
the 64-bit DWARF format, each offset is 8 bytes long.


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


1 Files Affected:

- (modified) lldb/source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp (+2-1) 


``diff
diff --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp
index f216ab13e8936..daaa4eca6f198 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp
@@ -1077,7 +1077,8 @@ uint32_t DWARFUnit::GetHeaderByteSize() const { return 
m_header.getSize(); }
 
 std::optional
 DWARFUnit::GetStringOffsetSectionItem(uint32_t index) const {
-  lldb::offset_t offset = GetStrOffsetsBase() + index * 4;
+  lldb::offset_t offset =
+  GetStrOffsetsBase() + index * m_header.getDwarfOffsetByteSize();
   return m_dwarf.GetDWARFContext().getOrLoadStrOffsetsData().GetU32(&offset);
 }
 

``




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

[Lldb-commits] [lldb] [lldb] Update the String table offset based on the DWARF format (PR #147054)

2025-07-04 Thread Hemang Gadhavi via lldb-commits 

HemangGadhavi wrote:

@labath @DavidSpickett 
Related to PR https://github.com/llvm/llvm-project/issues/135208 
Please have review once.  DW_AT_str_offsets_base was missing to handle for 
DWARF64.


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

[Lldb-commits] [lldb] [lldb] Update the String table offset based on the DWARF format (PR #147054)

2025-07-04 Thread Hemang Gadhavi via lldb-commits 

HemangGadhavi wrote:

@DhruvSrivastavaX FYI

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

[Lldb-commits] [lldb] [lldb] Update the String table offset based on the DWARF format (PR #147054)

2025-07-04 Thread Hemang Gadhavi via lldb-commits 

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

[Lldb-commits] [lldb] 32946eb - [lldb][Formatters] Fix weak reference count for std::shared_ptr/std::weak_ptr (#147033)

2025-07-04 Thread via lldb-commits 

Author: Michael Buch
Date: 2025-07-04T15:31:47+01:00
New Revision: 32946eb124e87a58a94b55ee0a64d1d2265fc58d

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

LOG: [lldb][Formatters] Fix weak reference count for 
std::shared_ptr/std::weak_ptr (#147033)

For the `__shared_owners_` we need to add `+1` to the count, but for
`__shared_weak_owners_` the value reflects the exact number of weak
references.

Added: 


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

lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/shared_ptr/TestDataFormatterLibcxxSharedPtr.py

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

Removed: 




diff  --git a/lldb/source/Plugins/Language/CPlusPlus/LibCxx.cpp 
b/lldb/source/Plugins/Language/CPlusPlus/LibCxx.cpp
index 009586f525282..104521b8c3e71 100644
--- a/lldb/source/Plugins/Language/CPlusPlus/LibCxx.cpp
+++ b/lldb/source/Plugins/Language/CPlusPlus/LibCxx.cpp
@@ -177,6 +177,9 @@ bool 
lldb_private::formatters::LibcxxSmartPointerSummaryProvider(
 if (!success)
   return false;
 
+// std::shared_ptr releases the underlying resource when the
+// __shared_owners_ count hits -1. So `__shared_owners_ == 0` indicates 1
+// owner. Hence add +1 here.
 stream.Printf(" strong=%" PRIu64, count + 1);
   }
 
@@ -187,7 +190,9 @@ bool 
lldb_private::formatters::LibcxxSmartPointerSummaryProvider(
 if (!success)
   return false;
 
-stream.Printf(" weak=%" PRIu64, count + 1);
+// Unlike __shared_owners_, __shared_weak_owners_ indicates the exact
+// std::weak_ptr reference count.
+stream.Printf(" weak=%" PRIu64, count);
   }
 
   return true;

diff  --git 
a/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/shared_ptr/TestDataFormatterLibcxxSharedPtr.py
 
b/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/shared_ptr/TestDataFormatterLibcxxSharedPtr.py
index 6ecf5ca88e90e..25f616ff61046 100644
--- 
a/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/shared_ptr/TestDataFormatterLibcxxSharedPtr.py
+++ 
b/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/shared_ptr/TestDataFormatterLibcxxSharedPtr.py
@@ -14,7 +14,7 @@ def test_shared_ptr_variables(self):
 """Test `frame variable` output for `std::shared_ptr` types."""
 self.build()
 
-lldbutil.run_to_source_breakpoint(
+(_, process, _, bkpt) = lldbutil.run_to_source_breakpoint(
 self, "// break here", lldb.SBFileSpec("main.cpp")
 )
 
@@ -37,7 +37,7 @@ def test_shared_ptr_variables(self):
 type="std::shared_ptr",
 children=[ValueCheck(name="__ptr_")],
 )
-self.assertRegex(valobj.summary, r"^10( strong=1)? weak=1$")
+self.assertRegex(valobj.summary, r"^10( strong=1)? weak=0$")
 self.assertNotEqual(valobj.child[0].unsigned, 0)
 
 valobj = self.expect_var_path(
@@ -45,7 +45,7 @@ def test_shared_ptr_variables(self):
 type="std::shared_ptr &",
 children=[ValueCheck(name="__ptr_")],
 )
-self.assertRegex(valobj.summary, r"^10( strong=1)? weak=1$")
+self.assertRegex(valobj.summary, r"^10( strong=1)? weak=0$")
 self.assertNotEqual(valobj.child[0].unsigned, 0)
 
 valobj = self.expect_var_path(
@@ -53,7 +53,7 @@ def test_shared_ptr_variables(self):
 type="std::shared_ptr &&",
 children=[ValueCheck(name="__ptr_")],
 )
-self.assertRegex(valobj.summary, r"^10( strong=1)? weak=1$")
+self.assertRegex(valobj.summary, r"^10( strong=1)? weak=0$")
 self.assertNotEqual(valobj.child[0].unsigned, 0)
 
 if self.expectedCompiler(["clang"]) and self.expectedCompilerVersion(
@@ -68,12 +68,12 @@ def test_shared_ptr_variables(self):
 type="std::shared_ptr<" + string_type + ">",
 children=[ValueCheck(name="__ptr_", summary='"hello"')],
 )
-self.assertRegex(valobj.summary, r'^"hello"( strong=1)? weak=1$')
+self.assertRegex(valobj.summary, r'^"hello"( strong=1)? weak=0$')
 
 valobj = self.expect_var_path("sp_user", type="std::shared_ptr")
 self.assertRegex(
 valobj.summary,
-"^std(::__[^:]*)?::shared_ptr::element_type @ 
0x0*[1-9a-f][0-9a-f]+( strong=1)? weak=1",
+"^std(::__[^:]*)?::shared_ptr::element_type @ 
0x0*[1-9a-f][0-9a-f]+( strong=1)? weak=0",
 )
 self.assertNotEqual(valobj.child[0].unsigned, 0)
 
@@ -91,11 +91,23 @@ def test_shared_ptr_variables(self):
 self.expect_var_path("sp_user->name", type="std::string", 
summary='"steph"')
 
 valobj = self.expect_var_path(
-

[Lldb-commits] [lldb] [lldb][Formatters] Fix weak reference count for std::shared_ptr/std::weak_ptr (PR #147033)

2025-07-04 Thread Michael Buch via lldb-commits 

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

[Lldb-commits] [lldb] Draft: [LLDB] Add scalar literal node (PR #147064)

2025-07-04 Thread Ilia Kuklin via lldb-commits 

kuilpd wrote:

@labath @cmtice @jimingham @asl
This is a draft with some potential changes I'd like to discuss regarding how 
to handle the type system of constant literals.
I'm also trying to demonstrate how they interact further with other values in a 
binary addition node. A lot of the code is cut out for better visibility of the 
important parts, but it's still quite a lot, I will later split this into 
separate PRs if anything comes out of this.

Things I've tried to address:
1. `DILEval.cpp:406-439`: Upon creation of `ScalarLiteralNode` it will default 
to the current compile unit's type system, instead of iterating through 
`target_sp->GetScratchTypeSystems()` [(old 
code)](https://github.com/kuilpd/llvm-project/blob/ad204cdfd226ca2a886c5475775fe67b29a70926/lldb/source/ValueObject/DILEval.cpp#L244).
 I think it's a good bet to assume that we want the type system of where we're 
currently stopped at. The node has to have some type in case it needs to be 
output as is. 
2. `DILEval.cpp:775-791`: However, when it is used in another node, like a + b, 
we check if operands' type systems match and if not, we check if one of them is 
a scalar literal, in which case they can be converted to the type system of 
another operand. 

The rest of the code in `DILEval.cpp:441-740` is mostly the type promotion and 
conversion implementation from our downstream, except I changed the compiler 
type to be retrieved from operands' type system, instead of the same scratch 
type system iteration. There's no need to review the entire logic here yet, 
just the part how it handles the types.

Here is the problem with types: initial scalar literal type, all the type 
promotions and conversions are done using `lldb::BasicType` enumeration types, 
and later converted to `CompilerType` using the `TypeSystem`. In C++, this 
works perfectly well, because in 
[`TypeSystemClang.cpp:5468`](https://github.com/llvm/llvm-project/blob/740da004af5ed402b6ddb0d71759f978bc814f7f/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp#L5468C1-L5468C41)
 it is implemented, but in 
[`TypeSystemSwift:304`](https://github.com/swiftlang/llvm-project/blob/4cbdeee819f3f2ce36d67af493fdd91c708612f4/lldb/source/Plugins/TypeSystem/Swift/TypeSystemSwift.h#L304)
 it is not.

Do we assume that this was just never needed before, so it can now be 
implemented and used? Or is there some sort of inherent incompatibility between 
LLDB's basic type system and Swift type system (talking about primitive types) 
that this cannot be implemented correctly? If so, what would be an alternative 
way to abstract the type promotion/conversion from the specific compiler type 
and type system?

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

[Lldb-commits] [lldb] [lldb][Formatters] Fix weak reference count for std::shared_ptr/std::weak_ptr (PR #147033)

2025-07-04 Thread Michael Buch via lldb-commits 

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

For the `__shared_owners_` we need to add `+1` to the count, but for 
`__shared_weak_owners_` the value reflects the exact number of weak references.

>From 6700e8ba954d0ce29b8703ec35a992e93bf1dfdc Mon Sep 17 00:00:00 2001
From: Michael Buch 
Date: Fri, 4 Jul 2025 11:22:57 +0100
Subject: [PATCH] [lldb][Formatters] Fix weak reference count for
 std::shared_ptr/std::weak_ptr

For the `__shared_owners_` we need to add `+1` to the count, but for
`__shared_weak_owners_` the value reflects the exact number of weak
references.
---
 .../Plugins/Language/CPlusPlus/LibCxx.cpp |  7 -
 .../TestDataFormatterLibcxxSharedPtr.py   | 28 +--
 .../libcxx/shared_ptr/main.cpp| 10 ++-
 3 files changed, 35 insertions(+), 10 deletions(-)

diff --git a/lldb/source/Plugins/Language/CPlusPlus/LibCxx.cpp 
b/lldb/source/Plugins/Language/CPlusPlus/LibCxx.cpp
index 009586f525282..104521b8c3e71 100644
--- a/lldb/source/Plugins/Language/CPlusPlus/LibCxx.cpp
+++ b/lldb/source/Plugins/Language/CPlusPlus/LibCxx.cpp
@@ -177,6 +177,9 @@ bool 
lldb_private::formatters::LibcxxSmartPointerSummaryProvider(
 if (!success)
   return false;
 
+// std::shared_ptr releases the underlying resource when the
+// __shared_owners_ count hits -1. So `__shared_owners_ == 0` indicates 1
+// owner. Hence add +1 here.
 stream.Printf(" strong=%" PRIu64, count + 1);
   }
 
@@ -187,7 +190,9 @@ bool 
lldb_private::formatters::LibcxxSmartPointerSummaryProvider(
 if (!success)
   return false;
 
-stream.Printf(" weak=%" PRIu64, count + 1);
+// Unlike __shared_owners_, __shared_weak_owners_ indicates the exact
+// std::weak_ptr reference count.
+stream.Printf(" weak=%" PRIu64, count);
   }
 
   return true;
diff --git 
a/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/shared_ptr/TestDataFormatterLibcxxSharedPtr.py
 
b/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/shared_ptr/TestDataFormatterLibcxxSharedPtr.py
index 6ecf5ca88e90e..25f616ff61046 100644
--- 
a/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/shared_ptr/TestDataFormatterLibcxxSharedPtr.py
+++ 
b/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/shared_ptr/TestDataFormatterLibcxxSharedPtr.py
@@ -14,7 +14,7 @@ def test_shared_ptr_variables(self):
 """Test `frame variable` output for `std::shared_ptr` types."""
 self.build()
 
-lldbutil.run_to_source_breakpoint(
+(_, process, _, bkpt) = lldbutil.run_to_source_breakpoint(
 self, "// break here", lldb.SBFileSpec("main.cpp")
 )
 
@@ -37,7 +37,7 @@ def test_shared_ptr_variables(self):
 type="std::shared_ptr",
 children=[ValueCheck(name="__ptr_")],
 )
-self.assertRegex(valobj.summary, r"^10( strong=1)? weak=1$")
+self.assertRegex(valobj.summary, r"^10( strong=1)? weak=0$")
 self.assertNotEqual(valobj.child[0].unsigned, 0)
 
 valobj = self.expect_var_path(
@@ -45,7 +45,7 @@ def test_shared_ptr_variables(self):
 type="std::shared_ptr &",
 children=[ValueCheck(name="__ptr_")],
 )
-self.assertRegex(valobj.summary, r"^10( strong=1)? weak=1$")
+self.assertRegex(valobj.summary, r"^10( strong=1)? weak=0$")
 self.assertNotEqual(valobj.child[0].unsigned, 0)
 
 valobj = self.expect_var_path(
@@ -53,7 +53,7 @@ def test_shared_ptr_variables(self):
 type="std::shared_ptr &&",
 children=[ValueCheck(name="__ptr_")],
 )
-self.assertRegex(valobj.summary, r"^10( strong=1)? weak=1$")
+self.assertRegex(valobj.summary, r"^10( strong=1)? weak=0$")
 self.assertNotEqual(valobj.child[0].unsigned, 0)
 
 if self.expectedCompiler(["clang"]) and self.expectedCompilerVersion(
@@ -68,12 +68,12 @@ def test_shared_ptr_variables(self):
 type="std::shared_ptr<" + string_type + ">",
 children=[ValueCheck(name="__ptr_", summary='"hello"')],
 )
-self.assertRegex(valobj.summary, r'^"hello"( strong=1)? weak=1$')
+self.assertRegex(valobj.summary, r'^"hello"( strong=1)? weak=0$')
 
 valobj = self.expect_var_path("sp_user", type="std::shared_ptr")
 self.assertRegex(
 valobj.summary,
-"^std(::__[^:]*)?::shared_ptr::element_type @ 
0x0*[1-9a-f][0-9a-f]+( strong=1)? weak=1",
+"^std(::__[^:]*)?::shared_ptr::element_type @ 
0x0*[1-9a-f][0-9a-f]+( strong=1)? weak=0",
 )
 self.assertNotEqual(valobj.child[0].unsigned, 0)
 
@@ -91,11 +91,23 @@ def test_shared_ptr_variables(self):
 self.expect_var_path("sp_user->name", type="std::string", 
summary='"steph"')
 
 valobj = self.expect_var_path(
-"si", type="std::shared_ptr", summary="47 strong=2 weak=1"
+"

[Lldb-commits] [lldb] [lldb][Formatters] Fix weak reference count for std::shared_ptr/std::weak_ptr (PR #147033)

2025-07-04 Thread via lldb-commits 

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Michael Buch (Michael137)


Changes

For the `__shared_owners_` we need to add `+1` to the count, but for 
`__shared_weak_owners_` the value reflects the exact number of weak references.

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


3 Files Affected:

- (modified) lldb/source/Plugins/Language/CPlusPlus/LibCxx.cpp (+6-1) 
- (modified) 
lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/shared_ptr/TestDataFormatterLibcxxSharedPtr.py
 (+20-8) 
- (modified) 
lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/shared_ptr/main.cpp
 (+9-1) 


``diff
diff --git a/lldb/source/Plugins/Language/CPlusPlus/LibCxx.cpp 
b/lldb/source/Plugins/Language/CPlusPlus/LibCxx.cpp
index 009586f525282..104521b8c3e71 100644
--- a/lldb/source/Plugins/Language/CPlusPlus/LibCxx.cpp
+++ b/lldb/source/Plugins/Language/CPlusPlus/LibCxx.cpp
@@ -177,6 +177,9 @@ bool 
lldb_private::formatters::LibcxxSmartPointerSummaryProvider(
 if (!success)
   return false;
 
+// std::shared_ptr releases the underlying resource when the
+// __shared_owners_ count hits -1. So `__shared_owners_ == 0` indicates 1
+// owner. Hence add +1 here.
 stream.Printf(" strong=%" PRIu64, count + 1);
   }
 
@@ -187,7 +190,9 @@ bool 
lldb_private::formatters::LibcxxSmartPointerSummaryProvider(
 if (!success)
   return false;
 
-stream.Printf(" weak=%" PRIu64, count + 1);
+// Unlike __shared_owners_, __shared_weak_owners_ indicates the exact
+// std::weak_ptr reference count.
+stream.Printf(" weak=%" PRIu64, count);
   }
 
   return true;
diff --git 
a/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/shared_ptr/TestDataFormatterLibcxxSharedPtr.py
 
b/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/shared_ptr/TestDataFormatterLibcxxSharedPtr.py
index 6ecf5ca88e90e..25f616ff61046 100644
--- 
a/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/shared_ptr/TestDataFormatterLibcxxSharedPtr.py
+++ 
b/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/shared_ptr/TestDataFormatterLibcxxSharedPtr.py
@@ -14,7 +14,7 @@ def test_shared_ptr_variables(self):
 """Test `frame variable` output for `std::shared_ptr` types."""
 self.build()
 
-lldbutil.run_to_source_breakpoint(
+(_, process, _, bkpt) = lldbutil.run_to_source_breakpoint(
 self, "// break here", lldb.SBFileSpec("main.cpp")
 )
 
@@ -37,7 +37,7 @@ def test_shared_ptr_variables(self):
 type="std::shared_ptr",
 children=[ValueCheck(name="__ptr_")],
 )
-self.assertRegex(valobj.summary, r"^10( strong=1)? weak=1$")
+self.assertRegex(valobj.summary, r"^10( strong=1)? weak=0$")
 self.assertNotEqual(valobj.child[0].unsigned, 0)
 
 valobj = self.expect_var_path(
@@ -45,7 +45,7 @@ def test_shared_ptr_variables(self):
 type="std::shared_ptr &",
 children=[ValueCheck(name="__ptr_")],
 )
-self.assertRegex(valobj.summary, r"^10( strong=1)? weak=1$")
+self.assertRegex(valobj.summary, r"^10( strong=1)? weak=0$")
 self.assertNotEqual(valobj.child[0].unsigned, 0)
 
 valobj = self.expect_var_path(
@@ -53,7 +53,7 @@ def test_shared_ptr_variables(self):
 type="std::shared_ptr &&",
 children=[ValueCheck(name="__ptr_")],
 )
-self.assertRegex(valobj.summary, r"^10( strong=1)? weak=1$")
+self.assertRegex(valobj.summary, r"^10( strong=1)? weak=0$")
 self.assertNotEqual(valobj.child[0].unsigned, 0)
 
 if self.expectedCompiler(["clang"]) and self.expectedCompilerVersion(
@@ -68,12 +68,12 @@ def test_shared_ptr_variables(self):
 type="std::shared_ptr<" + string_type + ">",
 children=[ValueCheck(name="__ptr_", summary='"hello"')],
 )
-self.assertRegex(valobj.summary, r'^"hello"( strong=1)? weak=1$')
+self.assertRegex(valobj.summary, r'^"hello"( strong=1)? weak=0$')
 
 valobj = self.expect_var_path("sp_user", type="std::shared_ptr")
 self.assertRegex(
 valobj.summary,
-"^std(::__[^:]*)?::shared_ptr::element_type @ 
0x0*[1-9a-f][0-9a-f]+( strong=1)? weak=1",
+"^std(::__[^:]*)?::shared_ptr::element_type @ 
0x0*[1-9a-f][0-9a-f]+( strong=1)? weak=0",
 )
 self.assertNotEqual(valobj.child[0].unsigned, 0)
 
@@ -91,11 +91,23 @@ def test_shared_ptr_variables(self):
 self.expect_var_path("sp_user->name", type="std::string", 
summary='"steph"')
 
 valobj = self.expect_var_path(
-"si", type="std::shared_ptr", summary="47 strong=2 weak=1"
+"si", type="std::shared_ptr", summary="47 strong=2 weak=0"
 )
 
 valobj = self.expect_var_path(
-"sie", type="std::shared_ptr", summary="nullptr strong=2 
weak

[Lldb-commits] [lldb] [lldb][Formatters] Fix weak reference count for std::shared_ptr/std::weak_ptr (PR #147033)

2025-07-04 Thread Pavel Labath via lldb-commits 

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


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

[Lldb-commits] [lldb] [lldb][Formatter] Consolidate libstdc++ and libc++ unique_ptr formatter tests into generic test (PR #147031)

2025-07-04 Thread Pavel Labath via lldb-commits 

https://github.com/labath commented:

Looks good modulo the failure in the libstdc++ version. The type name comes out 
different, presumably because libstdc++ doesn't contain the magic to print the 
template as std::string.

Testing string name printing is not really relevant for the unique_ptr 
formatter, so I'd delete the check from there. Testing that 
`SomeTemplate` prints the right way is useful, but would be better 
of in the test for preferred name printing (if we don't do that already).

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

[Lldb-commits] [lldb] [lldb] Update the String table offset based on the DWARF format (PR #147054)

2025-07-04 Thread Pavel Labath via lldb-commits 


@@ -1077,7 +1077,8 @@ uint32_t DWARFUnit::GetHeaderByteSize() const { return 
m_header.getSize(); }
 
 std::optional
 DWARFUnit::GetStringOffsetSectionItem(uint32_t index) const {
-  lldb::offset_t offset = GetStrOffsetsBase() + index * 4;
+  lldb::offset_t offset =
+  GetStrOffsetsBase() + index * m_header.getDwarfOffsetByteSize();
   return m_dwarf.GetDWARFContext().getOrLoadStrOffsetsData().GetU32(&offset);

labath wrote:

GetU32 should probably also change to `GetUnsigned(getDwarfOffsetByteSize())`

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

[Lldb-commits] [lldb] [lldb] Update the String table offset based on the DWARF format (PR #147054)

2025-07-04 Thread Pavel Labath via lldb-commits 

https://github.com/labath commented:

Could use a test case.

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

[Lldb-commits] [lldb] [lldb] Update the String table offset based on the DWARF format (PR #147054)

2025-07-04 Thread Pavel Labath via lldb-commits 

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

[Lldb-commits] [lldb] Draft: [LLDB] Add scalar literal node (PR #147064)

2025-07-04 Thread Ilia Kuklin via lldb-commits 

https://github.com/kuilpd created 
https://github.com/llvm/llvm-project/pull/147064

A draft to discuss scalar literal node implementation

>From cf1f908360399ac51770d9fb7e1dac03eceab0e9 Mon Sep 17 00:00:00 2001
From: Ilia Kuklin 
Date: Thu, 3 Jul 2025 19:34:17 +0500
Subject: [PATCH] [LLDB] *WIP* Add scalar literal node and binary addition

---
 lldb/include/lldb/ValueObject/DILAST.h|  58 
 lldb/include/lldb/ValueObject/DILEval.h   |  15 +
 lldb/include/lldb/ValueObject/DILLexer.h  |   1 +
 lldb/include/lldb/ValueObject/DILParser.h |   3 +
 lldb/source/ValueObject/DILAST.cpp|  21 ++
 lldb/source/ValueObject/DILEval.cpp   | 405 ++
 lldb/source/ValueObject/DILLexer.cpp  |  10 +-
 lldb/source/ValueObject/DILParser.cpp |  74 +++-
 8 files changed, 581 insertions(+), 6 deletions(-)

diff --git a/lldb/include/lldb/ValueObject/DILAST.h 
b/lldb/include/lldb/ValueObject/DILAST.h
index 709f0639135f1..a9d244031d55f 100644
--- a/lldb/include/lldb/ValueObject/DILAST.h
+++ b/lldb/include/lldb/ValueObject/DILAST.h
@@ -9,6 +9,7 @@
 #ifndef LLDB_VALUEOBJECT_DILAST_H
 #define LLDB_VALUEOBJECT_DILAST_H
 
+#include "lldb/ValueObject/DILLexer.h"
 #include "lldb/ValueObject/ValueObject.h"
 #include "llvm/Support/Error.h"
 #include 
@@ -19,10 +20,12 @@ namespace lldb_private::dil {
 /// The various types DIL AST nodes (used by the DIL parser).
 enum class NodeKind {
   eArraySubscriptNode,
+  eBinaryOpNode,
   eBitExtractionNode,
   eErrorNode,
   eIdentifierNode,
   eMemberOfNode,
+  eScalarLiteralNode,
   eUnaryOpNode,
 };
 
@@ -32,6 +35,14 @@ enum class UnaryOpKind {
   Deref,  // "*"
 };
 
+enum class BinaryOpKind {
+  Add, // "+"
+  Sub, // "-"
+};
+
+/// Translates DIL tokens to BinaryOpKind.
+BinaryOpKind GetBinaryOpKindFromToken(Token::Kind token_kind);
+
 /// Forward declaration, for use in DIL AST nodes. Definition is at the very
 /// end of this file.
 class Visitor;
@@ -178,6 +189,49 @@ class BitFieldExtractionNode : public ASTNode {
   int64_t m_last_index;
 };
 
+class ScalarLiteralNode : public ASTNode {
+public:
+  ScalarLiteralNode(uint32_t location, lldb::BasicType type, Scalar value)
+  : ASTNode(location, NodeKind::eScalarLiteralNode), m_type(type),
+m_value(value) {}
+
+  llvm::Expected Accept(Visitor *v) const override;
+
+  lldb::BasicType GetType() const { return m_type; }
+  Scalar GetValue() const & { return m_value; }
+
+  static bool classof(const ASTNode *node) {
+return node->GetKind() == NodeKind::eScalarLiteralNode;
+  }
+
+private:
+  lldb::BasicType m_type;
+  Scalar m_value;
+};
+
+class BinaryOpNode : public ASTNode {
+public:
+  BinaryOpNode(uint32_t location, BinaryOpKind kind, ASTNodeUP lhs,
+   ASTNodeUP rhs)
+  : ASTNode(location, NodeKind::eBinaryOpNode), m_kind(kind),
+m_lhs(std::move(lhs)), m_rhs(std::move(rhs)) {}
+
+  llvm::Expected Accept(Visitor *v) const override;
+
+  BinaryOpKind GetKind() const { return m_kind; }
+  ASTNode *GetLHS() const { return m_lhs.get(); }
+  ASTNode *GetRHS() const { return m_rhs.get(); }
+
+  static bool classof(const ASTNode *node) {
+return node->GetKind() == NodeKind::eBinaryOpNode;
+  }
+
+private:
+  BinaryOpKind m_kind;
+  ASTNodeUP m_lhs;
+  ASTNodeUP m_rhs;
+};
+
 /// This class contains one Visit method for each specialized type of
 /// DIL AST node. The Visit methods are used to dispatch a DIL AST node to
 /// the correct function in the DIL expression evaluator for evaluating that
@@ -195,6 +249,10 @@ class Visitor {
   Visit(const ArraySubscriptNode *node) = 0;
   virtual llvm::Expected
   Visit(const BitFieldExtractionNode *node) = 0;
+  virtual llvm::Expected
+  Visit(const ScalarLiteralNode *node) = 0;
+  virtual llvm::Expected
+  Visit(const BinaryOpNode *node) = 0;
 };
 
 } // namespace lldb_private::dil
diff --git a/lldb/include/lldb/ValueObject/DILEval.h 
b/lldb/include/lldb/ValueObject/DILEval.h
index 45e29b3ddcd7b..9e9028f6122fd 100644
--- a/lldb/include/lldb/ValueObject/DILEval.h
+++ b/lldb/include/lldb/ValueObject/DILEval.h
@@ -54,6 +54,21 @@ class Interpreter : Visitor {
   Visit(const ArraySubscriptNode *node) override;
   llvm::Expected
   Visit(const BitFieldExtractionNode *node) override;
+  llvm::Expected
+  Visit(const ScalarLiteralNode *node) override;
+  llvm::Expected Visit(const BinaryOpNode *node) override;
+
+  lldb::ValueObjectSP
+  ConvertValueObjectToTypeSystem(lldb::ValueObjectSP valobj,
+ lldb::TypeSystemSP type_system);
+
+  llvm::Error PrepareBinaryAddition(lldb::ValueObjectSP &lhs,
+lldb::ValueObjectSP &rhs,
+uint32_t location);
+
+  llvm::Expected
+  EvaluateBinaryAddition(lldb::ValueObjectSP lhs, lldb::ValueObjectSP rhs,
+ uint32_t location);
 
   // Used by the interpreter to create objects, perform casts, etc.
   lldb::TargetSP m_target;
diff --git a/lldb/include/lldb/ValueObject/DILLexer

[Lldb-commits] [lldb] Draft: [LLDB] Add scalar literal node (PR #147064)

2025-07-04 Thread via lldb-commits 

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Ilia Kuklin (kuilpd)


Changes

A draft to discuss scalar literal node implementation

---

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


8 Files Affected:

- (modified) lldb/include/lldb/ValueObject/DILAST.h (+58) 
- (modified) lldb/include/lldb/ValueObject/DILEval.h (+15) 
- (modified) lldb/include/lldb/ValueObject/DILLexer.h (+1) 
- (modified) lldb/include/lldb/ValueObject/DILParser.h (+3) 
- (modified) lldb/source/ValueObject/DILAST.cpp (+21) 
- (modified) lldb/source/ValueObject/DILEval.cpp (+405) 
- (modified) lldb/source/ValueObject/DILLexer.cpp (+6-4) 
- (modified) lldb/source/ValueObject/DILParser.cpp (+72-2) 


``diff
diff --git a/lldb/include/lldb/ValueObject/DILAST.h 
b/lldb/include/lldb/ValueObject/DILAST.h
index 709f0639135f1..a9d244031d55f 100644
--- a/lldb/include/lldb/ValueObject/DILAST.h
+++ b/lldb/include/lldb/ValueObject/DILAST.h
@@ -9,6 +9,7 @@
 #ifndef LLDB_VALUEOBJECT_DILAST_H
 #define LLDB_VALUEOBJECT_DILAST_H
 
+#include "lldb/ValueObject/DILLexer.h"
 #include "lldb/ValueObject/ValueObject.h"
 #include "llvm/Support/Error.h"
 #include 
@@ -19,10 +20,12 @@ namespace lldb_private::dil {
 /// The various types DIL AST nodes (used by the DIL parser).
 enum class NodeKind {
   eArraySubscriptNode,
+  eBinaryOpNode,
   eBitExtractionNode,
   eErrorNode,
   eIdentifierNode,
   eMemberOfNode,
+  eScalarLiteralNode,
   eUnaryOpNode,
 };
 
@@ -32,6 +35,14 @@ enum class UnaryOpKind {
   Deref,  // "*"
 };
 
+enum class BinaryOpKind {
+  Add, // "+"
+  Sub, // "-"
+};
+
+/// Translates DIL tokens to BinaryOpKind.
+BinaryOpKind GetBinaryOpKindFromToken(Token::Kind token_kind);
+
 /// Forward declaration, for use in DIL AST nodes. Definition is at the very
 /// end of this file.
 class Visitor;
@@ -178,6 +189,49 @@ class BitFieldExtractionNode : public ASTNode {
   int64_t m_last_index;
 };
 
+class ScalarLiteralNode : public ASTNode {
+public:
+  ScalarLiteralNode(uint32_t location, lldb::BasicType type, Scalar value)
+  : ASTNode(location, NodeKind::eScalarLiteralNode), m_type(type),
+m_value(value) {}
+
+  llvm::Expected Accept(Visitor *v) const override;
+
+  lldb::BasicType GetType() const { return m_type; }
+  Scalar GetValue() const & { return m_value; }
+
+  static bool classof(const ASTNode *node) {
+return node->GetKind() == NodeKind::eScalarLiteralNode;
+  }
+
+private:
+  lldb::BasicType m_type;
+  Scalar m_value;
+};
+
+class BinaryOpNode : public ASTNode {
+public:
+  BinaryOpNode(uint32_t location, BinaryOpKind kind, ASTNodeUP lhs,
+   ASTNodeUP rhs)
+  : ASTNode(location, NodeKind::eBinaryOpNode), m_kind(kind),
+m_lhs(std::move(lhs)), m_rhs(std::move(rhs)) {}
+
+  llvm::Expected Accept(Visitor *v) const override;
+
+  BinaryOpKind GetKind() const { return m_kind; }
+  ASTNode *GetLHS() const { return m_lhs.get(); }
+  ASTNode *GetRHS() const { return m_rhs.get(); }
+
+  static bool classof(const ASTNode *node) {
+return node->GetKind() == NodeKind::eBinaryOpNode;
+  }
+
+private:
+  BinaryOpKind m_kind;
+  ASTNodeUP m_lhs;
+  ASTNodeUP m_rhs;
+};
+
 /// This class contains one Visit method for each specialized type of
 /// DIL AST node. The Visit methods are used to dispatch a DIL AST node to
 /// the correct function in the DIL expression evaluator for evaluating that
@@ -195,6 +249,10 @@ class Visitor {
   Visit(const ArraySubscriptNode *node) = 0;
   virtual llvm::Expected
   Visit(const BitFieldExtractionNode *node) = 0;
+  virtual llvm::Expected
+  Visit(const ScalarLiteralNode *node) = 0;
+  virtual llvm::Expected
+  Visit(const BinaryOpNode *node) = 0;
 };
 
 } // namespace lldb_private::dil
diff --git a/lldb/include/lldb/ValueObject/DILEval.h 
b/lldb/include/lldb/ValueObject/DILEval.h
index 45e29b3ddcd7b..9e9028f6122fd 100644
--- a/lldb/include/lldb/ValueObject/DILEval.h
+++ b/lldb/include/lldb/ValueObject/DILEval.h
@@ -54,6 +54,21 @@ class Interpreter : Visitor {
   Visit(const ArraySubscriptNode *node) override;
   llvm::Expected
   Visit(const BitFieldExtractionNode *node) override;
+  llvm::Expected
+  Visit(const ScalarLiteralNode *node) override;
+  llvm::Expected Visit(const BinaryOpNode *node) override;
+
+  lldb::ValueObjectSP
+  ConvertValueObjectToTypeSystem(lldb::ValueObjectSP valobj,
+ lldb::TypeSystemSP type_system);
+
+  llvm::Error PrepareBinaryAddition(lldb::ValueObjectSP &lhs,
+lldb::ValueObjectSP &rhs,
+uint32_t location);
+
+  llvm::Expected
+  EvaluateBinaryAddition(lldb::ValueObjectSP lhs, lldb::ValueObjectSP rhs,
+ uint32_t location);
 
   // Used by the interpreter to create objects, perform casts, etc.
   lldb::TargetSP m_target;
diff --git a/lldb/include/lldb/ValueObject/DILLexer.h 
b/lldb/include/lldb/ValueObject/DILLexer.h
index 9c1ba976802

[Lldb-commits] [lldb] [lldb][Formatter] Consolidate libstdc++ and libc++ unique_ptr formatter tests into generic test (PR #147031)

2025-07-04 Thread Michael Buch via lldb-commits 

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

>From afa00be16641075f71bb7ce15e568ecb3b126719 Mon Sep 17 00:00:00 2001
From: Michael Buch 
Date: Thu, 3 Jul 2025 15:41:44 +0100
Subject: [PATCH 1/3] [lldb][Formatter] Consolidate libstdc++ and libc++
 unique_ptr formatter tests into generic test

The libc++ test was a subset of the tests in libstdc++. This test moves
the libc++ test into `generic` and somne additional test-cases from `libstdc++`
(specifically the recursive unique_ptr case). It turns out the libstdc++
formatter supports dereferencing using the "object" or "obj" names. We
could either drop those from the tests or support the same for libc++. I
took the latter approach but don't have strong opinions on this.

Split out from https://github.com/llvm/llvm-project/pull/146740
---
 .../Plugins/Language/CPlusPlus/LibCxx.cpp |   2 +-
 .../{libcxx => generic}/unique_ptr/Makefile   |   2 -
 .../TestDataFormatterStdUniquePtr.py} |  71 +-
 .../{libcxx => generic}/unique_ptr/main.cpp   |  17 ++-
 .../libstdcpp/unique_ptr/Makefile |   5 -
 .../TestDataFormatterStdUniquePtr.py  | 134 --
 .../TestDataFormatterInvalidStdUniquePtr.py   |   4 -
 .../libstdcpp/unique_ptr/invalid/main.cpp |  11 --
 .../libstdcpp/unique_ptr/main.cpp |  35 -
 9 files changed, 82 insertions(+), 199 deletions(-)
 rename lldb/test/API/functionalities/data-formatter/data-formatter-stl/{libcxx 
=> generic}/unique_ptr/Makefile (92%)
 rename 
lldb/test/API/functionalities/data-formatter/data-formatter-stl/{libcxx/unique_ptr/TestDataFormatterLibcxxUniquePtr.py
 => generic/unique_ptr/TestDataFormatterStdUniquePtr.py} (64%)
 rename lldb/test/API/functionalities/data-formatter/data-formatter-stl/{libcxx 
=> generic}/unique_ptr/main.cpp (74%)
 delete mode 100644 
lldb/test/API/functionalities/data-formatter/data-formatter-stl/libstdcpp/unique_ptr/Makefile
 delete mode 100644 
lldb/test/API/functionalities/data-formatter/data-formatter-stl/libstdcpp/unique_ptr/TestDataFormatterStdUniquePtr.py
 delete mode 100644 
lldb/test/API/functionalities/data-formatter/data-formatter-stl/libstdcpp/unique_ptr/invalid/TestDataFormatterInvalidStdUniquePtr.py
 delete mode 100644 
lldb/test/API/functionalities/data-formatter/data-formatter-stl/libstdcpp/unique_ptr/invalid/main.cpp
 delete mode 100644 
lldb/test/API/functionalities/data-formatter/data-formatter-stl/libstdcpp/unique_ptr/main.cpp

diff --git a/lldb/source/Plugins/Language/CPlusPlus/LibCxx.cpp 
b/lldb/source/Plugins/Language/CPlusPlus/LibCxx.cpp
index 009586f525282..51e43b2f62a1e 100644
--- a/lldb/source/Plugins/Language/CPlusPlus/LibCxx.cpp
+++ b/lldb/source/Plugins/Language/CPlusPlus/LibCxx.cpp
@@ -399,7 +399,7 @@ lldb_private::formatters::LibcxxUniquePtrSyntheticFrontEnd::
 return 0;
   if (name == "deleter")
 return 1;
-  if (name == "$$dereference$$")
+  if (name == "obj" || name == "object" || name == "$$dereference$$")
 return 2;
   return llvm::createStringError("Type has no child named '%s'",
  name.AsCString());
diff --git 
a/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/unique_ptr/Makefile
 
b/lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/unique_ptr/Makefile
similarity index 92%
rename from 
lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/unique_ptr/Makefile
rename to 
lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/unique_ptr/Makefile
index c1c8b4a2a0a53..ece665a0fd5b7 100644
--- 
a/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/unique_ptr/Makefile
+++ 
b/lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/unique_ptr/Makefile
@@ -1,7 +1,5 @@
 CXX_SOURCES := main.cpp
 
-USE_LIBCPP := 1
-
 # We need debug info tuning for lldb in order to emit the preferred name for
 # std::string. See https://reviews.llvm.org/D145803.
 CXXFLAGS_EXTRAS := -std=c++14 -glldb
diff --git 
a/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/unique_ptr/TestDataFormatterLibcxxUniquePtr.py
 
b/lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/unique_ptr/TestDataFormatterStdUniquePtr.py
similarity index 64%
rename from 
lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/unique_ptr/TestDataFormatterLibcxxUniquePtr.py
rename to 
lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/unique_ptr/TestDataFormatterStdUniquePtr.py
index 25a1cd82a4baa..57e1ea9f234f8 100644
--- 
a/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/unique_ptr/TestDataFormatterLibcxxUniquePtr.py
+++ 
b/lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/unique_ptr/TestDataFormatterStdUniquePtr.py
@@ -1,8 +1,7 @@
 """
-Test lldb data formatter for libc++ std::unique_ptr.
+Test lldb data formatter for std::unique_ptr.
 """
 
-
 i

[Lldb-commits] [lldb] [lldb][Formatter] Consolidate libstdc++ and libc++ unique_ptr formatter tests into generic test (PR #147031)

2025-07-04 Thread Michael Buch via lldb-commits 

Michael137 wrote:

> Looks good modulo the failure in the libstdc++ version. The type name comes 
> out different, presumably because libstdc++ doesn't contain the magic to 
> print the template as std::string.
> 
> Testing string name printing is not really relevant for the unique_ptr 
> formatter, so I'd delete the check from there. Testing that 
> `SomeTemplate` prints the right way is useful, but would be 
> better of in the test for preferred name printing (if we don't do that 
> already).

Agreed. Removed the typename checks

One final difference between the formatters was that the libstdc++ formatter 
created a synthetic child for the dereferenced object and calls it `object`. I 
removed that and made it do what libc++ does: just dereference and present that 
ValueObject (instead of cloning and renaming it).

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

[Lldb-commits] [lldb] [lldb][Formatter] Consolidate libstdc++ and libc++ unique_ptr formatter tests into generic test (PR #147031)

2025-07-04 Thread Michael Buch via lldb-commits 


@@ -1,7 +1,5 @@
 CXX_SOURCES := main.cpp
 
-USE_LIBCPP := 1
-
 # We need debug info tuning for lldb in order to emit the preferred name for
 # std::string. See https://reviews.llvm.org/D145803.
 CXXFLAGS_EXTRAS := -std=c++14 -glldb

Michael137 wrote:

We can probably drop these too now since we don't check the typenames.

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

[Lldb-commits] [lldb] [lldb][Formatter] Consolidate libstdc++ and libc++ unique_ptr formatter tests into generic test (PR #147031)

2025-07-04 Thread Michael Buch via lldb-commits 


@@ -1,7 +1,5 @@
 CXX_SOURCES := main.cpp
 
-USE_LIBCPP := 1
-
 # We need debug info tuning for lldb in order to emit the preferred name for
 # std::string. See https://reviews.llvm.org/D145803.
 CXXFLAGS_EXTRAS := -std=c++14 -glldb

Michael137 wrote:

```suggestion
```

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

[Lldb-commits] [lldb] [lldb][Formatter] Consolidate libstdc++ and libc++ unique_ptr formatter tests into generic test (PR #147031)

2025-07-04 Thread Michael Buch via lldb-commits 

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

>From afa00be16641075f71bb7ce15e568ecb3b126719 Mon Sep 17 00:00:00 2001
From: Michael Buch 
Date: Thu, 3 Jul 2025 15:41:44 +0100
Subject: [PATCH 1/4] [lldb][Formatter] Consolidate libstdc++ and libc++
 unique_ptr formatter tests into generic test

The libc++ test was a subset of the tests in libstdc++. This test moves
the libc++ test into `generic` and somne additional test-cases from `libstdc++`
(specifically the recursive unique_ptr case). It turns out the libstdc++
formatter supports dereferencing using the "object" or "obj" names. We
could either drop those from the tests or support the same for libc++. I
took the latter approach but don't have strong opinions on this.

Split out from https://github.com/llvm/llvm-project/pull/146740
---
 .../Plugins/Language/CPlusPlus/LibCxx.cpp |   2 +-
 .../{libcxx => generic}/unique_ptr/Makefile   |   2 -
 .../TestDataFormatterStdUniquePtr.py} |  71 +-
 .../{libcxx => generic}/unique_ptr/main.cpp   |  17 ++-
 .../libstdcpp/unique_ptr/Makefile |   5 -
 .../TestDataFormatterStdUniquePtr.py  | 134 --
 .../TestDataFormatterInvalidStdUniquePtr.py   |   4 -
 .../libstdcpp/unique_ptr/invalid/main.cpp |  11 --
 .../libstdcpp/unique_ptr/main.cpp |  35 -
 9 files changed, 82 insertions(+), 199 deletions(-)
 rename lldb/test/API/functionalities/data-formatter/data-formatter-stl/{libcxx 
=> generic}/unique_ptr/Makefile (92%)
 rename 
lldb/test/API/functionalities/data-formatter/data-formatter-stl/{libcxx/unique_ptr/TestDataFormatterLibcxxUniquePtr.py
 => generic/unique_ptr/TestDataFormatterStdUniquePtr.py} (64%)
 rename lldb/test/API/functionalities/data-formatter/data-formatter-stl/{libcxx 
=> generic}/unique_ptr/main.cpp (74%)
 delete mode 100644 
lldb/test/API/functionalities/data-formatter/data-formatter-stl/libstdcpp/unique_ptr/Makefile
 delete mode 100644 
lldb/test/API/functionalities/data-formatter/data-formatter-stl/libstdcpp/unique_ptr/TestDataFormatterStdUniquePtr.py
 delete mode 100644 
lldb/test/API/functionalities/data-formatter/data-formatter-stl/libstdcpp/unique_ptr/invalid/TestDataFormatterInvalidStdUniquePtr.py
 delete mode 100644 
lldb/test/API/functionalities/data-formatter/data-formatter-stl/libstdcpp/unique_ptr/invalid/main.cpp
 delete mode 100644 
lldb/test/API/functionalities/data-formatter/data-formatter-stl/libstdcpp/unique_ptr/main.cpp

diff --git a/lldb/source/Plugins/Language/CPlusPlus/LibCxx.cpp 
b/lldb/source/Plugins/Language/CPlusPlus/LibCxx.cpp
index 009586f525282..51e43b2f62a1e 100644
--- a/lldb/source/Plugins/Language/CPlusPlus/LibCxx.cpp
+++ b/lldb/source/Plugins/Language/CPlusPlus/LibCxx.cpp
@@ -399,7 +399,7 @@ lldb_private::formatters::LibcxxUniquePtrSyntheticFrontEnd::
 return 0;
   if (name == "deleter")
 return 1;
-  if (name == "$$dereference$$")
+  if (name == "obj" || name == "object" || name == "$$dereference$$")
 return 2;
   return llvm::createStringError("Type has no child named '%s'",
  name.AsCString());
diff --git 
a/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/unique_ptr/Makefile
 
b/lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/unique_ptr/Makefile
similarity index 92%
rename from 
lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/unique_ptr/Makefile
rename to 
lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/unique_ptr/Makefile
index c1c8b4a2a0a53..ece665a0fd5b7 100644
--- 
a/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/unique_ptr/Makefile
+++ 
b/lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/unique_ptr/Makefile
@@ -1,7 +1,5 @@
 CXX_SOURCES := main.cpp
 
-USE_LIBCPP := 1
-
 # We need debug info tuning for lldb in order to emit the preferred name for
 # std::string. See https://reviews.llvm.org/D145803.
 CXXFLAGS_EXTRAS := -std=c++14 -glldb
diff --git 
a/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/unique_ptr/TestDataFormatterLibcxxUniquePtr.py
 
b/lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/unique_ptr/TestDataFormatterStdUniquePtr.py
similarity index 64%
rename from 
lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/unique_ptr/TestDataFormatterLibcxxUniquePtr.py
rename to 
lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/unique_ptr/TestDataFormatterStdUniquePtr.py
index 25a1cd82a4baa..57e1ea9f234f8 100644
--- 
a/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/unique_ptr/TestDataFormatterLibcxxUniquePtr.py
+++ 
b/lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/unique_ptr/TestDataFormatterStdUniquePtr.py
@@ -1,8 +1,7 @@
 """
-Test lldb data formatter for libc++ std::unique_ptr.
+Test lldb data formatter for std::unique_ptr.
 """
 
-
 i

[Lldb-commits] [lldb] [lldb] Fix race condition in Process::WaitForProcessToStop() (PR #144919)

2025-07-04 Thread via lldb-commits 

https://github.com/athierry-oct updated 
https://github.com/llvm/llvm-project/pull/144919

>From 89fb97755c2edc1f6b4858bccdd8285292a67a59 Mon Sep 17 00:00:00 2001
From: Adrien Thierry 
Date: Thu, 3 Jul 2025 10:13:28 -0400
Subject: [PATCH] [lldb] Transfer events from previous listener when hijacking

This patch addresses a race condition that can occur when a script using
the Python API calls SBProcess::Kill() around the same time a breakpoint
is hit.

If a stop event is broadcast before the hijack listener is installed, it
may be delivered to the default listener and missed entirely by the
hijack listener. This causes Process::WaitForProcessToStop() to hang
until it times out, waiting for a public stop event that is never
received.

To fix this, we now transfer all pending events from the original
listener to the hijack listener before hijacking, using a new
Listener::MoveEvents method. We also do the reverse operation when
restoring the original listener to avoid dropping any event.
---
 lldb/include/lldb/Utility/Listener.h|  7 +++
 lldb/source/Utility/Broadcaster.cpp | 27 +
 lldb/source/Utility/Listener.cpp| 28 +
 lldb/unittests/Utility/ListenerTest.cpp | 81 +
 4 files changed, 143 insertions(+)

diff --git a/lldb/include/lldb/Utility/Listener.h 
b/lldb/include/lldb/Utility/Listener.h
index d48816ec0ea4d..e48d210a3a749 100644
--- a/lldb/include/lldb/Utility/Listener.h
+++ b/lldb/include/lldb/Utility/Listener.h
@@ -53,6 +53,13 @@ class Listener : public 
std::enable_shared_from_this {
 
   void AddEvent(lldb::EventSP &event);
 
+  // Transfers all events matching the specified broadcaster and type to the
+  // destination listener. This can be useful when setting up a hijack 
listener,
+  // to ensure that no relevant events are missed.
+  void MoveEvents(lldb::ListenerSP destination,
+  Broadcaster *broadcaster, // nullptr for any broadcaster
+  uint32_t event_type_mask);
+
   void Clear();
 
   const char *GetName() { return m_name.c_str(); }
diff --git a/lldb/source/Utility/Broadcaster.cpp 
b/lldb/source/Utility/Broadcaster.cpp
index c6b2606afe0c8..9d545d46bade4 100644
--- a/lldb/source/Utility/Broadcaster.cpp
+++ b/lldb/source/Utility/Broadcaster.cpp
@@ -335,6 +335,19 @@ bool Broadcaster::BroadcasterImpl::HijackBroadcaster(
   "{0} Broadcaster(\"{1}\")::HijackBroadcaster (listener(\"{2}\")={3})",
   static_cast(this), GetBroadcasterName(),
   listener_sp->m_name.c_str(), static_cast(listener_sp.get()));
+
+  // Move pending events from the previous listener to the
+  // hijack listener. This ensures that no relevant event queued before the
+  // transition is missed by the hijack listener.
+  ListenerSP prev_listener;
+  if (!m_hijacking_listeners.empty())
+prev_listener = m_hijacking_listeners.back();
+  else if (m_primary_listener_sp)
+prev_listener = m_primary_listener_sp;
+  if (prev_listener && listener_sp) {
+prev_listener->MoveEvents(listener_sp, &m_broadcaster, event_mask);
+  }
+
   m_hijacking_listeners.push_back(listener_sp);
   m_hijacking_masks.push_back(event_mask);
   return true;
@@ -367,6 +380,20 @@ void Broadcaster::BroadcasterImpl::RestoreBroadcaster() {
  static_cast(this), GetBroadcasterName(),
  listener_sp->m_name.c_str(),
  static_cast(listener_sp.get()));
+
+// Move any remaining events from the hijack listener back to
+// the previous listener. This ensures that no events are dropped when
+// restoring the original listener.
+ListenerSP prev_listener;
+if (m_hijacking_listeners.size() > 1)
+  prev_listener = m_hijacking_listeners[m_hijacking_listeners.size() - 2];
+else if (m_primary_listener_sp)
+  prev_listener = m_primary_listener_sp;
+if (listener_sp && prev_listener && !m_hijacking_masks.empty()) {
+  listener_sp->MoveEvents(prev_listener, &m_broadcaster,
+  m_hijacking_masks.back());
+}
+
 m_hijacking_listeners.pop_back();
   }
   if (!m_hijacking_masks.empty())
diff --git a/lldb/source/Utility/Listener.cpp b/lldb/source/Utility/Listener.cpp
index d4ce3bf25ec5a..448ecb9fcc3c4 100644
--- a/lldb/source/Utility/Listener.cpp
+++ b/lldb/source/Utility/Listener.cpp
@@ -176,6 +176,34 @@ void Listener::AddEvent(EventSP &event_sp) {
   m_events_condition.notify_all();
 }
 
+void Listener::MoveEvents(
+ListenerSP destination,
+Broadcaster *broadcaster, // nullptr for any broadcaster
+uint32_t event_type_mask) {
+  Log *log = GetLog(LLDBLog::Events);
+
+  std::lock_guard guard(m_events_mutex);
+  auto pos = m_events.begin();
+  while (pos != m_events.end()) {
+EventSP &event_sp = *pos;
+if (event_sp &&
+((broadcaster == nullptr) || event_sp->BroadcasterIs(broadcaster)) &&
+(event_type_mask == 0 || event_type_mask & event_sp->GetType())) {
+  if (log)
+LLDB_LOGF(
+log, "%p Listener('%s')::MoveEvents mo

[Lldb-commits] [lldb] [lldb] Fix race condition in Process::WaitForProcessToStop() (PR #144919)

2025-07-04 Thread via lldb-commits 

athierry-oct wrote:

@jimingham Thanks for the explanation!

@labath I've added some unit tests, let me know if you need something else

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