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

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

https://github.com/labath updated 
https://github.com/llvm/llvm-project/pull/124931

>From 7e4fa296561789ae95980ac0c1468573e80ef0cc Mon Sep 17 00:00:00 2001
From: Pavel Labath 
Date: Wed, 29 Jan 2025 16:15:44 +0100
Subject: [PATCH 1/3] [lldb] Fix Block::GetRangeIndexContainingAddress for
 discontinuous functions

This is a followup to #122440, which changed function-relative
calculations to use the function entry point rather than the lowest
address of the function (but missed this usage). Like in #116777, the
logic is changed to use file addresses instead of section offsets (as
not all parts of the function have to be in the same section).
---
 lldb/source/Symbol/Block.cpp  | 51 +++
 .../Python/sb_function_ranges.s   | 37 +-
 2 files changed, 43 insertions(+), 45 deletions(-)

diff --git a/lldb/source/Symbol/Block.cpp b/lldb/source/Symbol/Block.cpp
index 139fa06d08fca..bddb015333e09 100644
--- a/lldb/source/Symbol/Block.cpp
+++ b/lldb/source/Symbol/Block.cpp
@@ -243,25 +243,15 @@ bool Block::GetRangeContainingAddress(const Address &addr,
   AddressRange &range) {
   Function *function = CalculateSymbolContextFunction();
   if (function) {
-const AddressRange &func_range = function->GetAddressRange();
-if (addr.GetModule() == func_range.GetBaseAddress().GetModule()) {
-  const addr_t file_addr = addr.GetFileAddress();
-  const addr_t func_file_addr =
-  func_range.GetBaseAddress().GetFileAddress();
-  if (file_addr >= func_file_addr &&
-  file_addr < func_file_addr + func_range.GetByteSize()) {
-addr_t offset = file_addr - func_file_addr;
-
-const Range *range_ptr = m_ranges.FindEntryThatContains(offset);
-
-if (range_ptr) {
-  range.GetBaseAddress() =
-  Address(func_file_addr + range_ptr->GetRangeBase(),
-  addr.GetModule()->GetSectionList());
-  range.SetByteSize(range_ptr->GetByteSize());
-  return true;
-}
-  }
+if (uint32_t idx = GetRangeIndexContainingAddress(addr);
+idx != UINT32_MAX) {
+  const Range *range_ptr = m_ranges.GetEntryAtIndex(idx);
+  assert(range_ptr);
+
+  range.GetBaseAddress() = function->GetAddress();
+  range.GetBaseAddress().Slide(range_ptr->GetRangeBase());
+  range.SetByteSize(range_ptr->GetByteSize());
+  return true;
 }
   }
   range.Clear();
@@ -278,19 +268,16 @@ bool Block::GetRangeContainingLoadAddress(lldb::addr_t 
load_addr,
 
 uint32_t Block::GetRangeIndexContainingAddress(const Address &addr) {
   Function *function = CalculateSymbolContextFunction();
-  if (function) {
-const AddressRange &func_range = function->GetAddressRange();
-if (addr.GetSection() == func_range.GetBaseAddress().GetSection()) {
-  const addr_t addr_offset = addr.GetOffset();
-  const addr_t func_offset = func_range.GetBaseAddress().GetOffset();
-  if (addr_offset >= func_offset &&
-  addr_offset < func_offset + func_range.GetByteSize()) {
-addr_t offset = addr_offset - func_offset;
-return m_ranges.FindEntryIndexThatContains(offset);
-  }
-}
-  }
-  return UINT32_MAX;
+  if (!function)
+return UINT32_MAX;
+
+  const Address &func_addr = function->GetAddress();
+  if (addr.GetModule() != func_addr.GetModule())
+return UINT32_MAX;
+
+  const addr_t file_addr = addr.GetFileAddress();
+  const addr_t func_file_addr = func_addr.GetFileAddress();
+  return m_ranges.FindEntryIndexThatContains(file_addr - func_file_addr);
 }
 
 bool Block::GetRangeAtIndex(uint32_t range_idx, AddressRange &range) {
diff --git a/lldb/test/Shell/ScriptInterpreter/Python/sb_function_ranges.s 
b/lldb/test/Shell/ScriptInterpreter/Python/sb_function_ranges.s
index 2e2bc52cd3ff9..4d42c50467da0 100644
--- a/lldb/test/Shell/ScriptInterpreter/Python/sb_function_ranges.s
+++ b/lldb/test/Shell/ScriptInterpreter/Python/sb_function_ranges.s
@@ -6,15 +6,22 @@
 
 # CHECK: Found 1 function(s).
 # CHECK: foo: [input.o[0x0-0xe), input.o[0x14-0x1c)]
-# CHECK-NEXT: input.o[0x0]: cmpl   $0x0, %edi
-# CHECK-NEXT: input.o[0x3]: je 0x14
-# CHECK-NEXT: input.o[0x5]: jmp0x7
-# CHECK-NEXT: input.o[0x7]: callq  0xe
-# CHECK-NEXT: input.o[0xc]: jmp0x1b
+# CHECK-NEXT: input.o[0x0]: callq  0xe
+# CHECK-NEXT: input.o[0x5]: jmp0x1b
+# CHECK-NEXT: input.o[0x7]: cmpl   $0x0, %edi
+# CHECK-NEXT: input.o[0xa]: je 0x14
+# CHECK-NEXT: input.o[0xc]: jmp0x0
 # CHECK-EMPTY:
 # CHECK-NEXT: input.o[0x14]: callq  0x19
 # CHECK-NEXT: input.o[0x19]: jmp0x1b
 # CHECK-NEXT: input.o[0x1b]: retq
+# CHECK-NEXT: offset 0x00 => index 0
+# CHECK-NEXT: offset 0x0c => index 0
+# CHECK-NEXT: offset 0x0e => index 
+# CHECK-NEXT: offset 0x13 => index 
+# CHECK-NEXT: offset 0x14 => index 1
+# CHECK-NEXT: offset 0x1b => index 1
+# CHECK-NEXT: offset 0x1c => index 
 
 
 #--- script.py
@@ -28,6 +35,10 @@ def __lldb_ini

[Lldb-commits] [lldb] 70b994b - [lldb/DWARF] Resolve type unit references in llvm DWARFDIE compatibility wrappers (#126902)

2025-02-13 Thread via lldb-commits

Author: Pavel Labath
Date: 2025-02-13T09:05:19+01:00
New Revision: 70b994bcfaafadd649818d2a7f90f8f5989ec6c1

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

LOG: [lldb/DWARF] Resolve type unit references in llvm DWARFDIE compatibility 
wrappers (#126902)

The llvm versions of these functions do that, so we must to so as well.
Practically this meant that were were unable to correctly un-simplify
the names of some types when using type units, which resulted in type
lookup errors.

Added: 


Modified: 
lldb/source/Plugins/SymbolFile/DWARF/DWARFDIE.cpp
lldb/test/Shell/SymbolFile/DWARF/x86/simplified-template-names.cpp

Removed: 




diff  --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFDIE.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFDIE.cpp
index 1e2564cb22f25..0db230d0a8b56 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFDIE.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFDIE.cpp
@@ -622,12 +622,12 @@ std::optional DWARFDIE::getLanguage() const {
 }
 
 DWARFDIE DWARFDIE::resolveReferencedType(dw_attr_t attr) const {
-  return GetReferencedDIE(attr);
+  return GetReferencedDIE(attr).resolveTypeUnitReference();
 }
 
 DWARFDIE DWARFDIE::resolveReferencedType(DWARFFormValue v) const {
   if (IsValid())
-return v.Reference();
+return v.Reference().resolveTypeUnitReference();
   return {};
 }
 

diff  --git 
a/lldb/test/Shell/SymbolFile/DWARF/x86/simplified-template-names.cpp 
b/lldb/test/Shell/SymbolFile/DWARF/x86/simplified-template-names.cpp
index 328d6d2e16d59..ad5dfb6a6dded 100644
--- a/lldb/test/Shell/SymbolFile/DWARF/x86/simplified-template-names.cpp
+++ b/lldb/test/Shell/SymbolFile/DWARF/x86/simplified-template-names.cpp
@@ -11,12 +11,23 @@
 // Test that we following DW_AT_signature correctly. If not, lldb might 
confuse the types of v1 and v2.
 // RUN: %clangxx --target=x86_64-pc-linux -g -gsimple-template-names 
-fdebug-types-section %s -c -o %t2.o
 // RUN: ld.lld %t2.o -o %t2
-// RUN: %lldb %t2 -o "target variable v1 v2" -o exit | FileCheck %s 
--check-prefix=TYPE
+// RUN: %lldb %t2 -o "target variable v1 v2" \
+// RUN:   -o "type lookup t2" -o "type lookup 
t2" \
+// RUN:   -o exit | FileCheck %s --check-prefix=TYPE
 
 // LOG: unique name: t3 >::t4
 
-// TYPE:  (t2 >) v1 = {}
-// TYPE-NEXT: (t2 >) v2 = {}
+// TYPE-LABEL: target variable v1 v2
+// TYPE:   (t2 >) v1 = {}
+// TYPE:   (t2 >) v2 = {}
+
+// TYPE-LABEL: type lookup t2
+// TYPE:   template<> struct t2 {
+// TYPE-NEXT:  }
+
+// TYPE-LABEL: type lookup t2
+// TYPE:   template<> struct t2 {
+// TYPE-NEXT:  }
 
 struct outer_struct1 {
   template  struct t1 {};
@@ -30,6 +41,9 @@ template  struct t2 {};
 t2> v1;
 t2> v2;
 
+t2 v1_1;
+t2 v1_2;
+
 template  struct t3 {
   struct t4 {};
 };



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


[Lldb-commits] [lldb] [lldb/DWARF] Resolve type unit references in llvm DWARFDIE compatibility wrappers (PR #126902)

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

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


[Lldb-commits] [lldb] [lldb] Don't warn that libobjc was read from memory in corefile (PR #127138)

2025-02-13 Thread Jason Molenda via lldb-commits

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


[Lldb-commits] [lldb] 3c2ba68 - [lldb] Don't warn that libobjc was read from memory in corefile (#127138)

2025-02-13 Thread via lldb-commits

Author: Jason Molenda
Date: 2025-02-13T16:01:29-08:00
New Revision: 3c2ba68915b268fd3b7d39bf62e19199b2cb8995

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

LOG: [lldb] Don't warn that libobjc was read from memory in corefile (#127138)

AppleObjCRuntimeV2 prints a warning when we read libobjc.A.dylib from
memory, as a canary to detect that we are reading system binaries out of
memory (which is slow, and we try hard to avoid). But with a corefile,
reading out of "memory" is fine, and may be the only way we can find the
correct binary.

rdar://144322688

Added: 


Modified: 

lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp

Removed: 




diff  --git 
a/lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp
 
b/lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp
index a57099f3df454..ff17028e6662a 100644
--- 
a/lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp
+++ 
b/lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp
@@ -2666,6 +2666,9 @@ void AppleObjCRuntimeV2::WarnIfNoExpandedSharedCache() {
   if (!object_file->IsInMemory())
 return;
 
+  if (!GetProcess()->IsLiveDebugSession())
+return;
+
   Target &target = GetProcess()->GetTarget();
   Debugger &debugger = target.GetDebugger();
 



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


[Lldb-commits] [lldb] Allow option to ignore module load errors in ScriptedProcess (PR #127153)

2025-02-13 Thread via lldb-commits

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


[Lldb-commits] [lldb] Allow option to ignore module load errors in ScriptedProcess (PR #127153)

2025-02-13 Thread via lldb-commits

https://github.com/rchamala created 
https://github.com/llvm/llvm-project/pull/127153

Current state in scripted process expects [_all the 
modules_](https://github.com/llvm/llvm-project/blob/912b154f3a3f8c3cebf5cc5731fd8b0749762da5/lldb/source/Plugins/Process/scripted/ScriptedProcess.cpp#L498)
 passed into "get_loaded_images" to load successfully else none of them load. 
Even if a module loads fine, [but has already been 
appended](https://github.com/llvm/llvm-project/blob/912b154f3a3f8c3cebf5cc5731fd8b0749762da5/lldb/source/Plugins/Process/scripted/ScriptedProcess.cpp#L495)
 it still fails. This is restrictive and does not help our usecase. 

**Usecase**: We have a parent scripted process using coredump + tombstone. 

1) Scripted process uses child elf-core process to read memory dump

2) Uses tombstones to pass thread names and modules.

We do not know at load time, whether the modules will be successfully 
downloaded. We use [python module 
callbacks](https://github.com/llvm/llvm-project/blob/a57e58dbfaae0e86eb5cafeddf8b598f14b96e36/lldb/source/Target/Platform.cpp#L1593)
 to download a module from symbol server at LLDB load time. If one of the 
symbol is not found from the list specified in tombstone, none of the modules 
load in scripted process.

**Solution**: Pass in a custom boolean option arg for every module from python 
scripted process plugin which will indicate whether to ignore the module load 
error. This will provide the flexibility to user for loading the successfully 
fetched modules into target while ignoring the failed ones

>From a4fdb2d54e76aefb771fe8ad8399494bb5fa8b70 Mon Sep 17 00:00:00 2001
From: rchamala 
Date: Thu, 13 Feb 2025 15:00:37 -0800
Subject: [PATCH] Allow option to ignore module load errors in ScriptedProcess

---
 .../Process/scripted/ScriptedProcess.cpp  | 39 
 .../TestStackCoreScriptedProcess.py   | 15 -
 .../stack_core_scripted_process.py| 60 ++-
 3 files changed, 85 insertions(+), 29 deletions(-)

diff --git a/lldb/source/Plugins/Process/scripted/ScriptedProcess.cpp 
b/lldb/source/Plugins/Process/scripted/ScriptedProcess.cpp
index d2111ce877ce5..79d0bc51bc18c 100644
--- a/lldb/source/Plugins/Process/scripted/ScriptedProcess.cpp
+++ b/lldb/source/Plugins/Process/scripted/ScriptedProcess.cpp
@@ -165,7 +165,7 @@ Status ScriptedProcess::DoLoadCore() {
 Status ScriptedProcess::DoLaunch(Module *exe_module,
  ProcessLaunchInfo &launch_info) {
   LLDB_LOGF(GetLog(LLDBLog::Process), "ScriptedProcess::%s launching process", 
__FUNCTION__);
-  
+
   /* MARK: This doesn't reflect how lldb actually launches a process.
In reality, it attaches to debugserver, then resume the process.
That's not true in all cases.  If debugserver is remote, lldb
@@ -422,9 +422,11 @@ bool ScriptedProcess::GetProcessInfo(ProcessInstanceInfo 
&info) {
 lldb_private::StructuredData::ObjectSP
 ScriptedProcess::GetLoadedDynamicLibrariesInfos() {
   Status error;
-  auto error_with_message = [&error](llvm::StringRef message) {
-return ScriptedInterface::ErrorWithMessage(LLVM_PRETTY_FUNCTION,
- message.data(), error);
+  auto handle_error_with_message = [&error](llvm::StringRef message,
+bool ignore_error) {
+ScriptedInterface::ErrorWithMessage(LLVM_PRETTY_FUNCTION,
+  message.data(), error);
+return ignore_error;
   };
 
   StructuredData::ArraySP loaded_images_sp = GetInterface().GetLoadedImages();
@@ -436,12 +438,13 @@ ScriptedProcess::GetLoadedDynamicLibrariesInfos() {
   ModuleList module_list;
   Target &target = GetTarget();
 
-  auto reload_image = [&target, &module_list, &error_with_message](
+  auto reload_image = [&target, &module_list, &handle_error_with_message](
   StructuredData::Object *obj) -> bool {
 StructuredData::Dictionary *dict = obj->GetAsDictionary();
 
 if (!dict)
-  return error_with_message("Couldn't cast image object into dictionary.");
+  return handle_error_with_message(
+  "Couldn't cast image object into dictionary.", false);
 
 ModuleSpec module_spec;
 llvm::StringRef value;
@@ -449,9 +452,11 @@ ScriptedProcess::GetLoadedDynamicLibrariesInfos() {
 bool has_path = dict->HasKey("path");
 bool has_uuid = dict->HasKey("uuid");
 if (!has_path && !has_uuid)
-  return error_with_message("Dictionary should have key 'path' or 'uuid'");
+  return handle_error_with_message(
+  "Dictionary should have key 'path' or 'uuid'", false);
 if (!dict->HasKey("load_addr"))
-  return error_with_message("Dictionary is missing key 'load_addr'");
+  return handle_error_with_message("Dictionary is missing key 'load_addr'",
+   false);
 
 if (has_path) {
   dict->GetValueForKeyAsString("path", value);

[Lldb-commits] [lldb] Allow option to ignore module load errors in ScriptedProcess (PR #127153)

2025-02-13 Thread via lldb-commits

github-actions[bot] wrote:




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



You can test this locally with the following command:


``bash
darker --check --diff -r 
ff79d83caeeea8457f69406f38801fe8893bbfd8...a4fdb2d54e76aefb771fe8ad8399494bb5fa8b70
 lldb/test/API/functionalities/scripted_process/TestStackCoreScriptedProcess.py 
lldb/test/API/functionalities/scripted_process/stack_core_scripted_process.py
``





View the diff from darker here.


``diff
--- TestStackCoreScriptedProcess.py 2025-02-13 23:00:37.00 +
+++ TestStackCoreScriptedProcess.py 2025-02-14 01:20:21.869706 +
@@ -76,11 +76,13 @@
 )
 self.assertTrue(corefile_process, PROCESS_IS_VALID)
 
 # Create a random lib which does not exist in the corefile.
 random_dylib = self.get_module_with_name(corefile_target, 
"random.dylib")
-self.assertFalse(random_dylib, "Dynamic library random.dylib should 
not be found.")
+self.assertFalse(
+random_dylib, "Dynamic library random.dylib should not be found."
+)
 
 structured_data = lldb.SBStructuredData()
 structured_data.SetFromJSON(
 json.dumps(
 {
@@ -92,13 +94,13 @@
 "path": self.getBuildArtifact("libbaz.dylib"),
 },
 {
 "path": "/random/path/random.dylib",
 "load_addr": 12345678,
-"ignore_module_load_error": True
-}
-]
+"ignore_module_load_error": True,
+},
+],
 }
 )
 )
 launch_info = lldb.SBLaunchInfo(None)
 launch_info.SetProcessPluginName("ScriptedProcess")
--- stack_core_scripted_process.py  2025-02-13 23:00:37.00 +
+++ stack_core_scripted_process.py  2025-02-14 01:20:21.957178 +
@@ -49,35 +49,57 @@
 custom_modules = args.GetValueForKey("custom_modules")
 if custom_modules.GetType() == lldb.eStructuredDataTypeArray:
 for id in range(custom_modules.GetSize()):
 
 custom_module = custom_modules.GetItemAtIndex(id)
-if not custom_module or not custom_module.IsValid() or not 
custom_module.GetType() == lldb.eStructuredDataTypeDictionary:
+if (
+not custom_module
+or not custom_module.IsValid()
+or not custom_module.GetType() == 
lldb.eStructuredDataTypeDictionary
+):
 continue
 
 # Get custom module path from args
 module_path_arg = custom_module.GetValueForKey("path")
 module_path = None
-if not module_path_arg or not module_path_arg.IsValid() or not 
module_path_arg.GetType() == lldb.eStructuredDataTypeString:
+if (
+not module_path_arg
+or not module_path_arg.IsValid()
+or not module_path_arg.GetType() == 
lldb.eStructuredDataTypeString
+):
 return
 
 module_path = module_path_arg.GetStringValue(100)
 module_name = os.path.basename(module_path)
 
 # Get ignore_module_load_error boolean from args
 ignore_module_load_error = False
-ignore_module_load_error_arg = 
custom_module.GetValueForKey("ignore_module_load_error")
-if ignore_module_load_error_arg and 
ignore_module_load_error_arg.IsValid() and 
ignore_module_load_error_arg.GetType() == lldb.eStructuredDataTypeBoolean:
-ignore_module_load_error = 
ignore_module_load_error_arg.GetBooleanValue()
+ignore_module_load_error_arg = custom_module.GetValueForKey(
+"ignore_module_load_error"
+)
+if (
+ignore_module_load_error_arg
+and ignore_module_load_error_arg.IsValid()
+and ignore_module_load_error_arg.GetType()
+== lldb.eStructuredDataTypeBoolean
+):
+ignore_module_load_error = (
+ignore_module_load_error_arg.GetBooleanValue()
+)
 
 if not os.path.exists(module_path) and not 
ignore_module_load_error:
 return
 
 # Get custom module load address from args
 module_load_addr = None
 module_load_addr_arg = 
custom_module.GetValueForKey("load_addr")
-if module_load_addr_arg and module_load_addr_arg.IsValid() and 
module_load_addr_arg.GetType() == lldb.eStructuredDataTypeInteger:
+if (
+module_load_addr_arg
+   

[Lldb-commits] [lldb] [lldb][Mach-O] Read dyld_all_image_infos addr from `main bin spec` LC_NOTE (PR #127156)

2025-02-13 Thread Jason Molenda via lldb-commits

jasonmolenda wrote:

I wanted to add a new `eBinaryType` enum from the ObjectFile to describe what 
address is being returned.  But within ProcessMachCore, there was no need to 
add the distinction between the existing `m_dyld_addr` and the new 
`m_dyld_all_image_infos_addr`, I did it to keep the meaning of the address 
clear at this layer, and to make logging more clear.  But ProcessMachCore 
returns either address to DynamicLoaderMacOSX, and it sniffs for a Mach-O magic 
number in the first 4 bytes to disambiguate between them already.  I could have 
ProcessMachCore put either value in `m_dyld_addr` and everything would still 
work. 

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


[Lldb-commits] [lldb] Allow option to ignore module load errors in ScriptedProcess (PR #127153)

2025-02-13 Thread via lldb-commits

https://github.com/rchamala updated 
https://github.com/llvm/llvm-project/pull/127153

>From a4fdb2d54e76aefb771fe8ad8399494bb5fa8b70 Mon Sep 17 00:00:00 2001
From: rchamala 
Date: Thu, 13 Feb 2025 15:00:37 -0800
Subject: [PATCH 1/3] Allow option to ignore module load errors in
 ScriptedProcess

---
 .../Process/scripted/ScriptedProcess.cpp  | 39 
 .../TestStackCoreScriptedProcess.py   | 15 -
 .../stack_core_scripted_process.py| 60 ++-
 3 files changed, 85 insertions(+), 29 deletions(-)

diff --git a/lldb/source/Plugins/Process/scripted/ScriptedProcess.cpp 
b/lldb/source/Plugins/Process/scripted/ScriptedProcess.cpp
index d2111ce877ce5..79d0bc51bc18c 100644
--- a/lldb/source/Plugins/Process/scripted/ScriptedProcess.cpp
+++ b/lldb/source/Plugins/Process/scripted/ScriptedProcess.cpp
@@ -165,7 +165,7 @@ Status ScriptedProcess::DoLoadCore() {
 Status ScriptedProcess::DoLaunch(Module *exe_module,
  ProcessLaunchInfo &launch_info) {
   LLDB_LOGF(GetLog(LLDBLog::Process), "ScriptedProcess::%s launching process", 
__FUNCTION__);
-  
+
   /* MARK: This doesn't reflect how lldb actually launches a process.
In reality, it attaches to debugserver, then resume the process.
That's not true in all cases.  If debugserver is remote, lldb
@@ -422,9 +422,11 @@ bool ScriptedProcess::GetProcessInfo(ProcessInstanceInfo 
&info) {
 lldb_private::StructuredData::ObjectSP
 ScriptedProcess::GetLoadedDynamicLibrariesInfos() {
   Status error;
-  auto error_with_message = [&error](llvm::StringRef message) {
-return ScriptedInterface::ErrorWithMessage(LLVM_PRETTY_FUNCTION,
- message.data(), error);
+  auto handle_error_with_message = [&error](llvm::StringRef message,
+bool ignore_error) {
+ScriptedInterface::ErrorWithMessage(LLVM_PRETTY_FUNCTION,
+  message.data(), error);
+return ignore_error;
   };
 
   StructuredData::ArraySP loaded_images_sp = GetInterface().GetLoadedImages();
@@ -436,12 +438,13 @@ ScriptedProcess::GetLoadedDynamicLibrariesInfos() {
   ModuleList module_list;
   Target &target = GetTarget();
 
-  auto reload_image = [&target, &module_list, &error_with_message](
+  auto reload_image = [&target, &module_list, &handle_error_with_message](
   StructuredData::Object *obj) -> bool {
 StructuredData::Dictionary *dict = obj->GetAsDictionary();
 
 if (!dict)
-  return error_with_message("Couldn't cast image object into dictionary.");
+  return handle_error_with_message(
+  "Couldn't cast image object into dictionary.", false);
 
 ModuleSpec module_spec;
 llvm::StringRef value;
@@ -449,9 +452,11 @@ ScriptedProcess::GetLoadedDynamicLibrariesInfos() {
 bool has_path = dict->HasKey("path");
 bool has_uuid = dict->HasKey("uuid");
 if (!has_path && !has_uuid)
-  return error_with_message("Dictionary should have key 'path' or 'uuid'");
+  return handle_error_with_message(
+  "Dictionary should have key 'path' or 'uuid'", false);
 if (!dict->HasKey("load_addr"))
-  return error_with_message("Dictionary is missing key 'load_addr'");
+  return handle_error_with_message("Dictionary is missing key 'load_addr'",
+   false);
 
 if (has_path) {
   dict->GetValueForKeyAsString("path", value);
@@ -467,16 +472,21 @@ ScriptedProcess::GetLoadedDynamicLibrariesInfos() {
 ModuleSP module_sp =
 target.GetOrCreateModule(module_spec, true /* notify */);
 
+bool ignore_module_load_error = false;
+dict->GetValueForKeyAsBoolean("ignore_module_load_error",
+  ignore_module_load_error);
 if (!module_sp)
-  return error_with_message("Couldn't create or get module.");
+  return handle_error_with_message("Couldn't create or get module.",
+   ignore_module_load_error);
 
 lldb::addr_t load_addr = LLDB_INVALID_ADDRESS;
 lldb::offset_t slide = LLDB_INVALID_OFFSET;
 dict->GetValueForKeyAsInteger("load_addr", load_addr);
 dict->GetValueForKeyAsInteger("slide", slide);
 if (load_addr == LLDB_INVALID_ADDRESS)
-  return error_with_message(
-  "Couldn't get valid load address or slide offset.");
+  return handle_error_with_message(
+  "Couldn't get valid load address or slide offset.",
+  ignore_module_load_error);
 
 if (slide != LLDB_INVALID_OFFSET)
   load_addr += slide;
@@ -486,13 +496,16 @@ ScriptedProcess::GetLoadedDynamicLibrariesInfos() {
   changed);
 
 if (!changed && !module_sp->GetObjectFile())
-  return error_with_message("Couldn't set the load address for module.");
+  return handle_error_with_message(
+  "Couldn't set the load address for module.",
+

[Lldb-commits] [lldb] Allow option to ignore module load errors in ScriptedProcess (PR #127153)

2025-02-13 Thread via lldb-commits

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: None (rchamala)


Changes

Current state in scripted process expects [_all the 
modules_](https://github.com/llvm/llvm-project/blob/912b154f3a3f8c3cebf5cc5731fd8b0749762da5/lldb/source/Plugins/Process/scripted/ScriptedProcess.cpp#L498)
 passed into "get_loaded_images" to load successfully else none of them load. 
Even if a module loads fine, [but has already been 
appended](https://github.com/llvm/llvm-project/blob/912b154f3a3f8c3cebf5cc5731fd8b0749762da5/lldb/source/Plugins/Process/scripted/ScriptedProcess.cpp#L495)
 it still fails. This is restrictive and does not help our usecase. 

**Usecase**: We have a parent scripted process using coredump + tombstone. 

1) Scripted process uses child elf-core process to read memory dump

2) Uses tombstones to pass thread names and modules.

We do not know whether the modules will be successfully downloaded before 
creating the scripted process. We use [python module 
callbacks](https://github.com/llvm/llvm-project/blob/a57e58dbfaae0e86eb5cafeddf8b598f14b96e36/lldb/source/Target/Platform.cpp#L1593)
 to download a module from symbol server at LLDB load time when the scripted 
process is being created. The issue is that if one of the symbol is not found 
from the list specified in tombstone, none of the modules load in scripted 
process.

**Solution**: Pass in a custom boolean option arg for every module from python 
scripted process plugin which will indicate whether to ignore the module load 
error. This will provide the flexibility to user for loading the successfully 
fetched modules into target while ignoring the failed ones

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


3 Files Affected:

- (modified) lldb/source/Plugins/Process/scripted/ScriptedProcess.cpp (+26-13) 
- (modified) 
lldb/test/API/functionalities/scripted_process/TestStackCoreScriptedProcess.py 
(+16-1) 
- (modified) 
lldb/test/API/functionalities/scripted_process/stack_core_scripted_process.py 
(+75-15) 


``diff
diff --git a/lldb/source/Plugins/Process/scripted/ScriptedProcess.cpp 
b/lldb/source/Plugins/Process/scripted/ScriptedProcess.cpp
index d2111ce877ce5..79d0bc51bc18c 100644
--- a/lldb/source/Plugins/Process/scripted/ScriptedProcess.cpp
+++ b/lldb/source/Plugins/Process/scripted/ScriptedProcess.cpp
@@ -165,7 +165,7 @@ Status ScriptedProcess::DoLoadCore() {
 Status ScriptedProcess::DoLaunch(Module *exe_module,
  ProcessLaunchInfo &launch_info) {
   LLDB_LOGF(GetLog(LLDBLog::Process), "ScriptedProcess::%s launching process", 
__FUNCTION__);
-  
+
   /* MARK: This doesn't reflect how lldb actually launches a process.
In reality, it attaches to debugserver, then resume the process.
That's not true in all cases.  If debugserver is remote, lldb
@@ -422,9 +422,11 @@ bool ScriptedProcess::GetProcessInfo(ProcessInstanceInfo 
&info) {
 lldb_private::StructuredData::ObjectSP
 ScriptedProcess::GetLoadedDynamicLibrariesInfos() {
   Status error;
-  auto error_with_message = [&error](llvm::StringRef message) {
-return ScriptedInterface::ErrorWithMessage(LLVM_PRETTY_FUNCTION,
- message.data(), error);
+  auto handle_error_with_message = [&error](llvm::StringRef message,
+bool ignore_error) {
+ScriptedInterface::ErrorWithMessage(LLVM_PRETTY_FUNCTION,
+  message.data(), error);
+return ignore_error;
   };
 
   StructuredData::ArraySP loaded_images_sp = GetInterface().GetLoadedImages();
@@ -436,12 +438,13 @@ ScriptedProcess::GetLoadedDynamicLibrariesInfos() {
   ModuleList module_list;
   Target &target = GetTarget();
 
-  auto reload_image = [&target, &module_list, &error_with_message](
+  auto reload_image = [&target, &module_list, &handle_error_with_message](
   StructuredData::Object *obj) -> bool {
 StructuredData::Dictionary *dict = obj->GetAsDictionary();
 
 if (!dict)
-  return error_with_message("Couldn't cast image object into dictionary.");
+  return handle_error_with_message(
+  "Couldn't cast image object into dictionary.", false);
 
 ModuleSpec module_spec;
 llvm::StringRef value;
@@ -449,9 +452,11 @@ ScriptedProcess::GetLoadedDynamicLibrariesInfos() {
 bool has_path = dict->HasKey("path");
 bool has_uuid = dict->HasKey("uuid");
 if (!has_path && !has_uuid)
-  return error_with_message("Dictionary should have key 'path' or 'uuid'");
+  return handle_error_with_message(
+  "Dictionary should have key 'path' or 'uuid'", false);
 if (!dict->HasKey("load_addr"))
-  return error_with_message("Dictionary is missing key 'load_addr'");
+  return handle_error_with_message("Dictionary is missing key 'load_addr'",
+   false);
 
 if (has_path) {
   dict->GetValueForKeyAsString("

[Lldb-commits] [lldb] Allow option to ignore module load errors in ScriptedProcess (PR #127153)

2025-02-13 Thread via lldb-commits

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


[Lldb-commits] [lldb] [lldb-dap] Add: show return value on step out (PR #106907)

2025-02-13 Thread via lldb-commits

https://github.com/Da-Viper updated 
https://github.com/llvm/llvm-project/pull/106907

>From aeb8854bbe7695e576257c8403e04d4b8268b679 Mon Sep 17 00:00:00 2001
From: Ezike Ebuka 
Date: Sun, 1 Sep 2024 13:48:41 +0100
Subject: [PATCH 1/9] Add: show return value on step out

---
 lldb/tools/lldb-dap/lldb-dap.cpp | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/lldb/tools/lldb-dap/lldb-dap.cpp b/lldb/tools/lldb-dap/lldb-dap.cpp
index e323990d8b6ed..3cacc16dedb25 100644
--- a/lldb/tools/lldb-dap/lldb-dap.cpp
+++ b/lldb/tools/lldb-dap/lldb-dap.cpp
@@ -4225,6 +4225,17 @@ void request_variables(DAP &dap, const 
llvm::json::Object &request) {
   variable_name_counts[GetNonNullVariableName(variable)]++;
 }
 
+// Show return value if there is any ( in the top frame )
+auto process = g_dap.target.GetProcess();
+auto selectedThread = process.GetSelectedThread();
+lldb::SBValue stopReturnValue = selectedThread.GetStopReturnValue();
+if (stopReturnValue.IsValid() &&
+(selectedThread.GetSelectedFrame().GetFrameID() == 0)) {
+  auto renamedReturnValue = stopReturnValue.Clone("(Return Value)");
+  variables.emplace_back(
+  CreateVariable(renamedReturnValue,0, UINT64_MAX, hex, false));
+}
+
 // Now we construct the result with unique display variable names
 for (auto i = start_idx; i < end_idx; ++i) {
   lldb::SBValue variable = top_scope->GetValueAtIndex(i);

>From 07c3c56bc987cdd947b8de126be6497f45f1da7b Mon Sep 17 00:00:00 2001
From: Ezike Ebuka 
Date: Sun, 1 Sep 2024 14:10:54 +0100
Subject: [PATCH 2/9] format file

---
 lldb/tools/lldb-dap/lldb-dap.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lldb/tools/lldb-dap/lldb-dap.cpp b/lldb/tools/lldb-dap/lldb-dap.cpp
index 3cacc16dedb25..30b3354c184b0 100644
--- a/lldb/tools/lldb-dap/lldb-dap.cpp
+++ b/lldb/tools/lldb-dap/lldb-dap.cpp
@@ -4233,7 +4233,7 @@ void request_variables(DAP &dap, const llvm::json::Object 
&request) {
 (selectedThread.GetSelectedFrame().GetFrameID() == 0)) {
   auto renamedReturnValue = stopReturnValue.Clone("(Return Value)");
   variables.emplace_back(
-  CreateVariable(renamedReturnValue,0, UINT64_MAX, hex, false));
+  CreateVariable(renamedReturnValue, 0, UINT64_MAX, hex, false));
 }
 
 // Now we construct the result with unique display variable names

>From c9ef0294def8919536ade9f8097c3471b94b0355 Mon Sep 17 00:00:00 2001
From: Ezike Ebuka 
Date: Sun, 15 Sep 2024 22:22:09 +0100
Subject: [PATCH 3/9] [lldb-dap] Add: Show children for return values

---
 lldb/tools/lldb-dap/lldb-dap.cpp | 20 +---
 1 file changed, 13 insertions(+), 7 deletions(-)

diff --git a/lldb/tools/lldb-dap/lldb-dap.cpp b/lldb/tools/lldb-dap/lldb-dap.cpp
index 30b3354c184b0..00584f31848cf 100644
--- a/lldb/tools/lldb-dap/lldb-dap.cpp
+++ b/lldb/tools/lldb-dap/lldb-dap.cpp
@@ -4227,13 +4227,19 @@ void request_variables(DAP &dap, const 
llvm::json::Object &request) {
 
 // Show return value if there is any ( in the top frame )
 auto process = g_dap.target.GetProcess();
-auto selectedThread = process.GetSelectedThread();
-lldb::SBValue stopReturnValue = selectedThread.GetStopReturnValue();
-if (stopReturnValue.IsValid() &&
-(selectedThread.GetSelectedFrame().GetFrameID() == 0)) {
-  auto renamedReturnValue = stopReturnValue.Clone("(Return Value)");
-  variables.emplace_back(
-  CreateVariable(renamedReturnValue, 0, UINT64_MAX, hex, false));
+auto selected_thread = process.GetSelectedThread();
+lldb::SBValue stop_return_value = selected_thread.GetStopReturnValue();
+if (stop_return_value.IsValid() &&
+(selected_thread.GetSelectedFrame().GetFrameID() == 0)) {
+  auto renamed_return_value = stop_return_value.Clone("(Return Value)");
+  int64_t return_ref = 0;
+  if (stop_return_value.MightHaveChildren() ||
+  stop_return_value.IsSynthetic()) {
+return_ref = g_dap.variables.InsertExpandableVariable(
+stop_return_value, /*is_permanent=*/false);
+  }
+  variables.emplace_back(CreateVariable(renamed_return_value, return_ref,
+UINT64_MAX, hex, false));
 }
 
 // Now we construct the result with unique display variable names

>From 91e7042f9c3438b13ff8b476d07057da52b2589f Mon Sep 17 00:00:00 2001
From: Ezike Ebuka 
Date: Wed, 12 Feb 2025 00:16:46 +
Subject: [PATCH 4/9] [lldb-dap] Add Tests: Show children for return values

---
 .../lldb-dap/variables/TestDAP_variables.py   | 57 +++
 .../children/TestDAP_variables_children.py| 55 ++
 .../lldb-dap/variables/children/main.cpp  | 12 
 .../API/tools/lldb-dap/variables/main.cpp |  9 +++
 4 files changed, 122 insertions(+), 11 deletions(-)

diff --git a/lldb/test/API/tools/lldb-dap/variables/TestDAP_variables.py 
b/lldb/test/API/tools/lldb-dap/variables/TestDAP_variables.py

[Lldb-commits] [lldb] [lldb][Mach-O] Read dyld_all_image_infos addr from `main bin spec` LC_NOTE (PR #127156)

2025-02-13 Thread Jason Molenda via lldb-commits

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

Mach-O corefiles have LC_NOTE metadata, one LC_NOTE that lldb recognizes is 
`main bin spec` which can specify that this is a kernel corefile, userland 
corefile, or firmware/standalone corefile. With a userland corefile, the 
LC_NOTE would specify the virtual address of the dyld binary's Mach-O header.  
lldb would create a Module from that in-memory binary, find the 
`dyld_all_image_infos` object in dyld's DATA segment, and use that object to 
find all of the binaries present in the corefile.

ProcessMachCore takes the metadata from this LC_NOTE and passes the address to 
the DynamicLoader plugin via its `GetImageInfoAddress()` method, so the 
DynamicLoader can find all of the binaries and load them in the Target at their 
correct virtual addresses.

We have a corefile creator who would prefer to specify the address of 
`dyld_all_image_infos` directly, instead of specifying the address of dyld and 
parsing that to find the object.  DynamicLoaderMacOSX, the DynamicLoader plugin 
being used here, will accept either a dyld virtual address or a 
`dyld_all_image_infos` virtual address from ProcessMachCore, and do the correct 
thing with either value.

lldb's process save-core mach-o corefile reader will continue to specify the 
virtual address of the dyld binary.

rdar://144322688

>From 0a6558940403814ffa2bf6c265bc0e9267eef855 Mon Sep 17 00:00:00 2001
From: Jason Molenda 
Date: Thu, 13 Feb 2025 18:20:28 -0800
Subject: [PATCH] [lldb][Mach-O] Read dyld_all_image_infos addr from `main bin
 spec` LC_NOTE

Mach-O corefiles have LC_NOTE metadata, one LC_NOTE that lldb
recognizes is `main bin spec` which can specify that this is a
kernel corefile, userland corefile, or firmware/standalone corefile.
With a userland corefile, the LC_NOTE would specify the virtual
address of the dyld binary's Mach-O header.  lldb would create a
Module from that in-memory binary, find the `dyld_all_image_infos`
object in dyld's DATA segment, and use that object to find all of
the binaries present in the corefile.

ProcessMachCore takes the metadata from this LC_NOTE and passes the
address to the DynamicLoader plugin via its `GetImageInfoAddress()`
method, so the DynamicLoader can find all of the binaries and load
them in the Target at their correct virtual addresses.

We have a corefile creator who would prefer to specify the address
of `dyld_all_image_infos` directly, instead of specifying the address
of dyld and parsing that to find the object.  DynamicLoaderMacOSX,
the DynamicLoader plugin being used here, will accept either a
dyld virtual address or a `dyld_all_image_infos` virtual address
from ProcessMachCore, and do the correct thing with either value.

lldb's process save-core mach-o corefile reader will continue to
specify the virtual address of the dyld binary.

rdar://144322688
---
 lldb/include/lldb/Symbol/ObjectFile.h |  9 ++--
 .../ObjectFile/Mach-O/ObjectFileMachO.cpp | 10 -
 .../Process/mach-core/ProcessMachCore.cpp | 45 +++
 .../Process/mach-core/ProcessMachCore.h   |  1 +
 4 files changed, 53 insertions(+), 12 deletions(-)

diff --git a/lldb/include/lldb/Symbol/ObjectFile.h 
b/lldb/include/lldb/Symbol/ObjectFile.h
index d89314d44bf67..8873209eeece6 100644
--- a/lldb/include/lldb/Symbol/ObjectFile.h
+++ b/lldb/include/lldb/Symbol/ObjectFile.h
@@ -81,9 +81,12 @@ class ObjectFile : public 
std::enable_shared_from_this,
   enum BinaryType {
 eBinaryTypeInvalid = 0,
 eBinaryTypeUnknown,
-eBinaryTypeKernel,/// kernel binary
-eBinaryTypeUser,  /// user process binary
-eBinaryTypeStandalone /// standalone binary / firmware
+eBinaryTypeKernel,/// kernel binary
+eBinaryTypeUser,  /// user process binary,
+  /// dyld addr
+eBinaryTypeUserAllImageInfos, /// user process binary,
+  /// dyld_all_image_infos addr
+eBinaryTypeStandalone /// standalone binary / firmware
   };
 
   struct LoadableData {
diff --git a/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp 
b/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
index 4e356a7c8f5d9..8cf6ed268f3b8 100644
--- a/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
+++ b/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
@@ -5599,9 +5599,13 @@ bool ObjectFileMachO::GetCorefileMainBinaryInfo(addr_t 
&value,
   // struct main_bin_spec
   // {
   // uint32_t version;   // currently 2
-  // uint32_t type;  // 0 == unspecified, 1 == kernel,
+  // uint32_t type;  // 0 == unspecified,
+  // // 1 == kernel
   // // 2 == user process,
+  // dyld mach-o binary addr
   // // 3 == standalone binary
+  //   

[Lldb-commits] [lldb] [lldb][Mach-O] Read dyld_all_image_infos addr from `main bin spec` LC_NOTE (PR #127156)

2025-02-13 Thread via lldb-commits

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Jason Molenda (jasonmolenda)


Changes

Mach-O corefiles have LC_NOTE metadata, one LC_NOTE that lldb recognizes is 
`main bin spec` which can specify that this is a kernel corefile, userland 
corefile, or firmware/standalone corefile. With a userland corefile, the 
LC_NOTE would specify the virtual address of the dyld binary's Mach-O header.  
lldb would create a Module from that in-memory binary, find the 
`dyld_all_image_infos` object in dyld's DATA segment, and use that object to 
find all of the binaries present in the corefile.

ProcessMachCore takes the metadata from this LC_NOTE and passes the address to 
the DynamicLoader plugin via its `GetImageInfoAddress()` method, so the 
DynamicLoader can find all of the binaries and load them in the Target at their 
correct virtual addresses.

We have a corefile creator who would prefer to specify the address of 
`dyld_all_image_infos` directly, instead of specifying the address of dyld and 
parsing that to find the object.  DynamicLoaderMacOSX, the DynamicLoader plugin 
being used here, will accept either a dyld virtual address or a 
`dyld_all_image_infos` virtual address from ProcessMachCore, and do the correct 
thing with either value.

lldb's process save-core mach-o corefile reader will continue to specify the 
virtual address of the dyld binary.

rdar://144322688

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


4 Files Affected:

- (modified) lldb/include/lldb/Symbol/ObjectFile.h (+6-3) 
- (modified) lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp (+9-1) 
- (modified) lldb/source/Plugins/Process/mach-core/ProcessMachCore.cpp (+37-8) 
- (modified) lldb/source/Plugins/Process/mach-core/ProcessMachCore.h (+1) 


``diff
diff --git a/lldb/include/lldb/Symbol/ObjectFile.h 
b/lldb/include/lldb/Symbol/ObjectFile.h
index d89314d44bf67..8873209eeece6 100644
--- a/lldb/include/lldb/Symbol/ObjectFile.h
+++ b/lldb/include/lldb/Symbol/ObjectFile.h
@@ -81,9 +81,12 @@ class ObjectFile : public 
std::enable_shared_from_this,
   enum BinaryType {
 eBinaryTypeInvalid = 0,
 eBinaryTypeUnknown,
-eBinaryTypeKernel,/// kernel binary
-eBinaryTypeUser,  /// user process binary
-eBinaryTypeStandalone /// standalone binary / firmware
+eBinaryTypeKernel,/// kernel binary
+eBinaryTypeUser,  /// user process binary,
+  /// dyld addr
+eBinaryTypeUserAllImageInfos, /// user process binary,
+  /// dyld_all_image_infos addr
+eBinaryTypeStandalone /// standalone binary / firmware
   };
 
   struct LoadableData {
diff --git a/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp 
b/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
index 4e356a7c8f5d9..8cf6ed268f3b8 100644
--- a/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
+++ b/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
@@ -5599,9 +5599,13 @@ bool ObjectFileMachO::GetCorefileMainBinaryInfo(addr_t 
&value,
   // struct main_bin_spec
   // {
   // uint32_t version;   // currently 2
-  // uint32_t type;  // 0 == unspecified, 1 == kernel,
+  // uint32_t type;  // 0 == unspecified,
+  // // 1 == kernel
   // // 2 == user process,
+  // dyld mach-o binary addr
   // // 3 == standalone binary
+  // // 4 == user process,
+  // //  dyld_all_image_infos addr
   // uint64_t address;   // UINT64_MAX if address not specified
   // uint64_t slide; // slide, UINT64_MAX if unspecified
   // // 0 if no slide needs to be applied to
@@ -5669,6 +5673,10 @@ bool ObjectFileMachO::GetCorefileMainBinaryInfo(addr_t 
&value,
 type = eBinaryTypeStandalone;
 typestr = "standalone";
 break;
+  case 4:
+type = eBinaryTypeUserAllImageInfos;
+typestr = "userland dyld_all_image_infos";
+break;
   }
   LLDB_LOGF(log,
 "LC_NOTE 'main bin spec' found, version %d type %d "
diff --git a/lldb/source/Plugins/Process/mach-core/ProcessMachCore.cpp 
b/lldb/source/Plugins/Process/mach-core/ProcessMachCore.cpp
index eef9bd4a175ec..281f3a0db8f69 100644
--- a/lldb/source/Plugins/Process/mach-core/ProcessMachCore.cpp
+++ b/lldb/source/Plugins/Process/mach-core/ProcessMachCore.cpp
@@ -114,6 +114,7 @@ ProcessMachCore::ProcessMachCore(lldb::TargetSP target_sp,
 : PostMortemProcess(target_sp, listener_sp, core_file), m_core_aranges(),
   m_core_range_infos(), m_core_module_sp(),
   m_dyld_addr(LLDB_INVALID_ADDRESS),
+  m_dyld_all_image_infos_addr(LLDB_INVALID_ADDRESS),
   m_

[Lldb-commits] [lldb] [lldb] Fix broken pipe error (PR #127100)

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

labath wrote:

I agree with Jonas and Michał. I think we should take a step back. Can you 
explain where exactly does this BrokenPipeError come from (an exception 
backtrace for example)?

The code here assumes that we get a "connection refused" error if the port 
wasn't open. Maybe we need to catch "broken pipe" as well (but first I want to 
understand how does it get triggered).

And if that isn't enough, we can increase the sleep time or change it into an 
exponential backoff thingy.

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


[Lldb-commits] [lldb] 2818df3 - [lldb] Remove UtilityTests->Target dep (#127060)

2025-02-13 Thread via lldb-commits

Author: Pavel Labath
Date: 2025-02-14T08:40:45+01:00
New Revision: 2818df38c133cf7278b0174d01fe99c9c558fa2c

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

LOG: [lldb] Remove UtilityTests->Target dep (#127060)

It's completely unnecessary right now, but having it present means that
some real unwanted dependencies could sneak in. (This also makes
building the test binary much faster.)

Added: 


Modified: 
lldb/unittests/Utility/CMakeLists.txt
lldb/unittests/Utility/ProcessInstanceInfoTest.cpp

Removed: 




diff  --git a/lldb/unittests/Utility/CMakeLists.txt 
b/lldb/unittests/Utility/CMakeLists.txt
index 3a73bdc3e9e1a..8d4e2ea35f267 100644
--- a/lldb/unittests/Utility/CMakeLists.txt
+++ b/lldb/unittests/Utility/CMakeLists.txt
@@ -52,7 +52,6 @@ add_lldb_unittest(UtilityTests
   XcodeSDKTest.cpp
 
   LINK_LIBS
-  lldbTarget
   lldbUtility
   lldbUtilityHelpers
   LLVMTestingSupport

diff  --git a/lldb/unittests/Utility/ProcessInstanceInfoTest.cpp 
b/lldb/unittests/Utility/ProcessInstanceInfoTest.cpp
index 3ba35d4efacc1..b653df5fe01a1 100644
--- a/lldb/unittests/Utility/ProcessInstanceInfoTest.cpp
+++ b/lldb/unittests/Utility/ProcessInstanceInfoTest.cpp
@@ -6,7 +6,11 @@
 //
 
//===--===//
 
-#include "lldb/Target/Process.h"
+#include "lldb/Utility/ArchSpec.h"
+#include "lldb/Utility/ProcessInfo.h"
+#include "lldb/Utility/StreamString.h"
+#include "lldb/Utility/UserIDResolver.h"
+#include "llvm/ADT/Twine.h"
 #include "gtest/gtest.h"
 #include 
 



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


[Lldb-commits] [lldb] [lldb] Remove UtilityTests->Target dep (PR #127060)

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

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


[Lldb-commits] [lldb] [lldb-dap] Add: show return value on step out (PR #106907)

2025-02-13 Thread via lldb-commits


@@ -3801,6 +3801,23 @@ void request_variables(const llvm::json::Object 
&request) {
   variable_name_counts[GetNonNullVariableName(variable)]++;
 }
 
+// Show return value if there is any ( in the top frame )

Da-Viper wrote:

I am not sure where the ReleaseNotes.rst for LLDB is as clang et al stores it 
in `clang/docs/ReleaseNotes.rst` 

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


[Lldb-commits] [lldb] [lldb-dap] Add: show return value on step out (PR #106907)

2025-02-13 Thread via lldb-commits

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


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

2025-02-13 Thread via lldb-commits

https://github.com/kper updated https://github.com/llvm/llvm-project/pull/124475

>From 7d97df1b70d6d648992f9af2f4211768d3a14aa5 Mon Sep 17 00:00:00 2001
From: Kevin Per 
Date: Sun, 26 Jan 2025 17:34:17 +
Subject: [PATCH] lldb: Extended if conditions to support alias names for
 registers

---
 .../Plugins/ABI/RISCV/ABISysV_riscv.cpp   |  54 ++
 .../TestGDBServerTargetXML.py | 147 
 .../basic_eh_frame-riscv64.yaml   |  20 +++
 .../postmortem/elf-core/TestLinuxCore.py  | 158 ++
 .../Shell/Register/Inputs/riscv64-gp-read.cpp |  36 
 lldb/test/Shell/Register/riscv64-gp-read.test |  37 
 llvm/utils/lit/lit/llvm/config.py |   9 +-
 7 files changed, 387 insertions(+), 74 deletions(-)
 create mode 100644 
lldb/test/API/functionalities/gdb_remote_client/basic_eh_frame-riscv64.yaml
 create mode 100644 lldb/test/Shell/Register/Inputs/riscv64-gp-read.cpp
 create mode 100644 lldb/test/Shell/Register/riscv64-gp-read.test

diff --git a/lldb/source/Plugins/ABI/RISCV/ABISysV_riscv.cpp 
b/lldb/source/Plugins/ABI/RISCV/ABISysV_riscv.cpp
index 8412991933d27..c463bd006b3db 100644
--- a/lldb/source/Plugins/ABI/RISCV/ABISysV_riscv.cpp
+++ b/lldb/source/Plugins/ABI/RISCV/ABISysV_riscv.cpp
@@ -850,8 +850,62 @@ void ABISysV_riscv::AugmentRegisterInfo(
   it.value().alt_name.SetCString("x3");
 else if (it.value().name == "fp")
   it.value().alt_name.SetCString("s0");
+else if (it.value().name == "tp")
+  it.value().alt_name.SetCString("x4");
 else if (it.value().name == "s0")
   it.value().alt_name.SetCString("x8");
+else if (it.value().name == "s1")
+  it.value().alt_name.SetCString("x9");
+else if (it.value().name == "t0")
+  it.value().alt_name.SetCString("x5");
+else if (it.value().name == "t1")
+  it.value().alt_name.SetCString("x6");
+else if (it.value().name == "t2")
+  it.value().alt_name.SetCString("x7");
+else if (it.value().name == "a0")
+  it.value().alt_name.SetCString("x10");
+else if (it.value().name == "a1")
+  it.value().alt_name.SetCString("x11");
+else if (it.value().name == "a2")
+  it.value().alt_name.SetCString("x12");
+else if (it.value().name == "a3")
+  it.value().alt_name.SetCString("x13");
+else if (it.value().name == "a4")
+  it.value().alt_name.SetCString("x14");
+else if (it.value().name == "a5")
+  it.value().alt_name.SetCString("x15");
+else if (it.value().name == "a6")
+  it.value().alt_name.SetCString("x16");
+else if (it.value().name == "a7")
+  it.value().alt_name.SetCString("x17");
+else if (it.value().name == "s2")
+  it.value().alt_name.SetCString("x18");
+else if (it.value().name == "s3")
+  it.value().alt_name.SetCString("x19");
+else if (it.value().name == "s4")
+  it.value().alt_name.SetCString("x20");
+else if (it.value().name == "s5")
+  it.value().alt_name.SetCString("x21");
+else if (it.value().name == "s6")
+  it.value().alt_name.SetCString("x22");
+else if (it.value().name == "s7")
+  it.value().alt_name.SetCString("x23");
+else if (it.value().name == "s8")
+  it.value().alt_name.SetCString("x24");
+else if (it.value().name == "s9")
+  it.value().alt_name.SetCString("x25");
+else if (it.value().name == "s10")
+  it.value().alt_name.SetCString("x26");
+else if (it.value().name == "s11")
+  it.value().alt_name.SetCString("x27");
+else if (it.value().name == "t3")
+  it.value().alt_name.SetCString("x28");
+else if (it.value().name == "t4")
+  it.value().alt_name.SetCString("x29");
+else if (it.value().name == "t5")
+  it.value().alt_name.SetCString("x30");
+else if (it.value().name == "t6")
+  it.value().alt_name.SetCString("x31");
 
 // Set generic regnum so lldb knows what the PC, etc is
 it.value().regnum_generic = GetGenericNum(it.value().name.GetStringRef());
diff --git 
a/lldb/test/API/functionalities/gdb_remote_client/TestGDBServerTargetXML.py 
b/lldb/test/API/functionalities/gdb_remote_client/TestGDBServerTargetXML.py
index 22f5553e40802..cf82f7f168c20 100644
--- a/lldb/test/API/functionalities/gdb_remote_client/TestGDBServerTargetXML.py
+++ b/lldb/test/API/functionalities/gdb_remote_client/TestGDBServerTargetXML.py
@@ -652,6 +652,153 @@ def haltReason(self):
 )
 self.match("register read s31", ["s31 = 128"])
 
+@skipIfXmlSupportMissing
+@skipIfRemote
+@skipIfLLVMTargetMissing("RISCV")
+def test_riscv64_regs(self):
+"""Test grabbing various riscv64 registers from gdbserver."""
+
+class MyResponder(MockGDBServerResponder):
+reg_data = (
+"0102030405060708"  # zero
+"0102030405060708"  # ra
+"0102030405060708"  # sp
+"0102030405060708"  # gp
+"0102030405060708"  # tp
+"0102030405060708"  # t0
+

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

2025-02-13 Thread via lldb-commits

kper wrote:

@DavidSpickett unfortunately, I did not manage to test it with the test suite. 
Both `ninja check-lldb-shell` and `ninja check-llvm` do not list my risc-v test 
as supported and run it.
I manually compiled and tested it with lldb remotely and it works.

However, why the pipeline is now failing for Bolt and lld is a mystery to me. I 
have updated the branch and maybe the flaky tests go away. 

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


[Lldb-commits] [lldb] [lldb] Synchronize the debugger's stdout and stderr streams (PR #126630)

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

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


[Lldb-commits] [lldb] Define Telemetry plugin for LLDB. (PR #126588)

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

https://github.com/labath commented:

I like this. Now it's so simple that a test might not have even been necessary, 
but since you've already started it, let's keep it, and we can later extend it 
to test sending of telemetry events.

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


[Lldb-commits] [lldb] Define Telemetry plugin for LLDB. (PR #126588)

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


@@ -59,11 +60,21 @@ struct LLDBBaseTelemetryInfo : public 
llvm::telemetry::TelemetryInfo {
 /// The base Telemetry manager instance in LLDB
 /// This class declares additional instrumentation points
 /// applicable to LLDB.
-class TelemetryManager : public llvm::telemetry::Manager {
+class TelemetryManager : public llvm::telemetry::Manager,
+ public PluginInterface {
 public:
+  llvm::Error preDispatch(llvm::telemetry::TelemetryInfo *entry) override;
+
+  // Plugin interface
+  llvm::StringRef GetPluginName() override { return "TelemetryManager"; }

labath wrote:

Can we delete this (due to not needing to instantiate the base class)?

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


[Lldb-commits] [lldb] Define Telemetry plugin for LLDB. (PR #126588)

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


@@ -59,11 +60,21 @@ struct LLDBBaseTelemetryInfo : public 
llvm::telemetry::TelemetryInfo {
 /// The base Telemetry manager instance in LLDB
 /// This class declares additional instrumentation points
 /// applicable to LLDB.
-class TelemetryManager : public llvm::telemetry::Manager {
+class TelemetryManager : public llvm::telemetry::Manager,
+ public PluginInterface {
 public:
+  llvm::Error preDispatch(llvm::telemetry::TelemetryInfo *entry) override;
+
+  // Plugin interface
+  llvm::StringRef GetPluginName() override { return "TelemetryManager"; }
+
+  static TelemetryManager *getInstance();
+
+protected:
   TelemetryManager(std::unique_ptr config);
 
-  llvm::Error preDispatch(llvm::telemetry::TelemetryInfo *entry) override;
+  static std::unique_ptr g_instance;

labath wrote:

This one ought to be private since subclasses should go through `setInstance`. 
We could also delete the setter and have subclasses set the member directly, 
but I sort of like the setter approach more.

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


[Lldb-commits] [lldb] Define Telemetry plugin for LLDB. (PR #126588)

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


@@ -79,3 +79,7 @@ add_subdirectory(ValueObject)
 if(LLDB_CAN_USE_DEBUGSERVER AND LLDB_TOOL_DEBUGSERVER_BUILD AND NOT 
LLDB_USE_SYSTEM_DEBUGSERVER)
   add_subdirectory(debugserver)
 endif()
+
+if(LLVM_BUILD_TELEMETRY)
+  add_subdirectory(telemetry)
+endif()

labath wrote:

Our usual pattern is to have the unit test tree mirror the source tree, which 
would put these tests at `unittests/Core/TelemetryTest.cpp`. The debugserver 
directory is an exception I'd rather not emulate. I can imagine doing it 
differently if the tests get rather big, or there are some other issues which 
make collocating this with the rest of Core tests difficult, but I don't think 
we're there yet.

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


[Lldb-commits] [lldb] Define Telemetry plugin for LLDB. (PR #126588)

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

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


[Lldb-commits] [lldb] Define Telemetry plugin for LLDB. (PR #126588)

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


@@ -0,0 +1,45 @@
+//===-- FakePlugin.cpp --*- C++ 
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "FakePlugin.h"
+#include "lldb/Core/PluginInterface.h"
+#include "lldb/Core/PluginManager.h"
+#include "lldb/Core/Telemetry.h"
+#include "llvm/ADT/StringRef.h"
+#include "llvm/Support/Casting.h"
+#include "llvm/Support/Error.h"
+#include "llvm/Telemetry/Telemetry.h"
+
+#include 
+
+LLDB_PLUGIN_DEFINE(FakePlugin)
+
+namespace lldb_private {
+
+FakePlugin::FakePlugin()
+: telemetry::TelemetryManager(
+  std::make_unique(true)) {}
+
+llvm::Error FakePlugin::preDispatch(llvm::telemetry::TelemetryInfo *entry) {
+  if (auto *fake_entry = llvm::dyn_cast(entry)) {
+fake_entry->msg = "In FakePlugin";
+  }
+
+  return llvm::Error::success();
+}
+
+void FakePlugin::Initialize() {
+  telemetry::TelemetryManager::setInstance(std::make_unique());
+  // TODO: do we need all the PluginManagerL::RegisterPlugin()  stuff???

labath wrote:

We don't.

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


[Lldb-commits] [lldb] Define Telemetry plugin for LLDB. (PR #126588)

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


@@ -0,0 +1,45 @@
+//===-- FakePlugin.cpp --*- C++ 
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "FakePlugin.h"
+#include "lldb/Core/PluginInterface.h"
+#include "lldb/Core/PluginManager.h"
+#include "lldb/Core/Telemetry.h"
+#include "llvm/ADT/StringRef.h"
+#include "llvm/Support/Casting.h"
+#include "llvm/Support/Error.h"
+#include "llvm/Telemetry/Telemetry.h"
+
+#include 
+
+LLDB_PLUGIN_DEFINE(FakePlugin)
+
+namespace lldb_private {
+
+FakePlugin::FakePlugin()
+: telemetry::TelemetryManager(
+  std::make_unique(true)) {}
+
+llvm::Error FakePlugin::preDispatch(llvm::telemetry::TelemetryInfo *entry) {
+  if (auto *fake_entry = llvm::dyn_cast(entry)) {
+fake_entry->msg = "In FakePlugin";
+  }
+
+  return llvm::Error::success();
+}
+
+void FakePlugin::Initialize() {
+  telemetry::TelemetryManager::setInstance(std::make_unique());
+  // TODO: do we need all the PluginManagerL::RegisterPlugin()  stuff???
+}
+
+void FakePlugin::Terminate() {
+  // nothing to do?

labath wrote:

maybe call `setInstance(nullptr)`

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


[Lldb-commits] [lldb] Define Telemetry plugin for LLDB. (PR #126588)

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


@@ -0,0 +1,34 @@
+//===-- TestFakePlugin.cpp 
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "lldb/Core/PluginInterface.h"
+#include "lldb/Core/PluginManager.h"
+#include "lldb/Core/Telemetry.h"
+#include "plugin/FakePlugin.h"
+#include "llvm/ADT/StringRef.h"
+#include "llvm/Support/Error.h"
+#include "llvm/Telemetry/Telemetry.h"
+#include "gtest/gtest.h"
+
+#include 
+
+TEST(TelemetryTest, PluginTest) {
+  // This would have been called by the plugin reg in a "real" plugin
+  // For tests, we just call it directly.
+  lldb_private::FakePlugin::Initialize();
+
+  auto ins = lldb_private::telemetry::TelemetryManager::getInstance();
+
+  ASSERT_NE(ins, nullptr);
+  lldb_private::FakeTelemetryInfo entry;
+  entry.msg = "";
+
+  auto stat = ins->preDispatch(&entry);

labath wrote:

This isn't the public API for sending a telemetry event, is it? (Why is it even 
a public method?) I think we could delete this for now. After you add some 
actual events, we can extend this to test sending of events using the real API.

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


[Lldb-commits] [clang] [lldb] [lldb] Analyze enum promotion type during parsing (PR #115005)

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

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

Looks great! Thank you for moving all this functionality into Clang

LGTM (just one minor comment left)

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


[Lldb-commits] [clang] [lldb] [lldb] Analyze enum promotion type during parsing (PR #115005)

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


@@ -8476,27 +8476,20 @@ bool TypeSystemClang::CompleteTagDeclarationDefinition(
 
   clang::ASTContext &ast = lldb_ast->getASTContext();
 
-  /// TODO This really needs to be fixed.
+  unsigned NumNegativeBits = 0;

Michael137 wrote:

Can we move this block back into the `if (!integer_type.isNull()) {` condition 
below?

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


[Lldb-commits] [lldb] [lldb] Correctly resolve (discontinuous) function offsets when disassembling (PR #126925)

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

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

LGTM

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


[Lldb-commits] [lldb] Define Telemetry plugin for LLDB. (PR #126588)

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


@@ -79,3 +79,7 @@ add_subdirectory(ValueObject)
 if(LLDB_CAN_USE_DEBUGSERVER AND LLDB_TOOL_DEBUGSERVER_BUILD AND NOT 
LLDB_USE_SYSTEM_DEBUGSERVER)
   add_subdirectory(debugserver)
 endif()
+
+if(LLVM_BUILD_TELEMETRY)
+  add_subdirectory(telemetry)
+endif()

labath wrote:

(That means wrapping whole of TelemetryTest.cpp in `#ifdef TELEMETRY`)

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


[Lldb-commits] [lldb] 499d6da - [lldb] Correctly resolve (discontinuous) function offsets when disassembling (#126925)

2025-02-13 Thread via lldb-commits

Author: Pavel Labath
Date: 2025-02-13T11:23:38+01:00
New Revision: 499d6da3bb2c967abda298518dc22b7baf084a9e

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

LOG: [lldb] Correctly resolve (discontinuous) function offsets when 
disassembling (#126925)

We need to iterate through the all symbol context ranges returned by
(since #126505) SymbolContext::GetAddressRange. This also includes a fix
to print the function offsets as signed values.

I've also wanted to check that the addresses which are in the middle of
the function do *not* resolve to the function, but that's not entirely
the case right now. This appears to be a separate issue though, so I've
just left a TODO for now.

Added: 


Modified: 
lldb/source/Plugins/Disassembler/LLVMC/DisassemblerLLVMC.cpp
lldb/source/Symbol/SymbolContext.cpp
lldb/test/Shell/Commands/command-disassemble.s

Removed: 




diff  --git a/lldb/source/Plugins/Disassembler/LLVMC/DisassemblerLLVMC.cpp 
b/lldb/source/Plugins/Disassembler/LLVMC/DisassemblerLLVMC.cpp
index 76f2db086476f..a77155f6bf41e 100644
--- a/lldb/source/Plugins/Disassembler/LLVMC/DisassemblerLLVMC.cpp
+++ b/lldb/source/Plugins/Disassembler/LLVMC/DisassemblerLLVMC.cpp
@@ -31,6 +31,7 @@
 
 #include "lldb/Core/Address.h"
 #include "lldb/Core/Module.h"
+#include "lldb/Symbol/Function.h"
 #include "lldb/Symbol/SymbolContext.h"
 #include "lldb/Target/ExecutionContext.h"
 #include "lldb/Target/Process.h"
@@ -1806,10 +1807,13 @@ const char *DisassemblerLLVMC::SymbolLookup(uint64_t 
value, uint64_t *type_ptr,
 bool format_omitting_current_func_name = false;
 if (sym_ctx.symbol || sym_ctx.function) {
   AddressRange range;
-  if (sym_ctx.GetAddressRange(resolve_scope, 0, false, range) &&
-  range.GetBaseAddress().IsValid() &&
-  range.ContainsLoadAddress(value_so_addr, target)) {
-format_omitting_current_func_name = true;
+  for (uint32_t idx = 0;
+   sym_ctx.GetAddressRange(resolve_scope, idx, false, range);
+   ++idx) {
+if (range.ContainsLoadAddress(value_so_addr, target)) {
+  format_omitting_current_func_name = true;
+  break;
+}
   }
 }
 

diff  --git a/lldb/source/Symbol/SymbolContext.cpp 
b/lldb/source/Symbol/SymbolContext.cpp
index 4725df52ff559..183947a694363 100644
--- a/lldb/source/Symbol/SymbolContext.cpp
+++ b/lldb/source/Symbol/SymbolContext.cpp
@@ -104,15 +104,19 @@ bool SymbolContext::DumpStopContext(
 
 if (addr_t file_addr = addr.GetFileAddress();
 file_addr != LLDB_INVALID_ADDRESS) {
-  const addr_t function_offset =
-  file_addr - function->GetAddress().GetFileAddress();
+  // Avoiding signed arithmetic due to UB in -INT_MAX.
+  const char sign =
+  file_addr >= function->GetAddress().GetFileAddress() ? '+' : '-';
+  addr_t offset = file_addr - function->GetAddress().GetFileAddress();
+  if (sign == '-')
+offset = -offset;
   if (!show_function_name) {
 // Print +offset even if offset is 0
 dumped_something = true;
-s->Printf("+%" PRIu64 ">", function_offset);
-  } else if (function_offset) {
+s->Format("{0}{1}>", sign, offset);
+  } else if (offset) {
 dumped_something = true;
-s->Printf(" + %" PRIu64, function_offset);
+s->Format(" {0} {1}", sign, offset);
   }
 }
 

diff  --git a/lldb/test/Shell/Commands/command-disassemble.s 
b/lldb/test/Shell/Commands/command-disassemble.s
index 951d96cefd4b9..eb84a9ce39d4a 100644
--- a/lldb/test/Shell/Commands/command-disassemble.s
+++ b/lldb/test/Shell/Commands/command-disassemble.s
@@ -84,7 +84,7 @@
 # CHECK-NEXT: command-disassemble.s.tmp[0x2044] <+0>: int$0x32
 # CHECK-NEXT: warning: Not disassembling a function because it is very large 
[0x2046-0x4046). To disassemble specify an instruction 
count limit, start/stop addresses or use the --force option.
 # CHECK-NEXT: (lldb) disassemble --name case3
-# CHECK-NEXT: error: Not disassembling a function because it is very large 
[0x6046-0x7046)[0x9046-0xa046). 
To disassemble specify an instruction count limit, start/stop addresses or use 
the --force option.
+# CHECK-NEXT: error: Not disassembling a function because it is very large 
[0x6046-0x7046)[0x9046-0xa050). 
To disassemble specify an instruction count limit, start/stop addresses or use 
the --force option.
 # CHECK-NEXT: Not disassembling a function because it is very large 
[0x4046-0x6046). To disassemble specify an instruction 
count limit, start/stop addresses or use the --force

[Lldb-commits] [lldb] [lldb] Correctly resolve (discontinuous) function offsets when disassembling (PR #126925)

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

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


[Lldb-commits] [lldb] [lldb-dap] Add: show return value on step out (PR #106907)

2025-02-13 Thread via lldb-commits


@@ -663,6 +663,41 @@ def do_test_indexedVariables(self, 
enableSyntheticChildDebugging: bool):
 ]["variables"]
 self.verify_variables(verify_children, children)
 
+def test_return_variables(self):

Da-Viper wrote:

I am a little bit confused about something just need some clarification. 

lldb provides SBThread::GetStopReturnValue(). I am assuming on arm64, checking 
`isValid()` will be false?.

when you say scalar return test is it the one return a value in register and 
the memory returns a memory address to the variable ? 


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


[Lldb-commits] [lldb] [lldb-dap] Add: show return value on step out (PR #106907)

2025-02-13 Thread via lldb-commits


@@ -3801,6 +3801,23 @@ void request_variables(const llvm::json::Object 
&request) {
   variable_name_counts[GetNonNullVariableName(variable)]++;
 }
 
+// Show return value if there is any ( in the top frame )

Da-Viper wrote:

Not sure

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


[Lldb-commits] [lldb] [lldb] Fix RangeDataVector::CombineConsecutiveEntriesWithEqualData (PR #127059)

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

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

Function was merging equal data even if they weren't adjecant. This caused a 
problem in command-disassemble.s test because the two ranges describing the 
function would be merged and "swallow" the function between them.

This PR copies/adapts the algorithm from
RangeVector::CombineConsecutiveEntries (which does not have the same problem) 
and also adds a call to ComputeUpperBounds as moving entries around invalidates 
the binary tree. (The lack of this call wasn't noticed until now either because 
we were not calling methods which rely on upper bounds (right now, it's only 
the ill-named FindEntryIndexes method), or because we weren't merging anything.

>From 2647987f2a33ddd2cd11ea6c4b8d125ccffcf89e Mon Sep 17 00:00:00 2001
From: Pavel Labath 
Date: Thu, 13 Feb 2025 14:08:25 +0100
Subject: [PATCH] [lldb] Fix
 RangeDataVector::CombineConsecutiveEntriesWithEqualData

Function was merging equal data even if they weren't adjecant. This
caused a problem in command-disassemble.s test because the two ranges
describing the function would be merged and "swallow" the function
between them.

This PR copies/adapts the algorithm from
RangeVector::CombineConsecutiveEntries (which does not have the same
problem) and also adds a call to ComputeUpperBounds as moving entries
around invalidates the binary tree. (The lack of this call wasn't
noticed until now either because we were not calling methods which rely
on upper bounds (right now, it's only the ill-named FindEntryIndexes
method), or because we weren't merging anything.
---
 lldb/include/lldb/Utility/RangeMap.h  | 47 ---
 .../test/Shell/Commands/command-disassemble.s |  3 +-
 lldb/unittests/Utility/RangeMapTest.cpp   | 21 +
 3 files changed, 41 insertions(+), 30 deletions(-)

diff --git a/lldb/include/lldb/Utility/RangeMap.h 
b/lldb/include/lldb/Utility/RangeMap.h
index 433466eebced8..2bebe74cc4cfe 100644
--- a/lldb/include/lldb/Utility/RangeMap.h
+++ b/lldb/include/lldb/Utility/RangeMap.h
@@ -493,36 +493,27 @@ class RangeDataVector {
 #ifdef ASSERT_RANGEMAP_ARE_SORTED
 assert(IsSorted());
 #endif
-typename Collection::iterator pos;
-typename Collection::iterator end;
-typename Collection::iterator prev;
-bool can_combine = false;
-// First we determine if we can combine any of the Entry objects so we
-// don't end up allocating and making a new collection for no reason
-for (pos = m_entries.begin(), end = m_entries.end(), prev = end; pos != 
end;
- prev = pos++) {
-  if (prev != end && prev->data == pos->data) {
-can_combine = true;
-break;
-  }
-}
+auto first_intersect = std::adjacent_find(
+m_entries.begin(), m_entries.end(), [](const Entry &a, const Entry &b) 
{
+  return a.DoesAdjoinOrIntersect(b) && a.data == b.data;
+});
+if (first_intersect == m_entries.end())
+  return;
 
-// We can combine at least one entry, then we make a new collection and
-// populate it accordingly, and then swap it into place.
-if (can_combine) {
-  Collection minimal_ranges;
-  for (pos = m_entries.begin(), end = m_entries.end(), prev = end;
-   pos != end; prev = pos++) {
-if (prev != end && prev->data == pos->data)
-  minimal_ranges.back().SetRangeEnd(pos->GetRangeEnd());
-else
-  minimal_ranges.push_back(*pos);
-  }
-  // Use the swap technique in case our new vector is much smaller. We must
-  // swap when using the STL because std::vector objects never release or
-  // reduce the memory once it has been allocated/reserved.
-  m_entries.swap(minimal_ranges);
+// We can combine at least one entry. Make a new collection and populate it
+// accordingly, and then swap it into place.
+auto pos = std::next(first_intersect);
+Collection minimal_ranges(m_entries.begin(), pos);
+for (; pos != m_entries.end(); ++pos) {
+  Entry &back = minimal_ranges.back();
+  if (back.DoesAdjoinOrIntersect(*pos) && back.data == pos->data)
+back.SetRangeEnd(std::max(back.GetRangeEnd(), pos->GetRangeEnd()));
+  else
+minimal_ranges.push_back(*pos);
 }
+m_entries.swap(minimal_ranges);
+if (!m_entries.empty())
+  ComputeUpperBounds(0, m_entries.size());
   }
 
   void Clear() { m_entries.clear(); }
diff --git a/lldb/test/Shell/Commands/command-disassemble.s 
b/lldb/test/Shell/Commands/command-disassemble.s
index eb84a9ce39d4a..14f416d221231 100644
--- a/lldb/test/Shell/Commands/command-disassemble.s
+++ b/lldb/test/Shell/Commands/command-disassemble.s
@@ -94,8 +94,7 @@
 # CHECK-EMPTY:
 # CHECK-NEXT: command-disassemble.s.tmp`n2::case3:
 # CHECK-NEXT: command-disassemble.s.tmp[0x9046] <+0>: jmp 0x6046 ; <-12288>
-## FIXME: This should resolve to `middle_of_case3`
-# CHECK-NEXT: command-disassemble.s.tmp[0x904b] <+5>: jmp 0x7046 ; n2::case3 - 
819

[Lldb-commits] [lldb] [lldb] Fix RangeDataVector::CombineConsecutiveEntriesWithEqualData (PR #127059)

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

https://github.com/labath updated 
https://github.com/llvm/llvm-project/pull/127059

>From 450371c5fd3ecce3ec54237379fef751fba45751 Mon Sep 17 00:00:00 2001
From: Pavel Labath 
Date: Thu, 13 Feb 2025 14:08:25 +0100
Subject: [PATCH] [lldb] Fix
 RangeDataVector::CombineConsecutiveEntriesWithEqualData

Function was merging equal data even if they weren't adjecant. This
caused a problem in command-disassemble.s test because the two ranges
describing the function would be merged and "swallow" the function
between them.

This PR copies/adapts the algorithm from
RangeVector::CombineConsecutiveEntries (which does not have the same
problem) and also adds a call to ComputeUpperBounds as moving entries
around invalidates the binary tree. (The lack of this call wasn't
noticed until now either because we were not calling methods which rely
on upper bounds (right now, it's only the ill-named FindEntryIndexes
method), or because we weren't merging anything.
---
 lldb/include/lldb/Utility/RangeMap.h  | 47 ---
 .../test/Shell/Commands/command-disassemble.s |  3 +-
 lldb/unittests/Utility/RangeMapTest.cpp   | 21 +
 3 files changed, 41 insertions(+), 30 deletions(-)

diff --git a/lldb/include/lldb/Utility/RangeMap.h 
b/lldb/include/lldb/Utility/RangeMap.h
index 433466eebced8..2bebe74cc4cfe 100644
--- a/lldb/include/lldb/Utility/RangeMap.h
+++ b/lldb/include/lldb/Utility/RangeMap.h
@@ -493,36 +493,27 @@ class RangeDataVector {
 #ifdef ASSERT_RANGEMAP_ARE_SORTED
 assert(IsSorted());
 #endif
-typename Collection::iterator pos;
-typename Collection::iterator end;
-typename Collection::iterator prev;
-bool can_combine = false;
-// First we determine if we can combine any of the Entry objects so we
-// don't end up allocating and making a new collection for no reason
-for (pos = m_entries.begin(), end = m_entries.end(), prev = end; pos != 
end;
- prev = pos++) {
-  if (prev != end && prev->data == pos->data) {
-can_combine = true;
-break;
-  }
-}
+auto first_intersect = std::adjacent_find(
+m_entries.begin(), m_entries.end(), [](const Entry &a, const Entry &b) 
{
+  return a.DoesAdjoinOrIntersect(b) && a.data == b.data;
+});
+if (first_intersect == m_entries.end())
+  return;
 
-// We can combine at least one entry, then we make a new collection and
-// populate it accordingly, and then swap it into place.
-if (can_combine) {
-  Collection minimal_ranges;
-  for (pos = m_entries.begin(), end = m_entries.end(), prev = end;
-   pos != end; prev = pos++) {
-if (prev != end && prev->data == pos->data)
-  minimal_ranges.back().SetRangeEnd(pos->GetRangeEnd());
-else
-  minimal_ranges.push_back(*pos);
-  }
-  // Use the swap technique in case our new vector is much smaller. We must
-  // swap when using the STL because std::vector objects never release or
-  // reduce the memory once it has been allocated/reserved.
-  m_entries.swap(minimal_ranges);
+// We can combine at least one entry. Make a new collection and populate it
+// accordingly, and then swap it into place.
+auto pos = std::next(first_intersect);
+Collection minimal_ranges(m_entries.begin(), pos);
+for (; pos != m_entries.end(); ++pos) {
+  Entry &back = minimal_ranges.back();
+  if (back.DoesAdjoinOrIntersect(*pos) && back.data == pos->data)
+back.SetRangeEnd(std::max(back.GetRangeEnd(), pos->GetRangeEnd()));
+  else
+minimal_ranges.push_back(*pos);
 }
+m_entries.swap(minimal_ranges);
+if (!m_entries.empty())
+  ComputeUpperBounds(0, m_entries.size());
   }
 
   void Clear() { m_entries.clear(); }
diff --git a/lldb/test/Shell/Commands/command-disassemble.s 
b/lldb/test/Shell/Commands/command-disassemble.s
index eb84a9ce39d4a..14f416d221231 100644
--- a/lldb/test/Shell/Commands/command-disassemble.s
+++ b/lldb/test/Shell/Commands/command-disassemble.s
@@ -94,8 +94,7 @@
 # CHECK-EMPTY:
 # CHECK-NEXT: command-disassemble.s.tmp`n2::case3:
 # CHECK-NEXT: command-disassemble.s.tmp[0x9046] <+0>: jmp 0x6046 ; <-12288>
-## FIXME: This should resolve to `middle_of_case3`
-# CHECK-NEXT: command-disassemble.s.tmp[0x904b] <+5>: jmp 0x7046 ; n2::case3 - 
8192
+# CHECK-NEXT: command-disassemble.s.tmp[0x904b] <+5>: jmp 0x7046 ; 
middle_of_case3
 # CHECK-NEXT: command-disassemble.s.tmp[0x9050] <+10>: int$0x2a
 # CHECK-EMPTY:
 # CHECK-NEXT: command-disassemble.s.tmp`n1::case3:
diff --git a/lldb/unittests/Utility/RangeMapTest.cpp 
b/lldb/unittests/Utility/RangeMapTest.cpp
index 981fa2a7d1c34..2022a2374fb8d 100644
--- a/lldb/unittests/Utility/RangeMapTest.cpp
+++ b/lldb/unittests/Utility/RangeMapTest.cpp
@@ -238,3 +238,24 @@ TEST(RangeDataVector, FindEntryIndexesThatContain_Overlap) 
{
   EXPECT_THAT(FindEntryIndexes(39, Map), testing::ElementsAre(10));
   EXPECT_THAT(FindEntryIndexes(40, Map), testing::Elemen

[Lldb-commits] [lldb] [lldb] Fix RangeDataVector::CombineConsecutiveEntriesWithEqualData (PR #127059)

2025-02-13 Thread via lldb-commits

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Pavel Labath (labath)


Changes

Function was merging equal data even if they weren't adjecant. This caused a 
problem in command-disassemble.s test because the two ranges describing the 
function would be merged and "swallow" the function between them.

This PR copies/adapts the algorithm from
RangeVector::CombineConsecutiveEntries (which does not have the same problem) 
and also adds a call to ComputeUpperBounds as moving entries around invalidates 
the binary tree. (The lack of this call wasn't noticed until now either because 
we were not calling methods which rely on upper bounds (right now, it's only 
the ill-named FindEntryIndexes method), or because we weren't merging anything.

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


3 Files Affected:

- (modified) lldb/include/lldb/Utility/RangeMap.h (+19-28) 
- (modified) lldb/test/Shell/Commands/command-disassemble.s (+1-2) 
- (modified) lldb/unittests/Utility/RangeMapTest.cpp (+21) 


``diff
diff --git a/lldb/include/lldb/Utility/RangeMap.h 
b/lldb/include/lldb/Utility/RangeMap.h
index 433466eebced8..2bebe74cc4cfe 100644
--- a/lldb/include/lldb/Utility/RangeMap.h
+++ b/lldb/include/lldb/Utility/RangeMap.h
@@ -493,36 +493,27 @@ class RangeDataVector {
 #ifdef ASSERT_RANGEMAP_ARE_SORTED
 assert(IsSorted());
 #endif
-typename Collection::iterator pos;
-typename Collection::iterator end;
-typename Collection::iterator prev;
-bool can_combine = false;
-// First we determine if we can combine any of the Entry objects so we
-// don't end up allocating and making a new collection for no reason
-for (pos = m_entries.begin(), end = m_entries.end(), prev = end; pos != 
end;
- prev = pos++) {
-  if (prev != end && prev->data == pos->data) {
-can_combine = true;
-break;
-  }
-}
+auto first_intersect = std::adjacent_find(
+m_entries.begin(), m_entries.end(), [](const Entry &a, const Entry &b) 
{
+  return a.DoesAdjoinOrIntersect(b) && a.data == b.data;
+});
+if (first_intersect == m_entries.end())
+  return;
 
-// We can combine at least one entry, then we make a new collection and
-// populate it accordingly, and then swap it into place.
-if (can_combine) {
-  Collection minimal_ranges;
-  for (pos = m_entries.begin(), end = m_entries.end(), prev = end;
-   pos != end; prev = pos++) {
-if (prev != end && prev->data == pos->data)
-  minimal_ranges.back().SetRangeEnd(pos->GetRangeEnd());
-else
-  minimal_ranges.push_back(*pos);
-  }
-  // Use the swap technique in case our new vector is much smaller. We must
-  // swap when using the STL because std::vector objects never release or
-  // reduce the memory once it has been allocated/reserved.
-  m_entries.swap(minimal_ranges);
+// We can combine at least one entry. Make a new collection and populate it
+// accordingly, and then swap it into place.
+auto pos = std::next(first_intersect);
+Collection minimal_ranges(m_entries.begin(), pos);
+for (; pos != m_entries.end(); ++pos) {
+  Entry &back = minimal_ranges.back();
+  if (back.DoesAdjoinOrIntersect(*pos) && back.data == pos->data)
+back.SetRangeEnd(std::max(back.GetRangeEnd(), pos->GetRangeEnd()));
+  else
+minimal_ranges.push_back(*pos);
 }
+m_entries.swap(minimal_ranges);
+if (!m_entries.empty())
+  ComputeUpperBounds(0, m_entries.size());
   }
 
   void Clear() { m_entries.clear(); }
diff --git a/lldb/test/Shell/Commands/command-disassemble.s 
b/lldb/test/Shell/Commands/command-disassemble.s
index eb84a9ce39d4a..14f416d221231 100644
--- a/lldb/test/Shell/Commands/command-disassemble.s
+++ b/lldb/test/Shell/Commands/command-disassemble.s
@@ -94,8 +94,7 @@
 # CHECK-EMPTY:
 # CHECK-NEXT: command-disassemble.s.tmp`n2::case3:
 # CHECK-NEXT: command-disassemble.s.tmp[0x9046] <+0>: jmp 0x6046 ; <-12288>
-## FIXME: This should resolve to `middle_of_case3`
-# CHECK-NEXT: command-disassemble.s.tmp[0x904b] <+5>: jmp 0x7046 ; n2::case3 - 
8192
+# CHECK-NEXT: command-disassemble.s.tmp[0x904b] <+5>: jmp 0x7046 ; 
middle_of_case3
 # CHECK-NEXT: command-disassemble.s.tmp[0x9050] <+10>: int$0x2a
 # CHECK-EMPTY:
 # CHECK-NEXT: command-disassemble.s.tmp`n1::case3:
diff --git a/lldb/unittests/Utility/RangeMapTest.cpp 
b/lldb/unittests/Utility/RangeMapTest.cpp
index 981fa2a7d1c34..337e74a0e3d8c 100644
--- a/lldb/unittests/Utility/RangeMapTest.cpp
+++ b/lldb/unittests/Utility/RangeMapTest.cpp
@@ -238,3 +238,24 @@ TEST(RangeDataVector, FindEntryIndexesThatContain_Overlap) 
{
   EXPECT_THAT(FindEntryIndexes(39, Map), testing::ElementsAre(10));
   EXPECT_THAT(FindEntryIndexes(40, Map), testing::ElementsAre());
 }
+
+TEST(RangeDataVector, CombineConsecutiveEntriesWithEqualData) {
+  RangeDataVectorT Map;
+  Map.Append(EntryT(0, 10, 10));
+  Map.Append(Entry

[Lldb-commits] [lldb] [lldb] Remove UtilityTests->Target dep (PR #127060)

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

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

It's completely unnecessary right now, but having it present means that some 
real unwanted dependencies could sneak in. (This also makes building the test 
binary much faster.)

>From b5dc90a88c8a0d4182f28ebf4f9844481bd93300 Mon Sep 17 00:00:00 2001
From: Pavel Labath 
Date: Thu, 13 Feb 2025 14:23:31 +0100
Subject: [PATCH] [lldb] Remove UtilityTests->Target dep

It's completely unnecessary right now, but having it present means that
some real unwanted dependencies could sneak it. (This also makes
building the test binary much faster.)
---
 lldb/unittests/Utility/CMakeLists.txt  | 1 -
 lldb/unittests/Utility/ProcessInstanceInfoTest.cpp | 6 +-
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/lldb/unittests/Utility/CMakeLists.txt 
b/lldb/unittests/Utility/CMakeLists.txt
index 3a73bdc3e9e1a..8d4e2ea35f267 100644
--- a/lldb/unittests/Utility/CMakeLists.txt
+++ b/lldb/unittests/Utility/CMakeLists.txt
@@ -52,7 +52,6 @@ add_lldb_unittest(UtilityTests
   XcodeSDKTest.cpp
 
   LINK_LIBS
-  lldbTarget
   lldbUtility
   lldbUtilityHelpers
   LLVMTestingSupport
diff --git a/lldb/unittests/Utility/ProcessInstanceInfoTest.cpp 
b/lldb/unittests/Utility/ProcessInstanceInfoTest.cpp
index 3ba35d4efacc1..b653df5fe01a1 100644
--- a/lldb/unittests/Utility/ProcessInstanceInfoTest.cpp
+++ b/lldb/unittests/Utility/ProcessInstanceInfoTest.cpp
@@ -6,7 +6,11 @@
 //
 
//===--===//
 
-#include "lldb/Target/Process.h"
+#include "lldb/Utility/ArchSpec.h"
+#include "lldb/Utility/ProcessInfo.h"
+#include "lldb/Utility/StreamString.h"
+#include "lldb/Utility/UserIDResolver.h"
+#include "llvm/ADT/Twine.h"
 #include "gtest/gtest.h"
 #include 
 

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


[Lldb-commits] [lldb] [lldb-dap] Add: show return value on step out (PR #106907)

2025-02-13 Thread via lldb-commits

https://github.com/Da-Viper updated 
https://github.com/llvm/llvm-project/pull/106907

>From aeb8854bbe7695e576257c8403e04d4b8268b679 Mon Sep 17 00:00:00 2001
From: Ezike Ebuka 
Date: Sun, 1 Sep 2024 13:48:41 +0100
Subject: [PATCH 1/6] Add: show return value on step out

---
 lldb/tools/lldb-dap/lldb-dap.cpp | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/lldb/tools/lldb-dap/lldb-dap.cpp b/lldb/tools/lldb-dap/lldb-dap.cpp
index e323990d8b6ed..3cacc16dedb25 100644
--- a/lldb/tools/lldb-dap/lldb-dap.cpp
+++ b/lldb/tools/lldb-dap/lldb-dap.cpp
@@ -4225,6 +4225,17 @@ void request_variables(DAP &dap, const 
llvm::json::Object &request) {
   variable_name_counts[GetNonNullVariableName(variable)]++;
 }
 
+// Show return value if there is any ( in the top frame )
+auto process = g_dap.target.GetProcess();
+auto selectedThread = process.GetSelectedThread();
+lldb::SBValue stopReturnValue = selectedThread.GetStopReturnValue();
+if (stopReturnValue.IsValid() &&
+(selectedThread.GetSelectedFrame().GetFrameID() == 0)) {
+  auto renamedReturnValue = stopReturnValue.Clone("(Return Value)");
+  variables.emplace_back(
+  CreateVariable(renamedReturnValue,0, UINT64_MAX, hex, false));
+}
+
 // Now we construct the result with unique display variable names
 for (auto i = start_idx; i < end_idx; ++i) {
   lldb::SBValue variable = top_scope->GetValueAtIndex(i);

>From 07c3c56bc987cdd947b8de126be6497f45f1da7b Mon Sep 17 00:00:00 2001
From: Ezike Ebuka 
Date: Sun, 1 Sep 2024 14:10:54 +0100
Subject: [PATCH 2/6] format file

---
 lldb/tools/lldb-dap/lldb-dap.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lldb/tools/lldb-dap/lldb-dap.cpp b/lldb/tools/lldb-dap/lldb-dap.cpp
index 3cacc16dedb25..30b3354c184b0 100644
--- a/lldb/tools/lldb-dap/lldb-dap.cpp
+++ b/lldb/tools/lldb-dap/lldb-dap.cpp
@@ -4233,7 +4233,7 @@ void request_variables(DAP &dap, const llvm::json::Object 
&request) {
 (selectedThread.GetSelectedFrame().GetFrameID() == 0)) {
   auto renamedReturnValue = stopReturnValue.Clone("(Return Value)");
   variables.emplace_back(
-  CreateVariable(renamedReturnValue,0, UINT64_MAX, hex, false));
+  CreateVariable(renamedReturnValue, 0, UINT64_MAX, hex, false));
 }
 
 // Now we construct the result with unique display variable names

>From c9ef0294def8919536ade9f8097c3471b94b0355 Mon Sep 17 00:00:00 2001
From: Ezike Ebuka 
Date: Sun, 15 Sep 2024 22:22:09 +0100
Subject: [PATCH 3/6] [lldb-dap] Add: Show children for return values

---
 lldb/tools/lldb-dap/lldb-dap.cpp | 20 +---
 1 file changed, 13 insertions(+), 7 deletions(-)

diff --git a/lldb/tools/lldb-dap/lldb-dap.cpp b/lldb/tools/lldb-dap/lldb-dap.cpp
index 30b3354c184b0..00584f31848cf 100644
--- a/lldb/tools/lldb-dap/lldb-dap.cpp
+++ b/lldb/tools/lldb-dap/lldb-dap.cpp
@@ -4227,13 +4227,19 @@ void request_variables(DAP &dap, const 
llvm::json::Object &request) {
 
 // Show return value if there is any ( in the top frame )
 auto process = g_dap.target.GetProcess();
-auto selectedThread = process.GetSelectedThread();
-lldb::SBValue stopReturnValue = selectedThread.GetStopReturnValue();
-if (stopReturnValue.IsValid() &&
-(selectedThread.GetSelectedFrame().GetFrameID() == 0)) {
-  auto renamedReturnValue = stopReturnValue.Clone("(Return Value)");
-  variables.emplace_back(
-  CreateVariable(renamedReturnValue, 0, UINT64_MAX, hex, false));
+auto selected_thread = process.GetSelectedThread();
+lldb::SBValue stop_return_value = selected_thread.GetStopReturnValue();
+if (stop_return_value.IsValid() &&
+(selected_thread.GetSelectedFrame().GetFrameID() == 0)) {
+  auto renamed_return_value = stop_return_value.Clone("(Return Value)");
+  int64_t return_ref = 0;
+  if (stop_return_value.MightHaveChildren() ||
+  stop_return_value.IsSynthetic()) {
+return_ref = g_dap.variables.InsertExpandableVariable(
+stop_return_value, /*is_permanent=*/false);
+  }
+  variables.emplace_back(CreateVariable(renamed_return_value, return_ref,
+UINT64_MAX, hex, false));
 }
 
 // Now we construct the result with unique display variable names

>From 91e7042f9c3438b13ff8b476d07057da52b2589f Mon Sep 17 00:00:00 2001
From: Ezike Ebuka 
Date: Wed, 12 Feb 2025 00:16:46 +
Subject: [PATCH 4/6] [lldb-dap] Add Tests: Show children for return values

---
 .../lldb-dap/variables/TestDAP_variables.py   | 57 +++
 .../children/TestDAP_variables_children.py| 55 ++
 .../lldb-dap/variables/children/main.cpp  | 12 
 .../API/tools/lldb-dap/variables/main.cpp |  9 +++
 4 files changed, 122 insertions(+), 11 deletions(-)

diff --git a/lldb/test/API/tools/lldb-dap/variables/TestDAP_variables.py 
b/lldb/test/API/tools/lldb-dap/variables/TestDAP_variables.py

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

2025-02-13 Thread via lldb-commits

https://github.com/kper updated https://github.com/llvm/llvm-project/pull/124475

>From 0265d7e28d95d2dc2c06832b63ce7bd141429b99 Mon Sep 17 00:00:00 2001
From: Kevin Per 
Date: Sun, 26 Jan 2025 17:34:17 +
Subject: [PATCH 01/12] lldb: Extended if conditions to support alias names for
 registers

---
 .../Plugins/ABI/RISCV/ABISysV_riscv.cpp   | 54 +++
 1 file changed, 54 insertions(+)

diff --git a/lldb/source/Plugins/ABI/RISCV/ABISysV_riscv.cpp 
b/lldb/source/Plugins/ABI/RISCV/ABISysV_riscv.cpp
index 8412991933d27..c463bd006b3db 100644
--- a/lldb/source/Plugins/ABI/RISCV/ABISysV_riscv.cpp
+++ b/lldb/source/Plugins/ABI/RISCV/ABISysV_riscv.cpp
@@ -850,8 +850,62 @@ void ABISysV_riscv::AugmentRegisterInfo(
   it.value().alt_name.SetCString("x3");
 else if (it.value().name == "fp")
   it.value().alt_name.SetCString("s0");
+else if (it.value().name == "tp")
+  it.value().alt_name.SetCString("x4");
 else if (it.value().name == "s0")
   it.value().alt_name.SetCString("x8");
+else if (it.value().name == "s1")
+  it.value().alt_name.SetCString("x9");
+else if (it.value().name == "t0")
+  it.value().alt_name.SetCString("x5");
+else if (it.value().name == "t1")
+  it.value().alt_name.SetCString("x6");
+else if (it.value().name == "t2")
+  it.value().alt_name.SetCString("x7");
+else if (it.value().name == "a0")
+  it.value().alt_name.SetCString("x10");
+else if (it.value().name == "a1")
+  it.value().alt_name.SetCString("x11");
+else if (it.value().name == "a2")
+  it.value().alt_name.SetCString("x12");
+else if (it.value().name == "a3")
+  it.value().alt_name.SetCString("x13");
+else if (it.value().name == "a4")
+  it.value().alt_name.SetCString("x14");
+else if (it.value().name == "a5")
+  it.value().alt_name.SetCString("x15");
+else if (it.value().name == "a6")
+  it.value().alt_name.SetCString("x16");
+else if (it.value().name == "a7")
+  it.value().alt_name.SetCString("x17");
+else if (it.value().name == "s2")
+  it.value().alt_name.SetCString("x18");
+else if (it.value().name == "s3")
+  it.value().alt_name.SetCString("x19");
+else if (it.value().name == "s4")
+  it.value().alt_name.SetCString("x20");
+else if (it.value().name == "s5")
+  it.value().alt_name.SetCString("x21");
+else if (it.value().name == "s6")
+  it.value().alt_name.SetCString("x22");
+else if (it.value().name == "s7")
+  it.value().alt_name.SetCString("x23");
+else if (it.value().name == "s8")
+  it.value().alt_name.SetCString("x24");
+else if (it.value().name == "s9")
+  it.value().alt_name.SetCString("x25");
+else if (it.value().name == "s10")
+  it.value().alt_name.SetCString("x26");
+else if (it.value().name == "s11")
+  it.value().alt_name.SetCString("x27");
+else if (it.value().name == "t3")
+  it.value().alt_name.SetCString("x28");
+else if (it.value().name == "t4")
+  it.value().alt_name.SetCString("x29");
+else if (it.value().name == "t5")
+  it.value().alt_name.SetCString("x30");
+else if (it.value().name == "t6")
+  it.value().alt_name.SetCString("x31");
 
 // Set generic regnum so lldb knows what the PC, etc is
 it.value().regnum_generic = GetGenericNum(it.value().name.GetStringRef());

>From 098913013c8b93d6c94813f81aa0ed9df707afe4 Mon Sep 17 00:00:00 2001
From: Kevin Per 
Date: Tue, 28 Jan 2025 15:23:54 +
Subject: [PATCH 02/12] Added RISCV reg test for the ServerTargetXML

---
 .../TestGDBServerTargetXML.py | 149 ++
 1 file changed, 149 insertions(+)

diff --git 
a/lldb/test/API/functionalities/gdb_remote_client/TestGDBServerTargetXML.py 
b/lldb/test/API/functionalities/gdb_remote_client/TestGDBServerTargetXML.py
index 22f5553e40802..c74726a88aa6f 100644
--- a/lldb/test/API/functionalities/gdb_remote_client/TestGDBServerTargetXML.py
+++ b/lldb/test/API/functionalities/gdb_remote_client/TestGDBServerTargetXML.py
@@ -652,6 +652,155 @@ def haltReason(self):
 )
 self.match("register read s31", ["s31 = 128"])
 
+@skipIfXmlSupportMissing
+@skipIfRemote
+@skipIfLLVMTargetMissing("RISCV")
+def test_riscv64_regs(self):
+"""Test grabbing various riscv64 registers from gdbserver."""
+
+class MyResponder(MockGDBServerResponder):
+reg_data = (
+(
+"0102030405060708"  # zero
+"0102030405060708"  # ra
+"0102030405060708"  # sp
+"0102030405060708"  # gp
+"0102030405060708"  # tp
+"0102030405060708"  # t0 
+"0102030405060708"  # t1
+"0102030405060708"  # t2
+"0102030405060708"  # fp 
+"0102030405060708"  # s1
+"0102030405060708"  # a0
+"01

[Lldb-commits] [lldb] Define Telemetry plugin for LLDB. (PR #126588)

2025-02-13 Thread Vy Nguyen via lldb-commits


@@ -79,3 +79,7 @@ add_subdirectory(ValueObject)
 if(LLDB_CAN_USE_DEBUGSERVER AND LLDB_TOOL_DEBUGSERVER_BUILD AND NOT 
LLDB_USE_SYSTEM_DEBUGSERVER)
   add_subdirectory(debugserver)
 endif()
+
+if(LLVM_BUILD_TELEMETRY)
+  add_subdirectory(telemetry)
+endif()

oontvoo wrote:

done

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


[Lldb-commits] [lldb] Define Telemetry plugin for LLDB. (PR #126588)

2025-02-13 Thread Vy Nguyen via lldb-commits


@@ -0,0 +1,13 @@
+if (LLVM_BUILD_TELEMETRY)
+  add_lldb_library(lldbPluginTelemetryFakePlugin PLUGIN
+   FakePlugin.cpp
+
+  LINK_LIBS
+lldbCore
+lldbUtility
+lldbPluginProcessUtility
+  LINK_COMPONENTS
+Support
+Telemetry   
+  )

oontvoo wrote:

done

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


[Lldb-commits] [lldb] Define Telemetry plugin for LLDB. (PR #126588)

2025-02-13 Thread Vy Nguyen via lldb-commits


@@ -59,11 +60,21 @@ struct LLDBBaseTelemetryInfo : public 
llvm::telemetry::TelemetryInfo {
 /// The base Telemetry manager instance in LLDB
 /// This class declares additional instrumentation points
 /// applicable to LLDB.
-class TelemetryManager : public llvm::telemetry::Manager {
+class TelemetryManager : public llvm::telemetry::Manager,
+ public PluginInterface {
 public:
+  llvm::Error preDispatch(llvm::telemetry::TelemetryInfo *entry) override;
+
+  // Plugin interface
+  llvm::StringRef GetPluginName() override { return "TelemetryManager"; }
+
+  static TelemetryManager *getInstance();
+
+protected:
   TelemetryManager(std::unique_ptr config);
 
-  llvm::Error preDispatch(llvm::telemetry::TelemetryInfo *entry) override;
+  static std::unique_ptr g_instance;

oontvoo wrote:

done

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


[Lldb-commits] [clang] [libc] [libcxx] [lldb] [llvm] [doc] Add Discord invite link alongside channel links (PR #126352)

2025-02-13 Thread Alex Bradbury via lldb-commits

https://github.com/asb updated https://github.com/llvm/llvm-project/pull/126352

>From 446b59bd47eb5356454665eeb82e75a77862350a Mon Sep 17 00:00:00 2001
From: Alex Bradbury 
Date: Sat, 8 Feb 2025 06:27:26 +
Subject: [PATCH 1/2] [doc] Add Discord invite link alongside channel links

By far the most important part of this patch is updating
GettingInvolved.rst to include the invite link, but I've grepped for
any other discord.com links.

I'm no Discord expert, but from my experience (confirmed via @preames
kindly testing as well) the direct channel links provide a confusing
experience if you haven't already found and used an invite link to the
LLVM Discord server. If you're logged into Discord, the web app opens
and then...nothing. No prompt to join the server or even a hint that you
need to find an invite link (and if you're not used to Discord, you may
not even know that's necessary).

This patch addresses the issue by providing the invite link where
Discord is mentioned.
---
 clang/www/OpenProjects.html   | 2 +-
 libc/docs/index.rst   | 3 ++-
 libcxx/docs/index.rst | 2 +-
 lldb/docs/index.rst   | 3 ++-
 llvm/docs/GettingInvolved.rst | 2 +-
 5 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/clang/www/OpenProjects.html b/clang/www/OpenProjects.html
index a9efdb8d762d7..6e32488b47b33 100755
--- a/clang/www/OpenProjects.html
+++ b/clang/www/OpenProjects.html
@@ -149,7 +149,7 @@ Open Clang Projects
 If you hit a bug with Clang, it is very useful for us if you reduce the code
 that demonstrates the problem down to something small. There are many ways to
 do this; ask on https://discourse.llvm.org/c/clang";>Discourse,
-https://discord.com/channels/636084430946959380/636725486533345280";>Discord
+https://discord.gg/xS7Z362";>Discord
 for advice.
 
 
diff --git a/libc/docs/index.rst b/libc/docs/index.rst
index 12dcba27a906b..f0e5c9db79b40 100644
--- a/libc/docs/index.rst
+++ b/libc/docs/index.rst
@@ -12,7 +12,8 @@ The LLVM C Library
   LLVM-libc is not fully complete right now. Some programs may fail to build 
due
   to missing functions. If you would like to help us finish LLVM-libc, check
   out "`Contributing to the libc project `__" in the sidebar
-  or ask on `discord 
`__.
+  or ask on `discord 
`__
+  (`invite link `__).
 
 Introduction
 
diff --git a/libcxx/docs/index.rst b/libcxx/docs/index.rst
index 37912e9f8d03e..53c6b84c22ea7 100644
--- a/libcxx/docs/index.rst
+++ b/libcxx/docs/index.rst
@@ -242,5 +242,5 @@ Quick Links
 * `LLVM Bug Tracker `_
 * `libcxx-commits Mailing List 
`_
 * `libc++ forum `_
-* `libc++ chat 
`_
+* `libc++ chat 
`_ (`invite 
link `_)
 * `Browse libc++ Sources 
`_
diff --git a/lldb/docs/index.rst b/lldb/docs/index.rst
index 5686a33e94c93..1ffdb08a1ca2c 100644
--- a/lldb/docs/index.rst
+++ b/lldb/docs/index.rst
@@ -182,7 +182,8 @@ interesting areas to contribute to lldb.
 
Source Code 
Releases 
-   Discord 
+   Join the Discord 
+   Discord Channel 

Discussion Forums 
Developer Policy 
Bug Reports 

diff --git a/llvm/docs/GettingInvolved.rst b/llvm/docs/GettingInvolved.rst
index 99e8d1e467384..d3663491766c2 100644
--- a/llvm/docs/GettingInvolved.rst
+++ b/llvm/docs/GettingInvolved.rst
@@ -392,7 +392,7 @@ Discord
 ---
 
 Users and developers of the LLVM project (including subprojects such as Clang)
-can be found on the community's `Discord 
`_
+can be found on the community's `Discord `_
 chat server. The server is actively moderated.
 
 The #buildbot-status channel has a bot for

>From 61fca1c2a58a1b649fbaeb5ce3489b42305b9651 Mon Sep 17 00:00:00 2001
From: Alex Bradbury 
Date: Thu, 13 Feb 2025 14:58:04 +
Subject: [PATCH 2/2] Keep channel link alongside invite link in clang open
 projects page

---
 clang/www/OpenProjects.html | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/clang/www/OpenProjects.html b/clang/www/OpenProjects.html
index 6e32

[Lldb-commits] [clang] [libc] [libcxx] [lldb] [llvm] [doc] Add Discord invite link alongside channel links (PR #126352)

2025-02-13 Thread Alex Bradbury via lldb-commits

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


[Lldb-commits] [lldb] [lldb] Use LLDB_LOG_ERROR in ObjectFilePECOFF.cpp (NFC) (PR #126972)

2025-02-13 Thread Dave Lee via lldb-commits

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


[Lldb-commits] [lldb] 277cb60 - [lldb] Use LLDB_LOG_ERROR in ObjectFilePECOFF.cpp (NFC) (#126972)

2025-02-13 Thread via lldb-commits

Author: Dave Lee
Date: 2025-02-13T07:03:00-08:00
New Revision: 277cb60d9ab4335bcc6aef4366278e1500237d2c

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

LOG: [lldb] Use LLDB_LOG_ERROR in ObjectFilePECOFF.cpp (NFC) (#126972)

Added: 


Modified: 
lldb/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp

Removed: 




diff  --git a/lldb/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp 
b/lldb/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp
index 6d92a204b86cc..609968bf0bde2 100644
--- a/lldb/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp
+++ b/lldb/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp
@@ -861,14 +861,9 @@ ObjectFilePECOFF::AppendFromExportTable(SectionList 
*sect_list,
   for (const auto &entry : m_binary->export_directories()) {
 llvm::StringRef sym_name;
 if (auto err = entry.getSymbolName(sym_name)) {
-  if (log)
-log->Format(
-__FILE__, __func__,
-"ObjectFilePECOFF::AppendFromExportTable - failed to get export "
-"table entry name: {0}",
-llvm::fmt_consume(std::move(err)));
-  else
-llvm::consumeError(std::move(err));
+  LLDB_LOG_ERROR(log, std::move(err),
+ "ObjectFilePECOFF::AppendFromExportTable - failed to get "
+ "export table entry name: {0}");
   continue;
 }
 Symbol symbol;
@@ -886,13 +881,10 @@ ObjectFilePECOFF::AppendFromExportTable(SectionList 
*sect_list,
   // it in symtab and make a note using the symbol name.
   llvm::StringRef forwarder_name;
   if (auto err = entry.getForwardTo(forwarder_name)) {
-if (log)
-  log->Format(__FILE__, __func__,
-  "ObjectFilePECOFF::AppendFromExportTable - failed to get 
"
-  "forwarder name of forwarder export '{0}': {1}",
-  sym_name, llvm::fmt_consume(std::move(err)));
-else
-  llvm::consumeError(std::move(err));
+LLDB_LOG_ERROR(log, std::move(err),
+   "ObjectFilePECOFF::AppendFromExportTable - failed to "
+   "get forwarder name of forwarder export '{1}': {0}",
+   sym_name);
 continue;
   }
   llvm::SmallString<256> new_name = 
{symbol.GetDisplayName().GetStringRef(),
@@ -904,13 +896,10 @@ ObjectFilePECOFF::AppendFromExportTable(SectionList 
*sect_list,
 
 uint32_t function_rva;
 if (auto err = entry.getExportRVA(function_rva)) {
-  if (log)
-log->Format(__FILE__, __func__,
-"ObjectFilePECOFF::AppendFromExportTable - failed to get "
-"address of export entry '{0}': {1}",
-sym_name, llvm::fmt_consume(std::move(err)));
-  else
-llvm::consumeError(std::move(err));
+  LLDB_LOG_ERROR(log, std::move(err),
+ "ObjectFilePECOFF::AppendFromExportTable - failed to get "
+ "address of export entry '{1}': {0}",
+ sym_name);
   continue;
 }
 // Skip the symbol if it doesn't look valid.



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


[Lldb-commits] [lldb] [lldb] Avoid expression evaluation in the std::deque formatter (PR #127071)

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

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

It's slower and it can fail in contexts where expression evaluation doesn't 
work.

>From 0bed8bfb406208b1934a5dc2c538e40891d86e1d Mon Sep 17 00:00:00 2001
From: Pavel Labath 
Date: Thu, 13 Feb 2025 16:09:36 +0100
Subject: [PATCH] [lldb] Avoid expression evaluation in the std::deque
 formatter

It's slower and it can fail in contexts where expression evaluation
doesn't work.
---
 lldb/examples/synthetic/libcxx.py | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/lldb/examples/synthetic/libcxx.py 
b/lldb/examples/synthetic/libcxx.py
index 7a71556e779df..5abeb3061f4f5 100644
--- a/lldb/examples/synthetic/libcxx.py
+++ b/lldb/examples/synthetic/libcxx.py
@@ -694,6 +694,13 @@ def get_child_index(self, name):
 except:
 return -1
 
+@staticmethod
+def _subscript(ptr: lldb.SBValue, idx: int, name: str) -> lldb.SBValue:
+"""Access a pointer value as if it was an array. Returns ptr[idx]."""
+deref_t = ptr.GetType().GetPointeeType()
+offset = idx * deref_t.GetByteSize()
+return ptr.CreateChildAtOffset(name, offset, deref_t)
+
 def get_child_at_index(self, index):
 logger = lldb.formatters.Logger.Logger()
 logger.write("Fetching child " + str(index))
@@ -703,11 +710,8 @@ def get_child_at_index(self, index):
 return None
 try:
 i, j = divmod(self.start + index, self.block_size)
-
-return self.first.CreateValueFromExpression(
-"[" + str(index) + "]",
-"*(*(%s + %d) + %d)" % (self.map_begin.get_expr_path(), i, j),
-)
+val = stddeque_SynthProvider._subscript(self.map_begin, i, "")
+return stddeque_SynthProvider._subscript(val, j, f"[{index}]")
 except:
 return None
 

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


[Lldb-commits] [lldb] [lldb] Avoid expression evaluation in the std::deque formatter (PR #127071)

2025-02-13 Thread via lldb-commits

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Pavel Labath (labath)


Changes

It's slower and it can fail in contexts where expression evaluation doesn't 
work.

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


1 Files Affected:

- (modified) lldb/examples/synthetic/libcxx.py (+9-5) 


``diff
diff --git a/lldb/examples/synthetic/libcxx.py 
b/lldb/examples/synthetic/libcxx.py
index 7a71556e779df..5abeb3061f4f5 100644
--- a/lldb/examples/synthetic/libcxx.py
+++ b/lldb/examples/synthetic/libcxx.py
@@ -694,6 +694,13 @@ def get_child_index(self, name):
 except:
 return -1
 
+@staticmethod
+def _subscript(ptr: lldb.SBValue, idx: int, name: str) -> lldb.SBValue:
+"""Access a pointer value as if it was an array. Returns ptr[idx]."""
+deref_t = ptr.GetType().GetPointeeType()
+offset = idx * deref_t.GetByteSize()
+return ptr.CreateChildAtOffset(name, offset, deref_t)
+
 def get_child_at_index(self, index):
 logger = lldb.formatters.Logger.Logger()
 logger.write("Fetching child " + str(index))
@@ -703,11 +710,8 @@ def get_child_at_index(self, index):
 return None
 try:
 i, j = divmod(self.start + index, self.block_size)
-
-return self.first.CreateValueFromExpression(
-"[" + str(index) + "]",
-"*(*(%s + %d) + %d)" % (self.map_begin.get_expr_path(), i, j),
-)
+val = stddeque_SynthProvider._subscript(self.map_begin, i, "")
+return stddeque_SynthProvider._subscript(val, j, f"[{index}]")
 except:
 return None
 

``




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


[Lldb-commits] [lldb] [lldb] Avoid expression evaluation in the std::deque formatter (PR #127071)

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

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


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


[Lldb-commits] [lldb] db2953d - [doc] Add Discord invite link alongside channel links (#126352)

2025-02-13 Thread via lldb-commits

Author: Alex Bradbury
Date: 2025-02-13T15:00:21Z
New Revision: db2953d80148870ee22b0ffaed883a02174485c4

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

LOG: [doc] Add Discord invite link alongside channel links (#126352)

By far the most important part of this patch is updating
GettingInvolved.rst to include the invite link, but I've grepped for any
other discord.com links.

I'm no Discord expert, but from my experience (confirmed via @preames
kindly testing as well) the direct channel links provide a confusing
experience if you haven't already found and used an invite link to the
LLVM Discord server. If you're logged into Discord but not a member of
LLVM's sever, the web app opens and then...nothing. No channel opens, no
prompt to join the server or even a hint that you need to find an invite
link (and if you're not used to Discord, you likely don't even know
that's necessary).

This patch addresses the issue by providing the invite link where
Discord is mentioned.

Added: 


Modified: 
clang/www/OpenProjects.html
libc/docs/index.rst
libcxx/docs/index.rst
lldb/docs/index.rst
llvm/docs/GettingInvolved.rst

Removed: 




diff  --git a/clang/www/OpenProjects.html b/clang/www/OpenProjects.html
index a9efdb8d762d7..ae0ec1d4d12cb 100755
--- a/clang/www/OpenProjects.html
+++ b/clang/www/OpenProjects.html
@@ -150,7 +150,7 @@ Open Clang Projects
 that demonstrates the problem down to something small. There are many ways to
 do this; ask on https://discourse.llvm.org/c/clang";>Discourse,
 https://discord.com/channels/636084430946959380/636725486533345280";>Discord
-for advice.
+(https://discord.gg/xS7Z362";>invite link) for advice.
 
 
 

diff  --git a/libc/docs/index.rst b/libc/docs/index.rst
index 12dcba27a906b..f0e5c9db79b40 100644
--- a/libc/docs/index.rst
+++ b/libc/docs/index.rst
@@ -12,7 +12,8 @@ The LLVM C Library
   LLVM-libc is not fully complete right now. Some programs may fail to build 
due
   to missing functions. If you would like to help us finish LLVM-libc, check
   out "`Contributing to the libc project `__" in the sidebar
-  or ask on `discord 
`__.
+  or ask on `discord 
`__
+  (`invite link `__).
 
 Introduction
 

diff  --git a/libcxx/docs/index.rst b/libcxx/docs/index.rst
index 37912e9f8d03e..53c6b84c22ea7 100644
--- a/libcxx/docs/index.rst
+++ b/libcxx/docs/index.rst
@@ -242,5 +242,5 @@ Quick Links
 * `LLVM Bug Tracker `_
 * `libcxx-commits Mailing List 
`_
 * `libc++ forum `_
-* `libc++ chat 
`_
+* `libc++ chat 
`_ (`invite 
link `_)
 * `Browse libc++ Sources 
`_

diff  --git a/lldb/docs/index.rst b/lldb/docs/index.rst
index 5686a33e94c93..1ffdb08a1ca2c 100644
--- a/lldb/docs/index.rst
+++ b/lldb/docs/index.rst
@@ -182,7 +182,8 @@ interesting areas to contribute to lldb.
 
Source Code 
Releases 
-   Discord 
+   Join the Discord 
+   Discord Channel 

Discussion Forums 
Developer Policy 
Bug Reports 


diff  --git a/llvm/docs/GettingInvolved.rst b/llvm/docs/GettingInvolved.rst
index 99e8d1e467384..d3663491766c2 100644
--- a/llvm/docs/GettingInvolved.rst
+++ b/llvm/docs/GettingInvolved.rst
@@ -392,7 +392,7 @@ Discord
 ---
 
 Users and developers of the LLVM project (including subprojects such as Clang)
-can be found on the community's `Discord 
`_
+can be found on the community's `Discord `_
 chat server. The server is actively moderated.
 
 The #buildbot-status channel has a bot for



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


[Lldb-commits] [clang] [lldb] [lldb] Analyze enum promotion type during parsing (PR #115005)

2025-02-13 Thread Ilia Kuklin via lldb-commits

https://github.com/kuilpd updated 
https://github.com/llvm/llvm-project/pull/115005

>From dd65babbf4c73a0b2fc2e4aa47a9a346bd5a9adf Mon Sep 17 00:00:00 2001
From: Ilia Kuklin 
Date: Mon, 4 Nov 2024 14:33:45 +0500
Subject: [PATCH 01/15] [lldb] Analyze enum promotion type during parsing

---
 clang/include/clang/AST/Decl.h|  2 +-
 .../SymbolFile/DWARF/DWARFASTParserClang.cpp  | 93 +++
 .../TypeSystem/Clang/TypeSystemClang.cpp  | 25 +
 3 files changed, 97 insertions(+), 23 deletions(-)

diff --git a/clang/include/clang/AST/Decl.h b/clang/include/clang/AST/Decl.h
index f305cbbce4c60..177f7df5bfee8 100644
--- a/clang/include/clang/AST/Decl.h
+++ b/clang/include/clang/AST/Decl.h
@@ -3910,6 +3910,7 @@ class EnumDecl : public TagDecl {
   void setInstantiationOfMemberEnum(ASTContext &C, EnumDecl *ED,
 TemplateSpecializationKind TSK);
 
+public:
   /// Sets the width in bits required to store all the
   /// non-negative enumerators of this enum.
   void setNumPositiveBits(unsigned Num) {
@@ -3921,7 +3922,6 @@ class EnumDecl : public TagDecl {
   /// negative enumerators of this enum. (see getNumNegativeBits)
   void setNumNegativeBits(unsigned Num) { EnumDeclBits.NumNegativeBits = Num; }
 
-public:
   /// True if this tag declaration is a scoped enumeration. Only
   /// possible in C++11 mode.
   void setScoped(bool Scoped = true) { EnumDeclBits.IsScoped = Scoped; }
diff --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
index ec0004c70c6da..f8678909ce732 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
@@ -2315,6 +2315,8 @@ size_t DWARFASTParserClang::ParseChildEnumerators(
 return 0;
 
   size_t enumerators_added = 0;
+  unsigned NumNegativeBits = 0;
+  unsigned NumPositiveBits = 0;
 
   for (DWARFDIE die : parent_die.children()) {
 const dw_tag_t tag = die.Tag();
@@ -2367,8 +2369,99 @@ size_t DWARFASTParserClang::ParseChildEnumerators(
   m_ast.AddEnumerationValueToEnumerationType(
   clang_type, decl, name, *enum_value, enumerator_byte_size * 8);
   ++enumerators_added;
+
+  llvm::APSInt InitVal = ECD->getInitVal();
+  // Keep track of the size of positive and negative values.
+  if (InitVal.isUnsigned() || InitVal.isNonNegative()) {
+// If the enumerator is zero that should still be counted as a positive
+// bit since we need a bit to store the value zero.
+unsigned ActiveBits = InitVal.getActiveBits();
+NumPositiveBits = std::max({NumPositiveBits, ActiveBits, 1u});
+  } else {
+NumNegativeBits =
+std::max(NumNegativeBits, (unsigned)InitVal.getSignificantBits());
+  }
 }
   }
+
+  /// The following code follows the same logic as in Sema::ActOnEnumBody
+  /// clang/lib/Sema/SemaDecl.cpp
+  // If we have an empty set of enumerators we still need one bit.
+  // From [dcl.enum]p8
+  // If the enumerator-list is empty, the values of the enumeration are as if
+  // the enumeration had a single enumerator with value 0
+  if (!NumPositiveBits && !NumNegativeBits)
+NumPositiveBits = 1;
+
+  clang::QualType qual_type(ClangUtil::GetQualType(clang_type));
+  clang::EnumDecl *enum_decl = qual_type->getAs()->getDecl();
+  enum_decl->setNumPositiveBits(NumPositiveBits);
+  enum_decl->setNumNegativeBits(NumNegativeBits);
+
+  // C++0x N3000 [conv.prom]p3:
+  //   An rvalue of an unscoped enumeration type whose underlying
+  //   type is not fixed can be converted to an rvalue of the first
+  //   of the following types that can represent all the values of
+  //   the enumeration: int, unsigned int, long int, unsigned long
+  //   int, long long int, or unsigned long long int.
+  // C99 6.4.4.3p2:
+  //   An identifier declared as an enumeration constant has type int.
+  // The C99 rule is modified by C23.
+  clang::QualType BestPromotionType;
+  unsigned BestWidth;
+
+  auto &Context = m_ast.getASTContext();
+  unsigned LongWidth = Context.getTargetInfo().getLongWidth();
+  unsigned IntWidth = Context.getTargetInfo().getIntWidth();
+  unsigned CharWidth = Context.getTargetInfo().getCharWidth();
+  unsigned ShortWidth = Context.getTargetInfo().getShortWidth();
+
+  bool is_cpp = Language::LanguageIsCPlusPlus(
+  SymbolFileDWARF::GetLanguage(*parent_die.GetCU()));
+
+  if (NumNegativeBits) {
+// If there is a negative value, figure out the smallest integer type (of
+// int/long/longlong) that fits.
+if (NumNegativeBits <= CharWidth && NumPositiveBits < CharWidth) {
+  BestWidth = CharWidth;
+} else if (NumNegativeBits <= ShortWidth && NumPositiveBits < ShortWidth) {
+  BestWidth = ShortWidth;
+} else if (NumNegativeBits <= IntWidth && NumPositiveBits < IntWidth) {
+  BestWidth = IntWidth;
+} else if (NumNegativeBits <= LongWidth && NumPosit

[Lldb-commits] [clang] [lldb] [lldb] Analyze enum promotion type during parsing (PR #115005)

2025-02-13 Thread Ilia Kuklin via lldb-commits

kuilpd wrote:

@Michael137 
Thank you for seeing this through!

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


[Lldb-commits] [lldb] [lldb] Synchronize the debugger's stdout and stderr streams (PR #126630)

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

https://github.com/labath commented:

Mostly yes. It's not as clean as I would have liked, though I suppose that is 
to be expected of an attempt to retrofit a significant change like this. The 
existence of Debugger::Get{Output,Error}File in particular is a very large hole 
in the RAII locking scheme. From the looks of things, none of the uses of these 
functions (GetErrorFile is unused already) is particularly load-bearing and 
they could be replaced by something else (but don't do that here, as the patch 
is big enough already).

The RAII thing doesn't make things much safer than the original implementation 
did because the Printf currently translate to a single `Write` call anyway, but 
they are more future-proof, as I can easily see someone "modernising" them into 
a `Format` call and then someone else "optimizing" our `Format` implementation 
to use the llvm raw_ostream method (which does *not* use a single write call). 
The current implementation will work even with those changes.

I do want to spend some time discussing the relationship between stdout and 
stderr. The current implementation uses a separate mutex for each stream, which 
is not *un*reasonable, but I can see at least two other possible philosophies:

1. Since both of the streams will be going to the same terminal most of the 
time, it might make sense to use a single mutex for both of them, as that's 
sort of the only way to ensure consistent output. (Imagine the situation of 
printing the "stderr" of a CLI command while the status line is being updated)
2. Alternatively, we could say that stderr is for immediate and exceptional 
output where it is more important to get the message to the user than it being 
formatted beautifully. In this world, we could keep "stderr" as a regular 
unlocked stream. In specific cases, where synchronizing the output is 
particularly important to us (like the beforementioned case of "stderr" of a 
CLI command) we could synchronize its output by holding the "stdout" mutex 
while writing it.

What do you think of that? I'm sort of leaning towards option two since stderr 
might be used in contexts where holding a mutex might not be completely safe 
(and the first option would make that even worse), and the current 
implementation with separate mutexes doesn't really guarantee "reasonable" 
stdout/err sequencing.

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


[Lldb-commits] [lldb] [lldb] Synchronize the debugger's stdout and stderr streams (PR #126630)

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


@@ -574,10 +581,10 @@ int Editline::GetCharacter(EditLineGetCharType *c) {
 // indefinitely. This gives a chance for someone to interrupt us. After
 // Read returns, immediately lock the mutex again and check if we were
 // interrupted.
-m_output_mutex.unlock();
+m_output_stream_sp->GetMutex().unlock();

labath wrote:

What would you say if, instead of exposing rather non-RAII method on the 
generic class, we worked around this issue (the issue being us wanting to put 
libedit code in a critical section) locally, by having something like 
`std::optional m_locked_output` member on the editline class? 
GetLine could set this member when doing its work, and here we would clear it 
before blocking, and re-set it immediately afterwards.

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


[Lldb-commits] [lldb] [lldb] Synchronize the debugger's stdout and stderr streams (PR #126630)

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


@@ -500,19 +502,16 @@ bool 
CommandObjectExpression::EvaluateExpression(llvm::StringRef expr,
 void CommandObjectExpression::IOHandlerInputComplete(IOHandler &io_handler,
  std::string &line) {
   io_handler.SetIsDone(true);
-  StreamFileSP output_sp = io_handler.GetOutputStreamFileSP();
-  StreamFileSP error_sp = io_handler.GetErrorStreamFileSP();
+  LockedStreamFile locked_output_stream =
+  io_handler.GetOutputStreamFileSP()->Lock();
+  LockedStreamFile locked_error_stream =
+  io_handler.GetErrorStreamFileSP()->Lock();

labath wrote:

We probably don't want to hold this locked while the expression is being 
evaluated. (Although I also don't know why does this function take streams to 
begin with. It seems like it could just print everything into the return 
object).

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


[Lldb-commits] [lldb] [lldb] Synchronize the debugger's stdout and stderr streams (PR #126630)

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


@@ -700,12 +707,14 @@ unsigned char Editline::EndOrAddLineCommand(int ch) {
 }
   }
   MoveCursor(CursorLocation::EditingCursor, CursorLocation::BlockEnd);
-  fprintf(m_output_file, "\n");
+  LockedStreamFile locked_stream = m_output_stream_sp->Lock();

labath wrote:

And I suspect most/all of these callbacks are called from `GetLine` which means 
that they could reuse the `locked_stream` member instead of locking it once 
again.

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


[Lldb-commits] [lldb] [lldb] Synchronize the debugger's stdout and stderr streams (PR #126630)

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


@@ -193,10 +193,12 @@ are no syntax errors may indicate that a function was 
declared but never called.
   Options *GetOptions() override { return &m_all_options; }
 
   void IOHandlerActivated(IOHandler &io_handler, bool interactive) override {
-StreamFileSP output_sp(io_handler.GetOutputStreamFileSP());
-if (output_sp && interactive) {
-  output_sp->PutCString(g_reader_instructions);
-  output_sp->Flush();
+if (interactive) {
+  if (lldb::LockableStreamFileSP output_sp =
+  io_handler.GetOutputStreamFileSP()) {
+LockedStreamFile locked_stream = output_sp->Lock();
+locked_stream.PutCString(g_reader_instructions);
+  }

labath wrote:

Optional, but I think it would be reasonable to write all of these "simple" 
lock calls as one-liners like this
```suggestion
  io_handler.GetOutputStreamFileSP())
output_sp->Lock().PutCString(g_reader_instructions);
```

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


[Lldb-commits] [lldb] 3ad8657 - [lldb][SBAPI] Add new SBType::GetTemplateParameterValue API (#126901)

2025-02-13 Thread via lldb-commits

Author: Michael Buch
Date: 2025-02-13T09:53:17Z
New Revision: 3ad8657ff60b9967235ad65fdb8b767aae0e799d

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

LOG: [lldb][SBAPI] Add new SBType::GetTemplateParameterValue API (#126901)

This patch adds a new API to `SBType` to retrieve the value of a
template parameter given an index. We re-use the
`TypeSystemClang::GetIntegralTemplateArgument` for this and thus
currently only supports integral non-type template parameters. Types
like float/double are not supported yet.

rdar://144395216

Added: 


Modified: 
lldb/include/lldb/API/SBTarget.h
lldb/include/lldb/API/SBType.h
lldb/include/lldb/API/SBValue.h
lldb/source/API/SBType.cpp
lldb/test/API/lang/cpp/class-template-parameter-pack/TestTemplatePackArgs.py
lldb/test/API/lang/cpp/template-arguments/Makefile
lldb/test/API/lang/cpp/template-arguments/TestCppTemplateArguments.py
lldb/test/API/lang/cpp/template-arguments/main.cpp

Removed: 




diff  --git a/lldb/include/lldb/API/SBTarget.h 
b/lldb/include/lldb/API/SBTarget.h
index 9b97359d49cf9..bb912ab41d0fe 100644
--- a/lldb/include/lldb/API/SBTarget.h
+++ b/lldb/include/lldb/API/SBTarget.h
@@ -964,6 +964,7 @@ class LLDB_API SBTarget {
   friend class SBSection;
   friend class SBSourceManager;
   friend class SBSymbol;
+  friend class SBType;
   friend class SBTypeStaticField;
   friend class SBValue;
   friend class SBVariablesOptions;

diff  --git a/lldb/include/lldb/API/SBType.h b/lldb/include/lldb/API/SBType.h
index 63ba91082d576..9ad3244686328 100644
--- a/lldb/include/lldb/API/SBType.h
+++ b/lldb/include/lldb/API/SBType.h
@@ -221,6 +221,13 @@ class SBType {
 
   lldb::SBType GetTemplateArgumentType(uint32_t idx);
 
+  /// Returns the value of the non-type template parameter at index \c idx.
+  /// If \c idx is out-of-bounds or the template parameter doesn't have
+  /// a value, returns an empty SBValue.
+  ///
+  /// This function will expand parameter packs.
+  lldb::SBValue GetTemplateArgumentValue(lldb::SBTarget target, uint32_t idx);
+
   /// Return the TemplateArgumentKind of the template argument at index idx.
   /// Variadic argument packs are automatically expanded.
   lldb::TemplateArgumentKind GetTemplateArgumentKind(uint32_t idx);

diff  --git a/lldb/include/lldb/API/SBValue.h b/lldb/include/lldb/API/SBValue.h
index 9090cece80f7c..46ef6daa95264 100644
--- a/lldb/include/lldb/API/SBValue.h
+++ b/lldb/include/lldb/API/SBValue.h
@@ -446,6 +446,7 @@ class LLDB_API SBValue {
   friend class SBModule;
   friend class SBTarget;
   friend class SBThread;
+  friend class SBType;
   friend class SBTypeStaticField;
   friend class SBTypeSummary;
   friend class SBValueList;

diff  --git a/lldb/source/API/SBType.cpp b/lldb/source/API/SBType.cpp
index 4cc16c64e4756..6401d32c85795 100644
--- a/lldb/source/API/SBType.cpp
+++ b/lldb/source/API/SBType.cpp
@@ -687,6 +687,42 @@ lldb::TemplateArgumentKind 
SBType::GetTemplateArgumentKind(uint32_t idx) {
   return eTemplateArgumentKindNull;
 }
 
+lldb::SBValue SBType::GetTemplateArgumentValue(lldb::SBTarget target,
+   uint32_t idx) {
+  LLDB_INSTRUMENT_VA(this, target, idx);
+
+  if (!IsValid())
+return {};
+
+  std::optional arg;
+  const bool expand_pack = true;
+  switch (GetTemplateArgumentKind(idx)) {
+  case eTemplateArgumentKindIntegral:
+arg = m_opaque_sp->GetCompilerType(false).GetIntegralTemplateArgument(
+idx, expand_pack);
+break;
+  default:
+break;
+  }
+
+  if (!arg)
+return {};
+
+  Scalar value{arg->value};
+  DataExtractor data;
+  value.GetData(data);
+
+  ExecutionContext exe_ctx;
+  auto target_sp = target.GetSP();
+  if (!target_sp)
+return {};
+
+  target_sp->CalculateExecutionContext(exe_ctx);
+
+  return ValueObject::CreateValueObjectFromData("value", data, exe_ctx,
+arg->type);
+}
+
 SBType SBType::FindDirectNestedType(const char *name) {
   LLDB_INSTRUMENT_VA(this, name);
 

diff  --git 
a/lldb/test/API/lang/cpp/class-template-parameter-pack/TestTemplatePackArgs.py 
b/lldb/test/API/lang/cpp/class-template-parameter-pack/TestTemplatePackArgs.py
index c571357ff6720..f2467cbea9439 100644
--- 
a/lldb/test/API/lang/cpp/class-template-parameter-pack/TestTemplatePackArgs.py
+++ 
b/lldb/test/API/lang/cpp/class-template-parameter-pack/TestTemplatePackArgs.py
@@ -11,7 +11,7 @@
 class TemplatePackArgsTestCase(TestBase):
 def test_template_argument_pack(self):
 self.build()
-(_, _, thread, _) = lldbutil.run_to_source_breakpoint(
+(target, _, thread, _) = lldbutil.run_to_source_breakpoint(
 self, "breakpoint here", lldb.SBFileSpec("main.cpp"), 
exe_name="a.out"
 )
 frame =

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

2025-02-13 Thread via lldb-commits

Author: Pavel Labath
Date: 2025-02-13T10:08:16+01:00
New Revision: 298caebaadc38eadced7175c80ed6b2866755cb9

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

LOG: [lldb] Fix Block::GetRangeIndexContainingAddress for discontinuous 
functions (#124931)

This is a followup to #122440, which changed function-relative
calculations to use the function entry point rather than the lowest
address of the function (but missed this usage). Like in #116777, the
logic is changed to use file addresses instead of section offsets (as
not all parts of the function have to be in the same section).

Added: 


Modified: 
lldb/source/Symbol/Block.cpp
lldb/test/Shell/ScriptInterpreter/Python/sb_function_ranges.s

Removed: 




diff  --git a/lldb/source/Symbol/Block.cpp b/lldb/source/Symbol/Block.cpp
index 139fa06d08fca..6ecc988d7a5a9 100644
--- a/lldb/source/Symbol/Block.cpp
+++ b/lldb/source/Symbol/Block.cpp
@@ -243,25 +243,17 @@ bool Block::GetRangeContainingAddress(const Address &addr,
   AddressRange &range) {
   Function *function = CalculateSymbolContextFunction();
   if (function) {
-const AddressRange &func_range = function->GetAddressRange();
-if (addr.GetModule() == func_range.GetBaseAddress().GetModule()) {
-  const addr_t file_addr = addr.GetFileAddress();
-  const addr_t func_file_addr =
-  func_range.GetBaseAddress().GetFileAddress();
-  if (file_addr >= func_file_addr &&
-  file_addr < func_file_addr + func_range.GetByteSize()) {
-addr_t offset = file_addr - func_file_addr;
-
-const Range *range_ptr = m_ranges.FindEntryThatContains(offset);
-
-if (range_ptr) {
-  range.GetBaseAddress() =
-  Address(func_file_addr + range_ptr->GetRangeBase(),
-  addr.GetModule()->GetSectionList());
-  range.SetByteSize(range_ptr->GetByteSize());
-  return true;
-}
-  }
+if (uint32_t idx = GetRangeIndexContainingAddress(addr);
+idx != UINT32_MAX) {
+  const Range *range_ptr = m_ranges.GetEntryAtIndex(idx);
+  assert(range_ptr);
+
+  Address func_addr = function->GetAddress();
+  range.GetBaseAddress() =
+  Address(func_addr.GetFileAddress() + range_ptr->GetRangeBase(),
+  func_addr.GetModule()->GetSectionList());
+  range.SetByteSize(range_ptr->GetByteSize());
+  return true;
 }
   }
   range.Clear();
@@ -278,19 +270,16 @@ bool Block::GetRangeContainingLoadAddress(lldb::addr_t 
load_addr,
 
 uint32_t Block::GetRangeIndexContainingAddress(const Address &addr) {
   Function *function = CalculateSymbolContextFunction();
-  if (function) {
-const AddressRange &func_range = function->GetAddressRange();
-if (addr.GetSection() == func_range.GetBaseAddress().GetSection()) {
-  const addr_t addr_offset = addr.GetOffset();
-  const addr_t func_offset = func_range.GetBaseAddress().GetOffset();
-  if (addr_offset >= func_offset &&
-  addr_offset < func_offset + func_range.GetByteSize()) {
-addr_t offset = addr_offset - func_offset;
-return m_ranges.FindEntryIndexThatContains(offset);
-  }
-}
-  }
-  return UINT32_MAX;
+  if (!function)
+return UINT32_MAX;
+
+  const Address &func_addr = function->GetAddress();
+  if (addr.GetModule() != func_addr.GetModule())
+return UINT32_MAX;
+
+  const addr_t file_addr = addr.GetFileAddress();
+  const addr_t func_file_addr = func_addr.GetFileAddress();
+  return m_ranges.FindEntryIndexThatContains(file_addr - func_file_addr);
 }
 
 bool Block::GetRangeAtIndex(uint32_t range_idx, AddressRange &range) {

diff  --git a/lldb/test/Shell/ScriptInterpreter/Python/sb_function_ranges.s 
b/lldb/test/Shell/ScriptInterpreter/Python/sb_function_ranges.s
index 2e2bc52cd3ff9..1b15561c54283 100644
--- a/lldb/test/Shell/ScriptInterpreter/Python/sb_function_ranges.s
+++ b/lldb/test/Shell/ScriptInterpreter/Python/sb_function_ranges.s
@@ -6,15 +6,24 @@
 
 # CHECK: Found 1 function(s).
 # CHECK: foo: [input.o[0x0-0xe), input.o[0x14-0x1c)]
-# CHECK-NEXT: input.o[0x0]: cmpl   $0x0, %edi
-# CHECK-NEXT: input.o[0x3]: je 0x14
-# CHECK-NEXT: input.o[0x5]: jmp0x7
-# CHECK-NEXT: input.o[0x7]: callq  0xe
-# CHECK-NEXT: input.o[0xc]: jmp0x1b
+# CHECK-NEXT: input.o[0x0]: callq  0xe
+# CHECK-NEXT: input.o[0x5]: jmp0x1b
+# CHECK-NEXT: input.o[0x7]: cmpl   $0x0, %edi
+# CHECK-NEXT: input.o[0xa]: je 0x14
+# CHECK-NEXT: input.o[0xc]: jmp0x0
 # CHECK-EMPTY:
 # CHECK-NEXT: input.o[0x14]: callq  0x19
 # CHECK-NEXT: input.o[0x19]: jmp0x1b
 # CHECK-NEXT: input.o[0x1b]: retq
+## Testing the GetRangeIndexForBlockAddress API. "" indicates that
+## the address does not belong to any range.
+# CHECK-NE

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

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

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


[Lldb-commits] [lldb] [lldb][SBAPI] Add new SBType::GetTemplateParameterValue API (PR #126901)

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

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


[Lldb-commits] [lldb] Define Telemetry plugin for LLDB. (PR #126588)

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


@@ -0,0 +1,13 @@
+if (LLVM_BUILD_TELEMETRY)
+  add_lldb_library(lldbPluginTelemetryFakePlugin PLUGIN
+   FakePlugin.cpp
+
+  LINK_LIBS
+lldbCore
+lldbUtility
+lldbPluginProcessUtility
+  LINK_COMPONENTS
+Support
+Telemetry   
+  )

labath wrote:

I think this will actually cause the plugin to be linked into the main lldb 
library. We definitely don't want that. There's no need to emulate the plugin 
setup so elaborately. Just define the fake plugin inside `TelemetryTest.cpp`

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


[Lldb-commits] [lldb] Define Telemetry plugin for LLDB. (PR #126588)

2025-02-13 Thread Vy Nguyen via lldb-commits


@@ -0,0 +1,34 @@
+//===-- TestFakePlugin.cpp 
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "lldb/Core/PluginInterface.h"
+#include "lldb/Core/PluginManager.h"
+#include "lldb/Core/Telemetry.h"
+#include "plugin/FakePlugin.h"
+#include "llvm/ADT/StringRef.h"
+#include "llvm/Support/Error.h"
+#include "llvm/Telemetry/Telemetry.h"
+#include "gtest/gtest.h"
+
+#include 
+
+TEST(TelemetryTest, PluginTest) {
+  // This would have been called by the plugin reg in a "real" plugin
+  // For tests, we just call it directly.
+  lldb_private::FakePlugin::Initialize();
+
+  auto ins = lldb_private::telemetry::TelemetryManager::getInstance();
+
+  ASSERT_NE(ins, nullptr);
+  lldb_private::FakeTelemetryInfo entry;
+  entry.msg = "";
+
+  auto stat = ins->preDispatch(&entry);

oontvoo wrote:

> So you don't need to make it public if all you want is overridability 
> (customizability of behavior).
Ok, i'll send a separate PR to move preDispatch to protected.

> That makes sense, but then I also wonder why is `dispatch` virtual, because 
> `preDispatch` is basically equivalent to overriding `dispatch` to do the 
> custom thing and then delegate to base class.

The reason we have `dispatch` do most of the work was to avoid having 
subclasses repeating pretty much the same code (ie., iterating over the list of 
Destinations ... ).  But we made it virtual because it's possible downstream 
implementation want to do the dispatch in some different way (i., parallel ? 
whatnot)






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


[Lldb-commits] [clang] [lldb] [lldb] Analyze enum promotion type during parsing (PR #115005)

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

Michael137 wrote:

FYI on macOS CI this is failing with:
```
FAIL: test_dsym (TestCPPEnumPromotion.TestCPPEnumPromotion)
--
Traceback (most recent call last):
  File 
"/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py",
 line 1784, in test_method
return attrvalue(self)
  File 
"/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/llvm-project/lldb/test/API/lang/cpp/enum_promotion/TestCPPEnumPromotion.py",
 line 28, in test
self.expect_expr("+EnumUChar::UChar", result_type=UChar_promoted.type.name)
  File 
"/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py",
 line 2540, in expect_expr
value_check.check_value(self, eval_result, str(eval_result))
  File 
"/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py",
 line 299, in check_value
test_base.assertSuccess(val.GetError())
  File 
"/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py",
 line 2575, in assertSuccess
self.fail(self._formatMessage(msg, "'{}' is not success".format(error)))
AssertionError: 'error: :1:2: use of undeclared identifier 
'EnumUChar'
1 | +EnumUChar::UChar
  |  ^
' is not success
```

But only for dSYMs. Looking at the `dSYM`, none of the enums are actually 
preserved in the debug-info. You have to actually use the enum types in source 
to get dsymutil to preserve them. I'll fix it

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


[Lldb-commits] [clang] [lldb] [lldb] Analyze enum promotion type during parsing (PR #115005)

2025-02-13 Thread Ilia Kuklin via lldb-commits

kuilpd wrote:

> But only for dSYMs. Looking at the `dSYM`, none of the enums are actually 
> preserved in the debug-info. You have to actually use the enum types in 
> source to get dsymutil to preserve them. I'll fix it

Ah, I see. Thank you for handling this!

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


[Lldb-commits] [lldb] [lldb] Fix build problem in llgs tests for RISC-V (PR #127091)

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

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

Correct according to 
https://gcc.gnu.org/onlinedocs/cpp/_005f_005fhas_005fbuiltin.html, thanks for 
the fix.

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


[Lldb-commits] [lldb] c2e9677 - [lldb-dap] Ensure we do not print the close sentinel when closing stdout. (#126833)

2025-02-13 Thread via lldb-commits

Author: John Harrison
Date: 2025-02-13T10:35:50-08:00
New Revision: c2e96778e04197dd266f7c540bf174b6ec28a434

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

LOG: [lldb-dap] Ensure we do not print the close sentinel when closing stdout. 
(#126833)

If you have an lldb-dap log file you'll almost always see a final
message like:

```
<-- 
Content-Length: 94

{
  "body": {
"category": "stdout",
"output": "\u\u"
  },
  "event": "output",
  "seq": 0,
  "type": "event"
}
<-- 
Content-Length: 94

{
  "body": {
"category": "stderr",
"output": "\u\u"
  },
  "event": "output",
  "seq": 0,
  "type": "event"
}
```

The OutputRedirect is always writing the `"\0"` byte as a final stdout
message during shutdown. Instead, I adjusted this to detect the sentinel
value and break out of the read loop as if we detected EOF.

-

Co-authored-by: Pavel Labath 

Added: 


Modified: 
lldb/test/API/tools/lldb-dap/output/TestDAP_output.py
lldb/test/API/tools/lldb-dap/output/main.c
lldb/tools/lldb-dap/OutputRedirector.cpp
lldb/tools/lldb-dap/OutputRedirector.h

Removed: 




diff  --git a/lldb/test/API/tools/lldb-dap/output/TestDAP_output.py 
b/lldb/test/API/tools/lldb-dap/output/TestDAP_output.py
index 02c34ba10321b..eae7629409844 100644
--- a/lldb/test/API/tools/lldb-dap/output/TestDAP_output.py
+++ b/lldb/test/API/tools/lldb-dap/output/TestDAP_output.py
@@ -10,23 +10,33 @@
 class TestDAP_output(lldbdap_testcase.DAPTestCaseBase):
 @skipIfWindows
 def test_output(self):
+"""
+Test output handling for the running process.
+"""
 program = self.getBuildArtifact("a.out")
-self.build_and_launch(program)
+self.build_and_launch(
+program,
+exitCommands=[
+# Ensure that output produced by lldb itself is not consumed 
by the OutputRedirector.
+"?script print('out\\0\\0', end='\\r\\n', file=sys.stdout)",
+"?script print('err\\0\\0', end='\\r\\n', file=sys.stderr)",
+],
+)
 source = "main.c"
 lines = [line_number(source, "// breakpoint 1")]
 breakpoint_ids = self.set_source_breakpoints(source, lines)
 self.continue_to_breakpoints(breakpoint_ids)
-
+
 # Ensure partial messages are still sent.
 output = self.collect_stdout(timeout_secs=1.0, pattern="abcdef")
-self.assertTrue(output and len(output) > 0, "expect no program output")
+self.assertTrue(output and len(output) > 0, "expect program stdout")
 
 self.continue_to_exit()
-
+
 output += 
self.get_stdout(timeout=lldbdap_testcase.DAPTestCaseBase.timeoutval)
-self.assertTrue(output and len(output) > 0, "expect no program output")
+self.assertTrue(output and len(output) > 0, "expect program stdout")
 self.assertIn(
-"abcdefghi\r\nhello world\r\n",
+"abcdefghi\r\nhello world\r\nfinally\0\0out\0\0\r\nerr\0\0",
 output,
-'full output not found in: ' + output,
+"full stdout not found in: " + repr(output),
 )

diff  --git a/lldb/test/API/tools/lldb-dap/output/main.c 
b/lldb/test/API/tools/lldb-dap/output/main.c
index 0cfcf604aa68f..226cb607a1234 100644
--- a/lldb/test/API/tools/lldb-dap/output/main.c
+++ b/lldb/test/API/tools/lldb-dap/output/main.c
@@ -8,5 +8,8 @@ int main() {
   printf("def");
   printf("ghi\n");
   printf("hello world\n"); // breakpoint 1
+  // Ensure the OutputRedirector does not consume the programs \0\0 output.
+  char buf[] = "finally\0";
+  write(STDOUT_FILENO, buf, sizeof(buf));
   return 0;
 }

diff  --git a/lldb/tools/lldb-dap/OutputRedirector.cpp 
b/lldb/tools/lldb-dap/OutputRedirector.cpp
index a23572ab7ae04..df21fb850dc55 100644
--- a/lldb/tools/lldb-dap/OutputRedirector.cpp
+++ b/lldb/tools/lldb-dap/OutputRedirector.cpp
@@ -10,6 +10,7 @@
 #include "DAP.h"
 #include "llvm/ADT/StringRef.h"
 #include "llvm/Support/Error.h"
+#include 
 #include 
 #if defined(_WIN32)
 #include 
@@ -18,12 +19,9 @@
 #include 
 #endif
 
-using lldb_private::Pipe;
-using llvm::createStringError;
-using llvm::Error;
-using llvm::Expected;
-using llvm::inconvertibleErrorCode;
-using llvm::StringRef;
+using namespace llvm;
+
+static constexpr auto kCloseSentinel = StringLiteral::withInnerNUL("\0");
 
 namespace lldb_dap {
 
@@ -58,9 +56,6 @@ Error 
OutputRedirector::RedirectTo(std::function callback) {
 char buffer[OutputBufferSize];
 while (!m_stopped) {
   ssize_t bytes_count = ::read(read_fd, &buffer, sizeof(buffer));
-  // EOF detected.
-  if (bytes_count == 0)
-break;
   if (bytes_count == -1) {
 // Skip non-fatal errors.
 if (errno == EA

[Lldb-commits] [lldb] [lldb-dap] Ensure we do not print the close sentinel when closing stdout. (PR #126833)

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

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


[Lldb-commits] [lldb] Define Telemetry plugin for LLDB. (PR #126588)

2025-02-13 Thread Vy Nguyen via lldb-commits

oontvoo wrote:

> Based on the title of this PR I was expecting something slightly different, 
> so maybe I'm missing something. But if we want to make this an LLDB plugin 
> (which I agree we should ), I would expect the `PluginManager` to manage the 
> instance rather than the plugin doing itself. With the current patch, I don't 
> see how you're taking advantage of it being a plugin.
> 
> In the `PluginInterface`, I would expect a `Create` instance, something like 
> this:
 
> ```

This was what we were doing in the [initial 
PR](https://github.com/llvm/llvm-project/pull/98528/files#diff-20a2060f8e87c6742d6f2c7ae97e919f8485995d7808bd9fccbfbede697a9ec7)
  but Pavel had correctly pointed out that the architecture was unnecessarily 
"baroque". GIven there will be only one instance of the TelemetrManager at a 
time and that we will not be creating a new manager on the fly, none of those 
complex hooks are necessary.

Instead, we just need the downstream implemntation to register its instance 
(via the setInstance()).
Then the rest of (upstream) LLDB code, which uses the Telemetry, would just do 
`TelemetryManager::getInstance()`.



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


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

2025-02-13 Thread via lldb-commits

https://github.com/kper updated https://github.com/llvm/llvm-project/pull/124475

>From 7d97df1b70d6d648992f9af2f4211768d3a14aa5 Mon Sep 17 00:00:00 2001
From: Kevin Per 
Date: Sun, 26 Jan 2025 17:34:17 +
Subject: [PATCH] lldb: Extended if conditions to support alias names for
 registers

---
 .../Plugins/ABI/RISCV/ABISysV_riscv.cpp   |  54 ++
 .../TestGDBServerTargetXML.py | 147 
 .../basic_eh_frame-riscv64.yaml   |  20 +++
 .../postmortem/elf-core/TestLinuxCore.py  | 158 ++
 .../Shell/Register/Inputs/riscv64-gp-read.cpp |  36 
 lldb/test/Shell/Register/riscv64-gp-read.test |  37 
 llvm/utils/lit/lit/llvm/config.py |   9 +-
 7 files changed, 387 insertions(+), 74 deletions(-)
 create mode 100644 
lldb/test/API/functionalities/gdb_remote_client/basic_eh_frame-riscv64.yaml
 create mode 100644 lldb/test/Shell/Register/Inputs/riscv64-gp-read.cpp
 create mode 100644 lldb/test/Shell/Register/riscv64-gp-read.test

diff --git a/lldb/source/Plugins/ABI/RISCV/ABISysV_riscv.cpp 
b/lldb/source/Plugins/ABI/RISCV/ABISysV_riscv.cpp
index 8412991933d27..c463bd006b3db 100644
--- a/lldb/source/Plugins/ABI/RISCV/ABISysV_riscv.cpp
+++ b/lldb/source/Plugins/ABI/RISCV/ABISysV_riscv.cpp
@@ -850,8 +850,62 @@ void ABISysV_riscv::AugmentRegisterInfo(
   it.value().alt_name.SetCString("x3");
 else if (it.value().name == "fp")
   it.value().alt_name.SetCString("s0");
+else if (it.value().name == "tp")
+  it.value().alt_name.SetCString("x4");
 else if (it.value().name == "s0")
   it.value().alt_name.SetCString("x8");
+else if (it.value().name == "s1")
+  it.value().alt_name.SetCString("x9");
+else if (it.value().name == "t0")
+  it.value().alt_name.SetCString("x5");
+else if (it.value().name == "t1")
+  it.value().alt_name.SetCString("x6");
+else if (it.value().name == "t2")
+  it.value().alt_name.SetCString("x7");
+else if (it.value().name == "a0")
+  it.value().alt_name.SetCString("x10");
+else if (it.value().name == "a1")
+  it.value().alt_name.SetCString("x11");
+else if (it.value().name == "a2")
+  it.value().alt_name.SetCString("x12");
+else if (it.value().name == "a3")
+  it.value().alt_name.SetCString("x13");
+else if (it.value().name == "a4")
+  it.value().alt_name.SetCString("x14");
+else if (it.value().name == "a5")
+  it.value().alt_name.SetCString("x15");
+else if (it.value().name == "a6")
+  it.value().alt_name.SetCString("x16");
+else if (it.value().name == "a7")
+  it.value().alt_name.SetCString("x17");
+else if (it.value().name == "s2")
+  it.value().alt_name.SetCString("x18");
+else if (it.value().name == "s3")
+  it.value().alt_name.SetCString("x19");
+else if (it.value().name == "s4")
+  it.value().alt_name.SetCString("x20");
+else if (it.value().name == "s5")
+  it.value().alt_name.SetCString("x21");
+else if (it.value().name == "s6")
+  it.value().alt_name.SetCString("x22");
+else if (it.value().name == "s7")
+  it.value().alt_name.SetCString("x23");
+else if (it.value().name == "s8")
+  it.value().alt_name.SetCString("x24");
+else if (it.value().name == "s9")
+  it.value().alt_name.SetCString("x25");
+else if (it.value().name == "s10")
+  it.value().alt_name.SetCString("x26");
+else if (it.value().name == "s11")
+  it.value().alt_name.SetCString("x27");
+else if (it.value().name == "t3")
+  it.value().alt_name.SetCString("x28");
+else if (it.value().name == "t4")
+  it.value().alt_name.SetCString("x29");
+else if (it.value().name == "t5")
+  it.value().alt_name.SetCString("x30");
+else if (it.value().name == "t6")
+  it.value().alt_name.SetCString("x31");
 
 // Set generic regnum so lldb knows what the PC, etc is
 it.value().regnum_generic = GetGenericNum(it.value().name.GetStringRef());
diff --git 
a/lldb/test/API/functionalities/gdb_remote_client/TestGDBServerTargetXML.py 
b/lldb/test/API/functionalities/gdb_remote_client/TestGDBServerTargetXML.py
index 22f5553e40802..cf82f7f168c20 100644
--- a/lldb/test/API/functionalities/gdb_remote_client/TestGDBServerTargetXML.py
+++ b/lldb/test/API/functionalities/gdb_remote_client/TestGDBServerTargetXML.py
@@ -652,6 +652,153 @@ def haltReason(self):
 )
 self.match("register read s31", ["s31 = 128"])
 
+@skipIfXmlSupportMissing
+@skipIfRemote
+@skipIfLLVMTargetMissing("RISCV")
+def test_riscv64_regs(self):
+"""Test grabbing various riscv64 registers from gdbserver."""
+
+class MyResponder(MockGDBServerResponder):
+reg_data = (
+"0102030405060708"  # zero
+"0102030405060708"  # ra
+"0102030405060708"  # sp
+"0102030405060708"  # gp
+"0102030405060708"  # tp
+"0102030405060708"  # t0
+

[Lldb-commits] [lldb] [lldb] Fix build problem in llgs tests for RISC-V (PR #127091)

2025-02-13 Thread via lldb-commits

github-actions[bot] wrote:



Thank you for submitting a Pull Request (PR) to the LLVM Project!

This PR will be automatically labeled and the relevant teams will be notified.

If you wish to, you can add reviewers by using the "Reviewers" section on this 
page.

If this is not working for you, it is probably because you do not have write 
permissions for the repository. In which case you can instead tag reviewers by 
name in a comment by using `@` followed by their GitHub username.

If you have received no comments on your PR for a week, you can request a 
review by "ping"ing the PR by adding a comment “Ping”. The common courtesy 
"ping" rate is once a week. Please remember that you are asking for valuable 
time from other developers.

If you have further questions, they may be answered by the [LLVM GitHub User 
Guide](https://llvm.org/docs/GitHub.html).

You can also ask questions in a comment on this PR, on the [LLVM 
Discord](https://discord.com/invite/xS7Z362) or on the 
[forums](https://discourse.llvm.org/).

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


[Lldb-commits] [lldb] [lldb] Fix build problem in llgs tests for RISC-V (PR #127091)

2025-02-13 Thread via lldb-commits

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: None (sga-sc)


Changes

During testing of LLDB on RISC-V target, tests from the llgs category were 
built with an error: `Error when building test subject.`

```
llvm-project/lldb/test/API/tools/lldb-server/main.cpp:151:40: error: missing 
')' after '__builtin_debugtrap'
  151 | #elif __has_builtin(__builtin_debugtrap())
  | ~~~^
llvm-project/lldb/test/API/tools/lldb-server/main.cpp:151:20: note: to match 
this '('
  151 | #elif __has_builtin(__builtin_debugtrap())
  |^
```

This patch fixes this error.

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


1 Files Affected:

- (modified) lldb/test/API/tools/lldb-server/main.cpp (+1-1) 


``diff
diff --git a/lldb/test/API/tools/lldb-server/main.cpp 
b/lldb/test/API/tools/lldb-server/main.cpp
index 5d33ee6e1b0ba..484da8aa4bef9 100644
--- a/lldb/test/API/tools/lldb-server/main.cpp
+++ b/lldb/test/API/tools/lldb-server/main.cpp
@@ -148,7 +148,7 @@ static void trap() {
   asm volatile("udf #254");
 #elif defined(__powerpc__)
   asm volatile("trap");
-#elif __has_builtin(__builtin_debugtrap())
+#elif __has_builtin(__builtin_debugtrap)
   __builtin_debugtrap();
 #else
 #warning Don't know how to generate a trap. Some tests may fail.

``




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


[Lldb-commits] [lldb] 1138a49 - [lldb] Fix build problem in llgs tests for RISC-V (#127091)

2025-02-13 Thread via lldb-commits

Author: Georgiy Samoylov
Date: 2025-02-13T16:48:03Z
New Revision: 1138a4964adf76cc4af82b3f43dbc8db0b91cd46

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

LOG: [lldb] Fix build problem in llgs tests for RISC-V (#127091)

During testing of LLDB on RISC-V target, tests from the llgs category
were built with an error: `Error when building test subject.`

```
llvm-project/lldb/test/API/tools/lldb-server/main.cpp:151:40: error: missing 
')' after '__builtin_debugtrap'
  151 | #elif __has_builtin(__builtin_debugtrap())
  | ~~~^
llvm-project/lldb/test/API/tools/lldb-server/main.cpp:151:20: note: to match 
this '('
  151 | #elif __has_builtin(__builtin_debugtrap())
  |^
```

This patch fixes this error.

Added: 


Modified: 
lldb/test/API/tools/lldb-server/main.cpp

Removed: 




diff  --git a/lldb/test/API/tools/lldb-server/main.cpp 
b/lldb/test/API/tools/lldb-server/main.cpp
index 5d33ee6e1b0ba..484da8aa4bef9 100644
--- a/lldb/test/API/tools/lldb-server/main.cpp
+++ b/lldb/test/API/tools/lldb-server/main.cpp
@@ -148,7 +148,7 @@ static void trap() {
   asm volatile("udf #254");
 #elif defined(__powerpc__)
   asm volatile("trap");
-#elif __has_builtin(__builtin_debugtrap())
+#elif __has_builtin(__builtin_debugtrap)
   __builtin_debugtrap();
 #else
 #warning Don't know how to generate a trap. Some tests may fail.



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


[Lldb-commits] [lldb] [lldb-dap] Add: show return value on step out (PR #106907)

2025-02-13 Thread via lldb-commits


@@ -663,6 +663,41 @@ def do_test_indexedVariables(self, 
enableSyntheticChildDebugging: bool):
 ]["variables"]
 self.verify_variables(verify_children, children)
 
+def test_return_variables(self):

jimingham wrote:

lldb will do almost the right thing if it can't figure out the return value of 
a function.  The SBValue that SBThread::GetStopReturnValue() returns won't be 
valid.  I say that's "almost the right thing" because a better return would be 
a valid SBValue with an error that tells you why we couldn't fetch the return 
value.

In general, lldb will always be able to get the return value of functions that 
return their values in registers, since that information has to be available at 
the moment you step out of the function.  It doesn't matter whether the return 
is in one or multiple registers, so long as lldb can figure out from the ABI 
and the return type that it is returned in one or more registers, the 
information is available for lldb to figure out the value.

For return values that are bigger than will fit in registers for that ABI, the 
function gets passed the address that the caller expects the return value to be 
written to.  In the Itanium ABI - which is what for instance x86_64 uses, the 
ABI mandates that the return address be written back to the "return address 
register" specifically so that analysis tools like debuggers could reconstruct 
it.  But for the arm64 ABI someone decided that benefit wasn't worth the extra 
store & write, so the function is free to reuse that address-passing register.  
That means the only way that lldb could reconstruct the return value was if it 
stopped at the first instruction of the function, wrote down the address passed 
in, and then it would have it on stepping out.

We've toyed with ideas like: if you put a breakpoint anywhere in function A(), 
then we'll also put a breakpoint on the start of the function so we can 
transparently capture this value.  And when we step into a function, we could 
stop at the first instruction and write down the address as well.  This is 
probably doable, but no one has done it yet.

What I was mostly saying is if we have one test that tests both in register 
returns and in memory returns, then we'd have to disable the entire test for 
ABI's that don't restore the return address.  But if we had one test for in 
register returns, and one for in memory, we could keep running the first test, 
and not lose coverage for something that should work.

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


[Lldb-commits] [lldb] [lldb] Fix "in function" detection in "thread until" (PR #123622)

2025-02-13 Thread via lldb-commits

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

LGTM

I left the question of whether this high-low index finding algorithm would be 
useful elsewhere (it could be a method on Function from what you have & return).

If you don't think that's likely to be reusable, then this is fine as is.

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


[Lldb-commits] [lldb] [lldb] Fix "in function" detection in "thread until" (PR #123622)

2025-02-13 Thread via lldb-commits

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


[Lldb-commits] [lldb] [lldb] Fix "in function" detection in "thread until" (PR #123622)

2025-02-13 Thread via lldb-commits


@@ -970,19 +969,26 @@ class CommandObjectThreadUntil : public 
CommandObjectParsed {
   return;
 }
 
-AddressRange fun_addr_range = sc.function->GetAddressRange();
-Address fun_start_addr = fun_addr_range.GetBaseAddress();
-line_table->FindLineEntryByAddress(fun_start_addr, function_start,
-   &index_ptr);
-
-Address fun_end_addr(fun_start_addr.GetSection(),
- fun_start_addr.GetOffset() +
- fun_addr_range.GetByteSize());
-
-bool all_in_function = true;
+uint32_t lowest_func_idx = UINT32_MAX;

jimingham wrote:

Would this be useful anywhere else?  It's asking a Function what its highest 
and lowest indexes are in the linetable from its CU.

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


[Lldb-commits] [lldb] 0feb00f - [lldb][test] TestCPPEnumPromotion: make sure enums are preserved in dSYM

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

Author: Michael Buch
Date: 2025-02-13T18:13:09Z
New Revision: 0feb00f17cbaac7428dcb7aed13d903b65974978

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

LOG: [lldb][test] TestCPPEnumPromotion: make sure enums are preserved in dSYM

On macOS CI this was failing with:
```
FAIL: test_dsym (TestCPPEnumPromotion.TestCPPEnumPromotion)
--
Traceback (most recent call last):
  File 
"/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py",
 line 1784, in test_method
return attrvalue(self)
  File 
"/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/llvm-project/lldb/test/API/lang/cpp/enum_promotion/TestCPPEnumPromotion.py",
 line 28, in test
self.expect_expr("+EnumUChar::UChar", result_type=UChar_promoted.type.name)
  File 
"/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py",
 line 2540, in expect_expr
value_check.check_value(self, eval_result, str(eval_result))
  File 
"/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py",
 line 299, in check_value
test_base.assertSuccess(val.GetError())
  File 
"/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py",
 line 2575, in assertSuccess
self.fail(self._formatMessage(msg, "'{}' is not success".format(error)))
AssertionError: 'error: :1:2: use of undeclared identifier 
'EnumUChar'
1 | +EnumUChar::UChar
  |  ^
' is not success
```
But only for the `dSYM` variant of the test.

Looking at the dSYM, none of the enums are actually preserved in the 
debug-info. We have to actually use the enum types in source to get dsymutil to 
preserve them. This patch does just that.

Added: 


Modified: 
lldb/test/API/lang/cpp/enum_promotion/main.cpp

Removed: 




diff  --git a/lldb/test/API/lang/cpp/enum_promotion/main.cpp 
b/lldb/test/API/lang/cpp/enum_promotion/main.cpp
index bcdb0adff5d40..a250115eabc11 100644
--- a/lldb/test/API/lang/cpp/enum_promotion/main.cpp
+++ b/lldb/test/API/lang/cpp/enum_promotion/main.cpp
@@ -1,12 +1,12 @@
-enum EnumUChar { UChar = 1 };
-enum EnumUShort { UShort = 0x101 };
-enum EnumUInt { UInt = 0x10001 };
-enum EnumSLong { SLong = 0x10001 };
-enum EnumULong { ULong = 0xFFF0 };
-enum EnumNChar { NChar = -1 };
-enum EnumNShort { NShort = -0x101 };
-enum EnumNInt { NInt = -0x10001 };
-enum EnumNLong { NLong = -0x10001 };
+enum EnumUChar { UChar = 1 } e1;
+enum EnumUShort { UShort = 0x101 } e2;
+enum EnumUInt { UInt = 0x10001 } e3;
+enum EnumSLong { SLong = 0x10001 } e4;
+enum EnumULong { ULong = 0xFFF0 } e5;
+enum EnumNChar { NChar = -1 } e6;
+enum EnumNShort { NShort = -0x101 } e7;
+enum EnumNInt { NInt = -0x10001 } e8;
+enum EnumNLong { NLong = -0x10001 } e9;
 
 int main() {
   auto UChar_promoted = +EnumUChar::UChar;



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


[Lldb-commits] [clang] [lldb] [lldb] Analyze enum promotion type during parsing (PR #115005)

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

Michael137 wrote:

Fixed in `0feb00f17cbaac7428dcb7aed13d903b65974978`

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


[Lldb-commits] [lldb] 050933b - [lldb][test] TestCppTemplateArguments.py: adjust expected type

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

Author: Michael Buch
Date: 2025-02-13T23:13:46Z
New Revision: 050933b41f8de8498c95dfd0bacb10f3d495d62d

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

LOG: [lldb][test] TestCppTemplateArguments.py: adjust expected type

LLVM started emitting the `DW_AT_const_value` for floating point template 
parameters since https://github.com/llvm/llvm-project/pull/127045. Adjust the 
expected type in this test. It's still not quite correct but that requires a 
separate fix in LLDB.

Added: 


Modified: 
lldb/test/API/lang/cpp/template-arguments/TestCppTemplateArguments.py

Removed: 




diff  --git 
a/lldb/test/API/lang/cpp/template-arguments/TestCppTemplateArguments.py 
b/lldb/test/API/lang/cpp/template-arguments/TestCppTemplateArguments.py
index f1b3d7a9806fd..c276aae449920 100644
--- a/lldb/test/API/lang/cpp/template-arguments/TestCppTemplateArguments.py
+++ b/lldb/test/API/lang/cpp/template-arguments/TestCppTemplateArguments.py
@@ -63,6 +63,8 @@ def test(self):
 
 # FIXME: type should be Foo
 # FIXME: double/float NTTP parameter values currently not supported.
-value = self.expect_expr("temp4", result_type="Foo")
+value = self.expect_expr("temp4", result_type="Foo")
 template_param_value = 
value.GetType().GetTemplateArgumentValue(target, 1)
-self.assertFalse(template_param_value)
+self.assertEqual(template_param_value.GetTypeName(), "float")
+# FIXME: this should return a float
+self.assertEqual(template_param_value.GetValueAsSigned(), 2)



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


[Lldb-commits] [lldb] [lldb-dap] Add: show return value on step out (PR #106907)

2025-02-13 Thread via lldb-commits


@@ -663,6 +663,41 @@ def do_test_indexedVariables(self, 
enableSyntheticChildDebugging: bool):
 ]["variables"]
 self.verify_variables(verify_children, children)
 
+def test_return_variables(self):

Da-Viper wrote:

I think understand it. 
A function can either return a value that fits in a register if it too big, it 
is placed in memory. hence register and memory returns.  

Some ABIs you may reuse the register with the return value address.

The test needs to be split to handle register returns and memory returns. 

The case of the memory returns does the new test in 
`TestDAP_variables_children.py` not cover that case ? as it  returns a value 
that will not fit in one register. 

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


[Lldb-commits] [lldb] [lldb-dap] Add: show return value on step out (PR #106907)

2025-02-13 Thread via lldb-commits

https://github.com/Da-Viper updated 
https://github.com/llvm/llvm-project/pull/106907

>From aeb8854bbe7695e576257c8403e04d4b8268b679 Mon Sep 17 00:00:00 2001
From: Ezike Ebuka 
Date: Sun, 1 Sep 2024 13:48:41 +0100
Subject: [PATCH 1/7] Add: show return value on step out

---
 lldb/tools/lldb-dap/lldb-dap.cpp | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/lldb/tools/lldb-dap/lldb-dap.cpp b/lldb/tools/lldb-dap/lldb-dap.cpp
index e323990d8b6ed..3cacc16dedb25 100644
--- a/lldb/tools/lldb-dap/lldb-dap.cpp
+++ b/lldb/tools/lldb-dap/lldb-dap.cpp
@@ -4225,6 +4225,17 @@ void request_variables(DAP &dap, const 
llvm::json::Object &request) {
   variable_name_counts[GetNonNullVariableName(variable)]++;
 }
 
+// Show return value if there is any ( in the top frame )
+auto process = g_dap.target.GetProcess();
+auto selectedThread = process.GetSelectedThread();
+lldb::SBValue stopReturnValue = selectedThread.GetStopReturnValue();
+if (stopReturnValue.IsValid() &&
+(selectedThread.GetSelectedFrame().GetFrameID() == 0)) {
+  auto renamedReturnValue = stopReturnValue.Clone("(Return Value)");
+  variables.emplace_back(
+  CreateVariable(renamedReturnValue,0, UINT64_MAX, hex, false));
+}
+
 // Now we construct the result with unique display variable names
 for (auto i = start_idx; i < end_idx; ++i) {
   lldb::SBValue variable = top_scope->GetValueAtIndex(i);

>From 07c3c56bc987cdd947b8de126be6497f45f1da7b Mon Sep 17 00:00:00 2001
From: Ezike Ebuka 
Date: Sun, 1 Sep 2024 14:10:54 +0100
Subject: [PATCH 2/7] format file

---
 lldb/tools/lldb-dap/lldb-dap.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lldb/tools/lldb-dap/lldb-dap.cpp b/lldb/tools/lldb-dap/lldb-dap.cpp
index 3cacc16dedb25..30b3354c184b0 100644
--- a/lldb/tools/lldb-dap/lldb-dap.cpp
+++ b/lldb/tools/lldb-dap/lldb-dap.cpp
@@ -4233,7 +4233,7 @@ void request_variables(DAP &dap, const llvm::json::Object 
&request) {
 (selectedThread.GetSelectedFrame().GetFrameID() == 0)) {
   auto renamedReturnValue = stopReturnValue.Clone("(Return Value)");
   variables.emplace_back(
-  CreateVariable(renamedReturnValue,0, UINT64_MAX, hex, false));
+  CreateVariable(renamedReturnValue, 0, UINT64_MAX, hex, false));
 }
 
 // Now we construct the result with unique display variable names

>From c9ef0294def8919536ade9f8097c3471b94b0355 Mon Sep 17 00:00:00 2001
From: Ezike Ebuka 
Date: Sun, 15 Sep 2024 22:22:09 +0100
Subject: [PATCH 3/7] [lldb-dap] Add: Show children for return values

---
 lldb/tools/lldb-dap/lldb-dap.cpp | 20 +---
 1 file changed, 13 insertions(+), 7 deletions(-)

diff --git a/lldb/tools/lldb-dap/lldb-dap.cpp b/lldb/tools/lldb-dap/lldb-dap.cpp
index 30b3354c184b0..00584f31848cf 100644
--- a/lldb/tools/lldb-dap/lldb-dap.cpp
+++ b/lldb/tools/lldb-dap/lldb-dap.cpp
@@ -4227,13 +4227,19 @@ void request_variables(DAP &dap, const 
llvm::json::Object &request) {
 
 // Show return value if there is any ( in the top frame )
 auto process = g_dap.target.GetProcess();
-auto selectedThread = process.GetSelectedThread();
-lldb::SBValue stopReturnValue = selectedThread.GetStopReturnValue();
-if (stopReturnValue.IsValid() &&
-(selectedThread.GetSelectedFrame().GetFrameID() == 0)) {
-  auto renamedReturnValue = stopReturnValue.Clone("(Return Value)");
-  variables.emplace_back(
-  CreateVariable(renamedReturnValue, 0, UINT64_MAX, hex, false));
+auto selected_thread = process.GetSelectedThread();
+lldb::SBValue stop_return_value = selected_thread.GetStopReturnValue();
+if (stop_return_value.IsValid() &&
+(selected_thread.GetSelectedFrame().GetFrameID() == 0)) {
+  auto renamed_return_value = stop_return_value.Clone("(Return Value)");
+  int64_t return_ref = 0;
+  if (stop_return_value.MightHaveChildren() ||
+  stop_return_value.IsSynthetic()) {
+return_ref = g_dap.variables.InsertExpandableVariable(
+stop_return_value, /*is_permanent=*/false);
+  }
+  variables.emplace_back(CreateVariable(renamed_return_value, return_ref,
+UINT64_MAX, hex, false));
 }
 
 // Now we construct the result with unique display variable names

>From 91e7042f9c3438b13ff8b476d07057da52b2589f Mon Sep 17 00:00:00 2001
From: Ezike Ebuka 
Date: Wed, 12 Feb 2025 00:16:46 +
Subject: [PATCH 4/7] [lldb-dap] Add Tests: Show children for return values

---
 .../lldb-dap/variables/TestDAP_variables.py   | 57 +++
 .../children/TestDAP_variables_children.py| 55 ++
 .../lldb-dap/variables/children/main.cpp  | 12 
 .../API/tools/lldb-dap/variables/main.cpp |  9 +++
 4 files changed, 122 insertions(+), 11 deletions(-)

diff --git a/lldb/test/API/tools/lldb-dap/variables/TestDAP_variables.py 
b/lldb/test/API/tools/lldb-dap/variables/TestDAP_variables.py

[Lldb-commits] [lldb] Define Telemetry plugin for LLDB. (PR #126588)

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

JDevlieghere wrote:

> This was what we were doing in the [initial 
> PR](https://github.com/llvm/llvm-project/pull/98528/files#diff-20a2060f8e87c6742d6f2c7ae97e919f8485995d7808bd9fccbfbede697a9ec7)
>  but Pavel had correctly pointed out that the architecture was unnecessarily 
> "baroque". GIven there will be only one instance of the TelemetrManager at a 
> time and that we will not be creating a new manager on the fly, none of those 
> complex hooks are necessary.
> 
> Instead, we just need the downstream implemntation to register its instance 
> (via the setInstance()). Then the rest of (upstream) LLDB code, which uses 
> the Telemetry, would just do `TelemetryManager::getInstance()`.

Thanks for the clarification. I had a feeling I had missed something. But then 
I don't get the point of making it a "plugin" at all. What's the benefit of 
declaring it as a plugin. As much as I agree that the plugin system is 
_baroque_, there is value in consistency and everything that's called a plugin 
working the same way. Me being surprised by the PR is a concrete example of 
that. 

More of a question for @labath but do we have an example of another place where 
we have "semi plugins" like this and if not, what are existing plugins that 
could be reworked to be lighter weight? I think we need to have a sufficiently 
strong motivation to diverge from the existing way of writing plugins (or have 
a renaissance where we improve it for all the plugins). 

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


[Lldb-commits] [lldb] [lldb] Don't warn that libobjc was read from memory in corefile (PR #127138)

2025-02-13 Thread Jason Molenda via lldb-commits

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

AppleObjCRuntimeV2 prints a warning when we read libobjc.A.dylib from memory, 
as a canary to detect that we are reading system binaries out of memory (which 
is slow, and we try hard to avoid). But with a corefile, reading out of 
"memory" is fine, and may be the only way we can find the correct binary.

rdar://144322688

>From 3d2befdb4dc42e08e50865faca4d2ef4ab94a300 Mon Sep 17 00:00:00 2001
From: Jason Molenda 
Date: Thu, 13 Feb 2025 14:30:48 -0800
Subject: [PATCH] [lldb] Don't warn that libobjc was read from memory in
 corefile

AppleObjCRuntimeV2 prints a warning when we read libobjc.A.dylib
from memory, as a canary to detect that we are reading system
binaries out of memory (which is slow, and we try hard to avoid).
But with a corefile, reading out of "memory" is fine, and may be
the only way we can find the correct binary.

rdar://144322688
---
 .../ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp   | 3 +++
 1 file changed, 3 insertions(+)

diff --git 
a/lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp
 
b/lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp
index a57099f3df454..ff17028e6662a 100644
--- 
a/lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp
+++ 
b/lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp
@@ -2666,6 +2666,9 @@ void AppleObjCRuntimeV2::WarnIfNoExpandedSharedCache() {
   if (!object_file->IsInMemory())
 return;
 
+  if (!GetProcess()->IsLiveDebugSession())
+return;
+
   Target &target = GetProcess()->GetTarget();
   Debugger &debugger = target.GetDebugger();
 

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


[Lldb-commits] [lldb] [lldb] Don't warn that libobjc was read from memory in corefile (PR #127138)

2025-02-13 Thread via lldb-commits

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Jason Molenda (jasonmolenda)


Changes

AppleObjCRuntimeV2 prints a warning when we read libobjc.A.dylib from memory, 
as a canary to detect that we are reading system binaries out of memory (which 
is slow, and we try hard to avoid). But with a corefile, reading out of 
"memory" is fine, and may be the only way we can find the correct binary.

rdar://144322688

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


1 Files Affected:

- (modified) 
lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp
 (+3) 


``diff
diff --git 
a/lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp
 
b/lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp
index a57099f3df454..ff17028e6662a 100644
--- 
a/lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp
+++ 
b/lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp
@@ -2666,6 +2666,9 @@ void AppleObjCRuntimeV2::WarnIfNoExpandedSharedCache() {
   if (!object_file->IsInMemory())
 return;
 
+  if (!GetProcess()->IsLiveDebugSession())
+return;
+
   Target &target = GetProcess()->GetTarget();
   Debugger &debugger = target.GetDebugger();
 

``




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


[Lldb-commits] [lldb] [lldb] Don't warn that libobjc was read from memory in corefile (PR #127138)

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

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

Makes sense. LGTM.

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


[Lldb-commits] [lldb] [lldb] Change lldb's breakpoint handling behavior (PR #96260)

2025-02-13 Thread Jason Molenda via lldb-commits

jasonmolenda wrote:

For the record, this PR was finally re-landed as 
https://github.com/llvm/llvm-project/pull/126988 after four separate commits to 
address issues found in CI testing when I originally merged this.

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


[Lldb-commits] [lldb] [lldb] Fix build problem in llgs tests for RISC-V (PR #127091)

2025-02-13 Thread via lldb-commits

https://github.com/sga-sc created 
https://github.com/llvm/llvm-project/pull/127091

During testing of LLDB on RISC-V target, tests from the llgs category were 
built with an error: `Error when building test subject.`

```
llvm-project/lldb/test/API/tools/lldb-server/main.cpp:151:40: error: missing 
')' after '__builtin_debugtrap'
  151 | #elif __has_builtin(__builtin_debugtrap())
  | ~~~^
llvm-project/lldb/test/API/tools/lldb-server/main.cpp:151:20: note: to match 
this '('
  151 | #elif __has_builtin(__builtin_debugtrap())
  |^
```

This patch fixes this error.

>From 3b40ce56eb57fff5351ad6dc75e9ce3bdd52517a Mon Sep 17 00:00:00 2001
From: Georgiy Samoylov 
Date: Thu, 6 Feb 2025 15:01:46 +0300
Subject: [PATCH] [lldb] Fixed build problem in llgs tests for RISC-V

---
 lldb/test/API/tools/lldb-server/main.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lldb/test/API/tools/lldb-server/main.cpp 
b/lldb/test/API/tools/lldb-server/main.cpp
index 5d33ee6e1b0ba..484da8aa4bef9 100644
--- a/lldb/test/API/tools/lldb-server/main.cpp
+++ b/lldb/test/API/tools/lldb-server/main.cpp
@@ -148,7 +148,7 @@ static void trap() {
   asm volatile("udf #254");
 #elif defined(__powerpc__)
   asm volatile("trap");
-#elif __has_builtin(__builtin_debugtrap())
+#elif __has_builtin(__builtin_debugtrap)
   __builtin_debugtrap();
 #else
 #warning Don't know how to generate a trap. Some tests may fail.

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


[Lldb-commits] [lldb] f30c891 - [lldb] Analyze enum promotion type during parsing (#115005)

2025-02-13 Thread via lldb-commits

Author: Ilia Kuklin
Date: 2025-02-13T22:08:31+05:00
New Revision: f30c891464debb4e0d47d27ea77dc2220d7cdf29

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

LOG: [lldb] Analyze enum promotion type during parsing (#115005)

The information about an enum's best promotion type is discarded after
compilation and is not present in debug info. This patch repeats the
same analysis of each enum value as in the front-end to determine the
best promotion type during DWARF info parsing.

Fixes #86989

Added: 
lldb/test/API/lang/cpp/enum_promotion/Makefile
lldb/test/API/lang/cpp/enum_promotion/TestCPPEnumPromotion.py
lldb/test/API/lang/cpp/enum_promotion/main.cpp

Modified: 
lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp

Removed: 




diff  --git a/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp 
b/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
index 4901b6029d9ce..bcb63f719de10 100644
--- a/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
+++ b/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
@@ -8474,29 +8474,22 @@ bool TypeSystemClang::CompleteTagDeclarationDefinition(
   if (enum_decl->isCompleteDefinition())
 return true;
 
-  clang::ASTContext &ast = lldb_ast->getASTContext();
-
-  /// TODO This really needs to be fixed.
-
   QualType integer_type(enum_decl->getIntegerType());
   if (!integer_type.isNull()) {
-unsigned NumPositiveBits = 1;
+clang::ASTContext &ast = lldb_ast->getASTContext();
+
 unsigned NumNegativeBits = 0;
+unsigned NumPositiveBits = 0;
+ast.computeEnumBits(enum_decl->enumerators(), NumNegativeBits,
+NumPositiveBits);
 
-clang::QualType promotion_qual_type;
-// If the enum integer type is less than an integer in bit width,
-// then we must promote it to an integer size.
-if (ast.getTypeSize(enum_decl->getIntegerType()) <
-ast.getTypeSize(ast.IntTy)) {
-  if (enum_decl->getIntegerType()->isSignedIntegerType())
-promotion_qual_type = ast.IntTy;
-  else
-promotion_qual_type = ast.UnsignedIntTy;
-} else
-  promotion_qual_type = enum_decl->getIntegerType();
+clang::QualType BestPromotionType;
+clang::QualType BestType;
+ast.computeBestEnumTypes(/*IsPacked=*/false, NumNegativeBits,
+ NumPositiveBits, BestType, BestPromotionType);
 
 enum_decl->completeDefinition(enum_decl->getIntegerType(),
-  promotion_qual_type, NumPositiveBits,
+  BestPromotionType, NumPositiveBits,
   NumNegativeBits);
   }
   return true;

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

diff  --git a/lldb/test/API/lang/cpp/enum_promotion/TestCPPEnumPromotion.py 
b/lldb/test/API/lang/cpp/enum_promotion/TestCPPEnumPromotion.py
new file mode 100644
index 0..2a73dc5357fe7
--- /dev/null
+++ b/lldb/test/API/lang/cpp/enum_promotion/TestCPPEnumPromotion.py
@@ -0,0 +1,36 @@
+"""
+Test LLDB type promotion of unscoped enums.
+"""
+
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+
+class TestCPPEnumPromotion(TestBase):
+def test(self):
+self.build()
+lldbutil.run_to_source_breakpoint(
+self, "// break here", lldb.SBFileSpec("main.cpp")
+)
+UChar_promoted = self.frame().FindVariable("UChar_promoted")
+UShort_promoted = self.frame().FindVariable("UShort_promoted")
+UInt_promoted = self.frame().FindVariable("UInt_promoted")
+SLong_promoted = self.frame().FindVariable("SLong_promoted")
+ULong_promoted = self.frame().FindVariable("ULong_promoted")
+NChar_promoted = self.frame().FindVariable("NChar_promoted")
+NShort_promoted = self.frame().FindVariable("NShort_promoted")
+NInt_promoted = self.frame().FindVariable("NInt_promoted")
+NLong_promoted = self.frame().FindVariable("NLong_promoted")
+
+# Check that LLDB's promoted type is the same as the compiler's
+self.expect_expr("+EnumUChar::UChar", 
result_type=UChar_promoted.type.name)
+self.expect_expr("+EnumUShort::UShort", 
result_type=UShort_promoted.type.name)
+self.expect_expr("+EnumUInt::UInt", 
result_type=UInt_promoted.type.name)
+self.expect_expr("+EnumSLong::SLong", 
result_type=SLong_promoted.type.name)
+self.expect_expr("+EnumULong::ULong", 
result_type=ULong_promo

[Lldb-commits] [clang] [lldb] [lldb] Analyze enum promotion type during parsing (PR #115005)

2025-02-13 Thread Ilia Kuklin via lldb-commits

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


[Lldb-commits] [lldb] [lldb] Fix broken pipe error (PR #127100)

2025-02-13 Thread via lldb-commits

github-actions[bot] wrote:




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



You can test this locally with the following command:


``bash
darker --check --diff -r 
a1345eb240c9456ce1c339106f066217eb5e6984...8844cd67967e7a55682f2b0fd06e8bebe63dd604
 lldb/packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py
``





View the diff from darker here.


``diff
--- gdbremote_testcase.py   2025-02-13 16:48:37.00 +
+++ gdbremote_testcase.py   2025-02-13 17:57:55.251695 +
@@ -343,19 +343,21 @@
 target = self.dbg.CreateTarget(inferior_exe_path)
 return target.GetByteOrder()
 
 def is_port_opened(self):
 connect_port = self.port
-
-err, retcode, cmd_output = self.run_platform_command(f"netstat -ltn | 
grep {connect_port} | grep LISTEN")
-
+
+err, retcode, cmd_output = self.run_platform_command(
+f"netstat -ltn | grep {connect_port} | grep LISTEN"
+)
+
 self.assertTrue(
 err.Success(),
 "Failed to get opened tcp sockets: %s, retcode: %d"
 % (err.GetCString(), retcode),
 )
-
+
 if retcode == 0:
 return True
 else:
 return False
 
@@ -425,11 +427,11 @@
 self._server = Server(self.sock, server)
 return server
 except _ConnectionRefused as serr:
 # Ignore, and try again.
 pass
-
+
 time.sleep(0.5)
 connect_attempts += 1
 
 # We should close the server here to be safe.
 server.terminate()

``




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


[Lldb-commits] [lldb] [lldb] Fix broken pipe error (PR #127100)

2025-02-13 Thread Michał Górny via lldb-commits

mgorny wrote:

I'm thoroughly confused by this. The idea is that if the port is not yet open, 
then `Server` should fail to connect, and the test should retry, correct? If 
you need to explicitly check if the port is already open, then it sounds like 
the code doesn't work correctly.

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


[Lldb-commits] [lldb] Define Telemetry plugin for LLDB. (PR #126588)

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

JDevlieghere wrote:

Based on the title of this PR I was expecting something slightly different, so 
maybe I'm missing something. But if we want to make this an LLDB plugin (which 
I agree we should ), I would expect the `PluginManager` to manage the instance 
rather than the plugin doing itself. With the current patch, I don't see how 
you're taking advantage of it being a plugin.  

In the `PluginInterface`, I would expect a `Create` instance, something like 
this:

```
class TelemetryManager : public PluginInterface {
public:
  static lldb::TelemetryManagerUP Create(const llvm::telemetry::Config& config);

  TelemetryManager() = default;

  virtual  = 0;
};
```

And then the `PluginManager` manages the plugin's lifetime:

```
typedef PluginInstance TelemetryManagerInstance;
typedef PluginInstances TelemetryManagerInstances; 

static TelemetryManager &GetTelemetryManagerInstance() {
  static TelemetryManager g_instances;
  return g_instances;
}

bool PluginManager::RegisterPlugin(
llvm::StringRef name, llvm::StringRef description,
TelemetryManagerCreateInstance create_callback, const 
llvm::telemetry::Config& config) {
  return GetTelemetryManagerInstances().RegisterPlugin(name, description, 
create_callback,
 config);
}

bool PluginManager::UnregisterPlugin(
TelemetryManagerCreateInstance create_callback) {
  return GetTelemetryManagerInstances().UnregisterPlugin(create_callback);
}

TelemetryManagerCreateInstance
PluginManager::GetTelemetryManagerCreateCallbackAtIndex(uint32_t idx) {
  return GetTelemetryManagerInstances().GetCallbackAtIndex(idx);
}
```

And then `Create` would iterate over the plugins:

```
lldb::TelemetryManagerUP TelemetryManager::Create() {
  uint32_t idx = 0;

  while (TelemetryManagerCreateInstance create_instance =
 PluginManager::GetTelemetryManagerCreateCallbackAtIndex(idx++)) {
if (auto device_up = (*create_instance)())
  return device_up;
  }
  return {};
}
```

And then `GetInstance` would look like this:

```
TelemetryManager *TelemetryManager::GetInstance() {
  if (!m_instance)
m_instance = TelemetryManager::Create();
  return m_instance.get();
}
```


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


[Lldb-commits] [lldb] Define Telemetry plugin for LLDB. (PR #126588)

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


@@ -0,0 +1,74 @@
+//===-- TelemetryTest.cpp ===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "llvm/Config/llvm-config.h"
+
+#ifdef LLVM_BUILD_TELEMETRY
+
+#include "lldb/Core/PluginInterface.h"
+#include "lldb/Core/PluginManager.h"
+#include "lldb/Core/Telemetry.h"
+#include "llvm/ADT/StringRef.h"
+#include "llvm/Support/Error.h"
+#include "llvm/Telemetry/Telemetry.h"
+#include "gtest/gtest.h"
+
+#include 

labath wrote:

```suggestion
#include "gtest/gtest.h"
#include 
```

(and then clang-format the file)

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


  1   2   >