[Lldb-commits] [clang] [clang-tools-extra] [flang] [lldb] [llvm] [clang] Move options from clangDriver into new clangOptions library (NFC) (PR #163659)

[Michael Spencer via lldb-commits]

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

Looks good with some minor changes. This should still wait for another approval 
because it's a big change even though it's NFC.

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

[Lldb-commits] [lldb] [lldb] Implement Process::ReadMemoryRanges (PR #163651)

[David Spickett via lldb-commits]

https://github.com/DavidSpickett commented:

What's the thinking for doing this in "ptrace style" where the caller allocates 
a buffer and gives it to the function, vs. allocating the buffer on behalf of 
the caller?

The latter would make it impossible to get the buffer size wrong, but on the 
other hand, the caller would know best how to allocate a given size buffer 
(stack, heap, and so on).

If the main use case (and the only one right now) is a small number of bytes 
from a large set of addresses, we're probably talking stack sized allocations 
not heap. So allowing the caller to set that up would be logical.

I also thought what about a MultiMemWrite, would it make sense to have a 
symmetric API for that hypothetical packet. If the caller allocates the buffer, 
the two would be symmetric. And you could do a "gather read" from N places and 
"scatter write" to N other places.

(no real use case for this, just theory crafting)

It's an internal API so we can always swap later but please include your 
thinking in the PR description even if it's an arbitrary choice, might be 
interesting in future.

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

[Lldb-commits] [lldb] faf070f - [lldb][test] TestExprDefinitionInDylib.py adjust test to account for older compiler versions

[Michael Buch via lldb-commits]

Author: Michael Buch
Date: 2025-10-02T14:08:40+01:00
New Revision: faf070f062ac7f3861092ab110982a613d7dfe1b

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

LOG: [lldb][test] TestExprDefinitionInDylib.py adjust test to account for older 
compiler versions

 Skip tests that require `-gstructor-decl-linkage-names` on Clang versions that 
don't support it.

 Don't pass `-gno-structor-decl-linkage-names` on Clang versions where it the 
flag didn't exist but it was the default behaviour of the compiler anyway.

Drive-by:
- We used to run `self.expect("Bar()")` which would always fail. So the 
`error=True` would be true even if we didn't pass the 
`-gno-structor-linkage-names`. So it wasn't testing the behaviour properly. 
This patch changes these to `self.expect("expr Bar()")`.

Added: 


Modified: 
lldb/test/API/lang/cpp/expr-definition-in-dylib/TestExprDefinitionInDylib.py

Removed: 




diff  --git 
a/lldb/test/API/lang/cpp/expr-definition-in-dylib/TestExprDefinitionInDylib.py 
b/lldb/test/API/lang/cpp/expr-definition-in-dylib/TestExprDefinitionInDylib.py
index c0545c70c84ea..b3bed43c75873 100644
--- 
a/lldb/test/API/lang/cpp/expr-definition-in-dylib/TestExprDefinitionInDylib.py
+++ 
b/lldb/test/API/lang/cpp/expr-definition-in-dylib/TestExprDefinitionInDylib.py
@@ -6,6 +6,11 @@
 
 class ExprDefinitionInDylibTestCase(TestBase):
 
+@skipIf(
+compiler="clang",
+compiler_version=["<", "22"],
+bugnumber="Required Clang flag not supported",
+)
 @skipIfWindows
 def test_with_structor_linkage_names(self):
 """
@@ -74,7 +79,16 @@ def test_no_structor_linkage_names(self):
 Tests that if structor declarations don't have linkage names, we can't
 call ABI-tagged constructors. But non-tagged ones are fine.
 """
-self.build(dictionary={"CXXFLAGS_EXTRAS": 
"-gno-structor-decl-linkage-names"})
+# In older versions of Clang the -gno-structor-decl-linkage-names
+# behaviour was the default.
+if self.expectedCompiler(["clang"]) and self.expectedCompilerVersion(
+[">=", "22.0"]
+):
+self.build(
+dictionary={"CXXFLAGS_EXTRAS": 
"-gno-structor-decl-linkage-names"}
+)
+else:
+self.build()
 
 target = self.dbg.CreateTarget(self.getBuildArtifact("a.out"))
 self.assertTrue(target, VALID_TARGET)
@@ -95,6 +109,6 @@ def test_no_structor_linkage_names(self):
 
 self.expect_expr("Foo(10)", result_type="Foo")
 
-self.expect("Base()", error=True)
+self.expect("expr Base()", error=True)
 
-self.expect("Bar()", error=True)
+self.expect("expr Bar()", error=True)



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

[Lldb-commits] [lldb] [lldb][ClangExpressionParser] Reset DiagnosticManager before we create persistent variables (PR #160074)

[via lldb-commits]

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Michael Buch (Michael137)


Changes

Here's an example crash that we've seen sporadically over the years:
```
0   libsystem_kernel.dylib 0x19d392388 __pthread_kill + 8
1   libsystem_pthread.dylib0x19d3cb88c pthread_kill + 296
2   libsystem_c.dylib  0x19d29cd04 raise + 32
3   LLDB   0x112cbbc94 SignalHandler(int, 
__siginfo*, void*) + 324
4   libsystem_platform.dylib   0x19d4056a4 _sigtramp + 56
5   LLDB   0x110dcbd38 
clang::TextDiagnosticPrinter::HandleDiagnostic(clang::DiagnosticsEngine::Level, 
clang::Diagnostic const&) + 1216
6   LLDB   0x110dcbd38 
clang::TextDiagnosticPrinter::HandleDiagnostic(clang::DiagnosticsEngine::Level, 
clang::Diagnostic const&) + 1216
7   LLDB   0x10de12128 
ClangDiagnosticManagerAdapter::HandleDiagnostic(clang::DiagnosticsEngine::Level,
 clang::Diagnostic const&) + 332
8   LLDB   0x1121eb3dc 
clang::DiagnosticIDs::ProcessDiag(clang::DiagnosticsEngine&) const + 200
9   LLDB   0x1121e67a0 
clang::DiagnosticsEngine::EmitCurrentDiagnostic(bool) + 100
10  LLDB   0x111d766cc 
IsStructurallyEquivalent(clang::StructuralEquivalenceContext&, 
clang::FieldDecl*, clang::FieldDecl*, clang::QualType) + 1568
11  LLDB   0x111d71b54 
IsStructurallyEquivalent(clang::StructuralEquivalenceContext&, 
clang::RecordDecl*, clang::RecordDecl*) + 2076
12  LLDB   0x111d6e448 
clang::StructuralEquivalenceContext::Finish() + 204
13  LLDB   0x111d6e1e0 
clang::StructuralEquivalenceContext::IsEquivalent(clang::Decl*, clang::Decl*) + 
32
14  LLDB   0x111d3b788 
clang::ASTNodeImporter::IsStructuralMatch(clang::Decl*, clang::Decl*, bool, 
bool) + 168
15  LLDB   0x111d404e0 
clang::ASTNodeImporter::VisitFunctionDecl(clang::FunctionDecl*) + 1300
16  LLDB   0x111d5cae0 
clang::ASTImporter::ImportImpl(clang::Decl*) + 24
17  LLDB   0x10ddf30bc 
lldb_private::ClangASTImporter::ASTImporterDelegate::ImportImpl(clang::Decl*) + 
308
18  LLDB   0x111d48140 
clang::ASTImporter::Import(clang::Decl*) + 984
19  LLDB   0x10ddee9dc 
lldb_private::ClangASTImporter::CopyDecl(clang::ASTContext*, clang::Decl*) + 100
20  LLDB   0x10ddfab40 
lldb_private::ClangASTSource::FindExternalLexicalDecls(clang::DeclContext 
const*, llvm::function_ref, 
llvm::SmallVectorImpl&) + 1692
21  LLDB   0x111e1cb84 
clang::DeclContext::LoadLexicalDeclsFromExternalStorage() const + 180
22  LLDB   0x111e1df50 
clang::DeclContext::buildLookup() + 204
23  LLDB   0x111e1dcf4 
clang::DeclContext::makeDeclVisibleInContextWithFlags(clang::NamedDecl*, bool, 
bool) + 504
24  LLDB   0x111d3b01c 
clang::ASTNodeImporter::ImportDeclContext(clang::DeclContext*, bool) + 724
25  LLDB   0x111d62d10 
clang::ASTImporter::ImportDefinition(clang::Decl*) + 428
26  LLDB   0x10ddf1cb0 
lldb_private::ClangASTImporter::ASTImporterDelegate::ImportDefinitionTo(clang::Decl*,
 clang::Decl*) + 524
27  LLDB   0x10ddef3c8 (anonymous 
namespace)::CompleteTagDeclsScope::~CompleteTagDeclsScope() + 616
28  LLDB   0x10ddef6dc 
lldb_private::ClangASTImporter::DeportDecl(clang::ASTContext*, clang::Decl*) + 
436
29  LLDB   0x10ddec3dc 
lldb_private::ASTResultSynthesizer::CommitPersistentDecls() + 236
30  LLDB   0x10de1091c 
lldb_private::ClangExpressionParser::ParseInternal(lldb_private::DiagnosticManager&,
 clang::CodeCompleteConsumer*, unsigned int, unsigned int) + 2292
31  LLDB   0x10de21238 
lldb_private::ClangUserExpression::TryParse(lldb_private::DiagnosticManager&,
 lldb_private::ExecutionContext&, lldb_private::ExecutionPolicy, bool, 
bool) + 328
...
```

Here `ASTImporter::IsStructurallyEquivalent` is trying to emit a diagnostic 
using `ClangExpressionParser`'s `ClangDiagnosticManagerAdapter`. But 
`TextDiagnosticPrinter::TextDiag` seems to be `nullptr`. This can only happen 
when we call `HandleDiagnostic` on `ClangDiagnosticManagerAdapter` after we 
called `EndSourceFile`. Specifically, it looks like when moving a type 

[Lldb-commits] [lldb] [lldb][Language] Simplify SourceLanguage::GetDescription (PR #161804)

[Michael Buch via lldb-commits]

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

>From 159ee47db1b9f6f609fe8b6b3e866f995d8f2e5c Mon Sep 17 00:00:00 2001
From: Michael Buch 
Date: Fri, 3 Oct 2025 09:37:52 +0100
Subject: [PATCH 1/3] [lldb][Language] Simplify SourceLanguage::GetDescription

Currently we don't benefit from the user-friendly names that 
`LanguageDescription` returns because we would always use 
`Language::GetNameForLanguageType`. I'm not aware of a situation where 
`GetDescription` should prefer the non-human readable form of the name with. 
This patch removes the call to `GetNameForLanguageType`.
---
 lldb/source/Target/Language.cpp | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/lldb/source/Target/Language.cpp b/lldb/source/Target/Language.cpp
index 484d9badde397..7ce85dd93f091 100644
--- a/lldb/source/Target/Language.cpp
+++ b/lldb/source/Target/Language.cpp
@@ -559,11 +559,8 @@ lldb::LanguageType SourceLanguage::AsLanguageType() const {
 }
 
 llvm::StringRef SourceLanguage::GetDescription() const {
-  LanguageType type = AsLanguageType();
-  if (type)
-return Language::GetNameForLanguageType(type);
   return llvm::dwarf::LanguageDescription(
-  (llvm::dwarf::SourceLanguageName)name);
+  static_cast(name));
 }
 bool SourceLanguage::IsC() const { return name == llvm::dwarf::DW_LNAME_C; }
 

>From 29d911d209ec3f64ce2dac02d6b996f6bd33869b Mon Sep 17 00:00:00 2001
From: Michael Buch 
Date: Fri, 3 Oct 2025 10:21:15 +0100
Subject: [PATCH 2/3] fixup! handle non-standard languages

---
 lldb/source/Target/Language.cpp | 16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/lldb/source/Target/Language.cpp b/lldb/source/Target/Language.cpp
index 7ce85dd93f091..5bdb634c29ac4 100644
--- a/lldb/source/Target/Language.cpp
+++ b/lldb/source/Target/Language.cpp
@@ -542,9 +542,21 @@ Language::Language() = default;
 // Destructor
 Language::~Language() = default;
 
+static llvm::dwarf::SourceLanguage
+ToDwarfSourceLanguage(lldb::LanguageType language_type) {
+  if (language_type < lldb::eLanguageTypeLastStandardLanguage)
+return static_cast(language_type);
+
+  switch (language_type) {
+  case eLanguageTypeMipsAssembler:
+return llvm::dwarf::DW_LANG_Mips_Assembler;
+  default:
+return llvm::dwarf::DW_LANG_hi_user;
+  }
+}
+
 SourceLanguage::SourceLanguage(lldb::LanguageType language_type) {
-  auto lname =
-  llvm::dwarf::toDW_LNAME((llvm::dwarf::SourceLanguage)language_type);
+  auto lname = llvm::dwarf::toDW_LNAME(ToDwarfSourceLanguage(language_type));
   if (!lname)
 return;
   name = lname->first;

>From bc4952c755862307402cfbe3c4d8e0ccaccc24b9 Mon Sep 17 00:00:00 2001
From: Michael Buch 
Date: Fri, 3 Oct 2025 12:47:32 +0100
Subject: [PATCH 3/3] fixup! add test

---
 lldb/source/Target/Language.cpp  |  5 ++-
 lldb/unittests/Target/CMakeLists.txt |  1 +
 lldb/unittests/Target/Language.cpp   | 56 
 3 files changed, 60 insertions(+), 2 deletions(-)
 create mode 100644 lldb/unittests/Target/Language.cpp

diff --git a/lldb/source/Target/Language.cpp b/lldb/source/Target/Language.cpp
index 5bdb634c29ac4..fa39e57575cc4 100644
--- a/lldb/source/Target/Language.cpp
+++ b/lldb/source/Target/Language.cpp
@@ -550,9 +550,10 @@ ToDwarfSourceLanguage(lldb::LanguageType language_type) {
   switch (language_type) {
   case eLanguageTypeMipsAssembler:
 return llvm::dwarf::DW_LANG_Mips_Assembler;
-  default:
-return llvm::dwarf::DW_LANG_hi_user;
+  default: break;
   }
+
+  llvm_unreachable("Unhandled language type");
 }
 
 SourceLanguage::SourceLanguage(lldb::LanguageType language_type) {
diff --git a/lldb/unittests/Target/CMakeLists.txt 
b/lldb/unittests/Target/CMakeLists.txt
index 3169339ec699f..0c79675a3d890 100644
--- a/lldb/unittests/Target/CMakeLists.txt
+++ b/lldb/unittests/Target/CMakeLists.txt
@@ -2,6 +2,7 @@ add_lldb_unittest(TargetTests
   ABITest.cpp
   DynamicRegisterInfoTest.cpp
   ExecutionContextTest.cpp
+  Language.cpp
   LocateModuleCallbackTest.cpp
   MemoryRegionInfoTest.cpp
   MemoryTest.cpp
diff --git a/lldb/unittests/Target/Language.cpp 
b/lldb/unittests/Target/Language.cpp
new file mode 100644
index 0..4de18b6d2c97b
--- /dev/null
+++ b/lldb/unittests/Target/Language.cpp
@@ -0,0 +1,56 @@
+//===-- LanguageTest.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/Target/Language.h"
+#include "lldb/lldb-enumerations.h"
+#include "gtest/gtest.h"
+
+using namespace lldb_private;
+using namespace lldb;
+
+namespace {
+class LanguageTest : public ::testing::Test {};
+} // namespace
+
+TEST_F(LanguageTest, SourceLanguage_GetDescription) {
+  for (ui

[Lldb-commits] [lldb] [lldb] Fix assertion caused by invalid SupportFileSP (PR #162710)

[Jonas Devlieghere via lldb-commits]

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

[Lldb-commits] [lldb] Fix empty register set when trying to get size of register (PR #162890)

[via lldb-commits]

https://github.com/aokblast created 
https://github.com/llvm/llvm-project/pull/162890

GetSharedRegisterInfoVector is a function to get the singleton of total 
register info. Also, PrivateGetRegisterCount assumes that we have already 
filled the object in GetSharedRegisterInfoVector and panic when the object is 
empty.
However, the actually function possess the register info is 
GetRegisterInfo_i386. Originally, I plan to solve this by only referencing 
object in GetSharedRegisterInfoVector. However, RegisterInfos_x86_64.h requires 
the symbol with name g_register_infos in current scope so that the header can 
append x86_64 registers after it. As a result, I decide to copy the info to the 
object in GetSharedRegisterInfoVector.

Also, reorder the header order and provide a test for debugging 32bit binary on 
64bit platform.

>From f5994f1f894a3b59feb3ad1ae84dba1302969c94 Mon Sep 17 00:00:00 2001
From: ShengYi Hung 
Date: Sat, 11 Oct 2025 01:07:36 +0800
Subject: [PATCH] Fix empty register set when trying to get size of register

GetSharedRegisterInfoVector is a function to get the singleton of total
register info. Also, PrivateGetRegisterCount assumes that we have already
filled the object in GetSharedRegisterInfoVector and panic when the object
is empty.
However, the actually function possess the register info
is GetRegisterInfo_i386. Originally, I plan to solve this by only
referencing object in GetSharedRegisterInfoVector. However,
RegisterInfos_x86_64.h requires the symbol with name g_register_infos in
current scope so that the header can append x86_64 registers after it.
As a result, I decide to copy the info to the object in
GetSharedRegisterInfoVector.

Also, reorder the header order and provide tests for debugging 32bit
binary on 64bit platform.
---
 lldb/source/Host/freebsd/Host.cpp   | 3 +--
 .../Process/Utility/RegisterContextFreeBSD_x86_64.cpp   | 6 --
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/lldb/source/Host/freebsd/Host.cpp 
b/lldb/source/Host/freebsd/Host.cpp
index fa7efad466bad..dfdbfea0c3c0a 100644
--- a/lldb/source/Host/freebsd/Host.cpp
+++ b/lldb/source/Host/freebsd/Host.cpp
@@ -18,8 +18,6 @@
 #include 
 #include 
 
-#include "llvm/Object/ELF.h"
-
 #include "lldb/Host/FileSystem.h"
 #include "lldb/Host/Host.h"
 #include "lldb/Host/HostInfo.h"
@@ -32,6 +30,7 @@
 #include "lldb/Utility/Status.h"
 #include "lldb/Utility/StreamString.h"
 
+#include "llvm/Object/ELF.h"
 #include "llvm/TargetParser/Host.h"
 
 namespace lldb_private {
diff --git 
a/lldb/source/Plugins/Process/Utility/RegisterContextFreeBSD_x86_64.cpp 
b/lldb/source/Plugins/Process/Utility/RegisterContextFreeBSD_x86_64.cpp
index e0f3971c6e272..b55a5c595d3ca 100644
--- a/lldb/source/Plugins/Process/Utility/RegisterContextFreeBSD_x86_64.cpp
+++ b/lldb/source/Plugins/Process/Utility/RegisterContextFreeBSD_x86_64.cpp
@@ -76,8 +76,7 @@ static std::vector 
&GetSharedRegisterInfoVector() {
 
 static const RegisterInfo *
 GetRegisterInfo_i386(const lldb_private::ArchSpec &arch) {
-  static std::vector g_register_infos(
-  GetSharedRegisterInfoVector());
+  static std::vector g_register_infos;
 
   // Allocate RegisterInfo only once
   if (g_register_infos.empty()) {
@@ -93,6 +92,9 @@ GetRegisterInfo_i386(const lldb_private::ArchSpec &arch) {
 #define UPDATE_REGISTER_INFOS_I386_STRUCT_WITH_X86_64_OFFSETS
 #include "RegisterInfos_x86_64.h"
 #undef UPDATE_REGISTER_INFOS_I386_STRUCT_WITH_X86_64_OFFSETS
+std::vector &shared_regs =
+GetSharedRegisterInfoVector();
+shared_regs = g_register_infos;
   }
 
   return &g_register_infos[0];

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

[Lldb-commits] [clang] [lldb] [Clang] Introduce OverflowBehaviorType for fine-grained overflow control (PR #148914)

[Oliver Hunt via lldb-commits]

@@ -9744,6 +9744,16 @@ static void DiagnoseNarrowingInInitList(Sema &S,
 
   case NK_Constant_Narrowing: {
 // A constant value was narrowed.
+
+// Overflow behavior destination types with a 'wrap' kind can elide

ojhunt wrote:

No, you are misunderstanding the point of this diagnostic.

The error is not the wrapping behavior, it is the author getting the underlying 
type wrong.

e.g. the author wrote `uint32_t` when they meant to write `unint64_t`. The fact 
that they want the type to have defined wrapping semantics is irrelevant to 
that diagnosis.

> But yes, it is possible to write bad code, even when using OBTs.

Correct, and the literally entire point of this warning is to prevent this 
*exact* error.

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

[Lldb-commits] [lldb] [lldb] Introduce ScriptedFrameProvider for real threads (PR #161870)

[Med Ismail Bennani via lldb-commits]

https://github.com/medismailben updated 
https://github.com/llvm/llvm-project/pull/161870

>From 70d72a2e14f8d937b70aa042ea5582b9127ae1cc Mon Sep 17 00:00:00 2001
From: Med Ismail Bennani 
Date: Sat, 4 Oct 2025 15:37:29 +0100
Subject: [PATCH] [lldb] Introduce ScriptedFrameProvider for real threads

This patch introduces a new scripting affordance: `ScriptedFrameProvider`.

This allows users to provide custom stack frames for real native threads,
augmenting or replacing the standard unwinding mechanism. This is useful
for:
- Providing frames for custom calling conventions or languages
- Reconstructing missing frames from crash dumps or core files
- Adding diagnostic or synthetic frames for debugging

The frame provider supports four merge strategies:
- Replace: Replace entire stack with scripted frames
- Prepend: Add scripted frames before real stack
- Append: Add scripted frames after real stack
- ReplaceByIndex: Replace specific frames by index

With this change, frames can be synthesized from different sources:
- Either from a dictionary containing a PC address and frame index
- Or by creating a ScriptedFrame python object for full control

To use it, first register the scripted frame provider then use existing
commands:
   (lldb) frame provider register -C my_module.MyFrameProvider

  or

   (lldb) script thread.RegisterFrameProvider("my_module.MyFrameProvider", 
lldb.SBStructuredData())

  then

   (lldb) bt

See examples/python/templates/scripted_frame_provider.py for details.

Architecture changes:
- Moved ScriptedFrame from `Plugins` to `Interpreter` to avoid
   layering violations
- Moved `RegisterContextMemory` from `Plugins` to `Target` as it only
   depends on Target and Utility layers
- Added `ScriptedFrameProvider` C++ wrapper and Python interface
- Updated `Thread::GetStackFrameList` to apply merge strategies

rdar://161834688

Signed-off-by: Med Ismail Bennani 
---
 lldb/bindings/python/CMakeLists.txt   |   1 +
 .../templates/scripted_frame_provider.py  | 147 +++
 lldb/include/lldb/API/SBThread.h  |   5 +
 .../ScriptedFrameProviderInterface.h  |  36 +++
 .../lldb/Interpreter/ScriptInterpreter.h  |   6 +
 .../lldb/Interpreter}/ScriptedFrame.h |  42 ++-
 .../lldb/Interpreter/ScriptedFrameProvider.h  |  58 
 .../lldb/Target}/RegisterContextMemory.h  |   6 +-
 lldb/include/lldb/Target/StackFrameList.h |   1 +
 lldb/include/lldb/Target/Thread.h |   9 +
 lldb/include/lldb/lldb-enumerations.h |  13 +
 lldb/include/lldb/lldb-forward.h  |   6 +
 lldb/source/API/SBThread.cpp  |  34 +++
 lldb/source/Commands/CommandObjectFrame.cpp   |  95 +++
 lldb/source/Commands/CommandObjectThread.cpp  |   1 +
 lldb/source/Interpreter/CMakeLists.txt|   2 +
 .../ScriptedFrame.cpp |  84 --
 .../Interpreter/ScriptedFrameProvider.cpp | 191 ++
 .../Python/OperatingSystemPython.cpp  |   2 +-
 .../Plugins/Process/Utility/CMakeLists.txt|   1 -
 .../Plugins/Process/scripted/CMakeLists.txt   |   1 -
 .../Process/scripted/ScriptedThread.cpp   |   5 +-
 .../Plugins/Process/scripted/ScriptedThread.h |   2 +-
 .../Python/Interfaces/CMakeLists.txt  |   1 +
 .../ScriptInterpreterPythonInterfaces.h   |   1 +
 .../ScriptedFrameProviderPythonInterface.cpp  |  71 +
 .../ScriptedFrameProviderPythonInterface.h|  45 
 .../Interfaces/ScriptedPythonInterface.h  |   4 +
 .../Python/ScriptInterpreterPython.cpp|   5 +
 .../Python/ScriptInterpreterPythonImpl.h  |   3 +
 lldb/source/Target/CMakeLists.txt |   1 +
 .../RegisterContextMemory.cpp |   2 +-
 lldb/source/Target/Thread.cpp | 131 -
 .../scripted_frame_provider/Makefile  |   3 +
 .../TestScriptedFrameProvider.py  | 248 ++
 .../scripted_frame_provider/main.c|  14 +
 .../test_frame_providers.py   | 182 +
 37 files changed, 1405 insertions(+), 54 deletions(-)
 create mode 100644 lldb/examples/python/templates/scripted_frame_provider.py
 create mode 100644 
lldb/include/lldb/Interpreter/Interfaces/ScriptedFrameProviderInterface.h
 rename lldb/{source/Plugins/Process/scripted => 
include/lldb/Interpreter}/ScriptedFrame.h (60%)
 create mode 100644 lldb/include/lldb/Interpreter/ScriptedFrameProvider.h
 rename lldb/{source/Plugins/Process/Utility => 
include/lldb/Target}/RegisterContextMemory.h (92%)
 rename lldb/source/{Plugins/Process/scripted => Interpreter}/ScriptedFrame.cpp 
(66%)
 create mode 100644 lldb/source/Interpreter/ScriptedFrameProvider.cpp
 create mode 100644 
lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedFrameProviderPythonInterface.cpp
 create mode 100644 
lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedFrameProviderPythonInterface.h
 rename lldb/source/{Plugins/Process/Utility => 
Target}/Re

[Lldb-commits] [lldb] [lldb] Adding A new Binding helper for JSONTransport. (PR #159160)

[Jonas Devlieghere via lldb-commits]

@@ -297,6 +354,463 @@ class JSONRPCTransport : public IOTransport {
   static constexpr llvm::StringLiteral kMessageSeparator = "\n";
 };
 
-} // namespace lldb_private
+/// A handler for the response to an outgoing request.
+template 
+using Reply =
+std::conditional_t,
+   llvm::unique_function,
+   llvm::unique_function)>>;
+
+namespace detail {
+template  struct request_t final {
+  using type = llvm::unique_function)>;
+};
+template  struct request_t final {
+  using type = llvm::unique_function)>;
+};
+template  struct event_t final {
+  using type = llvm::unique_function;
+};
+template <> struct event_t final {
+  using type = llvm::unique_function;
+};
+} // namespace detail
+
+template 
+using OutgoingRequest = typename detail::request_t::type;
+
+/// A function to send an outgoing event.
+template  using OutgoingEvent = typename detail::event_t::type;
+
+// FIXME: With c++20, we should use this concept:

JDevlieghere wrote:

I find commented out code really annoying and I strongly prefer putting code 
behind `#if 0`. Or even better, if it compiles with C++20 support, we could 
gate this by `#if __cplusplus >= 202002L`. 

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

[Lldb-commits] [lldb] [lldb] fix the "RegisterValue::SetValueFromData" method for 128-bit integer registers (PR #163646)

[Matej Košík via lldb-commits]

sedymrak wrote:

> Thanks for the reproducer. Please include it in the PR description as well, 
> as it may be the closest thing we get to a test case.

I am not sure if I understand correctly what you meant I should do.
I have edited my first post on this matter to include the instructions how one 
can reproduce the problem.
Is this what you meant?

> 
> I'm still not clear how you found this, but if the answer is:
> 
> * You spotted it by reading code
> 
> * You have a downstream target with registers like this
> 
> * You are working on some NDA'd thing

The problem floated to the surface when we adapted LLDB for debugging programs 
written in a [custom programming 
language](https://codasip.com/products/codasip-studio/codal/) that supports 
non-standard integer sizes.

> 
> Then the conclusion is the same. Hard to test this with an upstream target.

I am not aware of any platform where this bug could be directly reproduced.

I am not sure how much it would help, but I plan (tomorrow) to look at [related 
unit-tests](https://github.com/llvm/llvm-project/blob/77cb19d7aac29215a8cb2f58e35e790b0c94d799/lldb/unittests/Utility/RegisterValueTest.cpp).
 I need to know:
- Why they did not scream when I changed the `RegisterValue::SetValueFromData` 
method?
- Can I add a test that will cover the faulty branch?

At worst I will learn why it cannot be done...

> 
> We have faked targets in testing before, so I think we could fake an AArch64 
> where V registers were not vectors, as this type is set in the XML sent from 
> the debug server. 
> `lldb/test/API/functionalities/gdb_remote_client/TestXMLRegisterFlags.py` is 
> an example of this.
> 
> Then again, I found that there's no public API for this call. Running an 
> expression on a fake target like that could work but it'd be a lot of mock 
> stuff to implement (for a start, we'd need to pretend it can JIT code).
> 
> We have some tests that put a simulated debug sever in front of a real one, 
> but that's too much effort for this fix.
> 
> Let me think about it for a bit. If I don't come up with anything then I'll 
> approve this, as it does look correct to me.

+1


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

[Lldb-commits] [lldb] 550b2ef - [lldb][test][NFC] Rename Language.cpp to LanguageTest.cpp

[Michael Buch via lldb-commits]

Author: Michael Buch
Date: 2025-10-06T07:55:12+01:00
New Revision: 550b2ef041ba16ee8b5f55b5f2307f501b2c15a0

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

LOG: [lldb][test][NFC] Rename Language.cpp to LanguageTest.cpp

So it's consistent with the other tests in this directory.

Also aligns with the source file header comment.

Added: 
lldb/unittests/Target/LanguageTest.cpp

Modified: 
lldb/unittests/Target/CMakeLists.txt

Removed: 
lldb/unittests/Target/Language.cpp



diff  --git a/lldb/unittests/Target/CMakeLists.txt 
b/lldb/unittests/Target/CMakeLists.txt
index 0c79675a3d890..83eec3b1117bf 100644
--- a/lldb/unittests/Target/CMakeLists.txt
+++ b/lldb/unittests/Target/CMakeLists.txt
@@ -2,7 +2,7 @@ add_lldb_unittest(TargetTests
   ABITest.cpp
   DynamicRegisterInfoTest.cpp
   ExecutionContextTest.cpp
-  Language.cpp
+  LanguageTest.cpp
   LocateModuleCallbackTest.cpp
   MemoryRegionInfoTest.cpp
   MemoryTest.cpp

diff  --git a/lldb/unittests/Target/Language.cpp 
b/lldb/unittests/Target/LanguageTest.cpp
similarity index 100%
rename from lldb/unittests/Target/Language.cpp
rename to lldb/unittests/Target/LanguageTest.cpp



___
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 stdio redirection for integrated and external terminals (PR #161089)

[Sergei Druzhkov via lldb-commits]

https://github.com/DrSergei updated 
https://github.com/llvm/llvm-project/pull/161089

>From a6968292f13750262c4cf22d55d8150917cb46be Mon Sep 17 00:00:00 2001
From: Druzhkov Sergei 
Date: Sun, 28 Sep 2025 12:45:01 +0300
Subject: [PATCH 1/2] [lldb-dap] Add stdio redirection for integrated and
 external terminals

---
 .../tools/lldb-dap/launch/TestDAP_launch.py   | 22 +-
 .../tools/lldb-dap/Handler/RequestHandler.cpp |  4 +-
 lldb/tools/lldb-dap/JSONUtils.cpp | 15 -
 lldb/tools/lldb-dap/JSONUtils.h   |  7 +-
 lldb/tools/lldb-dap/Options.td|  6 ++
 .../lldb-dap/Protocol/ProtocolRequests.h  |  1 +
 lldb/tools/lldb-dap/package.json  |  5 +-
 lldb/tools/lldb-dap/tool/lldb-dap.cpp | 67 ++-
 8 files changed, 120 insertions(+), 7 deletions(-)

diff --git a/lldb/test/API/tools/lldb-dap/launch/TestDAP_launch.py 
b/lldb/test/API/tools/lldb-dap/launch/TestDAP_launch.py
index ceef95dfcd0d5..8db2316e73fc8 100644
--- a/lldb/test/API/tools/lldb-dap/launch/TestDAP_launch.py
+++ b/lldb/test/API/tools/lldb-dap/launch/TestDAP_launch.py
@@ -632,7 +632,27 @@ def test_stdio_redirection(self):
 program = self.getBuildArtifact("a.out")
 
 with tempfile.NamedTemporaryFile("rt") as f:
-self.launch(program, stdio=[None, f.name, None])
+self.launch(program, stdio=[None, f.name])
+self.continue_to_exit()
+lines = f.readlines()
+self.assertIn(
+program, lines[0], "make sure program path is in first 
argument"
+)
+
+@skipIfAsan
+@skipIfWindows
+@skipIf(oslist=["linux"], archs=no_match(["x86_64"]))
+def test_stdio_redirection_and_console(self):
+"""
+Test stdio redirection and console.
+"""
+self.build_and_create_debug_adapter()
+program = self.getBuildArtifact("a.out")
+
+with tempfile.NamedTemporaryFile("rt") as f:
+self.launch(
+program, console="integratedTerminal", stdio=[None, f.name, 
None]
+)
 self.continue_to_exit()
 lines = f.readlines()
 self.assertIn(
diff --git a/lldb/tools/lldb-dap/Handler/RequestHandler.cpp 
b/lldb/tools/lldb-dap/Handler/RequestHandler.cpp
index 773891353db6a..e7d9b89653f1c 100644
--- a/lldb/tools/lldb-dap/Handler/RequestHandler.cpp
+++ b/lldb/tools/lldb-dap/Handler/RequestHandler.cpp
@@ -57,7 +57,7 @@ SetupIORedirection(const 
std::vector> &stdio,
   size_t n = std::max(stdio.size(), static_cast(3));
   for (size_t i = 0; i < n; i++) {
 std::optional path;
-if (stdio.size() < i)
+if (stdio.size() <= i)
   path = stdio.back();
 else
   path = stdio[i];
@@ -107,7 +107,7 @@ RunInTerminal(DAP &dap, const 
protocol::LaunchRequestArguments &arguments) {
 
   llvm::json::Object reverse_request = CreateRunInTerminalReverseRequest(
   arguments.configuration.program, arguments.args, arguments.env,
-  arguments.cwd, comm_file.m_path, debugger_pid,
+  arguments.cwd, comm_file.m_path, debugger_pid, arguments.stdio,
   arguments.console == protocol::eConsoleExternalTerminal);
   dap.SendReverseRequest("runInTerminal",
 
std::move(reverse_request));
diff --git a/lldb/tools/lldb-dap/JSONUtils.cpp 
b/lldb/tools/lldb-dap/JSONUtils.cpp
index 4f26599a49bac..9ecb3a36543ce 100644
--- a/lldb/tools/lldb-dap/JSONUtils.cpp
+++ b/lldb/tools/lldb-dap/JSONUtils.cpp
@@ -866,7 +866,8 @@ llvm::json::Value CreateCompileUnit(lldb::SBCompileUnit 
&unit) {
 llvm::json::Object CreateRunInTerminalReverseRequest(
 llvm::StringRef program, const std::vector &args,
 const llvm::StringMap &env, llvm::StringRef cwd,
-llvm::StringRef comm_file, lldb::pid_t debugger_pid, bool external) {
+llvm::StringRef comm_file, lldb::pid_t debugger_pid,
+const std::vector> &stdio, bool external) {
   llvm::json::Object run_in_terminal_args;
   if (external) {
 // This indicates the IDE to open an external terminal window.
@@ -885,6 +886,18 @@ llvm::json::Object CreateRunInTerminalReverseRequest(
   }
   req_args.push_back("--launch-target");
   req_args.push_back(program.str());
+  if (!stdio.empty()) {
+req_args.push_back("--stdio");
+std::stringstream ss;
+for (const auto &file : stdio) {
+  if (file)
+ss << *file;
+  ss << ":";
+}
+std::string files = ss.str();
+files.pop_back();
+req_args.push_back(std::move(files));
+  }
   req_args.insert(req_args.end(), args.begin(), args.end());
   run_in_terminal_args.try_emplace("args", req_args);
 
diff --git a/lldb/tools/lldb-dap/JSONUtils.h b/lldb/tools/lldb-dap/JSONUtils.h
index e9094f67b94ec..0c865a33a6ce4 100644
--- a/lldb/tools/lldb-dap/JSONUtils.h
+++ b/lldb/tools/lldb-dap/JSONUtils.h
@@ -388,6 +388,10 @@ llvm::json::Value CreateCompileUnit(lldb::SBCompileUnit 
&unit);
 /// launcher uses it on Linux tell the kernel that it 

[Lldb-commits] [lldb] 332b4de - [lldb][IRExecutionUnit] Return error on failure to resolve function address (#161363)

[via lldb-commits]

Author: Michael Buch
Date: 2025-10-01T08:37:15+01:00
New Revision: 332b4deb0dfe9f4d11325513d4122e69024beea9

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

LOG: [lldb][IRExecutionUnit] Return error on failure to resolve function 
address (#161363)

Starting with https://github.com/llvm/llvm-project/pull/148877 we
started encoding the module ID of the function DIE we are currently
parsing into its `AsmLabel` in the AST. When the JIT asks LLDB to
resolve our special mangled name, we would locate the module and resolve
the function/symbol we found in it.

If we are debugging with a `SymbolFileDWARFDebugMap`, the module ID we
encode is that of the `.o` file that is tracked by the debug-map. To
resolve the address of the DIE in that `.o` file, we have to ask
`SymbolFileDWARFDebugMap::LinkOSOAddress` to turn the address of the
`.o` DIE into a real address in the linked executable. This will only
work if the `.o` address was actually tracked by the debug-map. However,
if the function definition appears in multiple `.o` files (which is the
case for functions defined in headers), the linker will most likely
de-deuplicate that definition. So most `.o`'s definition DIEs for that
function won't have a contribution in the debug-map, and thus we fail to
resolve the address.

When debugging Clang on Darwin, e.g., you'd see:
```
(lldb) expr CXXDecl->getName()

error: Couldn't look up symbols:
  $__lldb_func::0x1:0x4000d02359da:_ZNK5clang9NamedDecl7getNameEv
Hint: The expression tried to call a function that is not present in the 
target, perhaps because it was optimized out by the compiler.
```
unless you were stopped in the `.o` file whose definition of `getName`
made it into the final executable.

The fix here is to error out if we fail to resolve the address, causing
us to fall back on the old flow which did a lookup by mangled name,
which the `SymbolFileDWARFDebugMap` will handle correctly.

An alternative fix to this would be to encode the
`SymbolFileDWARFDebugMap`'s module-id. And implement
`SymbolFileDWARFDebugMap::ResolveFunctionCallLabel` by doing a mangled
name lookup. The proposed approach doesn't stop us from implementing
that, so we could choose to do it in a follow-up.

rdar://161393045

Added: 
lldb/test/API/lang/cpp/function-call-from-object-file/Makefile

lldb/test/API/lang/cpp/function-call-from-object-file/TestFunctionCallFromObjectFile.py
lldb/test/API/lang/cpp/function-call-from-object-file/common.h
lldb/test/API/lang/cpp/function-call-from-object-file/lib1.cpp
lldb/test/API/lang/cpp/function-call-from-object-file/lib2.cpp
lldb/test/API/lang/cpp/function-call-from-object-file/main.cpp

Modified: 
lldb/source/Expression/IRExecutionUnit.cpp

Removed: 




diff  --git a/lldb/source/Expression/IRExecutionUnit.cpp 
b/lldb/source/Expression/IRExecutionUnit.cpp
index 25d4a87b89ef2..60b9de0d21b2e 100644
--- a/lldb/source/Expression/IRExecutionUnit.cpp
+++ b/lldb/source/Expression/IRExecutionUnit.cpp
@@ -751,7 +751,12 @@ ResolveFunctionCallLabel(FunctionCallLabel &label,
   sc_list.Append(*sc_or_err);
 
   LoadAddressResolver resolver(*sc.target_sp, symbol_was_missing_weak);
-  return resolver.Resolve(sc_list).value_or(LLDB_INVALID_ADDRESS);
+  lldb::addr_t resolved_addr =
+  resolver.Resolve(sc_list).value_or(LLDB_INVALID_ADDRESS);
+  if (resolved_addr == LLDB_INVALID_ADDRESS)
+return llvm::createStringError("couldn't resolve address for function");
+
+  return resolved_addr;
 }
 
 lldb::addr_t

diff  --git a/lldb/test/API/lang/cpp/function-call-from-object-file/Makefile 
b/lldb/test/API/lang/cpp/function-call-from-object-file/Makefile
new file mode 100644
index 0..285bbfbbca4fe
--- /dev/null
+++ b/lldb/test/API/lang/cpp/function-call-from-object-file/Makefile
@@ -0,0 +1,3 @@
+CXX_SOURCES := main.cpp lib1.cpp lib2.cpp
+
+include Makefile.rules

diff  --git 
a/lldb/test/API/lang/cpp/function-call-from-object-file/TestFunctionCallFromObjectFile.py
 
b/lldb/test/API/lang/cpp/function-call-from-object-file/TestFunctionCallFromObjectFile.py
new file mode 100644
index 0..f0a7aef182a67
--- /dev/null
+++ 
b/lldb/test/API/lang/cpp/function-call-from-object-file/TestFunctionCallFromObjectFile.py
@@ -0,0 +1,29 @@
+"""
+Tests that we can call functions that have definitions in multiple
+CUs in the debug-info (which is the case for functions defined in headers).
+The linker will most likely de-duplicate the functiond definitions when linking
+the final executable. On Darwin, this will create a debug-map that LLDB will 
use
+to fix up object file addresses to addresses in the linked executable. However,
+if we parsed the DIE from the object file whose functiond definition got 
stripped
+by the linker, LLDB needs to ensure it can still re

[Lldb-commits] [lldb] [lldb][docs] DW_AT_APPLE_major_runtime_version -> DW_AT_APPLE_major_runtime_vers (PR #162062)

[Michael Buch via lldb-commits]

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

`DW_AT_APPLE_major_runtime_version` doesn't exist. This should be 
`DW_AT_APPLE_major_runtime_vers`.

>From 8420e7126b8dc07df82371dc49da1c1e702c1e68 Mon Sep 17 00:00:00 2001
From: Michael Buch 
Date: Mon, 6 Oct 2025 11:03:53 +0100
Subject: [PATCH] [lldb][docs] DW_AT_APPLE_major_runtime_version ->
 DW_AT_APPLE_major_runtime_vers

`DW_AT_APPLE_major_runtime_version` doesn't exist. This should be
`DW_AT_APPLE_major_runtime_vers`.
---
 lldb/docs/resources/extensions.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lldb/docs/resources/extensions.rst 
b/lldb/docs/resources/extensions.rst
index 30bd6d5c6b8da..61fffe7a56d27 100644
--- a/lldb/docs/resources/extensions.rst
+++ b/lldb/docs/resources/extensions.rst
@@ -134,5 +134,5 @@ Objective-C runtime
 
 Clang emits the Objective-C runtime version into the
 ``DW_TAG_compile_unit`` using the
-``DW_AT_APPLE_major_runtime_version`` attribute. The value 2 stands
+``DW_AT_APPLE_major_runtime_vers`` attribute. The value 2 stands
 for Objective-C 2.0.

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

[Lldb-commits] [lldb] [cmake][lldb][test] Respect LIBCXX_LIBDIR_SUBDIR (PR #159106)

[Raul Tambre via lldb-commits]

tambry wrote:

@Michael137 Added an example in the description. In-tree it's used by Fucshia 
for multilib runtimes but I myself use them in my downstream to install the 
libraries into Debian-style triple system directories instead of LLVM's own 
quadruple-based structure.

Ideally this same logic would be included from libc++ itself but LLVM CMake 
code in general is quite entangled it's hard to tell how this could even be 
shared. 😕

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

[Lldb-commits] [lldb] a7f1910 - [lldb][NFC] Remove unused find_program logic (#163446)

[via lldb-commits]

Author: Alex Langford
Date: 2025-10-14T15:50:28-07:00
New Revision: a7f1910621e7a68631a61c0f4d50ad6542ee1cd7

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

LOG: [lldb][NFC] Remove unused find_program logic (#163446)

All the unifdef logic was moved to source/API/CMakeLists.txt. This was
left behind during that move.

Added: 


Modified: 
lldb/cmake/modules/LLDBFramework.cmake

Removed: 




diff  --git a/lldb/cmake/modules/LLDBFramework.cmake 
b/lldb/cmake/modules/LLDBFramework.cmake
index c6f00ed05cfc2..23d9d49d0cefc 100644
--- a/lldb/cmake/modules/LLDBFramework.cmake
+++ b/lldb/cmake/modules/LLDBFramework.cmake
@@ -68,8 +68,6 @@ if(NOT APPLE_EMBEDDED)
   )
 endif()
 
-find_program(unifdef_EXECUTABLE unifdef)
-
 # Wrap output in a target, so lldb-framework can depend on it.
 add_custom_target(liblldb-resource-headers DEPENDS lldb-sbapi-dwarf-enums 
${lldb_staged_headers})
 set_target_properties(liblldb-resource-headers PROPERTIES FOLDER 
"LLDB/Resources")



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

[Lldb-commits] [lldb] [lldb][test] Wait for a file before attempting to attach to lldb-server test inferior (PR #162064)

[via lldb-commits]

github-actions[bot] wrote:




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



You can test this locally with the following command:


``bash
git-clang-format --diff origin/main HEAD --extensions cpp -- 
lldb/test/API/tools/lldb-server/main.cpp
``

:warning:
The reproduction instructions above might return results for more than one PR
in a stack if you are using a stacked PR workflow. You can limit the results by
changing `origin/main` to the base branch/commit you want to compare against.
:warning:





View the diff from clang-format here.


``diff
diff --git a/lldb/test/API/tools/lldb-server/main.cpp 
b/lldb/test/API/tools/lldb-server/main.cpp
index 688c17a36..7e84552b0 100644
--- a/lldb/test/API/tools/lldb-server/main.cpp
+++ b/lldb/test/API/tools/lldb-server/main.cpp
@@ -5,8 +5,8 @@
 #include 
 #include 
 #include 
-#include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -267,7 +267,8 @@ int main(int argc, char **argv) {
   for (int i = 1; i < argc; ++i) {
 std::string arg = argv[i];
 if (consume_front(arg, "syncfile:")) {
-  // Write to this file to tell test framework that attaching is now 
possible.
+  // Write to this file to tell test framework that attaching is now
+  // possible.
   std::ofstream(arg).close();
 } else if (consume_front(arg, "stderr:")) {
   // Treat remainder as text to go to stderr.

``




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

[Lldb-commits] [lldb] [lldb-dap] Allow empty memory reference in disassemble arguments (PR #162517)

[Jonas Devlieghere via lldb-commits]

@@ -156,11 +156,15 @@ DecodeMemoryReference(llvm::StringRef memoryReference);
 ///Indicates if the key is required to be present, otherwise report an 
error
 ///if the key is missing.
 ///
+/// \param[in] allow_empty
+///Interpret empty string as a valid value, don't report an error (see
+///VSCode issue https://github.com/microsoft/vscode/issues/270593).

JDevlieghere wrote:

Nit: It's `VS Code` not `VSCode` 
(https://code.visualstudio.com/brand#brand-name)

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

[Lldb-commits] [lldb] fca40b3 - [lldb][docs] State that the extension packets doc should be alphabetised

[David Spickett via lldb-commits]

Author: David Spickett
Date: 2025-10-10T15:03:54Z
New Revision: fca40b3b6fdc621e25166cd4b287a9b36b6f46a8

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

LOG: [lldb][docs] State that the extension packets doc should be alphabetised

I did this when I converted it but never stated so. Adding a comment
stating so. We'll probably forget at some point but might as well.

Also moved the x packet to the last place, after wasm which was
added to the end recently.

Added: 


Modified: 
lldb/docs/resources/lldbgdbremote.md

Removed: 




diff  --git a/lldb/docs/resources/lldbgdbremote.md 
b/lldb/docs/resources/lldbgdbremote.md
index 36b95f1073ebc..93fb0c9b5502f 100644
--- a/lldb/docs/resources/lldbgdbremote.md
+++ b/lldb/docs/resources/lldbgdbremote.md
@@ -1,3 +1,6 @@
+
+
 # GDB Remote Protocol Extensions
 
 LLDB has added new GDB server packets to better support multi-threaded and
@@ -2427,43 +2430,6 @@ Response is `F` plus the return value of `unlink()`, 
base 16 encoding.
 Return value may optionally be followed by a comma and the base16
 value of errno if unlink failed.
 
-## "x" - Binary memory read
-
-> **Warning:** The format of this packet was decided before GDB 16
-> introduced its own format for `x`. Future versions of LLDB may not
-> support the format described here, and new code should produce and
-> expect the format used by GDB.
-
-Like the `m` (read) and `M` (write) packets, this is a partner to the
-`X` (write binary data) packet, `x`.
-
-It is called like
-```
-xADDRESS,LENGTH
-```
-
-where both `ADDRESS` and `LENGTH` are big-endian base 16 values.
-
-To test if this packet is available, send a addr/len of 0:
-```
-x0,0
-```
-You will get an `OK` response if it is supported.
-
-The reply will be the data requested in 8-bit binary data format.
-The standard quoting is applied to the payload. Characters `}  #  $  *`
-will all be escaped with `}` (`0x7d`) character and then XOR'ed with `0x20`.
-
-A typical use to read 512 bytes at 0x1000 would look like:
-```
-x0x1000,0x200
-```
-The `0x` prefixes are optional - like most of the gdb-remote packets,
-omitting them will work fine; these numbers are always base 16.
-
-The length of the payload is not provided.  A reliable, 8-bit clean,
-transport layer is assumed.
-
 ## Wasm Packets
 
 The packet below are supported by the
@@ -2530,3 +2496,40 @@ read packet: $e0030100#b9
 
 **Priority to Implement:** Only required for Wasm support. Necessary to show
 variables.
+
+## "x" - Binary memory read
+
+> **Warning:** The format of this packet was decided before GDB 16
+> introduced its own format for `x`. Future versions of LLDB may not
+> support the format described here, and new code should produce and
+> expect the format used by GDB.
+
+Like the `m` (read) and `M` (write) packets, this is a partner to the
+`X` (write binary data) packet, `x`.
+
+It is called like
+```
+xADDRESS,LENGTH
+```
+
+where both `ADDRESS` and `LENGTH` are big-endian base 16 values.
+
+To test if this packet is available, send a addr/len of 0:
+```
+x0,0
+```
+You will get an `OK` response if it is supported.
+
+The reply will be the data requested in 8-bit binary data format.
+The standard quoting is applied to the payload. Characters `}  #  $  *`
+will all be escaped with `}` (`0x7d`) character and then XOR'ed with `0x20`.
+
+A typical use to read 512 bytes at 0x1000 would look like:
+```
+x0x1000,0x200
+```
+The `0x` prefixes are optional - like most of the gdb-remote packets,
+omitting them will work fine; these numbers are always base 16.
+
+The length of the payload is not provided.  A reliable, 8-bit clean,
+transport layer is assumed.



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

[Lldb-commits] [lldb] [lldb] Introduce ScriptedFrameProvider for real threads (PR #161870)

[Med Ismail Bennani via lldb-commits]

@@ -1439,13 +1444,133 @@ void 
Thread::CalculateExecutionContext(ExecutionContext &exe_ctx) {
 StackFrameListSP Thread::GetStackFrameList() {
   std::lock_guard guard(m_frame_mutex);
 
-  if (!m_curr_frames_sp)
-m_curr_frames_sp =
-std::make_shared(*this, m_prev_frames_sp, true);
+  if (!m_curr_frames_sp) {
+
+StackFrameListSP real_frames_sp =
+  std::make_shared(*this, m_prev_frames_sp, true);
+
+if (m_frame_provider_sp) {
+  lldb::ScriptedFrameProviderMergeStrategy strategy =
+  m_frame_provider_sp->GetMergeStrategy();
+  
+  auto scripted_list_or_err = GetScriptedFrameList();
+  if (!scripted_list_or_err) {
+LLDB_LOG_ERROR(GetLog(LLDBLog::Thread),
+   scripted_list_or_err.takeError(),
+   "Failed to get scripted frame list: {0}");
+m_curr_frames_sp = real_frames_sp;
+return m_curr_frames_sp;
+  }
+  
+  StackFrameListSP scripted_frames_sp = *scripted_list_or_err;
+  uint32_t num_real = real_frames_sp->GetNumFrames(true);
+  uint32_t num_scripted = scripted_frames_sp->GetNumFrames(false);
+
+  switch (strategy) {

medismailben wrote:

I don't think the ScriptedFrameProvider should be responsible for that since 
the main source of truth should be the Thread itself.

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

[Lldb-commits] [lldb] [lldb] Support shared cache relative objc method types (PR #163663)

[Jonas Devlieghere via lldb-commits]

https://github.com/JDevlieghere created 
https://github.com/llvm/llvm-project/pull/163663

Support the types and name field in the relative method list to be relative to 
a buffer in the shared cache, not relative to the field in the method list 
itself.

A new magic bit, 0x2000, is attached to method lists where the types are 
encoded in this way. This is covered by the existing tests when running against 
a shared cache that uses this encoding.

rdar://147545351

>From a30d9a91fe36964a1821dd091a0ce3b7f3717668 Mon Sep 17 00:00:00 2001
From: Jonas Devlieghere 
Date: Wed, 15 Oct 2025 17:18:30 -0700
Subject: [PATCH] [lldb] Support shared cache relative objc method types

Support the types and name field in the relative method list to be
relative to a buffer in the shared cache, not relative to the field in
the method list itself.

A new magic bit, 0x2000, is attached to method lists where the types
are encoded in this way. This is covered by the existing tests when
running against a shared cache that uses this encoding.

rdar://147545351
---
 .../AppleObjCClassDescriptorV2.cpp| 27 ---
 .../AppleObjCClassDescriptorV2.h  |  9 ---
 2 files changed, 22 insertions(+), 14 deletions(-)

diff --git 
a/lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCClassDescriptorV2.cpp
 
b/lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCClassDescriptorV2.cpp
index 6d8f41aef1ffc..460c503b25c73 100644
--- 
a/lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCClassDescriptorV2.cpp
+++ 
b/lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCClassDescriptorV2.cpp
@@ -260,6 +260,7 @@ bool ClassDescriptorV2::method_list_t::Read(Process 
*process,
   uint32_t entsize = extractor.GetU32_unchecked(&cursor);
   m_is_small = (entsize & 0x8000) != 0;
   m_has_direct_selector = (entsize & 0x4000) != 0;
+  m_has_relative_types = (entsize & 0x2000) != 0;
   m_entsize = entsize & 0xfffc;
   m_count = extractor.GetU32_unchecked(&cursor);
   m_first_ptr = addr + cursor;
@@ -269,8 +270,9 @@ bool ClassDescriptorV2::method_list_t::Read(Process 
*process,
 
 llvm::SmallVector
 ClassDescriptorV2::ReadMethods(llvm::ArrayRef addresses,
-   lldb::addr_t relative_selector_base_addr,
-   bool is_small, bool has_direct_sel) const {
+   lldb::addr_t relative_string_base_addr,
+   bool is_small, bool has_direct_sel,
+   bool has_relative_types) const {
   lldb_private::Process *process = m_runtime.GetProcess();
   if (!process)
 return {};
@@ -297,8 +299,8 @@ ClassDescriptorV2::ReadMethods(llvm::ArrayRef 
addresses,
 process->GetByteOrder(),
 process->GetAddressByteSize());
 methods.push_back(method_t());
-methods.back().Read(extractor, process, addr, relative_selector_base_addr,
-is_small, has_direct_sel);
+methods.back().Read(extractor, process, addr, relative_string_base_addr,
+is_small, has_direct_sel, has_relative_types);
   }
 
   return methods;
@@ -306,8 +308,9 @@ ClassDescriptorV2::ReadMethods(llvm::ArrayRef 
addresses,
 
 bool ClassDescriptorV2::method_t::Read(DataExtractor &extractor,
Process *process, lldb::addr_t addr,
-   lldb::addr_t 
relative_selector_base_addr,
-   bool is_small, bool has_direct_sel) {
+   lldb::addr_t relative_string_base_addr,
+   bool is_small, bool has_direct_sel,
+   bool has_relative_types) {
   lldb::offset_t cursor = 0;
 
   if (is_small) {
@@ -323,10 +326,13 @@ bool ClassDescriptorV2::method_t::Read(DataExtractor 
&extractor,
   m_name_ptr = process->ReadPointerFromMemory(m_name_ptr, error);
   if (error.Fail())
 return false;
-} else if (relative_selector_base_addr != LLDB_INVALID_ADDRESS) {
-  m_name_ptr = relative_selector_base_addr + nameref_offset;
+} else if (relative_string_base_addr != LLDB_INVALID_ADDRESS) {
+  m_name_ptr = relative_string_base_addr + nameref_offset;
 }
-m_types_ptr = addr + 4 + types_offset;
+if (has_relative_types)
+  m_types_ptr = relative_string_base_addr + types_offset;
+else
+  m_types_ptr = addr + 4 + types_offset;
 m_imp_ptr = addr + 8 + imp_offset;
   } else {
 m_name_ptr = extractor.GetAddress_unchecked(&cursor);
@@ -481,7 +487,8 @@ bool ClassDescriptorV2::ProcessMethodList(
 
   llvm::SmallVector methods =
   ReadMethods(addresses, m_runtime.GetRelativeSelectorBaseAddr(),
-  method_list.m_is_small, method_list.m_has_direct_selector);
+  method_list.m_is_small, method_list.m_has_direct_

[Lldb-commits] [lldb] [lldb][windows] add support for out of PATH python.dll resolution (PR #162509)

[Alex Langford via lldb-commits]

bulbazord wrote:

Should this be an `ifdef`?

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

[Lldb-commits] [lldb] [lldb][test] check if CoreDumping is supported at runtime (PR #161385)

[Michael Buch via lldb-commits]

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


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

[Lldb-commits] [lldb] support attaching by name for platform android (PR #160931)

[Walter Erquinigo via lldb-commits]

@@ -477,6 +477,248 @@ std::string PlatformAndroid::GetRunAs() {
   }
   return run_as.str();
 }
+
+// Helper function to populate process status information from
+// /proc/[pid]/status
+void PlatformAndroid::PopulateProcessStatusInfo(
+lldb::pid_t pid, ProcessInstanceInfo &process_info) {
+  // Read /proc/[pid]/status to get parent PID, UIDs, and GIDs
+  Status error;
+  auto status_adb = GetAdbClient(error);
+  if (error.Fail())
+return;
+
+  std::string status_output;
+  StreamString status_cmd;
+  status_cmd.Printf(
+  "cat /proc/%llu/status 2>/dev/null | grep -E '^(PPid|Uid|Gid):'",
+  (unsigned long long)pid);
+  Status status_error =
+  status_adb->Shell(status_cmd.GetData(), seconds(5), &status_output);
+
+  if (status_error.Fail() || status_output.empty())
+return;
+
+  llvm::SmallVector lines;
+  llvm::StringRef(status_output).split(lines, '\n');
+
+  for (llvm::StringRef line : lines) {
+line = line.trim();
+if (line.starts_with("PPid:")) {
+  llvm::StringRef ppid_str = line.substr(5).trim();
+  lldb::pid_t ppid;
+  if (llvm::to_integer(ppid_str, ppid))
+process_info.SetParentProcessID(ppid);
+} else if (line.starts_with("Uid:")) {
+  llvm::SmallVector uid_parts;
+  line.substr(4).trim().split(uid_parts, '\t', -1, false);
+  if (uid_parts.size() >= 2) {
+uint32_t uid, euid;
+if (llvm::to_integer(uid_parts[0].trim(), uid))
+  process_info.SetUserID(uid);
+if (llvm::to_integer(uid_parts[1].trim(), euid))
+  process_info.SetEffectiveUserID(euid);
+  }
+} else if (line.starts_with("Gid:")) {
+  llvm::SmallVector gid_parts;
+  line.substr(4).trim().split(gid_parts, '\t', -1, false);
+  if (gid_parts.size() >= 2) {
+uint32_t gid, egid;
+if (llvm::to_integer(gid_parts[0].trim(), gid))
+  process_info.SetGroupID(gid);
+if (llvm::to_integer(gid_parts[1].trim(), egid))
+  process_info.SetEffectiveGroupID(egid);
+  }
+}
+  }
+}
+
+// Helper function to populate command line arguments from /proc/[pid]/cmdline
+void PlatformAndroid::PopulateProcessCommandLine(
+lldb::pid_t pid, ProcessInstanceInfo &process_info) {
+  // Read /proc/[pid]/cmdline to get command line arguments
+  Status error;
+  auto cmdline_adb = GetAdbClient(error);
+  if (error.Fail())
+return;
+
+  std::string cmdline_output;
+  StreamString cmdline_cmd;
+  cmdline_cmd.Printf("cat /proc/%llu/cmdline 2>/dev/null | tr '\\000' ' '",
+ (unsigned long long)pid);
+  Status cmdline_error =
+  cmdline_adb->Shell(cmdline_cmd.GetData(), seconds(5), &cmdline_output);
+
+  if (cmdline_error.Fail() || cmdline_output.empty())
+return;
+
+  cmdline_output = llvm::StringRef(cmdline_output).trim().str();
+  if (cmdline_output.empty())
+return;
+
+  llvm::SmallVector args;
+  llvm::StringRef(cmdline_output).split(args, ' ', -1, false);
+  if (args.empty())
+return;
+
+  process_info.SetArg0(args[0]);
+  Args process_args;
+  for (size_t i = 1; i < args.size(); i++) {
+if (!args[i].empty())
+  process_args.AppendArgument(args[i]);
+  }
+  process_info.SetArguments(process_args, false);
+}
+
+// Helper function to populate architecture from /proc/[pid]/exe
+void PlatformAndroid::PopulateProcessArchitecture(
+lldb::pid_t pid, ProcessInstanceInfo &process_info) {
+  // Read /proc/[pid]/exe to get executable path for architecture detection
+  Status error;
+  auto exe_adb = GetAdbClient(error);
+  if (error.Fail())
+return;
+
+  std::string exe_output;
+  StreamString exe_cmd;
+  exe_cmd.Printf("readlink /proc/%llu/exe 2>/dev/null",
+ (unsigned long long)pid);

walter-erquinigo wrote:

ditto

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

[Lldb-commits] [lldb] [lldb] Introduce ScriptedFrameProvider for real threads (PR #161870)

[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 origin/main...HEAD 
lldb/examples/python/templates/scripted_frame_provider.py 
lldb/test/API/functionalities/scripted_frame_provider/TestScriptedFrameProvider.py
 
lldb/test/API/functionalities/scripted_frame_provider/c_python_frame_provider.py
 lldb/test/API/functionalities/scripted_frame_provider/test_frame_providers.py 
lldb/test/API/python_api/frame_list/TestSBFrameList.py 
lldb/examples/python/templates/scripted_process.py
``

:warning:
The reproduction instructions above might return results for more than one PR
in a stack if you are using a stacked PR workflow. You can limit the results by
changing `origin/main` to the base branch/commit you want to compare against.
:warning:





View the diff from darker here.


``diff
--- test/API/functionalities/scripted_frame_provider/c_python_frame_provider.py 
2025-10-15 03:23:33.00 +
+++ test/API/functionalities/scripted_frame_provider/c_python_frame_provider.py 
2025-10-15 03:25:32.616217 +
@@ -1,10 +1,11 @@
 import lldb
 from lldb.plugins.scripted_process import ScriptedFrame
 from lldb.plugins.scripted_frame_provider import ScriptedFrameProvider
 
 import inspect, re
+
 
 class CPythonScriptedFrame(ScriptedFrame):
 """CPython scripted frame with full control over frame behavior."""
 
 def __init__(self, thread, idx, py_frame_info):
@@ -21,11 +22,10 @@
 line_entry.SetLine(py_frame_info.positions.lineno)
 line_entry.SetColumn(py_frame_info.positions.col_offset)
 
 self.sym_ctx = lldb.SBSymbolContext()
 self.sym_ctx.SetLineEntry(line_entry)
-
 
 def get_id(self):
 return self.idx
 
 def get_pc(self):
@@ -61,6 +61,5 @@
 frames = []
 for idx, py_frame in enumerate(python_frames):
 frames.append(CPythonScriptedFrame(self.thread, idx, py_frame))
 
 return frames
-

``




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

[Lldb-commits] [lldb] [lldb] Ignore trailing spaces on quit confirmation (PR #162263)

[Jonas Devlieghere via lldb-commits]

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

LGTM!

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

[Lldb-commits] [lldb] [LLDB][NativePDB] Consolidate simple types (PR #163209)

[via lldb-commits]

https://github.com/Nerixyz updated 
https://github.com/llvm/llvm-project/pull/163209

>From cc32535a5a7c0ec28d30e7f029af06b61d78beab Mon Sep 17 00:00:00 2001
From: Nerixyz 
Date: Mon, 13 Oct 2025 16:20:19 +0200
Subject: [PATCH 1/2] [LLDB][NativePDB] Consolidate simple types

---
 .../Plugins/SymbolFile/NativePDB/PdbUtil.cpp  | 28 -
 .../NativePDB/SymbolFileNativePDB.cpp | 62 ++-
 .../SymbolFile/NativePDB/simple-types.cpp | 29 ++---
 3 files changed, 97 insertions(+), 22 deletions(-)

diff --git a/lldb/source/Plugins/SymbolFile/NativePDB/PdbUtil.cpp 
b/lldb/source/Plugins/SymbolFile/NativePDB/PdbUtil.cpp
index 888bd89a72625..f84508478ae6c 100644
--- a/lldb/source/Plugins/SymbolFile/NativePDB/PdbUtil.cpp
+++ b/lldb/source/Plugins/SymbolFile/NativePDB/PdbUtil.cpp
@@ -946,17 +946,21 @@ 
lldb_private::npdb::GetCompilerTypeForSimpleKind(SimpleTypeKind kind) {
   case SimpleTypeKind::Complex64:
 return lldb::eBasicTypeDoubleComplex;
   case SimpleTypeKind::Complex32:
+  case SimpleTypeKind::Complex32PartialPrecision:
 return lldb::eBasicTypeFloatComplex;
-  case SimpleTypeKind::Float128:
   case SimpleTypeKind::Float80:
 return lldb::eBasicTypeLongDouble;
+  case SimpleTypeKind::Float128:
+return lldb::eBasicTypeFloat128;
   case SimpleTypeKind::Float64:
 return lldb::eBasicTypeDouble;
   case SimpleTypeKind::Float32:
+  case SimpleTypeKind::Float32PartialPrecision:
 return lldb::eBasicTypeFloat;
   case SimpleTypeKind::Float16:
 return lldb::eBasicTypeHalf;
   case SimpleTypeKind::Int128:
+  case SimpleTypeKind::Int128Oct:
 return lldb::eBasicTypeInt128;
   case SimpleTypeKind::Int64:
   case SimpleTypeKind::Int64Quad:
@@ -967,6 +971,7 @@ 
lldb_private::npdb::GetCompilerTypeForSimpleKind(SimpleTypeKind kind) {
   case SimpleTypeKind::Int16Short:
 return lldb::eBasicTypeShort;
   case SimpleTypeKind::UInt128:
+  case SimpleTypeKind::UInt128Oct:
 return lldb::eBasicTypeUnsignedInt128;
   case SimpleTypeKind::UInt64:
   case SimpleTypeKind::UInt64Quad:
@@ -985,6 +990,15 @@ 
lldb_private::npdb::GetCompilerTypeForSimpleKind(SimpleTypeKind kind) {
 return lldb::eBasicTypeVoid;
   case SimpleTypeKind::WideCharacter:
 return lldb::eBasicTypeWChar;
+
+  case SimpleTypeKind::None:
+  case SimpleTypeKind::NotTranslated:
+
+  // unsupported
+  case SimpleTypeKind::Float48:
+  case SimpleTypeKind::Complex16:
+  case SimpleTypeKind::Complex48:
+  case SimpleTypeKind::Complex128:
   default:
 return lldb::eBasicTypeInvalid;
   }
@@ -993,8 +1007,11 @@ 
lldb_private::npdb::GetCompilerTypeForSimpleKind(SimpleTypeKind kind) {
 size_t lldb_private::npdb::GetTypeSizeForSimpleKind(SimpleTypeKind kind) {
   switch (kind) {
   case SimpleTypeKind::Boolean128:
+  case SimpleTypeKind::Complex128:
   case SimpleTypeKind::Int128:
+  case SimpleTypeKind::Int128Oct:
   case SimpleTypeKind::UInt128:
+  case SimpleTypeKind::UInt128Oct:
   case SimpleTypeKind::Float128:
 return 16;
   case SimpleTypeKind::Complex80:
@@ -1008,10 +1025,15 @@ size_t 
lldb_private::npdb::GetTypeSizeForSimpleKind(SimpleTypeKind kind) {
   case SimpleTypeKind::Int64:
   case SimpleTypeKind::Int64Quad:
 return 8;
+  case SimpleTypeKind::Complex48:
+  case SimpleTypeKind::Float48:
+return 6;
   case SimpleTypeKind::Boolean32:
   case SimpleTypeKind::Character32:
   case SimpleTypeKind::Complex32:
+  case SimpleTypeKind::Complex32PartialPrecision:
   case SimpleTypeKind::Float32:
+  case SimpleTypeKind::Float32PartialPrecision:
   case SimpleTypeKind::Int32:
   case SimpleTypeKind::Int32Long:
   case SimpleTypeKind::UInt32Long:
@@ -1020,6 +1042,7 @@ size_t 
lldb_private::npdb::GetTypeSizeForSimpleKind(SimpleTypeKind kind) {
 return 4;
   case SimpleTypeKind::Boolean16:
   case SimpleTypeKind::Character16:
+  case SimpleTypeKind::Complex16:
   case SimpleTypeKind::Float16:
   case SimpleTypeKind::Int16:
   case SimpleTypeKind::Int16Short:
@@ -1035,7 +1058,10 @@ size_t 
lldb_private::npdb::GetTypeSizeForSimpleKind(SimpleTypeKind kind) {
   case SimpleTypeKind::SByte:
   case SimpleTypeKind::Character8:
 return 1;
+
   case SimpleTypeKind::Void:
+  case SimpleTypeKind::None:
+  case SimpleTypeKind::NotTranslated:
   default:
 return 0;
   }
diff --git a/lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp 
b/lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp
index 7e275f196d10e..b202b19b65ee1 100644
--- a/lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp
+++ b/lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp
@@ -152,14 +152,24 @@ static bool IsFunctionEpilogue(const CompilandIndexItem 
&cci,
   return false;
 }
 
+// See llvm::codeview::TypeIndex::simpleTypeName as well as strForPrimitiveTi
+// from the original pdbdump:
+// 
https://github.com/microsoft/microsoft-pdb/blob/805655a28bd8198004be2ac27e6e0290121a5e89/pdbdump/pdbdump.cpp#L1896-L1974
+//
+// For 64bit integers we use "long long" like DIA ins

[Lldb-commits] [lldb] b66dfa7 - [LLDB] Add load core time to target metrics (#161581)

[via lldb-commits]

Author: Jacob Lalonde
Date: 2025-10-01T21:14:23Z
New Revision: b66dfa7273f0d7953965e00af3999315a015a563

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

LOG: [LLDB] Add load core time to target metrics (#161581)

This patch adds a load core time, right now we don't have much insight
into the performance of load core, especially for large coredumps. To
start collecting information on this I've added some minor
instrumentation code to measure the two call sites of `LoadCore`.

I've also added a test to validate the new metric is output in
statistics dump

Added: 
lldb/test/API/functionalities/stats_api/arm64-minidump-build-ids.yaml

Modified: 
lldb/include/lldb/Target/Statistics.h
lldb/source/API/SBTarget.cpp
lldb/source/Commands/CommandObjectTarget.cpp
lldb/source/Target/Statistics.cpp
lldb/test/API/functionalities/stats_api/TestStatisticsAPI.py

Removed: 




diff  --git a/lldb/include/lldb/Target/Statistics.h 
b/lldb/include/lldb/Target/Statistics.h
index d6983bb0b9d24..2653835206ec7 100644
--- a/lldb/include/lldb/Target/Statistics.h
+++ b/lldb/include/lldb/Target/Statistics.h
@@ -322,12 +322,14 @@ class TargetStats {
   void IncreaseSourceRealpathCompatibleCount(uint32_t count);
 
   StatsDuration &GetCreateTime() { return m_create_time; }
+  StatsDuration &GetLoadCoreTime() { return m_load_core_time; }
   StatsSuccessFail &GetExpressionStats() { return m_expr_eval; }
   StatsSuccessFail &GetFrameVariableStats() { return m_frame_var; }
   void Reset(Target &target);
 
 protected:
   StatsDuration m_create_time;
+  StatsDuration m_load_core_time;
   std::optional m_launch_or_attach_time;
   std::optional m_first_private_stop_time;
   std::optional m_first_public_stop_time;

diff  --git a/lldb/source/API/SBTarget.cpp b/lldb/source/API/SBTarget.cpp
index eb56337de3c44..90ffe786c696c 100644
--- a/lldb/source/API/SBTarget.cpp
+++ b/lldb/source/API/SBTarget.cpp
@@ -255,6 +255,7 @@ SBProcess SBTarget::LoadCore(const char *core_file, 
lldb::SBError &error) {
 ProcessSP process_sp(target_sp->CreateProcess(
 target_sp->GetDebugger().GetListener(), "", &filespec, false));
 if (process_sp) {
+  ElapsedTime loadCoreTime(target_sp->GetStatistics().GetLoadCoreTime());
   error.SetError(process_sp->LoadCore());
   if (error.Success())
 sb_process.SetSP(process_sp);

diff  --git a/lldb/source/Commands/CommandObjectTarget.cpp 
b/lldb/source/Commands/CommandObjectTarget.cpp
index 940be42d1b6e3..b5fc49d58c1eb 100644
--- a/lldb/source/Commands/CommandObjectTarget.cpp
+++ b/lldb/source/Commands/CommandObjectTarget.cpp
@@ -418,7 +418,11 @@ class CommandObjectTargetCreate : public 
CommandObjectParsed {
 if (process_sp) {
   // Seems weird that we Launch a core file, but that is what we
   // do!
-  error = process_sp->LoadCore();
+  {
+ElapsedTime loadCoreTime(
+target_sp->GetStatistics().GetLoadCoreTime());
+error = process_sp->LoadCore();
+  }
 
   if (error.Fail()) {
 result.AppendError(error.AsCString("unknown core file format"));

diff  --git a/lldb/source/Target/Statistics.cpp 
b/lldb/source/Target/Statistics.cpp
index 8ad8d507268e2..f7311a8b24416 100644
--- a/lldb/source/Target/Statistics.cpp
+++ b/lldb/source/Target/Statistics.cpp
@@ -148,6 +148,11 @@ TargetStats::ToJSON(Target &target,
 target_metrics_json.try_emplace("targetCreateTime",
 m_create_time.get().count());
 
+if (m_load_core_time.get().count() > 0) {
+  target_metrics_json.try_emplace("loadCoreTime",
+  m_load_core_time.get().count());
+}
+
 json::Array breakpoints_array;
 double totalBreakpointResolveTime = 0.0;
 // Report both the normal breakpoint list and the internal breakpoint list.

diff  --git a/lldb/test/API/functionalities/stats_api/TestStatisticsAPI.py 
b/lldb/test/API/functionalities/stats_api/TestStatisticsAPI.py
index f06c9ae14bb7a..d7249df350fc1 100644
--- a/lldb/test/API/functionalities/stats_api/TestStatisticsAPI.py
+++ b/lldb/test/API/functionalities/stats_api/TestStatisticsAPI.py
@@ -1,6 +1,7 @@
 # Test the SBAPI for GetStatistics()
 
 import json
+
 import lldb
 from lldbsuite.test.decorators import *
 from lldbsuite.test.lldbtest import *
@@ -54,6 +55,11 @@ def test_stats_api(self):
 stats_json,
 'Make sure the "frameVariable" key in in 
target.GetStatistics()["targets"][0]',
 )
+self.assertNotIn(
+"loadCoreTime",
+stats_json,
+"LoadCoreTime should not be present in a live, non-coredump 
target",
+)
 expressionEvaluation = stats_json["expressionEvaluation"]
   

[Lldb-commits] [clang] [lldb] [llvm] [ADT] Mark StringSwitch Cases with 6+ arguments as deprecated. NFC. (PR #163405)

[Sam Elliott via lldb-commits]

lenary wrote:

That seems reasonable, can you document the reasoning in the commit message 
please?

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

[Lldb-commits] [lldb] [lldb/cmake] unittests: Breakpoint: remove liblldb dep (PR #162571)

[Kees Cook via lldb-commits]

kees wrote:

I think this got fixed by commit 
https://github.com/llvm/llvm-project/commit/1395d4315bf49be64817b79e3863d183bb28c3e1
 ?

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

[Lldb-commits] [lldb] [debugserver] Implement MultiMemRead packet (PR #162670)

[Jason Molenda via lldb-commits]

jasonmolenda wrote:

Looks very good, I had a couple of small suggestions but thumbs-up from me.

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

[Lldb-commits] [lldb] [lldb] Implement Process::ReadMemoryRanges (PR #163651)

[via lldb-commits]

github-actions[bot] wrote:




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



You can test this locally with the following command:


``bash
git-clang-format --diff origin/main HEAD --extensions cpp,h -- 
lldb/include/lldb/Target/Process.h 
lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCClassDescriptorV2.cpp
 lldb/source/Target/Process.cpp lldb/unittests/Target/MemoryTest.cpp 
--diff_from_common_commit
``

:warning:
The reproduction instructions above might return results for more than one PR
in a stack if you are using a stacked PR workflow. You can limit the results by
changing `origin/main` to the base branch/commit you want to compare against.
:warning:





View the diff from clang-format here.


``diff
diff --git a/lldb/unittests/Target/MemoryTest.cpp 
b/lldb/unittests/Target/MemoryTest.cpp
index 1317dd27b..3bf7b7572 100644
--- a/lldb/unittests/Target/MemoryTest.cpp
+++ b/lldb/unittests/Target/MemoryTest.cpp
@@ -234,8 +234,8 @@ class DummyReaderProcess : public Process {
 public:
   size_t DoReadMemory(lldb::addr_t vm_addr, void *buf, size_t size,
   Status &error) override {
-uint8_t *buffer = static_cast(buf);
-for(size_t addr = vm_addr; addr < vm_addr + size; addr++)
+uint8_t *buffer = static_cast(buf);
+for (size_t addr = vm_addr; addr < vm_addr + size; addr++)
   buffer[addr - vm_addr] = addr;
 return size;
   }

``




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

[Lldb-commits] [lldb] [gdbremote] Document MultiMemRead packet in protocol extensions (PR #162675)

[David Spickett via lldb-commits]

@@ -735,6 +735,56 @@ This is a performance optimization, which speeds up 
debugging by avoiding
 multiple round-trips for retrieving thread information. The information from 
this
 packet can be retrieved using a combination of `qThreadStopInfo` and `m` 
packets.
 
+### MultiMemRead
+
+Read memory from multiple memory ranges.
+
+This packet has one argument:
+
+* `ranges`: a list of pairs of numbers, formatted in base-16. Each pair is
+separated by a `,`, as is each number in each pair. The first number of the
+pair denotes the base address of the memory read, the second denotes the number
+of bytes to be read. The list must end with a `;`.
+
+The reply packet starts with a comma-separated list of numbers formatted in
+base-16, denoting how many bytes were read from each range, in the same order
+as the request packet. The list is followed by a `;`, followed by a sequence of
+bytes containing binary encoded data for all memory that was read. The length
+of this sequence must be equal to the sum of the numbers provided at the start
+of the reply. The order of the binary data is the same as the order of the
+ranges in the request packet.
+
+If an entire range is not readable, the stub may perform a partial read of a
+prefix of the range.

DavidSpickett wrote:

I would add:
In other words, partial reads will only ever be from the start of the range, 
never the middle or end.

A prefix is a nice way to say it but not immediately obvious.

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

[Lldb-commits] [lldb] [lldb][test] Make Linux cpuinfo check more robust (PR #160675)

[via lldb-commits]

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: David Spickett (DavidSpickett)


Changes

We were looking for any mention of the feature name in cpuinfo, which could 
have hit anything including features with common prefixes like sme, sme2, 
smefa64.

Luckily this was not a problem but I'm changing this to find the features line 
and split the features into a list. Then we are only looking for exact matches.

Here's the information for one core as an example:
```
processor   : 7
BogoMIPS: 200.00
Features: fp asimd evtstrm crc32 atomics fphp asimdhp cpuid <...>
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x0
CPU part: 0xd0f
CPU revision: 0
```
(and to avoid any doubt, this is from a CPU simulated in Arm's FVP, it's not 
real)

Note that the layout of the label, colon, values is sometimes aligned but not 
always. So I trim whitespace a few times to normalise that.

This repeats once for each core so we only need to find one features line.

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


1 Files Affected:

- (modified) lldb/packages/Python/lldbsuite/test/cpu_feature.py (+10-3) 


``diff
diff --git a/lldb/packages/Python/lldbsuite/test/cpu_feature.py 
b/lldb/packages/Python/lldbsuite/test/cpu_feature.py
index 3f43cbba130c0..9cdf46d688dd1 100644
--- a/lldb/packages/Python/lldbsuite/test/cpu_feature.py
+++ b/lldb/packages/Python/lldbsuite/test/cpu_feature.py
@@ -39,9 +39,16 @@ def _is_supported_linux(self, cmd_runner):
 if err.Fail() or retcode != 0:
 return output, False
 
-# FIXME: simple substring match, e.g., test for 'sme' will be true if
-# 'sme2' or 'smefa64' is present
-return None, (self.cpu_info_flag in output)
+# Assume that every processor presents the same features.
+# Look for the first "Features: " line.
+for line in output.splitlines():
+line = line.strip()
+if line.startswith("Features"):
+# Feature names are space separated.
+features = line.split(":")[1].strip().split()
+return None, (self.cpu_info_flag in features)
+
+return f'No "Features:" line found in /proc/cpuinfo', False
 
 def _is_supported_darwin(self, cmd_runner):
 if not self.sysctl_key:

``




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

[Lldb-commits] [lldb] Add a scripted way to re-present a stop location (PR #158128)

[Jonas Devlieghere via lldb-commits]

@@ -454,8 +525,13 @@ bool 
BreakpointLocation::SetBreakpointSite(BreakpointSiteSP &bp_site_sp) {
 }
 
 llvm::Error BreakpointLocation::ClearBreakpointSite() {
-  if (!m_bp_site_sp)
-return llvm::createStringError("no breakpoint site to clear");
+  if (!m_bp_site_sp) {
+// This might be a Facade Location, which don't have sites or addresses
+if (IsFacade())
+  return llvm::Error::success();
+else
+  return llvm::createStringError("no breakpoint site to clear");

JDevlieghere wrote:

[No else after 
return](https://llvm.org/docs/CodingStandards.html#don-t-use-else-after-a-return).

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

[Lldb-commits] [lldb] [lldb][DataFormatter][NFC] LibCxxUnorderedMap: remove unused variable (PR #163226)

[Michael Buch via lldb-commits]

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

[Lldb-commits] [lldb] [debugserver] Support for `qMemTags` packet (PR #160952)

[David Spickett via lldb-commits]

@@ -213,22 +213,39 @@
 }
 
 //--
-// MachTask::MemoryRegionInfo
+// MachTask::GetMemoryRegionInfo

DavidSpickett wrote:

You can send this as it's own PR (or push it direct if you have access).

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

[Lldb-commits] [lldb] [lldb-dap] Unify the timeouts for the DAP tests (PR #163292)

[John Harrison via lldb-commits]

@@ -155,15 +152,13 @@ def assertCapabilityIsNotSet(self, key: str, msg: 
Optional[str] = None) -> None:
 if key in self.dap_server.capabilities:
 self.assertEqual(self.dap_server.capabilities[key], False, msg)
 
-def verify_breakpoint_hit(
-self, breakpoint_ids: List[Union[int, str]], timeout: float = 
DEFAULT_TIMEOUT
-):
+def verify_breakpoint_hit(self, breakpoint_ids: List[Union[int, str]]):

ashgti wrote:

This reminds me, I want to revisit breakpoint id handling.

We're inconsistent in handling breakpoint ids. Some APIs take them as strings, 
some convert them to strings and some take them as ints. They're an `int` in 
the spec, but I'm not sure why we're converting them into strings...

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

[Lldb-commits] [clang] [clang-tools-extra] [flang] [lldb] [llvm] [clang] Move options from clangDriver into new clangOptions library (NFC) (PR #163659)

[via lldb-commits]

llvmbot wrote:




@llvm/pr-subscribers-flang-driver

Author: Naveen Seth Hanig (naveen-seth)


Changes

The goal of this change is to remove dependencies on the Driver.

This is part of a larger effort to support driver-managed builds for 
compilations using C++ named modules and/or Clang modules. 
It is required to eventually allow linking the dependency scanning tooling 
against the Driver without creating cyclic dependencies, which would cause 
build failures when dynamic linking is enabled.

This PR is motivated by the following review comment: 
https://github.com/llvm/llvm-project/pull/152770#discussion_r2430756918

---

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


114 Files Affected:

- (modified) clang-tools-extra/clangd/CMakeLists.txt (+1) 
- (modified) clang-tools-extra/clangd/CompileCommands.cpp (+13-13) 
- (modified) clang-tools-extra/modularize/CMakeLists.txt (+1) 
- (modified) clang-tools-extra/modularize/CoverageChecker.cpp (+3-3) 
- (modified) clang-tools-extra/modularize/Modularize.cpp (+2-2) 
- (modified) clang-tools-extra/modularize/ModularizeUtilities.cpp (+3-3) 
- (modified) clang-tools-extra/pp-trace/CMakeLists.txt (+1) 
- (modified) clang-tools-extra/pp-trace/PPTrace.cpp (+1-1) 
- (modified) clang/docs/InternalsManual.rst (+4-4) 
- (modified) clang/include/clang/CMakeLists.txt (+1-1) 
- (modified) clang/include/clang/Driver/Driver.h (+1-1) 
- (modified) clang/include/clang/Frontend/Utils.h (+1-1) 
- (renamed) clang/include/clang/Options/CMakeLists.txt () 
- (renamed) clang/include/clang/Options/ClangOptionDocs.td (+1-1) 
- (renamed) clang/include/clang/Options/OptionUtils.h (+3-3) 
- (renamed) clang/include/clang/Options/Options.h (+8-10) 
- (renamed) clang/include/clang/Options/Options.td () 
- (modified) clang/lib/CMakeLists.txt (+1) 
- (modified) clang/lib/Driver/CMakeLists.txt (+1-2) 
- (modified) clang/lib/Driver/Compilation.cpp (+1-1) 
- (modified) clang/lib/Driver/Driver.cpp (+1-1) 
- (modified) clang/lib/Driver/SanitizerArgs.cpp (+1-1) 
- (modified) clang/lib/Driver/ToolChain.cpp (+3-3) 
- (modified) clang/lib/Driver/ToolChains/AIX.cpp (+3-2) 
- (modified) clang/lib/Driver/ToolChains/AMDGPU.cpp (+9-9) 
- (modified) clang/lib/Driver/ToolChains/AMDGPU.h (+1-1) 
- (modified) clang/lib/Driver/ToolChains/AMDGPUOpenMP.cpp (+1-1) 
- (modified) clang/lib/Driver/ToolChains/AVR.cpp (+1-1) 
- (modified) clang/lib/Driver/ToolChains/Arch/AArch64.cpp (+2-2) 
- (modified) clang/lib/Driver/ToolChains/Arch/ARM.cpp (+2-2) 
- (modified) clang/lib/Driver/ToolChains/Arch/CSKY.cpp (+3-3) 
- (modified) clang/lib/Driver/ToolChains/Arch/LoongArch.cpp (+2-2) 
- (modified) clang/lib/Driver/ToolChains/Arch/M68k.cpp (+8-8) 
- (modified) clang/lib/Driver/ToolChains/Arch/Mips.cpp (+2-2) 
- (modified) clang/lib/Driver/ToolChains/Arch/PPC.cpp (+1-1) 
- (modified) clang/lib/Driver/ToolChains/Arch/RISCV.cpp (+1-1) 
- (modified) clang/lib/Driver/ToolChains/Arch/Sparc.cpp (+2-2) 
- (modified) clang/lib/Driver/ToolChains/Arch/SystemZ.cpp (+4-4) 
- (modified) clang/lib/Driver/ToolChains/Arch/VE.cpp (+1-1) 
- (modified) clang/lib/Driver/ToolChains/Arch/X86.cpp (+9-9) 
- (modified) clang/lib/Driver/ToolChains/BareMetal.cpp (+2-2) 
- (modified) clang/lib/Driver/ToolChains/CSKYToolChain.cpp (+1-1) 
- (modified) clang/lib/Driver/ToolChains/Clang.cpp (+6-6) 
- (modified) clang/lib/Driver/ToolChains/CommonArgs.cpp (+10-10) 
- (modified) clang/lib/Driver/ToolChains/CrossWindows.cpp (+1-1) 
- (modified) clang/lib/Driver/ToolChains/Cuda.cpp (+4-4) 
- (modified) clang/lib/Driver/ToolChains/Cygwin.cpp (+2-2) 
- (modified) clang/lib/Driver/ToolChains/Darwin.cpp (+3-3) 
- (modified) clang/lib/Driver/ToolChains/DragonFly.cpp (+2-2) 
- (modified) clang/lib/Driver/ToolChains/Flang.cpp (+2-2) 
- (modified) clang/lib/Driver/ToolChains/FreeBSD.cpp (+2-2) 
- (modified) clang/lib/Driver/ToolChains/Fuchsia.cpp (+2-2) 
- (modified) clang/lib/Driver/ToolChains/Gnu.cpp (+4-4) 
- (modified) clang/lib/Driver/ToolChains/HIPAMD.cpp (+1-1) 
- (modified) clang/lib/Driver/ToolChains/HIPSPV.cpp (+2-2) 
- (modified) clang/lib/Driver/ToolChains/HIPUtility.cpp (+1-1) 
- (modified) clang/lib/Driver/ToolChains/Hexagon.cpp (+1-1) 
- (modified) clang/lib/Driver/ToolChains/Hurd.cpp (+2-2) 
- (modified) clang/lib/Driver/ToolChains/Linux.cpp (+2-2) 
- (modified) clang/lib/Driver/ToolChains/MSP430.cpp (+1-1) 
- (modified) clang/lib/Driver/ToolChains/MSVC.cpp (+1-1) 
- (modified) clang/lib/Driver/ToolChains/Managarm.cpp (+2-2) 
- (modified) clang/lib/Driver/ToolChains/MinGW.cpp (+1-1) 
- (modified) clang/lib/Driver/ToolChains/MipsLinux.cpp (+2-2) 
- (modified) clang/lib/Driver/ToolChains/NetBSD.cpp (+2-2) 
- (modified) clang/lib/Driver/ToolChains/OHOS.cpp (+2-2) 
- (modified) clang/lib/Driver/ToolChains/OpenBSD.cpp (+2-2) 
- (modified) clang/lib/Driver/ToolChains/PPCFreeBSD.cpp (+2-2) 
- (modified) clang/lib/Driver/ToolChains/PPCLinux.cpp (+2-2) 
- (modified) clang/lib/Driver/ToolCh

[Lldb-commits] [lldb] Delegate to ABI plugin to check if call frame addresses are valid (PR #161398)

[Jason Molenda via lldb-commits]

@@ -1870,10 +1880,8 @@ bool RegisterContextUnwind::TryFallbackUnwindPlan() {
 if (ReadRegisterValueFromRegisterLocation(regloc, reg_info,
   reg_value)) {
   new_caller_pc_value = reg_value.GetAsUInt64();
-  if (ProcessSP process_sp = m_thread.GetProcess()) {
-if (ABISP abi_sp = process_sp->GetABI())
-  new_caller_pc_value = 
abi_sp->FixCodeAddress(new_caller_pc_value);
-  }
+  if (abi_sp)
+new_caller_pc_value = abi_sp->FixCodeAddress(new_caller_pc_value);

jasonmolenda wrote:

This is fine now that we've got an `abi_sp` local, but I'd prefer the API 
`process_sp->FixCodeAddress` here, that's a newer simplified method of calling. 
We had a lot of code doing (`if (process->GetABI()) abi->Fix...`) and added the 
method directly into Process to simplify that sequence.  It makes zero 
difference here, except as an example of the more directly callable method.

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

[Lldb-commits] [lldb] Fix a potential use-after-free in StopInfoBreakpoint. (PR #163471)

[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 origin/main...HEAD 
lldb/test/API/functionalities/breakpoint/callback_deletes_breakpoints/TestCallbackDeletesBreakpoints.py
``

:warning:
The reproduction instructions above might return results for more than one PR
in a stack if you are using a stacked PR workflow. You can limit the results by
changing `origin/main` to the base branch/commit you want to compare against.
:warning:





View the diff from darker here.


``diff
--- TestCallbackDeletesBreakpoints.py   2025-10-14 22:57:23.00 +
+++ TestCallbackDeletesBreakpoints.py   2025-10-14 23:11:39.389607 +
@@ -29,12 +29,14 @@
 )
 
 # Now set a breakpoint on "I did something" several times
 #
 bkpt_numbers = []
-for idx in range(0,5):
-bkpt_numbers.append(lldbutil.run_break_set_by_source_regexp(self, 
"// Deletable location"))
+for idx in range(0, 5):
+bkpt_numbers.append(
+lldbutil.run_break_set_by_source_regexp(self, "// Deletable 
location")
+)
 
 # And add commands to the third one to delete two others:
 deleter = target.FindBreakpointByID(bkpt_numbers[2])
 self.assertTrue(deleter.IsValid(), "Deleter is a good breakpoint")
 commands = lldb.SBStringList()
@@ -49,15 +51,15 @@
 stop_data = thread.stop_reason_data
 # There are 5 breakpoints so 10 break_id, break_loc_id.
 self.assertEqual(len(stop_data), 10)
 # We should have been able to get break ID's and locations for all the
 # breakpoints that we originally hit, but some won't be around anymore:
-for idx in range(0,5):
-bkpt_id = stop_data[idx*2]
+for idx in range(0, 5):
+bkpt_id = stop_data[idx * 2]
 print(f"{idx}: {bkpt_id}")
 self.assertIn(bkpt_id, bkpt_numbers, "Found breakpoints are right")
-loc_id = stop_data[idx*2 + 1]
+loc_id = stop_data[idx * 2 + 1]
 self.assertEqual(loc_id, 1, "All breakpoints have one location")
 bkpt = target.FindBreakpointByID(bkpt_id)
 if bkpt_id in deleted_ids:
 # Looking these up should be an error:
 self.assertFalse(bkpt.IsValid(), "Deleted breakpoints are 
deleted")

``




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

[Lldb-commits] [lldb] [lldb] fix the "RegisterValue::SetValueFromData" method for 128-bit integer registers (PR #163646)

[Matej Košík via lldb-commits]

sedymrak wrote:

I came to the same conclusion a little later than you.
The test I was experimented with:
```
--- a/lldb/unittests/Utility/RegisterValueTest.cpp
+++ b/lldb/unittests/Utility/RegisterValueTest.cpp
@@ -7,6 +7,8 @@
 
//===--===//
 
 #include "lldb/Utility/RegisterValue.h"
+#include "lldb/lldb-private-types.h"
+#include "lldb/Utility/DataExtractor.h"
 #include "gtest/gtest.h"
 #include 
 
@@ -54,3 +56,21 @@ TEST(RegisterValueTest, GetScalarValue) {
 Scalar((APInt(128, 0xffeeddccbbaa9988ull) << 64) |
APInt(128, 0x7766554433221100)));
 }
+
+TEST(RegisterValueTest, SetValueFromData) {
+  uint8_t bytes[] = {0x00, 0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77,
+ 0x88, 0x99, 0xaa, 0xbb, 0xcc, 0xdd, 0xee, 0xff};
+  lldb::offset_t length = sizeof(bytes);
+  lldb_private::DataExtractor data(bytes, length, lldb::eByteOrderLittle,
+   sizeof(nullptr));
+  lldb_private::RegisterInfo reg_info;
+  reg_info.byte_size = 16;
+  reg_info.byte_offset = 0;
+  reg_info.encoding = lldb::eEncodingUint;
+  RegisterValue rv128;
+  EXPECT_TRUE(rv128.SetValueFromData(reg_info, data, 0, false).Success());
+  Scalar s128;
+  EXPECT_TRUE(rv128.GetScalarValue(s128));
+  EXPECT_TRUE(s128 == Scalar((APInt(128, 0xffeeddccbbaa9988ull) << 64) |
+ APInt(128, 0x7766554433221100ull)));
+}
```
nicely failed on the `main` branch but it succeed in the the branch that 
contains the fix.

I will think about it and push something today.

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

[Lldb-commits] [lldb] Fix a potential use-after-free in StopInfoBreakpoint. (PR #163471)

[Jonas Devlieghere via lldb-commits]

@@ -164,6 +173,14 @@ class BreakpointLocationCollection {
 
   collection m_break_loc_collection;
   mutable std::mutex m_collection_mutex;
+  /// These are used if we're preserving breakpoints in this list:
+  const bool m_preserving_bkpts = false;
+  struct RefCountedBPSP {
+RefCountedBPSP(lldb::BreakpointSP in_bp_sp) : ref_cnt(1), bp_sp(in_bp_sp) 
{}
+uint64_t ref_cnt;

JDevlieghere wrote:

Why do we need our own refcount? The shared pointer already maintains a ref 
count. Why can't we use that? This seems like a recipe for leaks if we don't 
remember to keep the two in sync. 

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

[Lldb-commits] [lldb] [debugserver] Implement MultiMemRead packet (PR #162670)

[David Spickett via lldb-commits]

@@ -0,0 +1,72 @@
+"""
+Tests the exit code/description coming from the debugserver.
+"""
+
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+
+@skipUnlessDarwin
+@skipIfOutOfTreeDebugserver
+class TestCase(TestBase):
+def send_process_packet(self, packet_str):
+self.runCmd(f"proc plugin packet send {packet_str}", check=False)
+# The output is of the form:
+#  packet: 
+#  response: 
+reply = self.res.GetOutput().split("\n")
+reply[0] = reply[0].strip()
+reply[1] = reply[1].strip()
+
+self.assertTrue(reply[0].startswith("packet: "), reply[0])
+self.assertTrue(reply[1].startswith("response: "))
+return reply[1][len("response: ") :]
+
+def test_packets(self):
+self.build()
+source_file = lldb.SBFileSpec("main.c")
+target, process, thread, bkpt = lldbutil.run_to_source_breakpoint(
+self, "break here", source_file
+)
+
+reply = self.send_process_packet("qSupported")
+self.assertIn("MultiMemRead+", reply)
+
+mem_address_var = thread.frames[0].FindVariable("memory")
+self.assertTrue(mem_address_var)
+mem_address = int(mem_address_var.GetValue(), 16)
+
+reply = self.send_process_packet("MultiMemRead:")
+self.assertEqual(reply, "E03")
+reply = self.send_process_packet("MultiMemRead:ranges:")

DavidSpickett wrote:

How about "ranges:,".

Also when you this many, I think it's fine to add a little function like:
def check_invalid_packet(...):

To save some lines. Yes it means the assert failure is always from the same 
place, but the python backtrace will tell the developer who called the function 
anyway.

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

[Lldb-commits] [lldb] support attaching by name for platform android (PR #160931)

[Roy Shi via lldb-commits]

@@ -477,6 +477,85 @@ std::string PlatformAndroid::GetRunAs() {
   }
   return run_as.str();
 }
+uint32_t
+PlatformAndroid::FindProcesses(const ProcessInstanceInfoMatch &match_info,
+   ProcessInstanceInfoList &proc_infos) {
+  // Use the parent implementation for host platform
+  if (IsHost())
+return PlatformLinux::FindProcesses(match_info, proc_infos);
+
+  // For remote Android platform, implement process name lookup using adb
+  proc_infos.clear();
+
+  // Check if we're looking for a process by name
+  const ProcessInstanceInfo &match_process_info = match_info.GetProcessInfo();
+  if (!match_process_info.GetExecutableFile() ||
+  match_info.GetNameMatchType() == NameMatch::Ignore) {
+// Fall back to the parent implementation if not searching by name
+return PlatformLinux::FindProcesses(match_info, proc_infos);
+  }
+
+  std::string process_name = match_process_info.GetExecutableFile().GetPath();
+  if (process_name.empty())
+return 0;
+
+  // Use adb to find the process by name
+  Status error;
+  AdbClientUP adb(GetAdbClient(error));
+  if (error.Fail()) {
+Log *log = GetLog(LLDBLog::Platform);
+LLDB_LOGF(log, "PlatformAndroid::%s failed to get ADB client: %s",
+  __FUNCTION__, error.AsCString());
+return 0;
+  }
+
+  // Use 'pidof' command to get the PID for the process name
+  std::string pidof_output;
+  std::string command = "pidof " + process_name;
+  error = adb->Shell(command.c_str(), seconds(5), &pidof_output);
+
+  if (error.Fail()) {
+Log *log = GetLog(LLDBLog::Platform);
+LLDB_LOGF(log, "PlatformAndroid::%s 'pidof %s' failed: %s", __FUNCTION__,
+  process_name.c_str(), error.AsCString());
+return 0;
+  }
+
+  // Parse the PID from pidof output
+  pidof_output = llvm::StringRef(pidof_output).trim().str();
+  if (pidof_output.empty()) {
+// No process found with that name
+return 0;

royitaqi wrote:

Do we need a LLDB_LOGF here?

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

[Lldb-commits] [clang] [lldb] [Clang] Introduce OverflowBehaviorType for fine-grained overflow control (PR #148914)

[Miguel Ojeda via lldb-commits]

ojeda wrote:

> Looking at Rust's arithmetic, there is just simply _no_ mismatched bit widths 
> allowed. Things need to be explicitly cast, so there is no ambiguity about 
> bit width. Going all the way to this requirement feels like the furthest 
> swing away from usability in C, especially with the goal of slowly adding 
> `__ob_trap` types/annotations to an existing codebase.

To be honest, not having to worry all the time about that in Rust is actually 
quite nice, and while skimming this discussion I felt it would be the simplest 
approach here too. But, yeah, some kernel developers may not be thrilled about 
it being an error -- it is very not-C-like. It would also require building the 
kernel often with a newer Clang, to catch all missing casts. It also feels a 
bit orthogonal to the overflow behavior (but since they do not behave the same 
anyway, it is a fair opportunity to introduce integers with less surprises...).

https://github.com/llvm/llvm-project/pull/148914
___
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 stdio redirection for integrated and external terminals (PR #161089)

[Walter Erquinigo via lldb-commits]

@@ -47,6 +47,12 @@ def debugger_pid: S<"debugger-pid">,
   HelpText<"The PID of the lldb-dap instance that sent the launchInTerminal "
 "request when using --launch-target.">;
 
+def stdio: S<"stdio">,

walter-erquinigo wrote:

would it be possible to redirect 2 to 1, for example, instead of providing full 
paths? If that works, state a couple of examples of different kinds of inputs 
here.

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

[Lldb-commits] [lldb] [lldb] Implement Process::ReadMemoryRanges (PR #163651)

[David Spickett via lldb-commits]

@@ -1971,6 +1971,34 @@ size_t Process::ReadMemory(addr_t addr, void *buf, 
size_t size, Status &error) {
   }
 }
 
+llvm::SmallVector>
+Process::ReadMemoryRanges(llvm::ArrayRef> ranges,
+  llvm::MutableArrayRef buffer) {
+  llvm::SmallVector> results;
+
+  for (auto [addr, len] : ranges) {
+// This is either a programmer error, or a protocol violation.
+// In production builds, gracefully fail.
+assert(buffer.size() >= len);
+if (buffer.size() < len) {
+  results.push_back(buffer.take_front(0));

DavidSpickett wrote:

For instance, this is a bit cryptic without a comment.

I suppose it's because there has to be some pointer into the original buffer, 
but you are returning 0 bytes for this. Perhaps you can use buffer.data instead 
to make it clear we do not intend to move the start of the buffer at all?

Seeing 0 here makes me wonder if you meant to type another number.

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

[Lldb-commits] [lldb] [lldb-dap] Send a 'process' event on restart. (PR #163833)

[John Harrison via lldb-commits]

https://github.com/ashgti created 
https://github.com/llvm/llvm-project/pull/163833

When we restart a process, send an updated 'process' event describing the newly 
launched process.

I also updated the `isLocalProcess` value based on if we're on the 'host' 
platform or not.

>From 49e0b3b886f68c60dbfb737688ae4959d69df130 Mon Sep 17 00:00:00 2001
From: John Harrison 
Date: Thu, 16 Oct 2025 10:34:48 -0700
Subject: [PATCH] [lldb-dap] Send a 'process' event on restart.

When we restart a process, send an updated 'process' event describing the newly 
launched process.
---
 lldb/tools/lldb-dap/EventHelper.cpp   | 5 -
 lldb/tools/lldb-dap/Handler/RestartRequestHandler.cpp | 2 ++
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/lldb/tools/lldb-dap/EventHelper.cpp 
b/lldb/tools/lldb-dap/EventHelper.cpp
index 2b9ed229405a8..ebddb4ec1f502 100644
--- a/lldb/tools/lldb-dap/EventHelper.cpp
+++ b/lldb/tools/lldb-dap/EventHelper.cpp
@@ -15,6 +15,7 @@
 #include "Protocol/ProtocolRequests.h"
 #include "Protocol/ProtocolTypes.h"
 #include "lldb/API/SBFileSpec.h"
+#include "lldb/API/SBPlatform.h"
 #include "llvm/Support/Error.h"
 #include 
 
@@ -136,7 +137,9 @@ void SendProcessEvent(DAP &dap, LaunchMethod launch_method) 
{
   EmplaceSafeString(body, "name", exe_path);
   const auto pid = dap.target.GetProcess().GetProcessID();
   body.try_emplace("systemProcessId", (int64_t)pid);
-  body.try_emplace("isLocalProcess", true);
+  body.try_emplace("isLocalProcess",
+   dap.target.GetPlatform().GetName() ==
+   lldb::SBPlatform::GetHostPlatform().GetName());
   const char *startMethod = nullptr;
   switch (launch_method) {
   case Launch:
diff --git a/lldb/tools/lldb-dap/Handler/RestartRequestHandler.cpp 
b/lldb/tools/lldb-dap/Handler/RestartRequestHandler.cpp
index 45dd7ddce0428..706e66fd643a3 100644
--- a/lldb/tools/lldb-dap/Handler/RestartRequestHandler.cpp
+++ b/lldb/tools/lldb-dap/Handler/RestartRequestHandler.cpp
@@ -124,6 +124,8 @@ void RestartRequestHandler::operator()(
 return;
   }
 
+  SendProcessEvent(dap, Attach);
+
   // This is normally done after receiving a "configuration done" request.
   // Because we're restarting, configuration has already happened so we can
   // continue the process right away.

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

[Lldb-commits] [lldb] ced01f3 - [lldb][Darwin] Add `process launch --memory-tagging` option (#162944)

[via lldb-commits]

Author: Julian Lettner
Date: 2025-10-14T13:01:24-07:00
New Revision: ced01f367183520e4b1a21dadfc1c3be044f5be3

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

LOG: [lldb][Darwin] Add `process launch --memory-tagging` option (#162944)

For debugging and bug-finding workflows on Darwin, support
launching processes with memory tagging for binaries that are
not entitled.

This will cause the process to behave as if the binary was entitled
with:
```
com.apple.security.hardened-process.checked-allocations

```

This has no effect on hardware without MTE support.

-

Co-authored-by: Jonas Devlieghere 

Added: 


Modified: 
lldb/include/lldb/lldb-enumerations.h
lldb/source/Commands/CommandOptionsProcessLaunch.cpp
lldb/source/Commands/Options.td
lldb/source/Host/macosx/objcxx/Host.mm
lldb/test/API/macosx/mte/Makefile
lldb/test/API/macosx/mte/TestDarwinMTE.py

Removed: 




diff  --git a/lldb/include/lldb/lldb-enumerations.h 
b/lldb/include/lldb/lldb-enumerations.h
index fec9fdef44df9..1a7db8faecd94 100644
--- a/lldb/include/lldb/lldb-enumerations.h
+++ b/lldb/include/lldb/lldb-enumerations.h
@@ -130,6 +130,8 @@ FLAGS_ENUM(LaunchFlags){
 eLaunchFlagInheritTCCFromParent =
 (1u << 12), ///< Don't make the inferior responsible for its own TCC
 ///< permissions but instead inherit them from its parent.
+eLaunchFlagMemoryTagging =
+(1u << 13), ///< Launch process with memory tagging explicitly enabled.
 };
 
 /// Thread Run Modes.

diff  --git a/lldb/source/Commands/CommandOptionsProcessLaunch.cpp 
b/lldb/source/Commands/CommandOptionsProcessLaunch.cpp
index 21d94d68ceb91..8ae20bd76f456 100644
--- a/lldb/source/Commands/CommandOptionsProcessLaunch.cpp
+++ b/lldb/source/Commands/CommandOptionsProcessLaunch.cpp
@@ -127,6 +127,10 @@ Status CommandOptionsProcessLaunch::SetOptionValue(
 break;
   }
 
+  case 'M':
+launch_info.GetFlags().Set(eLaunchFlagMemoryTagging);
+break;
+
   case 'c':
 if (!option_arg.empty())
   launch_info.SetShell(FileSpec(option_arg));

diff  --git a/lldb/source/Commands/Options.td b/lldb/source/Commands/Options.td
index 595b3d08abec5..a9f054e1d3d45 100644
--- a/lldb/source/Commands/Options.td
+++ b/lldb/source/Commands/Options.td
@@ -1173,6 +1173,11 @@ let Command = "process launch" in {
 Arg<"Boolean">,
 Desc<"Set whether to shell expand arguments to the process when "
  "launching.">;
+  def process_launch_memory_tagging
+  : Option<"memory-tagging", "M">,
+Desc<"Set whether to explicitly enable memory tagging when launching "
+ "the process.  Requires hardware support.  "
+ "(Only supported on Darwin.)">;
 }
 
 let Command = "process attach" in {

diff  --git a/lldb/source/Host/macosx/objcxx/Host.mm 
b/lldb/source/Host/macosx/objcxx/Host.mm
index 3c1d1179963d2..71208927e7c94 100644
--- a/lldb/source/Host/macosx/objcxx/Host.mm
+++ b/lldb/source/Host/macosx/objcxx/Host.mm
@@ -1210,6 +1210,39 @@ static Status LaunchProcessPosixSpawn(const char 
*exe_path,
 }
   }
 
+  if (launch_info.GetFlags().Test(eLaunchFlagMemoryTagging)) {
+// The following function configures the spawn attributes to launch the
+// process with memory tagging explicitly enabled.  We look it up
+// dynamically since it is only available on newer OS.  Does nothing on
+// hardware which does not support MTE.
+//
+//   int posix_spawnattr_set_use_sec_transition_shims_np(
+//   posix_spawnattr_t *attr, uint32_t flags);
+//
+using posix_spawnattr_set_use_sec_transition_shims_np_t =
+int (*)(posix_spawnattr_t *attr, uint32_t flags);
+auto posix_spawnattr_set_use_sec_transition_shims_np_fn =
+(posix_spawnattr_set_use_sec_transition_shims_np_t)dlsym(
+RTLD_DEFAULT, "posix_spawnattr_set_use_sec_transition_shims_np");
+if (posix_spawnattr_set_use_sec_transition_shims_np_fn) {
+  error =
+  Status(posix_spawnattr_set_use_sec_transition_shims_np_fn(&attr, 0),
+ eErrorTypePOSIX);
+  if (error.Fail()) {
+LLDB_LOG(log,
+ "error: {0}, "
+ "posix_spawnattr_set_use_sec_transition_shims_np(&attr, 0)",
+ error);
+return error;
+  }
+} else {
+  LLDB_LOG(log,
+   "error: posix_spawnattr_set_use_sec_transition_shims_np not "
+   "available",
+   error);
+}
+  }
+
   // Don't set the binpref if a shell was provided. After all, that's only
   // going to affect what version of the shell is launched, not what fork of
   // the binary is launched.  We insert "arch --arch  as part of the

diff  --git a/lldb/test/API/macosx/mte/Makefile 
b/lldb/test/

[Lldb-commits] [lldb] [lldb][test] Fix TestEmptyFuncThreadStepOut.py (PR #161788)

[Igor Kudrin via lldb-commits]

igorkudrin wrote:

> I would have thought finish from the epilogue had the same issue as from the 
> "body" of the function but you've apparently proven that not to be the case.

Perhaps I was not clear enough. As I understand it, the original test was 
supposed to demonstrate an issue with stepping out from the last instruction of 
a function after hitting a breakpoint at that location. Probably, prologue and 
epilogue code are not generated for empty functions on some targets, but it is 
on Linux/x64, for example.

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

[Lldb-commits] [lldb] [lldb] Introduce ScriptedFrameProvider for real threads (PR #161870)

[Med Ismail Bennani via lldb-commits]

medismailben wrote:

Hello! Thanks for your interest in this PR.

> Being able to modify the frame list from a script would indeed be amazing - 
> thanks for looking into this! 🙂
> 
> As it happens, I am currently looking into gdb's "frame filter" API, which 
> serves a very similar use case - and I am wondering if we should take some 
> inspiration from the gdb APIs here. Gdb's frame filter API differs from the 
> API in this PR in the following points:
> 

A non-goal for this PR and for lldb in general is copy what gdb or other 
debuggers do.

> * **simpler API**: gdb's API only has a single function `filter(frame_iter) 
> -> frame_iter` function. (This PR currently introduces two functions: 
> `get_merge_strategy` and `get_stack_frames`)
> * **lazy stack unwinding**: afaict, your patch leads to eager materialization 
> of all stack frames. Given that stacks can be pretty deep, it would be 
> preferable to only create those stack frames lazily, as the users inspects 
> the stack. gdb achieves this by only advancing the returned iterator as needed
> * **more flexible merging strategies**: in gdb, I can use all of Python's 
> iterator support (generator expressions, `yield`, ...)
> * **global registration**: in gdb, frame filters are registered globally for 
> all threads. In this PR, the frame providers are registered for each thread 
> individually
> * **multiple frame filters**: gdb supports registering multiple frame filters 
> at the same time. I didn't use that mechanism, yet, but afaict they are 
> simply chained
> 
> The relevant pieces of gdb's documentation:
> 
> * [Writing a frame 
> filter](https://www.sourceware.org/gdb/current/onlinedocs/gdb.html/Writing-a-Frame-Filter.html)
>  - high-level introduction
> * [Frame filter 
> API](https://www.sourceware.org/gdb/current/onlinedocs/gdb.html/Frame-Filter-API.html)
>  - corresponding API reference
> * [Frame decorators 
> API](https://www.sourceware.org/gdb/current/onlinedocs/gdb.html/Frame-Decorator-API.html#Frame-Decorator-API)
>  - close equivalent to lldb's `ScriptedFrame`
> * [Frame filter 
> management](https://www.sourceware.org/gdb/current/onlinedocs/gdb.html/Frame-Filter-Management.html#Frame-Filter-Management)
>  - end users can change enable, disable and reorder frame filters
> 
> My motivation for using frame filters in gdb are C++ couroutines. I want to 
> add frames for asynchronous operations. For more background see LLVM's 
> documentatin on [Async Stack 
> Traces]f(https://clang.llvm.org/docs/DebuggingCoroutines.html#async-stack-traces),
>  in particular the `coro bt` example. At least for my use case, gdb's design 
> decisions (global registration, flexible merging strategy, ...) are a pretty 
> good fit. But not sure, maybe your current design is a better fit for your 
> particular use case? Which use case are you envisioning?
> 

That sounds pretty exciting. I think ScriptedFrameProvider would be a great fit 
to support coroutines as long as the ABI doesn't spawn new threads for that. My 
current use case for this is to translate CPython frames into something that's 
more understandable, to hopefully improve debugging python / C++ 
interoperability in lldb.

> By the way: would discourse be better-suited for discussing the best approach 
> here? Happy to copy my reply over to discourse, if you would start a thread

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

[Lldb-commits] [lldb] [lldb] Fix TypeSystemClang::GetBasicTypeEnumeration for 128-bit int types (PR #162278)

[Michael Buch via lldb-commits]

Michael137 wrote:

So IIUC, the issue is that `SBModule::FindFirstType` falls back to 
`TypeSystemClang::GetBuiltinTypeByName`. Since `__int128` and `unsigned 
__int128` are the de-facto names for the builtin types, we expect LLDB to find 
them. But LLDB registers the 128-bit integer builtins as being called 
`__int128_t` and `__uint128_t`.

Seems like this dates back quite a while:
```
commit b43165b7a5d59d8178dc803ec0351d3a62a38946
Author: Greg Clayton 
Date:   Wed Dec 5 21:24:42 2012 +



Always allows getting builtin types by name even if there is no backing 
debug information.

llvm-svn: 169424
```

And there weren't associated tests for it, so hard to say why `__int128_t` was 
chosen. IIUC, `__int128_t` is a typedef to `__int128`. So using it for the name 
of the basic type seems wrong.

> (lldb) script lldb.debugger.GetSelectedTarget().FindFirstType("__int128").size
> 16
> (lldb) script lldb.debugger.GetSelectedTarget().FindFirstType("unsigned 
> __int128").size
> 16

Could you add a test for this?

E.g., you could add this to 
`lldb/test/API/functionalities/type_find_first/TestFindFirstType.py` or 
`lldb/test/API/python_api/sbtype_basic_type/TestSBTypeBasicType.py`

On the flip-side it looks like the following commands do currently work today:
```
(lldb) script lldb.debugger.GetSelectedTarget().FindFirstType("__int128_t").size
16
(lldb) script 
lldb.debugger.GetSelectedTarget().FindFirstType("__uint128_t").size
16
```
Do they still work after your patch?

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

[Lldb-commits] [lldb] [lldb][test] Fix TestEmptyFuncThreadStepOut.py (PR #161788)

[Igor Kudrin via lldb-commits]

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

[Lldb-commits] [lldb] Fix a potential use-after-free in StopInfoBreakpoint. (PR #163471)

[via lldb-commits]

https://github.com/jimingham created 
https://github.com/llvm/llvm-project/pull/163471

StopInfoBreakpoint keeps a BreakpointLocationCollection for all the breakpoint 
locations at the BreakpointSite that was hit. It is also lives through the time 
a given thread is stopped, so there are plenty of opportunities for one of the 
owning breakpoints to get deleted.

But BreakpointLocations don't keep their owner Breakpoints alive, so if the 
BreakpointLocationCollection can live past when some code gets a chance to 
delete an owner breakpoint, and then you ask that location for some breakpoint 
information, it will access freed memory.

This wasn't a problem before PR #158128 because the StopInfoBreakpoint just 
kept the BreakpointSite that was hit, and when you asked it questions, it 
relooked up that list.  That was not great, however, because if you hit 
breakpoints 5 & 6, deleted 5 and then asked which breakpoints got hit, you 
would just get 6.  For that and other reasons that PR changed to storing a 
BreakpointLocationCollection of the breakpoints that were hit.  That's better 
from a UI perspective but caused this potential problem.

I fix it by adding a variant of the BreakpointLocationCollection that also 
holds onto a shared pointer to the Breakpoints that own the locations that were 
hit, thus keeping them alive till the StopInfoBreakpoint goes away.

This fixed the ASAN assertion.  I also added a test that works harder to cause 
trouble by deleting breakpoints during a stop.

>From b060e19c0c2ee8b653d9d878181f1426f6ddb916 Mon Sep 17 00:00:00 2001
From: Jim Ingham 
Date: Tue, 14 Oct 2025 15:57:23 -0700
Subject: [PATCH] Fix a potential use-after-free in StopInfoBreakpoint.

StopInfoBreakpoint keeps a BreakpointLocationCollection for all the
breakpoint locations at the BreakpointSite that was hit. It is also
lives through the time a given thread is stopped, so there are plenty
of opportunities for one of the owning breakpoints to get deleted.

But BreakpointLocations don't keep their owner Breakpoints alive, so if
the BreakpointLocationCollection can live past when some code gets
a chance to delete an owner breakpoint, and then you ask that location
for some breakpoint information, it will access freed memory.

This wasn't a problem before PR #158128 because the StopInfoBreakpoint
just kept the BreakpointSite that was hit, and when you asked it questions,
it relooked up that list.  That was not great, however, because if you hit
breakpoints 5 & 6, deleted 5 and then asked which breakpoints got hit, you
would just get 6.  For that and other reasons that PR changed to storing
a BreakpointLocationCollection of the breakpoints that were hit.  That's
better from a UI perspective but caused this potential problem.

I fix it by adding a variant of the BreakpointLocationCollection that also
holds onto a shared pointer to the Breakpoints that own the locations that
were hit, thus keeping them alive till the StopInfoBreakpoint goes away.

This fixed the ASAN assertion.  I also added a test that works harder to
cause trouble by deleting breakpoints during a stop.
---
 .../Breakpoint/BreakpointLocationCollection.h | 28 ++--
 .../BreakpointLocationCollection.cpp  | 22 ++-
 lldb/source/Target/StopInfo.cpp   | 13 +++-
 .../callback_deletes_breakpoints/Makefile |  4 ++
 .../TestCallbackDeletesBreakpoints.py | 65 +++
 .../callback_deletes_breakpoints/main.c   | 15 +
 6 files changed, 137 insertions(+), 10 deletions(-)
 create mode 100644 
lldb/test/API/functionalities/breakpoint/callback_deletes_breakpoints/Makefile
 create mode 100644 
lldb/test/API/functionalities/breakpoint/callback_deletes_breakpoints/TestCallbackDeletesBreakpoints.py
 create mode 100644 
lldb/test/API/functionalities/breakpoint/callback_deletes_breakpoints/main.c

diff --git a/lldb/include/lldb/Breakpoint/BreakpointLocationCollection.h 
b/lldb/include/lldb/Breakpoint/BreakpointLocationCollection.h
index 1df4e074680f5..10a22476aba9b 100644
--- a/lldb/include/lldb/Breakpoint/BreakpointLocationCollection.h
+++ b/lldb/include/lldb/Breakpoint/BreakpointLocationCollection.h
@@ -9,6 +9,7 @@
 #ifndef LLDB_BREAKPOINT_BREAKPOINTLOCATIONCOLLECTION_H
 #define LLDB_BREAKPOINT_BREAKPOINTLOCATIONCOLLECTION_H
 
+#include 
 #include 
 #include 
 
@@ -19,9 +20,17 @@ namespace lldb_private {
 
 class BreakpointLocationCollection {
 public:
-  BreakpointLocationCollection();
-
-  ~BreakpointLocationCollection();
+  /// Breakpoint locations don't keep their breakpoint owners alive, so neither
+  /// will a collection of breakpoint locations.  However, if you need to
+  /// use this collection in a context where some of the breakpoints whose
+  /// locations are in the collection might get deleted during its lifespan,
+  /// then you need to make sure the breakpoints don't get deleted out from
+  /// under you.  To do that, pass true for preserving, and so long as there is
+  /// a location for a given b

[Lldb-commits] [lldb] [lldb] Enable locate module callback for main executable (PR #160199)

[via lldb-commits]

github-actions[bot] wrote:




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



You can test this locally with the following command:


``bash
git-clang-format --diff origin/main HEAD --extensions cpp,h -- 
lldb/include/lldb/Core/ModuleList.h lldb/include/lldb/Core/ModuleSpec.h 
lldb/include/lldb/Target/Platform.h 
lldb/include/lldb/Target/RemoteAwarePlatform.h lldb/source/API/SBModule.cpp 
lldb/source/Core/DynamicLoader.cpp lldb/source/Core/ModuleList.cpp 
lldb/source/Plugins/DynamicLoader/Darwin-Kernel/DynamicLoaderDarwinKernel.cpp 
lldb/source/Plugins/DynamicLoader/POSIX-DYLD/DynamicLoaderPOSIXDYLD.cpp 
lldb/source/Plugins/Platform/MacOSX/PlatformAppleSimulator.cpp 
lldb/source/Plugins/Platform/MacOSX/PlatformAppleSimulator.h 
lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp 
lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.h 
lldb/source/Plugins/Platform/MacOSX/PlatformDarwinDevice.cpp 
lldb/source/Plugins/Platform/MacOSX/PlatformDarwinDevice.h 
lldb/source/Plugins/Platform/MacOSX/PlatformDarwinKernel.cpp 
lldb/source/Plugins/Platform/MacOSX/PlatformDarwinKernel.h 
lldb/source/Plugins/Platform/MacOSX/PlatformMacOSX.cpp 
lldb/source/Plugins/Platform/MacOSX/PlatformMacOSX.h 
lldb/source/Plugins/Platform/MacOSX/PlatformRemoteDarwinDevice.cpp 
lldb/source/Plugins/Platform/MacOSX/PlatformRemoteDarwinDevice.h 
lldb/source/Plugins/Process/elf-core/ProcessElfCore.cpp 
lldb/source/Plugins/Process/mach-core/ProcessMachCore.cpp 
lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp 
lldb/source/Target/ModuleCache.cpp lldb/source/Target/Platform.cpp 
lldb/source/Target/RemoteAwarePlatform.cpp lldb/source/Target/Target.cpp 
lldb/source/Target/TargetList.cpp 
lldb/unittests/Target/LocateModuleCallbackTest.cpp 
lldb/unittests/Target/RemoteAwarePlatformTest.cpp --diff_from_common_commit
``

:warning:
The reproduction instructions above might return results for more than one PR
in a stack if you are using a stacked PR workflow. You can limit the results by
changing `origin/main` to the base branch/commit you want to compare against.
:warning:





View the diff from clang-format here.


``diff
diff --git a/lldb/include/lldb/Core/ModuleSpec.h 
b/lldb/include/lldb/Core/ModuleSpec.h
index 161e03e54..6df4c7564 100644
--- a/lldb/include/lldb/Core/ModuleSpec.h
+++ b/lldb/include/lldb/Core/ModuleSpec.h
@@ -274,8 +274,9 @@ protected:
   ArchSpec m_arch;
   UUID m_uuid;
   ConstString m_object_name;
-  /// This is set to take advantage of the target's search path and platform's 
locate module callback
-  std::weak_ptr m_target; 
+  /// This is set to take advantage of the target's search path and platform's
+  /// locate module callback
+  std::weak_ptr m_target;
   uint64_t m_object_offset = 0;
   uint64_t m_object_size = 0;
   llvm::sys::TimePoint<> m_object_mod_time;

``




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

[Lldb-commits] [lldb] Revert "Make SBBreakpoint/SBBreakpointLocation.SetCondition(nullptr) work again." (PR #162544)

[Kazu Hirata via lldb-commits]

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

[Lldb-commits] [lldb] 7ab271c - [lldb][examples] Use Python3 versions of types module in performance.py

[David Spickett via lldb-commits]

Author: David Spickett
Date: 2025-10-16T09:54:53Z
New Revision: 7ab271cbd26c869e354fff9c921b30276a3fa974

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

LOG: [lldb][examples] Use Python3 versions of types module in performance.py

2.x had ListType and StringTypes 
(https://docs.python.org/2.7/library/types.html),
3.x removed these (https://docs.python.org/3.0/library/types.html).

We can use "str" and "list" directly as in 3.x all strings are
just "str", and ListType was always an alias to "list".

Added: 


Modified: 
lldb/examples/python/performance.py

Removed: 




diff  --git a/lldb/examples/python/performance.py 
b/lldb/examples/python/performance.py
index b86b5a52522e0..c3181b61c84f7 100755
--- a/lldb/examples/python/performance.py
+++ b/lldb/examples/python/performance.py
@@ -16,7 +16,6 @@
 import sys
 import subprocess
 import time
-import types
 
 # --
 # Code that auto imports LLDB
@@ -121,19 +120,19 @@ def __init__(
 self.breakpoints.append(breakpoint)
 else:
 if module:
-if isinstance(module, types.ListType):
+if isinstance(module, list):
 for module_path in module:
 self.modules.Append(lldb.SBFileSpec(module_path, 
False))
-elif isinstance(module, types.StringTypes):
+elif isinstance(module, str):
 self.modules.Append(lldb.SBFileSpec(module, False))
 if name:
 # "file" can be a list or a string
 if file:
-if isinstance(file, types.ListType):
+if isinstance(file, list):
 self.files = lldb.SBFileSpecList()
 for f in file:
 self.files.Append(lldb.SBFileSpec(f, False))
-elif isinstance(file, types.StringTypes):
+elif isinstance(file, str):
 self.files.Append(lldb.SBFileSpec(file, False))
 self.breakpoints.append(
 self.target.BreakpointCreateByName(name, self.modules, 
self.files)



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

[Lldb-commits] [lldb] 64ed390 - [lldb] Fix stepping out if the return address is not allowed to stop at (#161982)

[via lldb-commits]

Author: Igor Kudrin
Date: 2025-10-08T16:30:24-07:00
New Revision: 64ed3903bbb56dd74e120e84442f4bbaae777eb3

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

LOG: [lldb] Fix stepping out if the return address is not allowed to stop at 
(#161982)

When a thread reaches a breakpoint at the return address set by
`ThreadPlanStepOut`, `ThreadPlanStepOut::ShouldStop()` calls
`ThreadPlanShouldStopHere::InvokeShouldStopHereCallback()`, and if it
returns `false`, `ThreadPlanShouldStopHere::QueueStepOutFromHerePlan()`
is called to queue a new plan to skip the corresponding range. Once the
new plan finishes, `ThreadPlanStepOut::ShouldStop()` should recheck the
stop condition; however, there is no code path in the method that sets
`done` to `true`. Before #126838, if `done` was `false`, the method checked
if a suitable frame had been reached. After the patch, the check is only
performed at a breakpoint; thus, the execution continues.

This patch causes `ThreadPlanStepOut::ShouldStop()` to recheck the stop
condition when `m_step_out_further_plan_sp` completes.

Added: 
lldb/test/API/functionalities/thread/step_out_line0/Makefile

lldb/test/API/functionalities/thread/step_out_line0/TestThreadStepOutLine0.py
lldb/test/API/functionalities/thread/step_out_line0/main.c

Modified: 
lldb/source/Target/ThreadPlanStepOut.cpp

Removed: 




diff  --git a/lldb/source/Target/ThreadPlanStepOut.cpp 
b/lldb/source/Target/ThreadPlanStepOut.cpp
index 0628451a5abf9..d49a01bdbcef7 100644
--- a/lldb/source/Target/ThreadPlanStepOut.cpp
+++ b/lldb/source/Target/ThreadPlanStepOut.cpp
@@ -397,9 +397,10 @@ bool ThreadPlanStepOut::ShouldStop(Event *event_ptr) {
 else
   return m_step_through_inline_plan_sp->ShouldStop(event_ptr);
   } else if (m_step_out_further_plan_sp) {
-if (m_step_out_further_plan_sp->MischiefManaged())
+if (m_step_out_further_plan_sp->MischiefManaged()) {
   m_step_out_further_plan_sp.reset();
-else
+  done = true;
+} else
   return m_step_out_further_plan_sp->ShouldStop(event_ptr);
   }
 

diff  --git a/lldb/test/API/functionalities/thread/step_out_line0/Makefile 
b/lldb/test/API/functionalities/thread/step_out_line0/Makefile
new file mode 100644
index 0..10495940055b6
--- /dev/null
+++ b/lldb/test/API/functionalities/thread/step_out_line0/Makefile
@@ -0,0 +1,3 @@
+C_SOURCES := main.c
+
+include Makefile.rules

diff  --git 
a/lldb/test/API/functionalities/thread/step_out_line0/TestThreadStepOutLine0.py 
b/lldb/test/API/functionalities/thread/step_out_line0/TestThreadStepOutLine0.py
new file mode 100644
index 0..2707ca852f662
--- /dev/null
+++ 
b/lldb/test/API/functionalities/thread/step_out_line0/TestThreadStepOutLine0.py
@@ -0,0 +1,35 @@
+"""
+Test stepping out of a function when the return location is an unsuitable
+stopping point.
+"""
+
+
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+
+class ThreadStepOutLine0TestCase(TestBase):
+def test(self):
+self.build()
+target, process, thread, _ = lldbutil.run_to_source_breakpoint(
+self, "// Set breakpoint here", lldb.SBFileSpec("main.c")
+)
+correct_stepped_out_line = line_number("main.c", "// Should stop here")
+return_statement_line = line_number("main.c", "// Ran too far")
+safety_bp = target.BreakpointCreateByLocation(
+lldb.SBFileSpec("main.c"), return_statement_line
+)
+self.assertTrue(safety_bp.IsValid())
+
+error = lldb.SBError()
+thread.StepOut(error)
+self.assertTrue(error.Success())
+
+frame = thread.GetSelectedFrame()
+self.assertEqual(
+frame.line_entry.GetLine(),
+correct_stepped_out_line,
+"Step-out lost control of execution, ran too far",
+)

diff  --git a/lldb/test/API/functionalities/thread/step_out_line0/main.c 
b/lldb/test/API/functionalities/thread/step_out_line0/main.c
new file mode 100644
index 0..ad0c1c05d6952
--- /dev/null
+++ b/lldb/test/API/functionalities/thread/step_out_line0/main.c
@@ -0,0 +1,11 @@
+int step_out_of_here(int a) {
+  return a + 5; // Set breakpoint here
+}
+
+int main() {
+#line 0
+  int v = step_out_of_here(3) + 7;
+#line 9
+  v += 11;  // Should stop here
+  return v; // Ran too far
+}



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

[Lldb-commits] [clang] [lldb] [Clang] Introduce OverflowBehaviorType for fine-grained overflow control (PR #148914)

[Justin Stitt via lldb-commits]

@@ -9744,6 +9744,16 @@ static void DiagnoseNarrowingInInitList(Sema &S,
 
   case NK_Constant_Narrowing: {
 // A constant value was narrowed.
+
+// Overflow behavior destination types with a 'wrap' kind can elide

JustinStitt wrote:

Without the OBT check in the diagnostic logic we get the following warning:

```c
constexpr short __ob_wrap cx2 = {10}; // constant expression evaluates to 
10 which cannot be narrowed to type '__ob_wrap short'
```

And I didn't want this to be the case for wrapping things. So it is just a 
design decisions really. It is consistent with the 
`-fsanitize=implicit-unsigned-integer-truncation` handling too. I just really 
want free reign over bit boundary stuff with `__ob_wrap` types.

It should be noted the OBT check only cares about the destination type.

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

[Lldb-commits] [lldb] [LLDB] Add unary plus and minus to DIL (PR #155617)

[Adrian Prantl via lldb-commits]

@@ -412,6 +412,13 @@ class TypeSystem : public PluginInterface,
   GetIntegralTemplateArgument(lldb::opaque_compiler_type_t type, size_t idx,
   bool expand_pack);
 
+  // DIL
+
+  virtual bool IsPromotableIntegerType(lldb::opaque_compiler_type_t type);

adrian-prantl wrote:

Can you add a Doxygen comment explaining the semantics of this function?

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

[Lldb-commits] [lldb] Revert "Make SBBreakpoint/SBBreakpointLocation.SetCondition(nullptr) work again." (PR #162544)

[Kazu Hirata via lldb-commits]

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

[Lldb-commits] [lldb] [lldb] Avoid copying header just to overwrite it (PR #160555)

[Justin Cady via lldb-commits]

https://github.com/justincady created 
https://github.com/llvm/llvm-project/pull/160555

The build script copies lldb-defines.h into the staging area but it gets
overwritten by version-header-fix.py. This flow assumes that the
lldb-defines.h from the source was writable originally (thus the copy
maintains that permission). This is problematic for systems that
integrate LLVM source as read only.

This change skips the initial copy of lldb-defines.h, which prevents
lldb build failures when the source is not writable.


>From d1ba166b80393567663c31ec94379d41b39efc06 Mon Sep 17 00:00:00 2001
From: Justin Cady 
Date: Wed, 24 Sep 2025 12:42:34 -0400
Subject: [PATCH] [lldb] Avoid copying header just to overwrite it

The build script copies lldb-defines.h into the staging area but it gets
overwritten by version-header-fix.py. This flow assumes that the
lldb-defines.h from the source was writable originally (thus the copy
maintains that permission). This is problematic for systems that
integrate LLVM source as read only.

This change skips the initial copy of lldb-defines.h, which prevents
lldb build failures when the source is not writable.
---
 lldb/source/API/CMakeLists.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/lldb/source/API/CMakeLists.txt b/lldb/source/API/CMakeLists.txt
index fdd6b3b077463..ce59ee505cd3d 100644
--- a/lldb/source/API/CMakeLists.txt
+++ b/lldb/source/API/CMakeLists.txt
@@ -299,6 +299,8 @@ set(generated_public_headers 
${LLDB_OBJ_DIR}/include/lldb/API/SBLanguages.h)
 file(GLOB root_public_headers ${LLDB_SOURCE_DIR}/include/lldb/lldb-*.h)
 file(GLOB root_private_headers ${LLDB_SOURCE_DIR}/include/lldb/lldb-private*.h)
 list(REMOVE_ITEM root_public_headers ${root_private_headers})
+# Skip the initial copy of lldb-defines.h. The fixed version is generated at 
build time.
+list(REMOVE_ITEM root_public_headers 
${LLDB_SOURCE_DIR}/include/lldb/lldb-defines.h)
 
 find_program(unifdef_EXECUTABLE unifdef)
 

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

[Lldb-commits] [lldb] e559d1f - Reland #158161 with cmake fix (#159842)

[via lldb-commits]

Author: barsolo2000
Date: 2025-09-22T10:12:51-05:00
New Revision: e559d1f56b206f3360e08be762b29d1c31a4cf84

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

LOG: Reland #158161 with cmake fix (#159842)

Initial PR was reverted due failing test since the buildbots don't
include the RISCV backend.

-

Co-authored-by: Bar Soloveychik 

Added: 
lldb/unittests/Instruction/RISCV/TestRiscvInstEmulation.cpp

Modified: 
lldb/include/lldb/Core/Opcode.h
lldb/source/Plugins/Instruction/RISCV/EmulateInstructionRISCV.cpp
lldb/source/Plugins/Instruction/RISCV/EmulateInstructionRISCV.h
lldb/unittests/Instruction/CMakeLists.txt

Removed: 




diff  --git a/lldb/include/lldb/Core/Opcode.h b/lldb/include/lldb/Core/Opcode.h
index 7bbd73d039f99..7e756d3f15d22 100644
--- a/lldb/include/lldb/Core/Opcode.h
+++ b/lldb/include/lldb/Core/Opcode.h
@@ -223,7 +223,9 @@ class Opcode {
   int Dump(Stream *s, uint32_t min_byte_width) const;
 
   const void *GetOpcodeBytes() const {
-return ((m_type == Opcode::eTypeBytes) ? m_data.inst.bytes : nullptr);
+return ((m_type == Opcode::eTypeBytes || m_type == 
Opcode::eType16_32Tuples)
+? m_data.inst.bytes
+: nullptr);
   }
 
   uint32_t GetByteSize() const {

diff  --git a/lldb/source/Plugins/Instruction/RISCV/EmulateInstructionRISCV.cpp 
b/lldb/source/Plugins/Instruction/RISCV/EmulateInstructionRISCV.cpp
index 5e429a92613ce..20661290ca4c6 100644
--- a/lldb/source/Plugins/Instruction/RISCV/EmulateInstructionRISCV.cpp
+++ b/lldb/source/Plugins/Instruction/RISCV/EmulateInstructionRISCV.cpp
@@ -33,6 +33,10 @@ LLDB_PLUGIN_DEFINE_ADV(EmulateInstructionRISCV, 
InstructionRISCV)
 
 namespace lldb_private {
 
+// RISC-V General Purpose Register numbers
+static constexpr uint32_t RISCV_GPR_SP = 2; // x2 is the stack pointer
+static constexpr uint32_t RISCV_GPR_FP = 8; // x8 is the frame pointer
+
 /// Returns all values wrapped in Optional, or std::nullopt if any of the 
values
 /// is std::nullopt.
 template 
@@ -108,6 +112,16 @@ static uint32_t FPREncodingToLLDB(uint32_t reg_encode) {
   return LLDB_INVALID_REGNUM;
 }
 
+// Helper function to get register info from GPR encoding
+static std::optional
+GPREncodingToRegisterInfo(EmulateInstructionRISCV &emulator,
+  uint32_t reg_encode) {
+  uint32_t lldb_reg = GPREncodingToLLDB(reg_encode);
+  if (lldb_reg == LLDB_INVALID_REGNUM)
+return std::nullopt;
+  return emulator.GetRegisterInfo(eRegisterKindLLDB, lldb_reg);
+}
+
 bool Rd::Write(EmulateInstructionRISCV &emulator, uint64_t value) {
   uint32_t lldb_reg = GPREncodingToLLDB(rd);
   EmulateInstruction::Context ctx;
@@ -230,10 +244,34 @@ Load(EmulateInstructionRISCV &emulator, I inst, uint64_t 
(*extend)(E)) {
   auto addr = LoadStoreAddr(emulator, inst);
   if (!addr)
 return false;
-  return transformOptional(
- emulator.ReadMem(*addr),
- [&](T t) { return inst.rd.Write(emulator, extend(E(t))); })
-  .value_or(false);
+
+  // Set up context for the load operation, similar to ARM64.
+  EmulateInstructionRISCV::Context context;
+
+  // Get register info for base register
+  std::optional reg_info_rs1 =
+  GPREncodingToRegisterInfo(emulator, inst.rs1.rs);
+
+  if (!reg_info_rs1)
+return false;
+
+  // Set context type based on whether this is a stack-based load.
+  if (inst.rs1.rs == RISCV_GPR_SP)
+context.type = EmulateInstruction::eContextPopRegisterOffStack;
+  else
+context.type = EmulateInstruction::eContextRegisterLoad;
+
+  // Set the context address information
+  context.SetAddress(*addr);
+
+  // Read from memory with context and write to register.
+  bool success = false;
+  uint64_t value =
+  emulator.ReadMemoryUnsigned(context, *addr, sizeof(T), 0, &success);
+  if (!success)
+return false;
+
+  return inst.rd.Write(emulator, extend(E(T(value;
 }
 
 template 
@@ -242,9 +280,35 @@ Store(EmulateInstructionRISCV &emulator, I inst) {
   auto addr = LoadStoreAddr(emulator, inst);
   if (!addr)
 return false;
-  return transformOptional(
- inst.rs2.Read(emulator),
- [&](uint64_t rs2) { return emulator.WriteMem(*addr, rs2); })
+
+  // Set up context for the store operation, similar to ARM64.
+  EmulateInstructionRISCV::Context context;
+
+  // Get register info for source and base registers.
+  std::optional reg_info_rs1 =
+  GPREncodingToRegisterInfo(emulator, inst.rs1.rs);
+  std::optional reg_info_rs2 =
+  GPREncodingToRegisterInfo(emulator, inst.rs2.rs);
+
+  if (!reg_info_rs1 || !reg_info_rs2)
+return false;
+
+  // Set context type based on whether this is a stack-based store.
+  if (inst.rs1.rs == RISCV_GPR_SP)
+context.type = EmulateInstruction::eContextPushRegisterOnSt

[Lldb-commits] [lldb] [lldb-dap] Improve the runInTerminal ux. (PR #163830)

[Jonas Devlieghere via lldb-commits]

@@ -121,6 +122,15 @@ class LLDBDAPOptTable : public llvm::opt::GenericOptTable {
 };
 } // anonymous namespace
 
+#define ESCAPE "\x1b"
+#define CSI ESCAPE "["
+// Move the cursor to 0,0
+#define ANSI_CURSOR_HOME CSI "H"
+// Clear the screen buffer
+#define ANSI_ERASE_SCREEN CSI "2J"
+// Clear the scroll back buffer
+#define ANSI_ERASE_SCROLLBACK CSI "3J"

JDevlieghere wrote:

Can we use `lldb/Utility/AnsiTerminal.h`?

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

[Lldb-commits] [lldb] support attaching by name for platform android (PR #160931)

[Chad Smith via lldb-commits]

https://github.com/cs01 updated https://github.com/llvm/llvm-project/pull/160931

>From 617de12c6d9ccfdd89d394c99132c596c9fd07ed Mon Sep 17 00:00:00 2001
From: Chad Smith 
Date: Fri, 26 Sep 2025 11:01:19 -0700
Subject: [PATCH 1/2] support attaching by name for platform android

---
 .../Platform/Android/PlatformAndroid.cpp  | 79 +++
 .../Platform/Android/PlatformAndroid.h|  3 +
 2 files changed, 82 insertions(+)

diff --git a/lldb/source/Plugins/Platform/Android/PlatformAndroid.cpp 
b/lldb/source/Plugins/Platform/Android/PlatformAndroid.cpp
index 600cc0a04cd22..bdef98c2d760f 100644
--- a/lldb/source/Plugins/Platform/Android/PlatformAndroid.cpp
+++ b/lldb/source/Plugins/Platform/Android/PlatformAndroid.cpp
@@ -477,6 +477,85 @@ std::string PlatformAndroid::GetRunAs() {
   }
   return run_as.str();
 }
+uint32_t
+PlatformAndroid::FindProcesses(const ProcessInstanceInfoMatch &match_info,
+   ProcessInstanceInfoList &proc_infos) {
+  // Use the parent implementation for host platform
+  if (IsHost())
+return PlatformLinux::FindProcesses(match_info, proc_infos);
+
+  // For remote Android platform, implement process name lookup using adb
+  proc_infos.clear();
+
+  // Check if we're looking for a process by name
+  const ProcessInstanceInfo &match_process_info = match_info.GetProcessInfo();
+  if (!match_process_info.GetExecutableFile() ||
+  match_info.GetNameMatchType() == NameMatch::Ignore) {
+// Fall back to the parent implementation if not searching by name
+return PlatformLinux::FindProcesses(match_info, proc_infos);
+  }
+
+  std::string process_name = match_process_info.GetExecutableFile().GetPath();
+  if (process_name.empty())
+return 0;
+
+  // Use adb to find the process by name
+  Status error;
+  AdbClientUP adb(GetAdbClient(error));
+  if (error.Fail()) {
+Log *log = GetLog(LLDBLog::Platform);
+LLDB_LOGF(log, "PlatformAndroid::%s failed to get ADB client: %s",
+  __FUNCTION__, error.AsCString());
+return 0;
+  }
+
+  // Use 'pidof' command to get the PID for the process name
+  std::string pidof_output;
+  std::string command = "pidof " + process_name;
+  error = adb->Shell(command.c_str(), seconds(5), &pidof_output);
+
+  if (error.Fail()) {
+Log *log = GetLog(LLDBLog::Platform);
+LLDB_LOGF(log, "PlatformAndroid::%s 'pidof %s' failed: %s", __FUNCTION__,
+  process_name.c_str(), error.AsCString());
+return 0;
+  }
+
+  // Parse the PID from pidof output
+  pidof_output = llvm::StringRef(pidof_output).trim().str();
+  if (pidof_output.empty()) {
+// No process found with that name
+return 0;
+  }
+
+  // Parse the output as a single PID
+  lldb::pid_t pid;
+  if (!llvm::to_integer(pidof_output, pid)) {
+Log *log = GetLog(LLDBLog::Platform);
+LLDB_LOGF(log, "PlatformAndroid::%s failed to parse PID from output: '%s'",
+  __FUNCTION__, pidof_output.c_str());
+return 0;
+  }
+
+  // Create ProcessInstanceInfo for the found process
+  ProcessInstanceInfo process_info;
+  process_info.SetProcessID(pid);
+  process_info.GetExecutableFile().SetFile(process_name,
+   FileSpec::Style::posix);
+
+  // Check if this process matches the criteria
+  if (match_info.Matches(process_info)) {
+proc_infos.push_back(process_info);
+
+Log *log = GetLog(LLDBLog::Platform);
+LLDB_LOGF(log, "PlatformAndroid::%s found process '%s' with PID %llu",
+  __FUNCTION__, process_name.c_str(), (unsigned long long)pid);
+return 1;
+  }
+
+  return 0;
+}
+
 std::unique_ptr PlatformAndroid::GetSyncService(Status &error) 
{
   auto sync_service = std::make_unique(m_device_id);
   error = sync_service->SetupSyncConnection();
diff --git a/lldb/source/Plugins/Platform/Android/PlatformAndroid.h 
b/lldb/source/Plugins/Platform/Android/PlatformAndroid.h
index 3384525362ecf..701d12922a383 100644
--- a/lldb/source/Plugins/Platform/Android/PlatformAndroid.h
+++ b/lldb/source/Plugins/Platform/Android/PlatformAndroid.h
@@ -59,6 +59,9 @@ class PlatformAndroid : public platform_linux::PlatformLinux {
 
   uint32_t GetDefaultMemoryCacheLineSize() override;
 
+  uint32_t FindProcesses(const ProcessInstanceInfoMatch &match_info,
+ ProcessInstanceInfoList &proc_infos) override;
+
 protected:
   const char *GetCacheHostname() override;
 

>From e292993f31e0ae5f05466672eb64fb0367d13dd0 Mon Sep 17 00:00:00 2001
From: Chad Smith 
Date: Wed, 8 Oct 2025 15:45:42 -0700
Subject: [PATCH 2/2] handle edge cases better

---
 .../Platform/Android/PlatformAndroid.cpp  | 232 +++---
 .../Platform/Android/PlatformAndroid.h|   8 +
 2 files changed, 206 insertions(+), 34 deletions(-)

diff --git a/lldb/source/Plugins/Platform/Android/PlatformAndroid.cpp 
b/lldb/source/Plugins/Platform/Android/PlatformAndroid.cpp
index bdef98c2d760f..f538fc60ef1e4 100644
--- a/lldb/source/Plugins/Platform/Android/Platform

[Lldb-commits] [lldb] [lldb][test] Allow '.c' files to be used as shell tests (PR #161520)

[Michael Buch via lldb-commits]

Michael137 wrote:

libc++ CI failure seems unrelated (not even sure why it ran)

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

[Lldb-commits] [lldb] [LLDB] Add unary plus and minus to DIL (PR #155617)

[Adrian Prantl via lldb-commits]

@@ -412,6 +412,13 @@ class TypeSystem : public PluginInterface,
   GetIntegralTemplateArgument(lldb::opaque_compiler_type_t type, size_t idx,
   bool expand_pack);
 
+  // DIL
+
+  virtual bool IsPromotableIntegerType(lldb::opaque_compiler_type_t type);
+
+  virtual llvm::Expected
+  DoIntegralPromotion(CompilerType from, ExecutionContextScope *exe_scope);

adrian-prantl wrote:

same here

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

[Lldb-commits] [lldb] [lldb] fix the "RegisterValue::SetValueFromData" method for 128-bit integer registers (PR #163646)

[David Spickett via lldb-commits]

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

[Lldb-commits] [lldb] 78c5d91 - [lldb][test] Disable TestLldbGdbServer.py on Linux temporarily (#161868)

[via lldb-commits]

Author: David Spickett
Date: 2025-10-03T16:54:18+01:00
New Revision: 78c5d9100f718fe380eeea6ca6236f3505a6c3a6

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

LOG: [lldb][test] Disable TestLldbGdbServer.py on Linux temporarily (#161868)

While #161510 is dealt with.

Added: 


Modified: 
lldb/test/API/tools/lldb-server/TestLldbGdbServer.py

Removed: 




diff  --git a/lldb/test/API/tools/lldb-server/TestLldbGdbServer.py 
b/lldb/test/API/tools/lldb-server/TestLldbGdbServer.py
index c01f6d83fafe5..f1c0519ae56d8 100644
--- a/lldb/test/API/tools/lldb-server/TestLldbGdbServer.py
+++ b/lldb/test/API/tools/lldb-server/TestLldbGdbServer.py
@@ -22,7 +22,9 @@
 from lldbsuite.test.lldbdwarf import *
 from lldbsuite.test import lldbutil, lldbplatformutil
 
-
+# On Linux systems with Yama ptrace_scope = 1 there is a race condition when 
the
+# debugee enables tracing. See 
https://github.com/llvm/llvm-project/issues/161510.
+@skipIfLinux
 class LldbGdbServerTestCase(
 gdbremote_testcase.GdbRemoteTestCaseBase, DwarfOpcodeParser
 ):



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

[Lldb-commits] [lldb] [lldb][Lanugage][NFC] Adapt Language::ForEach to IterationAction (PR #161830)

[Michael Buch via lldb-commits]

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

[Lldb-commits] [lldb] [lldb] Fix TypeSystemClang::GetBasicTypeEnumeration for 128-bit int types (PR #162278)

[Michael Buch via lldb-commits]

Matej =?utf-8?q?Košík?= ,
Matej =?utf-8?q?Košík?= 
Message-ID:
In-Reply-To: 



@@ -851,6 +851,8 @@ lldb::BasicType 
TypeSystemClang::GetBasicTypeEnumeration(llvm::StringRef name) {
   // "int128"
   {"__int128_t", eBasicTypeInt128},
   {"__uint128_t", eBasicTypeUnsignedInt128},

Michael137 wrote:

Can we add a comment saying the `_t` variants are actually typedefs and not 
builtins? But LLDB maps them for historical reasons

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

[Lldb-commits] [lldb] [lldb] Enforce that only the LLDB API unit tests can link liblldb (PR #162384)

[Alex Langford via lldb-commits]

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

Great idea. I wish CMake had a mechanism to enforce these kinds of linking 
constraints.

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

[Lldb-commits] [lldb] 23e0815 - [lldb][MachO][NFC] Extract ObjC metadata symbol parsing into helper function (#161536)

[via lldb-commits]

Author: Michael Buch
Date: 2025-10-01T15:58:09Z
New Revision: 23e081524fd9f64fb3430822e879b6dc36a1d3f1

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

LOG: [lldb][MachO][NFC] Extract ObjC metadata symbol parsing into helper 
function (#161536)

Just a simple de-duplication of the same code. We saw a bug here
recently (https://github.com/llvm/llvm-project/pull/161521). Might as
well isolate this all in one place.

rdar://158159242

Added: 


Modified: 
lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp

Removed: 




diff  --git a/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp 
b/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
index 91c93be1b8cfd..e8bbefe27f47f 100644
--- a/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
+++ b/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
@@ -2067,6 +2067,43 @@ static bool ParseTrieEntries(DataExtractor &data, 
lldb::offset_t offset,
   return true;
 }
 
+static bool
+TryParseV2ObjCMetadataSymbol(const char *&symbol_name,
+ const char *&symbol_name_non_abi_mangled,
+ SymbolType &type) {
+  static constexpr llvm::StringLiteral 
g_objc_v2_prefix_class("_OBJC_CLASS_$_");
+  static constexpr llvm::StringLiteral g_objc_v2_prefix_metaclass(
+  "_OBJC_METACLASS_$_");
+  static constexpr llvm::StringLiteral g_objc_v2_prefix_ivar("_OBJC_IVAR_$_");
+
+  llvm::StringRef symbol_name_ref(symbol_name);
+  if (symbol_name_ref.empty())
+return false;
+
+  if (symbol_name_ref.starts_with(g_objc_v2_prefix_class)) {
+symbol_name_non_abi_mangled = symbol_name + 1;
+symbol_name = symbol_name + g_objc_v2_prefix_class.size();
+type = eSymbolTypeObjCClass;
+return true;
+  }
+
+  if (symbol_name_ref.starts_with(g_objc_v2_prefix_metaclass)) {
+symbol_name_non_abi_mangled = symbol_name + 1;
+symbol_name = symbol_name + g_objc_v2_prefix_metaclass.size();
+type = eSymbolTypeObjCMetaClass;
+return true;
+  }
+
+  if (symbol_name_ref.starts_with(g_objc_v2_prefix_ivar)) {
+symbol_name_non_abi_mangled = symbol_name + 1;
+symbol_name = symbol_name + g_objc_v2_prefix_ivar.size();
+type = eSymbolTypeObjCIVar;
+return true;
+  }
+
+  return false;
+}
+
 static SymbolType GetSymbolType(const char *&symbol_name,
 bool &demangled_is_synthesized,
 const SectionSP &text_section_sp,
@@ -2183,9 +2220,6 @@ void ObjectFileMachO::ParseSymtab(Symtab &symtab) {
   lldb::offset_t offset = MachHeaderSizeFromMagic(m_header.magic);
   uint32_t i;
   FileSpecList dylib_files;
-  llvm::StringRef g_objc_v2_prefix_class("_OBJC_CLASS_$_");
-  llvm::StringRef g_objc_v2_prefix_metaclass("_OBJC_METACLASS_$_");
-  llvm::StringRef g_objc_v2_prefix_ivar("_OBJC_IVAR_$_");
   UUID image_uuid;
 
   for (i = 0; i < m_header.ncmds; ++i) {
@@ -2805,33 +2839,13 @@ void ObjectFileMachO::ParseSymtab(Symtab &symtab) {
 is_gsym = true;
 sym[sym_idx].SetExternal(true);
 
-llvm::StringRef symbol_name_ref(symbol_name);
-if (symbol_name_ref.starts_with(
-g_objc_v2_prefix_class)) {
-  symbol_name_non_abi_mangled = symbol_name + 1;
-  symbol_name =
-  symbol_name + g_objc_v2_prefix_class.size();
-  type = eSymbolTypeObjCClass;
-  demangled_is_synthesized = true;
-
-} else if (symbol_name_ref.starts_with(
-   g_objc_v2_prefix_metaclass)) {
-  symbol_name_non_abi_mangled = symbol_name + 1;
-  symbol_name =
-  symbol_name + g_objc_v2_prefix_metaclass.size();
-  type = eSymbolTypeObjCMetaClass;
+if (TryParseV2ObjCMetadataSymbol(
+symbol_name, symbol_name_non_abi_mangled,
+type)) {
   demangled_is_synthesized = true;
-} else if (symbol_name_ref.starts_with(
-   g_objc_v2_prefix_ivar)) {
-  symbol_name_non_abi_mangled = symbol_name + 1;
-  symbol_name =
-  symbol_name + g_objc_v2_prefix_ivar.size();
-  type = eSymbolTypeObjCIVar;
-  demangled_is_synthesized = true;
-} else {
-  if (nlist.n_value != 0)
-symbol_section = section_info.GetSe

[Lldb-commits] [lldb] [LLDB] Fix 64 bit support for CIE and FDE handling in DWARFCallFrameInfo (PR #158350)

[David Peixotto via lldb-commits]

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

LGTM. Thanks for the changes and adding the test!

> I do not know the proper way to test this change and am open to 
> recommendations on how to add a test.

We can update the commit message now that we have tests!

Question for my understanding. What would be the behavior of the tests without 
your fix? Would it crash in that case?

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

[Lldb-commits] [lldb] [lldb][IRExecutionUnit] Return error on failure to resolve function address (PR #161363)

[via lldb-commits]

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Michael Buch (Michael137)


Changes

Starting with https://github.com/llvm/llvm-project/pull/148877 we started 
encoding the module ID of the function DIE we are currently parsing into its 
`AsmLabel` in the AST. When the JIT asks LLDB to resolve our special mangled 
name, we would locate the module and resolve the function/symbol we found in it.

If we are debugging with a `SymbolFileDWARFDebugMap`, the module ID we encode 
is that of the `.o` file that is tracked by the debug-map. To resolve the 
address of the DIE in that `.o` file, we have to ask 
`SymbolFileDWARFDebugMap::LinkOSOAddress` to turn the address of the `.o` DIE 
into a real address in the linked executable. This will only work if the `.o` 
address was actually tracked by the debug-map. However, if the function 
definition appears in multiple `.o` files (which is the case for functions 
defined in headers), the linker will most likely de-deuplicate that definition. 
So most `.o`'s definition DIEs for that function won't have a contribution in 
the debug-map, and thus we fail to resolve the address.

When debugging Clang on Darwin, e.g., you'd see:
```
(lldb) expr CXXDecl->getName()

error: Couldn't look up symbols:
  $__lldb_func::0x1:0x4000d02359da:_ZNK5clang9NamedDecl7getNameEv
Hint: The expression tried to call a function that is not present in the 
target, perhaps because it was optimized out by the compiler.
```
unless you were stopped in the `.o` file whose definition of `getName` made it 
into the final executable.

The fix here is to error out if we fail to resolve the address, causing us to 
fall back on the old flow which did a lookup by mangled name, which the 
`SymbolFileDWARFDebugMap` will handle correctly.

An alternative fix to this would be to encode the
`SymbolFileDWARFDebugMap`'s module-id. And implement 
`SymbolFileDWARFDebugMap::ResolveFunctionCallLabel` by doing a mangled name 
lookup. The proposed approach doesn't stop us from implementing that, so we 
could choose to do it in a follow-up.

rdar://161393045

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


7 Files Affected:

- (modified) lldb/source/Expression/IRExecutionUnit.cpp (+6-1) 
- (added) lldb/test/API/lang/cpp/function-call-from-object-file/Makefile (+3) 
- (added) 
lldb/test/API/lang/cpp/function-call-from-object-file/TestFunctionCallFromObjectFile.py
 (+29) 
- (added) lldb/test/API/lang/cpp/function-call-from-object-file/common.h (+8) 
- (added) lldb/test/API/lang/cpp/function-call-from-object-file/lib1.cpp (+8) 
- (added) lldb/test/API/lang/cpp/function-call-from-object-file/lib2.cpp (+6) 
- (added) lldb/test/API/lang/cpp/function-call-from-object-file/main.cpp (+10) 


``diff
diff --git a/lldb/source/Expression/IRExecutionUnit.cpp 
b/lldb/source/Expression/IRExecutionUnit.cpp
index 25d4a87b89ef2..60b9de0d21b2e 100644
--- a/lldb/source/Expression/IRExecutionUnit.cpp
+++ b/lldb/source/Expression/IRExecutionUnit.cpp
@@ -751,7 +751,12 @@ ResolveFunctionCallLabel(FunctionCallLabel &label,
   sc_list.Append(*sc_or_err);
 
   LoadAddressResolver resolver(*sc.target_sp, symbol_was_missing_weak);
-  return resolver.Resolve(sc_list).value_or(LLDB_INVALID_ADDRESS);
+  lldb::addr_t resolved_addr =
+  resolver.Resolve(sc_list).value_or(LLDB_INVALID_ADDRESS);
+  if (resolved_addr == LLDB_INVALID_ADDRESS)
+return llvm::createStringError("couldn't resolve address for function");
+
+  return resolved_addr;
 }
 
 lldb::addr_t
diff --git a/lldb/test/API/lang/cpp/function-call-from-object-file/Makefile 
b/lldb/test/API/lang/cpp/function-call-from-object-file/Makefile
new file mode 100644
index 0..285bbfbbca4fe
--- /dev/null
+++ b/lldb/test/API/lang/cpp/function-call-from-object-file/Makefile
@@ -0,0 +1,3 @@
+CXX_SOURCES := main.cpp lib1.cpp lib2.cpp
+
+include Makefile.rules
diff --git 
a/lldb/test/API/lang/cpp/function-call-from-object-file/TestFunctionCallFromObjectFile.py
 
b/lldb/test/API/lang/cpp/function-call-from-object-file/TestFunctionCallFromObjectFile.py
new file mode 100644
index 0..f0a7aef182a67
--- /dev/null
+++ 
b/lldb/test/API/lang/cpp/function-call-from-object-file/TestFunctionCallFromObjectFile.py
@@ -0,0 +1,29 @@
+"""
+Tests that we can call functions that have definitions in multiple
+CUs in the debug-info (which is the case for functions defined in headers).
+The linker will most likely de-duplicate the functiond definitions when linking
+the final executable. On Darwin, this will create a debug-map that LLDB will 
use
+to fix up object file addresses to addresses in the linked executable. However,
+if we parsed the DIE from the object file whose functiond definition got 
stripped
+by the linker, LLDB needs to ensure it can still resolve the function symbol it
+got for it.
+"""
+
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+
+class TestFunctionCallF

[Lldb-commits] [lldb] e98f34e - [LLDB][NativePDB] Create functions with mangled name (#149701)

[via lldb-commits]

Author: nerix
Date: 2025-09-24T16:12:54+02:00
New Revision: e98f34eb08b2bf7aed787e7f8a7cea9111f044c8

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

LOG: [LLDB][NativePDB] Create functions with mangled name (#149701)

Before, functions created using the NativePDB plugin would not know
about their mangled name. This showed when printing a stacktrace. There,
only the function name was shown. For
https://github.com/llvm/llvm-project/issues/143149, the mangled function
name is required to separate different parts.

This PR adds that name if available.

The Clang AST nodes also take in a mangled name, which was previously
unset. I don't think this unblocks anything further, because Clang can
mangle the function anyway.

Added: 


Modified: 
lldb/source/Plugins/SymbolFile/NativePDB/PdbAstBuilder.cpp
lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp
lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.h
lldb/test/Shell/SymbolFile/NativePDB/break-by-function.cpp
lldb/test/Shell/SymbolFile/NativePDB/break-by-line.cpp
lldb/test/Shell/SymbolFile/NativePDB/disassembly.cpp
lldb/test/Shell/SymbolFile/NativePDB/find-functions.cpp
lldb/test/Shell/SymbolFile/NativePDB/local-variables.cpp
lldb/test/Shell/SymbolFile/NativePDB/stack_unwinding01.cpp
lldb/test/Shell/SymbolFile/PDB/function-nested-block.test
lldb/test/Shell/SymbolFile/PDB/variables.test

Removed: 




diff  --git a/lldb/source/Plugins/SymbolFile/NativePDB/PdbAstBuilder.cpp 
b/lldb/source/Plugins/SymbolFile/NativePDB/PdbAstBuilder.cpp
index 51bdcc92b05a8..e7fddf08967fb 100644
--- a/lldb/source/Plugins/SymbolFile/NativePDB/PdbAstBuilder.cpp
+++ b/lldb/source/Plugins/SymbolFile/NativePDB/PdbAstBuilder.cpp
@@ -38,16 +38,18 @@ struct CreateMethodDecl : public TypeVisitorCallbacks {
TypeIndex func_type_index,
clang::FunctionDecl *&function_decl,
lldb::opaque_compiler_type_t parent_ty,
-   llvm::StringRef proc_name, CompilerType func_ct)
+   llvm::StringRef proc_name, ConstString mangled_name,
+   CompilerType func_ct)
   : m_index(m_index), m_clang(m_clang), func_type_index(func_type_index),
 function_decl(function_decl), parent_ty(parent_ty),
-proc_name(proc_name), func_ct(func_ct) {}
+proc_name(proc_name), mangled_name(mangled_name), func_ct(func_ct) {}
   PdbIndex &m_index;
   TypeSystemClang &m_clang;
   TypeIndex func_type_index;
   clang::FunctionDecl *&function_decl;
   lldb::opaque_compiler_type_t parent_ty;
   llvm::StringRef proc_name;
+  ConstString mangled_name;
   CompilerType func_ct;
 
   llvm::Error visitKnownMember(CVMemberRecord &cvr,
@@ -87,8 +89,7 @@ struct CreateMethodDecl : public TypeVisitorCallbacks {
 bool is_artificial = (options & MethodOptions::CompilerGenerated) ==
  MethodOptions::CompilerGenerated;
 function_decl = m_clang.AddMethodToCXXRecordType(
-parent_ty, proc_name,
-/*asm_label=*/{}, func_ct, /*access=*/access_type,
+parent_ty, proc_name, mangled_name, func_ct, /*access=*/access_type,
 /*is_virtual=*/is_virtual, /*is_static=*/is_static,
 /*is_inline=*/false, /*is_explicit=*/false,
 /*is_attr_used=*/false, /*is_artificial=*/is_artificial);
@@ -892,6 +893,10 @@ PdbAstBuilder::CreateFunctionDecl(PdbCompilandSymId 
func_id,
 tag_record = CVTagRecord::create(index.tpi().getType(*eti)).asTag();
   }
 }
+
+ConstString mangled_name(
+pdb->FindMangledFunctionName(func_id).value_or(llvm::StringRef()));
+
 if (!tag_record.FieldList.isSimple()) {
   CVType field_list_cvt = index.tpi().getType(tag_record.FieldList);
   FieldListRecord field_list;
@@ -899,15 +904,15 @@ PdbAstBuilder::CreateFunctionDecl(PdbCompilandSymId 
func_id,
   field_list_cvt, field_list))
 llvm::consumeError(std::move(error));
   CreateMethodDecl process(index, m_clang, func_ti, function_decl,
-   parent_opaque_ty, func_name, func_ct);
+   parent_opaque_ty, func_name, mangled_name,
+   func_ct);
   if (llvm::Error err = visitMemberRecordStream(field_list.Data, process))
 llvm::consumeError(std::move(err));
 }
 
 if (!function_decl) {
   function_decl = m_clang.AddMethodToCXXRecordType(
-  parent_opaque_ty, func_name,
-  /*asm_label=*/{}, func_ct,
+  parent_opaque_ty, func_name, mangled_name, func_ct,
   /*access=*/lldb::AccessType::eAccessPublic,
   /*is_virtual=*/false, /*is_static=*/false,
   /*is_inline=*/false, /*is_explicit=*/false,

diff  --git a/

[Lldb-commits] [lldb] [lldb][test] check if CoreDumping is supported at runtime (PR #161385)

[Ebuka Ezike via lldb-commits]

https://github.com/da-viper created 
https://github.com/llvm/llvm-project/pull/161385

#160333 reimplementation but at runtime instead because of broken CI. 

>From bbc894aab1a2c58611b84025362422f5aa0821ac Mon Sep 17 00:00:00 2001
From: Ebuka Ezike 
Date: Tue, 30 Sep 2025 14:22:55 +0100
Subject: [PATCH 1/2] Revert "[lldb][test] check if CoreDumping info is
 supported (#160333)"

This reverts commit 02d8fb5789f64ed9cff3f42b005105a51c6c7550.
---
 lldb/unittests/Host/posix/HostTest.cpp | 9 -
 1 file changed, 9 deletions(-)

diff --git a/lldb/unittests/Host/posix/HostTest.cpp 
b/lldb/unittests/Host/posix/HostTest.cpp
index dc75b288ba76a..082edccf4e774 100644
--- a/lldb/unittests/Host/posix/HostTest.cpp
+++ b/lldb/unittests/Host/posix/HostTest.cpp
@@ -15,10 +15,6 @@
 #include 
 #include 
 
-#ifdef __linux__
-#include 
-#endif // __linux__
-
 using namespace lldb_private;
 
 namespace {
@@ -120,12 +116,7 @@ TEST_F(HostTest, GetProcessInfoSetsPriority) {
   ASSERT_TRUE(Info.IsZombie().has_value());
   ASSERT_FALSE(Info.IsZombie().value());
 
-  // CoreDumping was added in kernel version 4.15.
-#if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 15, 0)
   ASSERT_TRUE(Info.IsCoreDumping().has_value());
   ASSERT_FALSE(Info.IsCoreDumping().value());
-#else
-  ASSERT_FALSE(Info.IsCoreDumping().has_value());
-#endif
 }
 #endif

>From 7d3221629ec8da1e96363a2aa3783584f56cbaa4 Mon Sep 17 00:00:00 2001
From: Ebuka Ezike 
Date: Tue, 30 Sep 2025 15:37:20 +0100
Subject: [PATCH 2/2] [lldb][test] check if CoreDumping is supported at runtime

---
 lldb/unittests/Host/posix/HostTest.cpp | 40 --
 1 file changed, 38 insertions(+), 2 deletions(-)

diff --git a/lldb/unittests/Host/posix/HostTest.cpp 
b/lldb/unittests/Host/posix/HostTest.cpp
index 082edccf4e774..d4f6d10ec5d3d 100644
--- a/lldb/unittests/Host/posix/HostTest.cpp
+++ b/lldb/unittests/Host/posix/HostTest.cpp
@@ -15,6 +15,12 @@
 #include 
 #include 
 
+#ifdef __linux__
+#include 
+#include 
+#include 
+#endif // __linux__
+
 using namespace lldb_private;
 
 namespace {
@@ -94,6 +100,28 @@ TEST_F(HostTest, GetProcessInfo) {
 
 // Only linux currently sets these.
 #ifdef __linux__
+
+int KernelVersion(int major, int minor, int patch) {
+  return KERNEL_VERSION(major, minor, patch);
+}
+
+std::optional GetLinuxVersion() {
+  struct utsname buffer;
+
+  if (uname(&buffer) != 0)
+return std::nullopt;
+
+  std::stringstream release(buffer.release);
+  int major = 0;
+  int minor = 0;
+  int patch = 0;
+  release >> major;
+  release >> minor;
+  release >> patch;
+
+  return KernelVersion(major, minor, patch);
+}
+
 TEST_F(HostTest, GetProcessInfoSetsPriority) {
   ProcessInstanceInfo Info;
   struct rlimit rlim;
@@ -116,7 +144,15 @@ TEST_F(HostTest, GetProcessInfoSetsPriority) {
   ASSERT_TRUE(Info.IsZombie().has_value());
   ASSERT_FALSE(Info.IsZombie().value());
 
-  ASSERT_TRUE(Info.IsCoreDumping().has_value());
-  ASSERT_FALSE(Info.IsCoreDumping().value());
+  std::optional opt_linux_version = GetLinuxVersion();
+  if (opt_linux_version.has_value()) {
+
+if (opt_linux_version.value() >= KernelVersion(4, 15, 0)) {
+  ASSERT_TRUE(Info.IsCoreDumping().has_value());
+  ASSERT_FALSE(Info.IsCoreDumping().value());
+} else {
+  ASSERT_FALSE(Info.IsCoreDumping().has_value());
+}
+  }
 }
 #endif

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

[Lldb-commits] [lldb] 8e62ace - [lldb] Ignore trailing spaces on quit confirmation (#162263)

[via lldb-commits]

Author: Ebuka Ezike
Date: 2025-10-08T18:48:20+01:00
New Revision: 8e62acec9e0228118e2a5a982ca2eaa7b213a049

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

LOG: [lldb] Ignore trailing spaces on quit confirmation (#162263)

Added: 


Modified: 
lldb/source/Core/IOHandler.cpp
lldb/test/API/driver/quit_speed/TestQuitWithProcess.py

Removed: 




diff  --git a/lldb/source/Core/IOHandler.cpp b/lldb/source/Core/IOHandler.cpp
index 57819eeade6e8..c2530aa0d00c5 100644
--- a/lldb/source/Core/IOHandler.cpp
+++ b/lldb/source/Core/IOHandler.cpp
@@ -152,15 +152,16 @@ void IOHandlerConfirm::IOHandlerComplete(IOHandler 
&io_handler,
 
 void IOHandlerConfirm::IOHandlerInputComplete(IOHandler &io_handler,
   std::string &line) {
-  if (line.empty()) {
+  const llvm::StringRef input = llvm::StringRef(line).rtrim();
+  if (input.empty()) {
 // User just hit enter, set the response to the default
 m_user_response = m_default_response;
 io_handler.SetIsDone(true);
 return;
   }
 
-  if (line.size() == 1) {
-switch (line[0]) {
+  if (input.size() == 1) {
+switch (input[0]) {
 case 'y':
 case 'Y':
   m_user_response = true;
@@ -176,10 +177,10 @@ void IOHandlerConfirm::IOHandlerInputComplete(IOHandler 
&io_handler,
 }
   }
 
-  if (line == "yes" || line == "YES" || line == "Yes") {
+  if (input.equals_insensitive("yes")) {
 m_user_response = true;
 io_handler.SetIsDone(true);
-  } else if (line == "no" || line == "NO" || line == "No") {
+  } else if (input.equals_insensitive("no")) {
 m_user_response = false;
 io_handler.SetIsDone(true);
   }

diff  --git a/lldb/test/API/driver/quit_speed/TestQuitWithProcess.py 
b/lldb/test/API/driver/quit_speed/TestQuitWithProcess.py
index 2412b295bfb59..305e3cc397cf0 100644
--- a/lldb/test/API/driver/quit_speed/TestQuitWithProcess.py
+++ b/lldb/test/API/driver/quit_speed/TestQuitWithProcess.py
@@ -33,3 +33,28 @@ def test_run_quit(self):
 child.sendline("quit")
 print("sent quit")
 child.expect(pexpect.EOF, timeout=15)
+
+@skipIfAsan
+def test_run_quit_with_prompt(self):
+"""Test that the lldb driver's batch mode works correctly with 
trailing space in confimation."""
+import pexpect
+
+self.build()
+
+exe = self.getBuildArtifact("a.out")
+
+self.launch(executable=exe)
+child = self.child
+
+# Launch the process without a TTY so we don't have to interrupt:
+child.sendline("process launch -n")
+print("launched process")
+child.expect(r"Process ([\d]*) launched:")
+print("Got launch message")
+child.sendline("quit")
+print("sent quit")
+
+child.expect(r".*LLDB will kill one or more processes.*")
+# add trailing space to the confirmation.
+child.sendline("yEs ")
+child.expect(pexpect.EOF, timeout=15)



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

[Lldb-commits] [lldb] Fix comment typo in `StructuredDataPlugin.cpp` (PR #162637)

[Charles Zablit via lldb-commits]

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

[Lldb-commits] [lldb] 3d81008 - [lldb][Lanugage][NFC] Adapt Language::ForEach to IterationAction (#161830)

[via lldb-commits]

Author: Michael Buch
Date: 2025-10-03T15:47:21+01:00
New Revision: 3d810086d1e16e2de57634d7eb5ecf25a5227e4c

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

LOG: [lldb][Lanugage][NFC] Adapt Language::ForEach to IterationAction (#161830)

Added: 


Modified: 
lldb/include/lldb/Target/Language.h
lldb/source/Breakpoint/BreakpointResolverName.cpp
lldb/source/Commands/CommandObjectType.cpp
lldb/source/Core/Mangled.cpp
lldb/source/Symbol/Symtab.cpp
lldb/source/Target/Language.cpp

Removed: 




diff  --git a/lldb/include/lldb/Target/Language.h 
b/lldb/include/lldb/Target/Language.h
index 3d0aa326d5a6d..6f20a02335b35 100644
--- a/lldb/include/lldb/Target/Language.h
+++ b/lldb/include/lldb/Target/Language.h
@@ -166,7 +166,7 @@ class Language : public PluginInterface {
   llvm::StringRef file_path);
 
   // return false from callback to stop iterating
-  static void ForEach(std::function callback);
+  static void ForEach(llvm::function_ref 
callback);
 
   virtual lldb::LanguageType GetLanguageType() const = 0;
 
@@ -420,7 +420,8 @@ class Language : public PluginInterface {
 llvm::StringRef suffix);
 
   // return false from callback to stop iterating
-  static void ForAllLanguages(std::function 
callback);
+  static void ForAllLanguages(
+  llvm::function_ref callback);
 
   static bool LanguageIsCPlusPlus(lldb::LanguageType language);
 

diff  --git a/lldb/source/Breakpoint/BreakpointResolverName.cpp 
b/lldb/source/Breakpoint/BreakpointResolverName.cpp
index 6372595a0f21f..4f252f91cccdc 100644
--- a/lldb/source/Breakpoint/BreakpointResolverName.cpp
+++ b/lldb/source/Breakpoint/BreakpointResolverName.cpp
@@ -233,7 +233,7 @@ void BreakpointResolverName::AddNameLookup(ConstString name,
 m_lookups.emplace_back(variant_lookup);
   }
 }
-return true;
+return IterationAction::Continue;
   };
 
   if (Language *lang = Language::FindPlugin(m_language)) {

diff  --git a/lldb/source/Commands/CommandObjectType.cpp 
b/lldb/source/Commands/CommandObjectType.cpp
index 19cd3ff2972e9..22ed5b8ed593a 100644
--- a/lldb/source/Commands/CommandObjectType.cpp
+++ b/lldb/source/Commands/CommandObjectType.cpp
@@ -2610,7 +2610,7 @@ class CommandObjectTypeLookup : public CommandObjectRaw {
 Language::ForEach([&](Language *lang) {
   if (const char *help = lang->GetLanguageSpecificTypeLookupHelp())
 stream.Printf("%s\n", help);
-  return true;
+  return IterationAction::Continue;
 });
 
 m_cmd_help_long = std::string(stream.GetString());
@@ -2649,7 +2649,7 @@ class CommandObjectTypeLookup : public CommandObjectRaw {
  (m_command_options.m_language == eLanguageTypeUnknown))) {
   Language::ForEach([&](Language *lang) {
 languages.push_back(lang);
-return true;
+return IterationAction::Continue;
   });
 } else {
   languages.push_back(Language::FindPlugin(m_command_options.m_language));

diff  --git a/lldb/source/Core/Mangled.cpp b/lldb/source/Core/Mangled.cpp
index 0780846b0ed60..f7683c55baf84 100644
--- a/lldb/source/Core/Mangled.cpp
+++ b/lldb/source/Core/Mangled.cpp
@@ -428,9 +428,9 @@ lldb::LanguageType Mangled::GuessLanguage() const {
   Language::ForEach([this, &result](Language *l) {
 if (l->SymbolNameFitsToLanguage(*this)) {
   result = l->GetLanguageType();
-  return false;
+  return IterationAction::Stop;
 }
-return true;
+return IterationAction::Continue;
   });
   return result;
 }

diff  --git a/lldb/source/Symbol/Symtab.cpp b/lldb/source/Symbol/Symtab.cpp
index 970f6c474e375..6080703998ff2 100644
--- a/lldb/source/Symbol/Symtab.cpp
+++ b/lldb/source/Symbol/Symtab.cpp
@@ -289,7 +289,7 @@ void Symtab::InitNameIndexes() {
 std::vector languages;
 Language::ForEach([&languages](Language *l) {
   languages.push_back(l);
-  return true;
+  return IterationAction::Continue;
 });
 
 auto &name_to_index = GetNameToSymbolIndexMap(lldb::eFunctionNameTypeNone);

diff  --git a/lldb/source/Target/Language.cpp b/lldb/source/Target/Language.cpp
index 484d9badde397..d4a926874b0ce 100644
--- a/lldb/source/Target/Language.cpp
+++ b/lldb/source/Target/Language.cpp
@@ -111,9 +111,9 @@ Language *Language::FindPlugin(llvm::StringRef file_path) {
   ForEach([&result, file_path](Language *language) {
 if (language->IsSourceFile(file_path)) {
   result = language;
-  return false;
+  return IterationAction::Stop;
 }
-return true;
+return IterationAction::Continue;
   });
   return result;
 }
@@ -128,7 +128,8 @@ Language *Language::FindPlugin(LanguageType language,
   return result;
 }
 
-void Language::ForEach(std::function callback)

[Lldb-commits] [lldb] [LLDB] Add load core time to target metrics (PR #161581)

[via lldb-commits]

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Jacob Lalonde (Jlalond)


Changes

This patch adds a load core time, right now we don't have much insight into the 
performance of load core, especially for large coredumps. To start collecting 
information on this I've added some minor instrumentation code to measure the 
two call sites of `LoadCore`. 

I've also added a test to validate the new metric is output in statistics dump

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


6 Files Affected:

- (modified) lldb/include/lldb/Target/Statistics.h (+2) 
- (modified) lldb/source/API/SBTarget.cpp (+1) 
- (modified) lldb/source/Commands/CommandObjectTarget.cpp (+5-1) 
- (modified) lldb/source/Target/Statistics.cpp (+5) 
- (modified) lldb/test/API/functionalities/stats_api/TestStatisticsAPI.py (+23) 
- (added) lldb/test/API/functionalities/stats_api/arm64-minidump-build-ids.yaml 
(+19) 


``diff
diff --git a/lldb/include/lldb/Target/Statistics.h 
b/lldb/include/lldb/Target/Statistics.h
index d6983bb0b9d24..2653835206ec7 100644
--- a/lldb/include/lldb/Target/Statistics.h
+++ b/lldb/include/lldb/Target/Statistics.h
@@ -322,12 +322,14 @@ class TargetStats {
   void IncreaseSourceRealpathCompatibleCount(uint32_t count);
 
   StatsDuration &GetCreateTime() { return m_create_time; }
+  StatsDuration &GetLoadCoreTime() { return m_load_core_time; }
   StatsSuccessFail &GetExpressionStats() { return m_expr_eval; }
   StatsSuccessFail &GetFrameVariableStats() { return m_frame_var; }
   void Reset(Target &target);
 
 protected:
   StatsDuration m_create_time;
+  StatsDuration m_load_core_time;
   std::optional m_launch_or_attach_time;
   std::optional m_first_private_stop_time;
   std::optional m_first_public_stop_time;
diff --git a/lldb/source/API/SBTarget.cpp b/lldb/source/API/SBTarget.cpp
index eb56337de3c44..90ffe786c696c 100644
--- a/lldb/source/API/SBTarget.cpp
+++ b/lldb/source/API/SBTarget.cpp
@@ -255,6 +255,7 @@ SBProcess SBTarget::LoadCore(const char *core_file, 
lldb::SBError &error) {
 ProcessSP process_sp(target_sp->CreateProcess(
 target_sp->GetDebugger().GetListener(), "", &filespec, false));
 if (process_sp) {
+  ElapsedTime loadCoreTime(target_sp->GetStatistics().GetLoadCoreTime());
   error.SetError(process_sp->LoadCore());
   if (error.Success())
 sb_process.SetSP(process_sp);
diff --git a/lldb/source/Commands/CommandObjectTarget.cpp 
b/lldb/source/Commands/CommandObjectTarget.cpp
index 940be42d1b6e3..b5fc49d58c1eb 100644
--- a/lldb/source/Commands/CommandObjectTarget.cpp
+++ b/lldb/source/Commands/CommandObjectTarget.cpp
@@ -418,7 +418,11 @@ class CommandObjectTargetCreate : public 
CommandObjectParsed {
 if (process_sp) {
   // Seems weird that we Launch a core file, but that is what we
   // do!
-  error = process_sp->LoadCore();
+  {
+ElapsedTime loadCoreTime(
+target_sp->GetStatistics().GetLoadCoreTime());
+error = process_sp->LoadCore();
+  }
 
   if (error.Fail()) {
 result.AppendError(error.AsCString("unknown core file format"));
diff --git a/lldb/source/Target/Statistics.cpp 
b/lldb/source/Target/Statistics.cpp
index 8ad8d507268e2..f7311a8b24416 100644
--- a/lldb/source/Target/Statistics.cpp
+++ b/lldb/source/Target/Statistics.cpp
@@ -148,6 +148,11 @@ TargetStats::ToJSON(Target &target,
 target_metrics_json.try_emplace("targetCreateTime",
 m_create_time.get().count());
 
+if (m_load_core_time.get().count() > 0) {
+  target_metrics_json.try_emplace("loadCoreTime",
+  m_load_core_time.get().count());
+}
+
 json::Array breakpoints_array;
 double totalBreakpointResolveTime = 0.0;
 // Report both the normal breakpoint list and the internal breakpoint list.
diff --git a/lldb/test/API/functionalities/stats_api/TestStatisticsAPI.py 
b/lldb/test/API/functionalities/stats_api/TestStatisticsAPI.py
index f06c9ae14bb7a..b638347b4f6f4 100644
--- a/lldb/test/API/functionalities/stats_api/TestStatisticsAPI.py
+++ b/lldb/test/API/functionalities/stats_api/TestStatisticsAPI.py
@@ -1,6 +1,7 @@
 # Test the SBAPI for GetStatistics()
 
 import json
+
 import lldb
 from lldbsuite.test.decorators import *
 from lldbsuite.test.lldbtest import *
@@ -157,3 +158,25 @@ def test_command_stats_force(self):
 stats_force.GetAsJSON(stream_force)
 debug_stats_force = json.loads(stream_force.GetData())
 self.assertEqual(debug_stats_force["totalDebugInfoByteSize"], 445)
+
+def test_core_load_time(self):
+"""
+Test to see if the coredump path is included in statistics dump.
+"""
+yaml_file = "arm64-minidump-build-ids.yaml"
+src_dir = self.getSourceDir()
+minidump_path = self.getBuildArtifact(os.path.basename(yaml_file) + 
".dmp")
+self.yaml2obj(os.path.join(src_dir, yaml_fi

[Lldb-commits] [lldb] [LLDB] Handle i686 mingw32 mangling prefix (PR #160930)

[Michael Buch via lldb-commits]

Michael137 wrote:

> That's the case, and also why just checking for __Z isn't enough. For one, 
> this doesn't play nice with Rust, which also has two underscores on i686. And 
> secondly, C names are displayed incorrectly right now. For example, you'd see 
> _main instead of main and a function like void Zone() would become _Zone and 
> interpreted as an itanium name.

I see. So just checking `__Z` in `GetManglingScheme` doesn't work because Rust 
and other mangling schemes suffer from this issue. Then yea, I think we can do 
the stripping in PDB.

I don't think we need to in DWARF though? At least I haven't seen the prefix be 
added into DWARF `DW_AT_linkage_name`s before.

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

[Lldb-commits] [lldb] Make SBBreakpoint/SBBreakpointLocation.SetCondition(nullptr) work again. (PR #162370)

[via lldb-commits]

@@ -1,10 +1,15 @@
-add_lldb_unittest(LLDBBreakpointTests
+add_lldb_unittest(LLDBBreakpointTests  
   BreakpointIDTest.cpp
+  BreakpointClearConditionTest.cpp
   WatchpointAlgorithmsTests.cpp
 
   LINK_COMPONENTS
 Support
   LINK_LIBS
+liblldb

jimingham wrote:

Also, if this is a rule, it would be good to have it documented somewhere.

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

[Lldb-commits] [lldb] [LLDB][PDB] Fix plugin warning message style (PR #160398)

[via lldb-commits]

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

[Lldb-commits] [lldb] [lldb][NFCI] Remove the non-const reference Mangled::GetMangledName accessor (PR #161495)

[Michael Buch via lldb-commits]

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

We've been seen (very sporadic) lifetime issues around this area. We noticed 
that `GetMangledName` has two accessors, one of which returns a non-const 
reference. I audited all the callsites and no users of this overload actually 
mutate the `ConstString` itself (which is a suspicious thing to do anyway since 
it's just a wrapper around a `const char*`).

This patch removes the redundant overload.

rdar://161128180

>From bf3f96512240f1387003405544fa081c64a63025 Mon Sep 17 00:00:00 2001
From: Michael Buch 
Date: Wed, 1 Oct 2025 10:18:53 +0100
Subject: [PATCH] [lldb][NFCI] Remove the non-const reference
 Mangled::GetMangledName accessor

We've been seen (very sporadic) lifetime issues around this area. We
noticed that `GetMangledName` has two accessors, one of which returns a
non-const reference. I audited all the callsites and no users of this
overload actually mutate the `ConstString` itself (which is a suspicious
thing to do anyway since it's just a wrapper around a `const char*`).

This patch removes the redundant overload.

rdar://161128180
---
 lldb/include/lldb/Core/Mangled.h | 8 +---
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/lldb/include/lldb/Core/Mangled.h b/lldb/include/lldb/Core/Mangled.h
index 47f1c6a8d80b7..1dcc34b4989dd 100644
--- a/lldb/include/lldb/Core/Mangled.h
+++ b/lldb/include/lldb/Core/Mangled.h
@@ -148,13 +148,7 @@ class Mangled {
   /// Mangled name get accessor.
   ///
   /// \return
-  /// A reference to the mangled name string object.
-  ConstString &GetMangledName() { return m_mangled; }
-
-  /// Mangled name get accessor.
-  ///
-  /// \return
-  /// A const reference to the mangled name string object.
+  /// A the mangled name string object.
   ConstString GetMangledName() const { return m_mangled; }
 
   /// Best name get accessor.

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

[Lldb-commits] [lldb] 097f1e7 - [lldb] Do not stop the process on SIGWINCH by default. (#163182)

[via lldb-commits]

Author: Ebuka Ezike
Date: 2025-10-15T17:19:51+01:00
New Revision: 097f1e7625966673b881df63a241f755317b0bb9

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

LOG: [lldb] Do not stop the process on SIGWINCH by default. (#163182)

SIGWINCH is sent when the terminal window size changes.. Most people
debugging do not want the process on this signal.

When using lldb-dap, the user may be using an integrated terminal and
may resize the pane/window mulitple times when debugging. this causes
the signal to be sent multiple times. It gets in the way.

The process ignores this signal by default

Added: 


Modified: 
lldb/source/Plugins/Process/Utility/GDBRemoteSignals.cpp
lldb/source/Plugins/Process/Utility/LinuxSignals.cpp
llvm/docs/ReleaseNotes.md

Removed: 




diff  --git a/lldb/source/Plugins/Process/Utility/GDBRemoteSignals.cpp 
b/lldb/source/Plugins/Process/Utility/GDBRemoteSignals.cpp
index 15981a2c1cb80..a8d18f774c361 100644
--- a/lldb/source/Plugins/Process/Utility/GDBRemoteSignals.cpp
+++ b/lldb/source/Plugins/Process/Utility/GDBRemoteSignals.cpp
@@ -47,7 +47,7 @@ void GDBRemoteSignals::Reset() {
   AddSignal(25, "SIGXFSZ",  false,true,   true,   "file size limit 
exceeded");
   AddSignal(26, "SIGVTALRM",false,true,   true,   "virtual time 
alarm");
   AddSignal(27, "SIGPROF",  false,false,  false,  "profiling time 
alarm");
-  AddSignal(28, "SIGWINCH", false,true,   true,   "window size 
changes");
+  AddSignal(28, "SIGWINCH", false,false,   false,   "window size 
changes");
   AddSignal(29, "SIGLOST",  false,true,   true,   "resource lost");
   AddSignal(30, "SIGUSR1",  false,true,   true,   "user defined 
signal 1");
   AddSignal(31, "SIGUSR2",  false,true,   true,   "user defined 
signal 2");

diff  --git a/lldb/source/Plugins/Process/Utility/LinuxSignals.cpp 
b/lldb/source/Plugins/Process/Utility/LinuxSignals.cpp
index 5346babc18576..dbbfc6a352e02 100644
--- a/lldb/source/Plugins/Process/Utility/LinuxSignals.cpp
+++ b/lldb/source/Plugins/Process/Utility/LinuxSignals.cpp
@@ -160,7 +160,7 @@ void LinuxSignals::Reset() {
   ADD_LINUX_SIGNAL(25, "SIGXFSZ",  false,true,   true,   "file 
size limit exceeded");
   ADD_LINUX_SIGNAL(26, "SIGVTALRM",false,true,   true,   "virtual 
time alarm");
   ADD_LINUX_SIGNAL(27, "SIGPROF",  false,false,  false,  
"profiling time alarm");
-  ADD_LINUX_SIGNAL(28, "SIGWINCH", false,true,   true,   "window 
size changes");
+  ADD_LINUX_SIGNAL(28, "SIGWINCH", false,false,   false,   "window 
size changes");
   ADD_LINUX_SIGNAL(29, "SIGIO",false,true,   true,   
"input/output ready/Pollable event", "SIGPOLL");
   ADD_LINUX_SIGNAL(30, "SIGPWR",   false,true,   true,   "power 
failure");
   ADD_LINUX_SIGNAL(31, "SIGSYS",   false,true,   true,   "invalid 
system call");

diff  --git a/llvm/docs/ReleaseNotes.md b/llvm/docs/ReleaseNotes.md
index 9ca08d63ec021..c352cd6e1cae7 100644
--- a/llvm/docs/ReleaseNotes.md
+++ b/llvm/docs/ReleaseNotes.md
@@ -176,6 +176,9 @@ Changes to LLDB
 
 * LLDB can now set breakpoints, show backtraces, and display variables when
   debugging Wasm with supported runtimes (WAMR and V8).
+* LLDB no longer stops processes by default when receiving SIGWINCH signals 
+  (window resize events) on Linux. This is the default on other Unix platforms.
+  You can re-enable it using `process handle --notify=true --stop=true 
SIGWINCH`.
 * The `show-progress` setting, which became a NOOP with the introduction of the
   statusline, now defaults to off and controls using OSC escape codes to show a
   native progress bar in supporting terminals like Ghostty and ConEmu.



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

[Lldb-commits] [lldb] [LLDB, FreeBSD, x86] Fix empty register set when trying to get size of register (PR #162890)

[via lldb-commits]

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

[Lldb-commits] [lldb] [lldb][Language] Sync LanguageType enumeration with DWARF codes (PR #161810)

[David Spickett via lldb-commits]

DavidSpickett wrote:

If there's a stack based type to hand use it, but otherwise yeah we were always 
gonna hit this limit eventually.

Also double check that what the comment says is still true. Maybe bitvector got 
better in the meantime?

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

[Lldb-commits] [lldb] [LLDB][NativePDB] Consolidate simple types (PR #163209)

[Michael Buch via lldb-commits]

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


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

[Lldb-commits] [clang] [lldb] [llvm] [ADT] Mark StringSwitch Cases with 6+ arguments as deprecated. NFC. (PR #163405)

[Jakub Kuderski via lldb-commits]

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

[Lldb-commits] [lldb] [debugserver] Implement MultiMemRead packet (PR #162670)

[Felipe de Azevedo Piovezan via lldb-commits]

https://github.com/felipepiovezan created 
https://github.com/llvm/llvm-project/pull/162670

This commit implements, in debugserver, the packet as discussed in the RFC [1].

[1]: https://discourse.llvm.org/t/rfc-a-new-vectorized-memory-read-packet/88441

>From 86c55d2a5ac398a86a29d722a4d4e44ba783d08f Mon Sep 17 00:00:00 2001
From: Felipe de Azevedo Piovezan 
Date: Wed, 8 Oct 2025 15:37:48 -0700
Subject: [PATCH] [debugserver] Implement MultiMemRead packet

This commit implements, in debugserver, the packet as discussed in the
RFC [1].

[1]: https://discourse.llvm.org/t/rfc-a-new-vectorized-memory-read-packet/88441
---
 .../macosx/debugserver-multimemread/Makefile  |   3 +
 .../TestDebugserverMultiMemRead.py|  72 +
 .../macosx/debugserver-multimemread/main.c|  10 ++
 lldb/tools/debugserver/source/RNBRemote.cpp   | 140 ++
 lldb/tools/debugserver/source/RNBRemote.h |   2 +
 5 files changed, 227 insertions(+)
 create mode 100644 lldb/test/API/macosx/debugserver-multimemread/Makefile
 create mode 100644 
lldb/test/API/macosx/debugserver-multimemread/TestDebugserverMultiMemRead.py
 create mode 100644 lldb/test/API/macosx/debugserver-multimemread/main.c

diff --git a/lldb/test/API/macosx/debugserver-multimemread/Makefile 
b/lldb/test/API/macosx/debugserver-multimemread/Makefile
new file mode 100644
index 0..10495940055b6
--- /dev/null
+++ b/lldb/test/API/macosx/debugserver-multimemread/Makefile
@@ -0,0 +1,3 @@
+C_SOURCES := main.c
+
+include Makefile.rules
diff --git 
a/lldb/test/API/macosx/debugserver-multimemread/TestDebugserverMultiMemRead.py 
b/lldb/test/API/macosx/debugserver-multimemread/TestDebugserverMultiMemRead.py
new file mode 100644
index 0..5c0c7a34e18bd
--- /dev/null
+++ 
b/lldb/test/API/macosx/debugserver-multimemread/TestDebugserverMultiMemRead.py
@@ -0,0 +1,72 @@
+"""
+Tests the exit code/description coming from the debugserver.
+"""
+
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+
+@skipUnlessDarwin
+@skipIfOutOfTreeDebugserver
+class TestCase(TestBase):
+def send_process_packet(self, packet_str):
+self.runCmd(f"proc plugin packet send {packet_str}", check=False)
+# The output is of the form:
+#  packet: 
+#  response: 
+reply = self.res.GetOutput().split("\n")
+reply[0] = reply[0].strip()
+reply[1] = reply[1].strip()
+
+self.assertTrue(reply[0].startswith("packet: "), reply[0])
+self.assertTrue(reply[1].startswith("response: "))
+return reply[1][len("response: ") :]
+
+def test_packets(self):
+self.build()
+source_file = lldb.SBFileSpec("main.c")
+target, process, thread, bkpt = lldbutil.run_to_source_breakpoint(
+self, "break here", source_file
+)
+
+reply = self.send_process_packet("qSupported")
+self.assertIn("MultiMemRead+", reply)
+
+mem_address_var = thread.frames[0].FindVariable("memory")
+self.assertTrue(mem_address_var)
+mem_address = int(mem_address_var.GetValue(), 16)
+
+reply = self.send_process_packet("MultiMemRead:")
+self.assertEqual(reply, "E03")
+reply = self.send_process_packet("MultiMemRead:ranges:")
+self.assertEqual(reply, "E03")
+reply = self.send_process_packet("MultiMemRead:ranges:10")
+self.assertEqual(reply, "E03")
+reply = self.send_process_packet("MultiMemRead:ranges:10,")
+self.assertEqual(reply, "E03")
+reply = self.send_process_packet("MultiMemRead:ranges:10,2")
+self.assertEqual(reply, "E03")
+reply = self.send_process_packet("MultiMemRead:ranges:10,2,")
+self.assertEqual(reply, "E03")
+reply = self.send_process_packet("MultiMemRead:ranges:10,2,;")
+self.assertEqual(reply, "0;")  # Debugserver is permissive with 
trailing commas.
+reply = self.send_process_packet("MultiMemRead:ranges:10,2;")
+self.assertEqual(reply, "0;")
+reply = 
self.send_process_packet(f"MultiMemRead:ranges:{mem_address:x},0;")
+self.assertEqual(reply, "0;")
+reply = self.send_process_packet(
+f"MultiMemRead:ranges:{mem_address:x},0;options:;"
+)
+self.assertEqual(reply, "0;")
+reply = 
self.send_process_packet(f"MultiMemRead:ranges:{mem_address:x},2;")
+self.assertEqual(reply, "2;ab")
+reply = self.send_process_packet(
+f"MultiMemRead:ranges:{mem_address:x},2,{mem_address+2:x},4;"
+)
+self.assertEqual(reply, "2,4;abcdef")
+reply = self.send_process_packet(
+
f"MultiMemRead:ranges:{mem_address:x},2,{mem_address+2:x},4,{mem_address+6:x},8;"
+)
+self.assertEqual(reply, "2,4,8;abcdefghijklmn")
diff --git a/lldb/test/API/macosx/debugserver-multimemread/main.c 
b/lldb/test/API/macosx/debugserver-multimemread/main.

[Lldb-commits] [lldb] [lldb-dap] Remove timings from TestDAP_attach (PR #163452)

[Walter Erquinigo via lldb-commits]

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

I love it when I see @skips getting removed

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

[Lldb-commits] [lldb] [LLDB] Add type casting to DIL. (PR #159500)

[Ilia Kuklin via lldb-commits]

kuilpd wrote:

> Swift does have builtin types, they just aren't exposed to the user directly. 

@jimingham 
Ah, I see. Well, then we can still check for builtin types first, and when it 
comes to implementing `GetBuiltinTypeByName` in `TypeSystemSwift` for DIL, you 
can decide whether you want to allow users to lookup builtin types or leave 
that function empty.

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

[Lldb-commits] [lldb] [lldb][TypeSystemClang] Added unique builtins types for __bf16 and _Float16 (PR #157674)

[Michael Buch via lldb-commits]

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


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

[Lldb-commits] [lldb] [LLDB][NativePDB] Use typedef compiler type for typedef types (PR #156250)

[via lldb-commits]

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

[Lldb-commits] [lldb] [lldb][test] Don't run libc++ API tests without a locally built libc++ (PR #162657)

[David Spickett via lldb-commits]

DavidSpickett wrote:

Also please add to the PR description a single line like:
```
If you need to re-enable these tests do 
```
In case the reader is a person who cared about system library compatibility.

You kinda say what to do already but not in a Friday afternoon in a rush 
compatible way :)

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

[Lldb-commits] [lldb] [llvm] [lldb] Do not stop the process on SIGWINCH by default. (PR #163182)

[James Y Knight via lldb-commits]

@@ -174,6 +174,9 @@ Changes to LLDB
 
 * LLDB can now set breakpoints, show backtraces, and display variables when
   debugging Wasm with supported runtimes (WAMR and V8).
+* LLDB no longer stops processes by default when receiving SIGWINCH signals 
+  (window resize events) on Linux. This is the default on other Unix platforms.
+  You can re-enable it using `process handle --notify=false --stop=false 
SIGWINCH`.

jyknight wrote:

This is backwards, it would disable not re-enable. It should read: `process 
handle --notify=true --stop=true SIGWINCH`.

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

[Lldb-commits] [lldb] [lldb][TypeSystemClang] Added unique builtins types for __bf16 and _Float16 (PR #157674)

[Timur Golubovich via lldb-commits]

tgs-sc wrote:

@Michael137, can you please then merge this patch? Because I don't have 
corresponding rights.

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