[Lldb-commits] [lldb] [lldb][aix] 2. Updating XCOFF, PPC entry in LLDB ArchSpec (PR #105507)
https://github.com/DhruvSrivastavaX created
https://github.com/llvm/llvm-project/pull/105507
This PR is in reference to porting LLDB on AIX.
Link to discussions on llvm discourse and github:
1. https://discourse.llvm.org/t/port-lldb-to-ibm-aix/80640
2. #101657
The complete changes for porting are present in this draft PR:
https://github.com/llvm/llvm-project/pull/102601
The changes in this PR are intended to update the Architecture entry for LLDB
with XCOFF,PPC.
1. Added a new `ArchDefinitionEntry g_xcoff_arch_entries[]`
2. Added a new case for XCOFF in `ArchSpec::SetArchitecture(..)`
3. Updated ArchDefinition *g_arch_definitions[]
>From 53e2a7bffaad8a6813fdc5422805d332fdee86fa Mon Sep 17 00:00:00 2001
From: Dhruv-Srivastava
Date: Wed, 21 Aug 2024 06:37:30 -0500
Subject: [PATCH 1/2] Updating XCOFF architecture lookup in LLDB
---
lldb/source/Utility/ArchSpec.cpp | 20 +++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/lldb/source/Utility/ArchSpec.cpp b/lldb/source/Utility/ArchSpec.cpp
index 07ef435ef451d2..38b403408e38fd 100644
--- a/lldb/source/Utility/ArchSpec.cpp
+++ b/lldb/source/Utility/ArchSpec.cpp
@@ -14,6 +14,7 @@
#include "lldb/lldb-defines.h"
#include "llvm/ADT/STLExtras.h"
#include "llvm/BinaryFormat/COFF.h"
+#include "llvm/BinaryFormat/XCOFF.h"
#include "llvm/BinaryFormat/ELF.h"
#include "llvm/BinaryFormat/MachO.h"
#include "llvm/Support/Compiler.h"
@@ -459,10 +460,24 @@ static const ArchDefinition g_coff_arch_def = {
"pe-coff",
};
+
+static const ArchDefinitionEntry g_xcoff_arch_entries[] = {
+{ArchSpec::eCore_ppc_generic, llvm::XCOFF::TCPU_COM, LLDB_INVALID_CPUTYPE,
0xu, 0xu},
+{ArchSpec::eCore_ppc64_generic, llvm::XCOFF::TCPU_PPC64,
LLDB_INVALID_CPUTYPE, 0xu, 0xu}
+};
+
+static const ArchDefinition g_xcoff_arch_def = {
+eArchTypeXCOFF,
+std::size(g_xcoff_arch_entries),
+g_xcoff_arch_entries,
+"xcoff",
+};
+
+
//===--===//
// Table of all ArchDefinitions
static const ArchDefinition *g_arch_definitions[] = {
-&g_macho_arch_def, &g_elf_arch_def, &g_coff_arch_def};
+&g_macho_arch_def, &g_elf_arch_def, &g_coff_arch_def, &g_xcoff_arch_def};
//===--===//
// Static helper functions.
@@ -903,6 +918,9 @@ bool ArchSpec::SetArchitecture(ArchitectureType arch_type,
uint32_t cpu,
} else if (arch_type == eArchTypeCOFF && os == llvm::Triple::Win32) {
m_triple.setVendor(llvm::Triple::PC);
m_triple.setOS(llvm::Triple::Win32);
+} else if (arch_type == eArchTypeXCOFF && os == llvm::Triple::AIX) {
+m_triple.setVendor(llvm::Triple::IBM);
+m_triple.setOS(llvm::Triple::AIX);
} else {
m_triple.setVendor(llvm::Triple::UnknownVendor);
m_triple.setOS(llvm::Triple::UnknownOS);
>From f9b94258b175fe24b3f7612d785155566ed5d270 Mon Sep 17 00:00:00 2001
From: Dhruv-Srivastava
Date: Wed, 21 Aug 2024 06:46:36 -0500
Subject: [PATCH 2/2] clang-format modifications
---
lldb/source/Utility/ArchSpec.cpp | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/lldb/source/Utility/ArchSpec.cpp b/lldb/source/Utility/ArchSpec.cpp
index 38b403408e38fd..4fd1a800023ce3 100644
--- a/lldb/source/Utility/ArchSpec.cpp
+++ b/lldb/source/Utility/ArchSpec.cpp
@@ -14,9 +14,9 @@
#include "lldb/lldb-defines.h"
#include "llvm/ADT/STLExtras.h"
#include "llvm/BinaryFormat/COFF.h"
-#include "llvm/BinaryFormat/XCOFF.h"
#include "llvm/BinaryFormat/ELF.h"
#include "llvm/BinaryFormat/MachO.h"
+#include "llvm/BinaryFormat/XCOFF.h"
#include "llvm/Support/Compiler.h"
#include "llvm/TargetParser/ARMTargetParser.h"
@@ -460,11 +460,11 @@ static const ArchDefinition g_coff_arch_def = {
"pe-coff",
};
-
static const ArchDefinitionEntry g_xcoff_arch_entries[] = {
-{ArchSpec::eCore_ppc_generic, llvm::XCOFF::TCPU_COM, LLDB_INVALID_CPUTYPE,
0xu, 0xu},
-{ArchSpec::eCore_ppc64_generic, llvm::XCOFF::TCPU_PPC64,
LLDB_INVALID_CPUTYPE, 0xu, 0xu}
-};
+{ArchSpec::eCore_ppc_generic, llvm::XCOFF::TCPU_COM, LLDB_INVALID_CPUTYPE,
+ 0xu, 0xu},
+{ArchSpec::eCore_ppc64_generic, llvm::XCOFF::TCPU_PPC64,
+ LLDB_INVALID_CPUTYPE, 0xu, 0xu}};
static const ArchDefinition g_xcoff_arch_def = {
eArchTypeXCOFF,
@@ -473,7 +473,6 @@ static const ArchDefinition g_xcoff_arch_def = {
"xcoff",
};
-
//===--===//
// Table of all ArchDefinitions
static const ArchDefinition *g_arch_definitions[] = {
@@ -919,8 +918,8 @@ bool ArchSpec::SetArchitecture(ArchitectureType arch_type,
uint32_t cpu,
m_triple.setVendor(llvm::Triple::PC);
m_triple.setOS(llvm::Triple::Win32);
} else if (arch_type == eArc
[Lldb-commits] [lldb] [lldb][aix] 2. Updating XCOFF, PPC entry in LLDB ArchSpec (PR #105507)
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Dhruv Srivastava (DhruvSrivastavaX)
Changes
This PR is in reference to porting LLDB on AIX.
Link to discussions on llvm discourse and github:
1. https://discourse.llvm.org/t/port-lldb-to-ibm-aix/80640
2. #101657
The complete changes for porting are present in this draft PR:
https://github.com/llvm/llvm-project/pull/102601
The changes in this PR are intended to update the Architecture entry for LLDB
with XCOFF,PPC.
1. Added a new `ArchDefinitionEntry g_xcoff_arch_entries[]`
2. Added a new case for XCOFF in `ArchSpec::SetArchitecture(..)`
3. Updated ArchDefinition *g_arch_definitions[]
---
Full diff: https://github.com/llvm/llvm-project/pull/105507.diff
1 Files Affected:
- (modified) lldb/source/Utility/ArchSpec.cpp (+18-1)
``diff
diff --git a/lldb/source/Utility/ArchSpec.cpp b/lldb/source/Utility/ArchSpec.cpp
index 07ef435ef451d2..4fd1a800023ce3 100644
--- a/lldb/source/Utility/ArchSpec.cpp
+++ b/lldb/source/Utility/ArchSpec.cpp
@@ -16,6 +16,7 @@
#include "llvm/BinaryFormat/COFF.h"
#include "llvm/BinaryFormat/ELF.h"
#include "llvm/BinaryFormat/MachO.h"
+#include "llvm/BinaryFormat/XCOFF.h"
#include "llvm/Support/Compiler.h"
#include "llvm/TargetParser/ARMTargetParser.h"
@@ -459,10 +460,23 @@ static const ArchDefinition g_coff_arch_def = {
"pe-coff",
};
+static const ArchDefinitionEntry g_xcoff_arch_entries[] = {
+{ArchSpec::eCore_ppc_generic, llvm::XCOFF::TCPU_COM, LLDB_INVALID_CPUTYPE,
+ 0xu, 0xu},
+{ArchSpec::eCore_ppc64_generic, llvm::XCOFF::TCPU_PPC64,
+ LLDB_INVALID_CPUTYPE, 0xu, 0xu}};
+
+static const ArchDefinition g_xcoff_arch_def = {
+eArchTypeXCOFF,
+std::size(g_xcoff_arch_entries),
+g_xcoff_arch_entries,
+"xcoff",
+};
+
//===--===//
// Table of all ArchDefinitions
static const ArchDefinition *g_arch_definitions[] = {
-&g_macho_arch_def, &g_elf_arch_def, &g_coff_arch_def};
+&g_macho_arch_def, &g_elf_arch_def, &g_coff_arch_def, &g_xcoff_arch_def};
//===--===//
// Static helper functions.
@@ -903,6 +917,9 @@ bool ArchSpec::SetArchitecture(ArchitectureType arch_type,
uint32_t cpu,
} else if (arch_type == eArchTypeCOFF && os == llvm::Triple::Win32) {
m_triple.setVendor(llvm::Triple::PC);
m_triple.setOS(llvm::Triple::Win32);
+} else if (arch_type == eArchTypeXCOFF && os == llvm::Triple::AIX) {
+ m_triple.setVendor(llvm::Triple::IBM);
+ m_triple.setOS(llvm::Triple::AIX);
} else {
m_triple.setVendor(llvm::Triple::UnknownVendor);
m_triple.setOS(llvm::Triple::UnknownOS);
``
https://github.com/llvm/llvm-project/pull/105507
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][aix] 2. Updating XCOFF, PPC entry in LLDB ArchSpec (PR #105507)
https://github.com/DhruvSrivastavaX edited https://github.com/llvm/llvm-project/pull/105507 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Implement `StepGranularity` for "next" and "step-in" (PR #105464)
@@ -3193,7 +3213,11 @@ void request_stackTrace(const llvm::json::Object
&request) {
// "targetId": {
// "type": "integer",
// "description": "Optional id of the target to step into."
-// }
+// },
+// "granularity": {
+// "$ref": "#/definitions/SteppingGranularity",
+// "description": "Stepping granularity. If no granularity is specified,
a
+// granularity of `statement` is assumed."
// },
vogelsgesang wrote:
missing closing `}`
https://github.com/llvm/llvm-project/pull/105464
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][aix] 2. Updating XCOFF, PPC entry in LLDB ArchSpec (PR #105507)
https://github.com/DhruvSrivastavaX closed https://github.com/llvm/llvm-project/pull/105507 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][aix] 2. Updating XCOFF, PPC entry in LLDB ArchSpec (PR #105523)
https://github.com/DhruvSrivastavaX created
https://github.com/llvm/llvm-project/pull/105523
This PR is in reference to porting LLDB on AIX.
Link to discussions on llvm discourse and github:
1. https://discourse.llvm.org/t/port-lldb-to-ibm-aix/80640
2. #101657
The complete changes for porting are present in this draft PR:
#102601
The changes in this PR are intended to update the Architecture entry for LLDB
with XCOFF,PPC.
1. Added new ArchitectureType `eArchTypeXCOFF`
2. Added a new `ArchDefinitionEntry g_xcoff_arch_entries[]`
3. Added a new case for `XCOFF in ArchSpec::SetArchitecture(..)`
4. Updated `ArchDefinition *g_arch_definitions[]`
>From 53e2a7bffaad8a6813fdc5422805d332fdee86fa Mon Sep 17 00:00:00 2001
From: Dhruv-Srivastava
Date: Wed, 21 Aug 2024 06:37:30 -0500
Subject: [PATCH 1/3] Updating XCOFF architecture lookup in LLDB
---
lldb/source/Utility/ArchSpec.cpp | 20 +++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/lldb/source/Utility/ArchSpec.cpp b/lldb/source/Utility/ArchSpec.cpp
index 07ef435ef451d2..38b403408e38fd 100644
--- a/lldb/source/Utility/ArchSpec.cpp
+++ b/lldb/source/Utility/ArchSpec.cpp
@@ -14,6 +14,7 @@
#include "lldb/lldb-defines.h"
#include "llvm/ADT/STLExtras.h"
#include "llvm/BinaryFormat/COFF.h"
+#include "llvm/BinaryFormat/XCOFF.h"
#include "llvm/BinaryFormat/ELF.h"
#include "llvm/BinaryFormat/MachO.h"
#include "llvm/Support/Compiler.h"
@@ -459,10 +460,24 @@ static const ArchDefinition g_coff_arch_def = {
"pe-coff",
};
+
+static const ArchDefinitionEntry g_xcoff_arch_entries[] = {
+{ArchSpec::eCore_ppc_generic, llvm::XCOFF::TCPU_COM, LLDB_INVALID_CPUTYPE,
0xu, 0xu},
+{ArchSpec::eCore_ppc64_generic, llvm::XCOFF::TCPU_PPC64,
LLDB_INVALID_CPUTYPE, 0xu, 0xu}
+};
+
+static const ArchDefinition g_xcoff_arch_def = {
+eArchTypeXCOFF,
+std::size(g_xcoff_arch_entries),
+g_xcoff_arch_entries,
+"xcoff",
+};
+
+
//===--===//
// Table of all ArchDefinitions
static const ArchDefinition *g_arch_definitions[] = {
-&g_macho_arch_def, &g_elf_arch_def, &g_coff_arch_def};
+&g_macho_arch_def, &g_elf_arch_def, &g_coff_arch_def, &g_xcoff_arch_def};
//===--===//
// Static helper functions.
@@ -903,6 +918,9 @@ bool ArchSpec::SetArchitecture(ArchitectureType arch_type,
uint32_t cpu,
} else if (arch_type == eArchTypeCOFF && os == llvm::Triple::Win32) {
m_triple.setVendor(llvm::Triple::PC);
m_triple.setOS(llvm::Triple::Win32);
+} else if (arch_type == eArchTypeXCOFF && os == llvm::Triple::AIX) {
+m_triple.setVendor(llvm::Triple::IBM);
+m_triple.setOS(llvm::Triple::AIX);
} else {
m_triple.setVendor(llvm::Triple::UnknownVendor);
m_triple.setOS(llvm::Triple::UnknownOS);
>From f9b94258b175fe24b3f7612d785155566ed5d270 Mon Sep 17 00:00:00 2001
From: Dhruv-Srivastava
Date: Wed, 21 Aug 2024 06:46:36 -0500
Subject: [PATCH 2/3] clang-format modifications
---
lldb/source/Utility/ArchSpec.cpp | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/lldb/source/Utility/ArchSpec.cpp b/lldb/source/Utility/ArchSpec.cpp
index 38b403408e38fd..4fd1a800023ce3 100644
--- a/lldb/source/Utility/ArchSpec.cpp
+++ b/lldb/source/Utility/ArchSpec.cpp
@@ -14,9 +14,9 @@
#include "lldb/lldb-defines.h"
#include "llvm/ADT/STLExtras.h"
#include "llvm/BinaryFormat/COFF.h"
-#include "llvm/BinaryFormat/XCOFF.h"
#include "llvm/BinaryFormat/ELF.h"
#include "llvm/BinaryFormat/MachO.h"
+#include "llvm/BinaryFormat/XCOFF.h"
#include "llvm/Support/Compiler.h"
#include "llvm/TargetParser/ARMTargetParser.h"
@@ -460,11 +460,11 @@ static const ArchDefinition g_coff_arch_def = {
"pe-coff",
};
-
static const ArchDefinitionEntry g_xcoff_arch_entries[] = {
-{ArchSpec::eCore_ppc_generic, llvm::XCOFF::TCPU_COM, LLDB_INVALID_CPUTYPE,
0xu, 0xu},
-{ArchSpec::eCore_ppc64_generic, llvm::XCOFF::TCPU_PPC64,
LLDB_INVALID_CPUTYPE, 0xu, 0xu}
-};
+{ArchSpec::eCore_ppc_generic, llvm::XCOFF::TCPU_COM, LLDB_INVALID_CPUTYPE,
+ 0xu, 0xu},
+{ArchSpec::eCore_ppc64_generic, llvm::XCOFF::TCPU_PPC64,
+ LLDB_INVALID_CPUTYPE, 0xu, 0xu}};
static const ArchDefinition g_xcoff_arch_def = {
eArchTypeXCOFF,
@@ -473,7 +473,6 @@ static const ArchDefinition g_xcoff_arch_def = {
"xcoff",
};
-
//===--===//
// Table of all ArchDefinitions
static const ArchDefinition *g_arch_definitions[] = {
@@ -919,8 +918,8 @@ bool ArchSpec::SetArchitecture(ArchitectureType arch_type,
uint32_t cpu,
m_triple.setVendor(llvm::Triple::PC);
m_triple.setOS(llvm::Triple::Win32);
} else if (arch_typ
[Lldb-commits] [lldb] [lldb][aix] 2. Updating XCOFF, PPC entry in LLDB ArchSpec (PR #105523)
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Dhruv Srivastava (DhruvSrivastavaX)
Changes
This PR is in reference to porting LLDB on AIX.
Link to discussions on llvm discourse and github:
1. https://discourse.llvm.org/t/port-lldb-to-ibm-aix/80640
2. #101657
The complete changes for porting are present in this draft PR:
#102601
The changes in this PR are intended to update the Architecture entry for LLDB
with XCOFF,PPC.
1. Added new ArchitectureType `eArchTypeXCOFF`
2. Added a new `ArchDefinitionEntry g_xcoff_arch_entries[]`
3. Added a new case for `XCOFF in ArchSpec::SetArchitecture(..)`
4. Updated `ArchDefinition *g_arch_definitions[]`
---
Full diff: https://github.com/llvm/llvm-project/pull/105523.diff
2 Files Affected:
- (modified) lldb/include/lldb/lldb-private-enumerations.h (+1)
- (modified) lldb/source/Utility/ArchSpec.cpp (+18-1)
``diff
diff --git a/lldb/include/lldb/lldb-private-enumerations.h
b/lldb/include/lldb/lldb-private-enumerations.h
index c24a3538f58dac..98c1e956bf8f7b 100644
--- a/lldb/include/lldb/lldb-private-enumerations.h
+++ b/lldb/include/lldb/lldb-private-enumerations.h
@@ -65,6 +65,7 @@ enum ArchitectureType {
eArchTypeMachO,
eArchTypeELF,
eArchTypeCOFF,
+ eArchTypeXCOFF,
kNumArchTypes
};
diff --git a/lldb/source/Utility/ArchSpec.cpp b/lldb/source/Utility/ArchSpec.cpp
index 07ef435ef451d2..4fd1a800023ce3 100644
--- a/lldb/source/Utility/ArchSpec.cpp
+++ b/lldb/source/Utility/ArchSpec.cpp
@@ -16,6 +16,7 @@
#include "llvm/BinaryFormat/COFF.h"
#include "llvm/BinaryFormat/ELF.h"
#include "llvm/BinaryFormat/MachO.h"
+#include "llvm/BinaryFormat/XCOFF.h"
#include "llvm/Support/Compiler.h"
#include "llvm/TargetParser/ARMTargetParser.h"
@@ -459,10 +460,23 @@ static const ArchDefinition g_coff_arch_def = {
"pe-coff",
};
+static const ArchDefinitionEntry g_xcoff_arch_entries[] = {
+{ArchSpec::eCore_ppc_generic, llvm::XCOFF::TCPU_COM, LLDB_INVALID_CPUTYPE,
+ 0xu, 0xu},
+{ArchSpec::eCore_ppc64_generic, llvm::XCOFF::TCPU_PPC64,
+ LLDB_INVALID_CPUTYPE, 0xu, 0xu}};
+
+static const ArchDefinition g_xcoff_arch_def = {
+eArchTypeXCOFF,
+std::size(g_xcoff_arch_entries),
+g_xcoff_arch_entries,
+"xcoff",
+};
+
//===--===//
// Table of all ArchDefinitions
static const ArchDefinition *g_arch_definitions[] = {
-&g_macho_arch_def, &g_elf_arch_def, &g_coff_arch_def};
+&g_macho_arch_def, &g_elf_arch_def, &g_coff_arch_def, &g_xcoff_arch_def};
//===--===//
// Static helper functions.
@@ -903,6 +917,9 @@ bool ArchSpec::SetArchitecture(ArchitectureType arch_type,
uint32_t cpu,
} else if (arch_type == eArchTypeCOFF && os == llvm::Triple::Win32) {
m_triple.setVendor(llvm::Triple::PC);
m_triple.setOS(llvm::Triple::Win32);
+} else if (arch_type == eArchTypeXCOFF && os == llvm::Triple::AIX) {
+ m_triple.setVendor(llvm::Triple::IBM);
+ m_triple.setOS(llvm::Triple::AIX);
} else {
m_triple.setVendor(llvm::Triple::UnknownVendor);
m_triple.setOS(llvm::Triple::UnknownOS);
``
https://github.com/llvm/llvm-project/pull/105523
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] 6528157 - [lldb][swig] Use the correct variable in the return statement
Author: Dmitri Gribenko Date: 2024-08-21T15:29:03+02:00 New Revision: 65281570afd7e35e01533b07c6c2937de410fc52 URL: https://github.com/llvm/llvm-project/commit/65281570afd7e35e01533b07c6c2937de410fc52 DIFF: https://github.com/llvm/llvm-project/commit/65281570afd7e35e01533b07c6c2937de410fc52.diff LOG: [lldb][swig] Use the correct variable in the return statement The issue was introduced in https://github.com/llvm/llvm-project/pull/104523. The code introduces the `ret_val` variable but does not use it. Instead it returns a pointer, which gets implicitly converted to bool. Added: Modified: lldb/bindings/python/python-wrapper.swig Removed: diff --git a/lldb/bindings/python/python-wrapper.swig b/lldb/bindings/python/python-wrapper.swig index 2ce42e3e017d5b..360c392235a866 100644 --- a/lldb/bindings/python/python-wrapper.swig +++ b/lldb/bindings/python/python-wrapper.swig @@ -837,7 +837,7 @@ bool lldb_private::python::SWIGBridge::LLDBSwigPython_ShouldHide( bool ret_val = result ? PyObject_IsTrue(result) : false; Py_XDECREF(result); - return result; + return ret_val; } void *lldb_private::python::SWIGBridge::LLDBSWIGPython_GetDynamicSetting( ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [clang] [flang] [lldb] [llvm] [mlir] [APInt] Assert correct values in APInt constructor (PR #80309)
nikic wrote: Okay, looks like I tracked down all the assertion failures in tests. My plan would now be to land this in three phases, first to add the new assertions and implicitTrunc parameter, but with implicitTrunc=true by default. Then to land fixes (possibly split up further), and finally to flip the implicitTrunc default. https://github.com/llvm/llvm-project/pull/80309 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][aix] Updating XCOFF, PPC entry in LLDB ArchSpec (PR #105523)
https://github.com/DhruvSrivastavaX edited https://github.com/llvm/llvm-project/pull/105523 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] When sending a DAP Output Event break each message into separate lines. (PR #105456)
@@ -311,10 +309,22 @@ void DAP::SendOutput(OutputType o, const llvm::StringRef
output) {
category = "telemetry";
break;
}
- body.try_emplace("category", category);
- EmplaceSafeString(body, "output", output.str());
- event.try_emplace("body", std::move(body));
- SendJSON(llvm::json::Value(std::move(event)));
+
+ // Send each line of output as an individual event, including the newline if
+ // present.
+ ::size_t idx = 0;
+ do {
+::size_t end = output.find('\n', idx);
+if (end == llvm::StringRef::npos)
+ end = output.size() - 1;
+llvm::json::Object event(CreateEventObject("output"));
+llvm::json::Object body;
+body.try_emplace("category", category);
+EmplaceSafeString(body, "output", output.slice(idx, end + 1).str());
+event.try_emplace("body", std::move(body));
+SendJSON(llvm::json::Value(std::move(event)));
+idx = end + 1;
+ } while (idx < output.size());
ashgti wrote:
VS Code append to the previous lines if the previous line don't end in a `\n`
or `\r\n`
(https://github.com/microsoft/vscode/blob/d193e4b6f525e90911df21f8f1820cf0fe0fda0c/src/vs/workbench/contrib/debug/common/replModel.ts#L306).
With the previous version of this, if we had an output event like `abc\ndef`
followed by `foo\n`, these would have been merged into a single 'output' item
in the UI. With this change it will instead have `abc\n` as one output item and
`deffoo\n` would become a second output item.
I can also increase the buffer size for the reads.
https://github.com/llvm/llvm-project/pull/105456
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Fix dap stacktrace perf issue (PR #104874)
@@ -3091,17 +3093,20 @@ void request_stackTrace(const llvm::json::Object
&request) {
// This will always return an invalid thread when
// libBacktraceRecording.dylib is not loaded or if there is no extended
// backtrace.
-lldb::SBThread queue_backtrace_thread =
-thread.GetExtendedBacktraceThread("libdispatch");
+lldb::SBThread queue_backtrace_thread;
+if (g_dap.enable_display_extended_backtrace)
+ queue_backtrace_thread =
thread.GetExtendedBacktraceThread("libdispatch");
ashgti wrote:
Maybe we should check SBProcess::GetNumExtendedBacktraceTypes() /
GetExtendedBacktraceTypeAtIndex() instead of hard coding the `libdispatch`? I
think that is configured by the target platform.
Would that solve the issue without needing an extra configuration flag?
https://github.com/llvm/llvm-project/pull/104874
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB][SBSaveCore] Add selectable memory regions to SBSaveCore (PR #105442)
@@ -449,6 +449,10 @@ class RangeDataVector {
~RangeDataVector() = default;
void Append(const Entry &entry) { m_entries.emplace_back(entry); }
+
+ void Append(const B&& b, const S&& s, const T&& t) {
mbucko wrote:
Cannot have const rvalue reference. You can either use const ref like this:
`const B& b, const S& s, const T& t`
or do a perfect forwarding with `B &&b` and then pass it into Entry like so:
`Entry(std::forward(b), std::forward(s), std::forward(t))`
https://github.com/llvm/llvm-project/pull/105442
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB][SBSaveCore] Add selectable memory regions to SBSaveCore (PR #105442)
@@ -80,6 +80,17 @@ class LLDB_API SBSaveCoreOptions {
/// \return True if the thread was removed, false if it was not in the list.
bool RemoveThread(lldb::SBThread thread);
+ /// Add a memory region to save in the core file.
+ ///
+ /// \param region The memory region to save.
+ /// \returns An empty SBStatus upon success, or an error if the region is
mbucko wrote:
'empty SBError'
https://github.com/llvm/llvm-project/pull/105442
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB][SBSaveCore] Add selectable memory regions to SBSaveCore (PR #105442)
@@ -449,6 +449,10 @@ class RangeDataVector {
~RangeDataVector() = default;
void Append(const Entry &entry) { m_entries.emplace_back(entry); }
+
+ void Append(const B&& b, const S&& s, const T&& t) {
Jlalond wrote:
Yeah, I can drop const but these are r values so we can just emplace them
directly.
https://github.com/llvm/llvm-project/pull/105442
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB][Minidump] Fix ProcessMinidump::GetMemoryRegions to include 64b regions when /proc/pid maps are missing. (PR #101086)
https://github.com/clayborg approved this pull request. https://github.com/llvm/llvm-project/pull/101086 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] 6cb1459 - [LLDB][Minidump] Fix ProcessMinidump::GetMemoryRegions to include 64b regions when /proc/pid maps are missing. (#101086)
Author: Jacob Lalonde
Date: 2024-08-21T10:25:23-07:00
New Revision: 6cb14599ade843be3171fa7e4dd5f3601a3bb0de
URL:
https://github.com/llvm/llvm-project/commit/6cb14599ade843be3171fa7e4dd5f3601a3bb0de
DIFF:
https://github.com/llvm/llvm-project/commit/6cb14599ade843be3171fa7e4dd5f3601a3bb0de.diff
LOG: [LLDB][Minidump] Fix ProcessMinidump::GetMemoryRegions to include 64b
regions when /proc/pid maps are missing. (#101086)
This PR is in response to a bug my coworker @mbucko discovered where on
MacOS Minidumps were being created where the 64b memory regions were
readable, but were not being listed in
`SBProcess.GetMemoryRegionList()`. This went unnoticed in #95312 due to
all the linux testing including /proc/pid maps. On MacOS generated dumps
(or any dump without access to /proc/pid) we would fail to properly map
Memory Regions due to there being two independent methods for 32b and
64b mapping.
In this PR I addressed this minor bug and merged the methods, but in
order to add test coverage required additions to `obj2yaml` and
`yaml2obj` which make up the bulk of this patch.
Lastly, there are some non-required changes such as the addition of the
`Memory64ListHeader` type, to make writing/reading the header section of
the Memory64List easier.
Added:
lldb/test/API/functionalities/postmortem/minidump-new/linux-x86_64_mem64.yaml
Modified:
lldb/source/Plugins/ObjectFile/Minidump/MinidumpFileBuilder.cpp
lldb/source/Plugins/Process/minidump/MinidumpParser.cpp
lldb/source/Plugins/Process/minidump/MinidumpParser.h
lldb/source/Plugins/Process/minidump/MinidumpTypes.cpp
lldb/source/Plugins/Process/minidump/MinidumpTypes.h
lldb/test/API/functionalities/postmortem/minidump-new/TestMiniDumpNew.py
Removed:
diff --git a/lldb/source/Plugins/ObjectFile/Minidump/MinidumpFileBuilder.cpp
b/lldb/source/Plugins/ObjectFile/Minidump/MinidumpFileBuilder.cpp
index c0cc3af638a777..4b862d8d8e99b8 100644
--- a/lldb/source/Plugins/ObjectFile/Minidump/MinidumpFileBuilder.cpp
+++ b/lldb/source/Plugins/ObjectFile/Minidump/MinidumpFileBuilder.cpp
@@ -1014,15 +1014,17 @@
MinidumpFileBuilder::AddMemoryList_32(Process::CoreFileMemoryRanges &ranges) {
// With a size of the number of ranges as a 32 bit num
// And then the size of all the ranges
error = AddDirectory(StreamType::MemoryList,
- sizeof(llvm::support::ulittle32_t) +
+ sizeof(llvm::minidump::MemoryListHeader) +
descriptors.size() *
sizeof(llvm::minidump::MemoryDescriptor));
if (error.Fail())
return error;
+ llvm::minidump::MemoryListHeader list_header;
llvm::support::ulittle32_t memory_ranges_num =
static_cast(descriptors.size());
- m_data.AppendData(&memory_ranges_num, sizeof(llvm::support::ulittle32_t));
+ list_header.NumberOfMemoryRanges = memory_ranges_num;
+ m_data.AppendData(&list_header, sizeof(llvm::minidump::MemoryListHeader));
// For 32b we can get away with writing off the descriptors after the data.
// This means no cleanup loop needed.
m_data.AppendData(descriptors.data(),
@@ -1044,9 +1046,10 @@
MinidumpFileBuilder::AddMemoryList_64(Process::CoreFileMemoryRanges &ranges) {
if (error.Fail())
return error;
+ llvm::minidump::Memory64ListHeader list_header;
llvm::support::ulittle64_t memory_ranges_num =
static_cast(ranges.size());
- m_data.AppendData(&memory_ranges_num, sizeof(llvm::support::ulittle64_t));
+ list_header.NumberOfMemoryRanges = memory_ranges_num;
// Capture the starting offset for all the descriptors so we can clean them
up
// if needed.
offset_t starting_offset =
@@ -1058,8 +1061,8 @@
MinidumpFileBuilder::AddMemoryList_64(Process::CoreFileMemoryRanges &ranges) {
(ranges.size() * sizeof(llvm::minidump::MemoryDescriptor_64));
llvm::support::ulittle64_t memory_ranges_base_rva =
static_cast(base_rva);
- m_data.AppendData(&memory_ranges_base_rva,
-sizeof(llvm::support::ulittle64_t));
+ list_header.BaseRVA = memory_ranges_base_rva;
+ m_data.AppendData(&list_header, sizeof(llvm::minidump::Memory64ListHeader));
bool cleanup_required = false;
std::vector descriptors;
diff --git a/lldb/source/Plugins/Process/minidump/MinidumpParser.cpp
b/lldb/source/Plugins/Process/minidump/MinidumpParser.cpp
index be9fae938e2276..c099c28a620ecf 100644
--- a/lldb/source/Plugins/Process/minidump/MinidumpParser.cpp
+++ b/lldb/source/Plugins/Process/minidump/MinidumpParser.cpp
@@ -429,7 +429,6 @@ const minidump::ExceptionStream
*MinidumpParser::GetExceptionStream() {
std::optional
MinidumpParser::FindMemoryRange(lldb::addr_t addr) {
- llvm::ArrayRef data64 = GetStream(StreamType::Memory64List);
Log *log = GetLog(LLDBLog::Modules);
auto ExpectedMemory = GetMinidumpFile().getMemoryList();
@@ -457,33 +456,17 @@ MinidumpParser::F
[Lldb-commits] [lldb] [LLDB][Minidump] Fix ProcessMinidump::GetMemoryRegions to include 64b regions when /proc/pid maps are missing. (PR #101086)
https://github.com/Jlalond closed https://github.com/llvm/llvm-project/pull/101086 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] When sending a DAP Output Event break each message into separate lines. (PR #105456)
https://github.com/ashgti updated
https://github.com/llvm/llvm-project/pull/105456
>From 9246649c24991127b8f54ae1f21121386cef7254 Mon Sep 17 00:00:00 2001
From: John Harrison
Date: Tue, 20 Aug 2024 16:33:14 -0700
Subject: [PATCH 1/2] When sending a DAP Output Event break each message into
separate lines.
Previously, when output like `"hello\nworld\n"` was produced by lldb (or the
process) the message would be sent as a single Output event.
By being a single event this causes VS Code to treat this as a single message
in the console when handling displaying and filtering in the Debug Console.
Instead, with these changes we send each line as its own event. This results in
VS Code representing each line of output from lldb-dap as an individual output
message.
---
.../test/tools/lldb-dap/lldbdap_testcase.py | 5 +++
lldb/test/API/tools/lldb-dap/output/Makefile | 3 ++
.../tools/lldb-dap/output/TestDAP_output.py | 37 +++
lldb/test/API/tools/lldb-dap/output/main.c| 11 ++
lldb/tools/lldb-dap/DAP.cpp | 22 ---
5 files changed, 72 insertions(+), 6 deletions(-)
create mode 100644 lldb/test/API/tools/lldb-dap/output/Makefile
create mode 100644 lldb/test/API/tools/lldb-dap/output/TestDAP_output.py
create mode 100644 lldb/test/API/tools/lldb-dap/output/main.c
diff --git
a/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/lldbdap_testcase.py
b/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/lldbdap_testcase.py
index a312a88ebd7e58..8341bfda748206 100644
--- a/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/lldbdap_testcase.py
+++ b/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/lldbdap_testcase.py
@@ -202,6 +202,11 @@ def collect_console(self, timeout_secs, pattern=None):
"console", timeout_secs=timeout_secs, pattern=pattern
)
+def collect_stdout(self, timeout_secs, pattern=None):
+return self.dap_server.collect_output(
+"stdout", timeout_secs=timeout_secs, pattern=pattern
+)
+
def get_local_as_int(self, name, threadId=None):
value = self.dap_server.get_local_variable_value(name,
threadId=threadId)
# 'value' may have the variable value and summary.
diff --git a/lldb/test/API/tools/lldb-dap/output/Makefile
b/lldb/test/API/tools/lldb-dap/output/Makefile
new file mode 100644
index 00..10495940055b63
--- /dev/null
+++ b/lldb/test/API/tools/lldb-dap/output/Makefile
@@ -0,0 +1,3 @@
+C_SOURCES := main.c
+
+include Makefile.rules
diff --git a/lldb/test/API/tools/lldb-dap/output/TestDAP_output.py
b/lldb/test/API/tools/lldb-dap/output/TestDAP_output.py
new file mode 100644
index 00..08d5f07f224e4c
--- /dev/null
+++ b/lldb/test/API/tools/lldb-dap/output/TestDAP_output.py
@@ -0,0 +1,37 @@
+"""
+Test lldb-dap output events
+"""
+
+import dap_server
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+import lldbdap_testcase
+import re
+
+
+class TestDAP_output(lldbdap_testcase.DAPTestCaseBase):
+def test_output(self):
+program = self.getBuildArtifact("a.out")
+self.build_and_launch(program)
+source = "main.c"
+main_source_path = self.getSourcePath(source)
+lines = [line_number(source, "// breakpoint 1")]
+breakpoint_ids = self.set_source_breakpoints(source, lines)
+self.continue_to_breakpoints(breakpoint_ids)
+
+output = self.collect_stdout(
+timeout_secs=1.0,
+pattern="abcdef"
+)
+self.assertTrue(output and len(output) > 0, "expect no program output")
+
+self.continue_to_exit()
+
+output +=
self.get_stdout(timeout=lldbdap_testcase.DAPTestCaseBase.timeoutval)
+self.assertTrue(output and len(output) > 0, "expect no program output")
+self.assertIn(
+"abcdefghi\r\nhello world\r\n",
+output,
+'full output not found in: ' + output
+)
diff --git a/lldb/test/API/tools/lldb-dap/output/main.c
b/lldb/test/API/tools/lldb-dap/output/main.c
new file mode 100644
index 00..62a3337d865db2
--- /dev/null
+++ b/lldb/test/API/tools/lldb-dap/output/main.c
@@ -0,0 +1,11 @@
+#include
+#include
+#include
+
+int main() {
+ printf("abc");
+ printf("def");
+ printf("ghi\n");
+ printf("hello world\n"); // breakpoint 1
+ return 0;
+}
diff --git a/lldb/tools/lldb-dap/DAP.cpp b/lldb/tools/lldb-dap/DAP.cpp
index c3c70e9d739846..1fd560f21904ab 100644
--- a/lldb/tools/lldb-dap/DAP.cpp
+++ b/lldb/tools/lldb-dap/DAP.cpp
@@ -294,8 +294,6 @@ void DAP::SendOutput(OutputType o, const llvm::StringRef
output) {
if (output.empty())
return;
- llvm::json::Object event(CreateEventObject("output"));
- llvm::json::Object body;
const char *category = nullptr;
switch (o) {
case OutputType::Console:
@@ -311,10 +309,22 @@ void DAP::SendOutput(OutputType o, const llvm::StringRef
outp
[Lldb-commits] [lldb] Remove redundant symbol lookups in IRExecutionUnit::FindInSymbols (PR #102835)
augusto2112 wrote: I agree with Michael, I think just adding the search hint and clearly documenting it would already be a great improvement and would make implementing this patch a lot simpler. https://github.com/llvm/llvm-project/pull/102835 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB][SBSaveCore] Add selectable memory regions to SBSaveCore (PR #105442)
https://github.com/bulbazord commented: I didn't look at all the implementation details, but the SBAPI stuff looks fine. I don't see anything that will cause trouble down the line. Thanks! https://github.com/llvm/llvm-project/pull/105442 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB][SBSaveCore] Add selectable memory regions to SBSaveCore (PR #105442)
https://github.com/bulbazord edited https://github.com/llvm/llvm-project/pull/105442 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB][SBSaveCore] Add selectable memory regions to SBSaveCore (PR #105442)
@@ -90,6 +93,16 @@ bool SBSaveCoreOptions::RemoveThread(lldb::SBThread thread) {
return m_opaque_up->RemoveThread(thread.GetSP());
}
+
+lldb::SBError SBSaveCoreOptions::AddMemoryRegionToSave(const
SBMemoryRegionInfo ®ion) {
+ LLDB_INSTRUMENT_VA(this, region);
+ // Currently add memory region can't fail, so we always return a success
+ // SBerror, but because these API's live forever, this is the most future
+ // proof thing to do.
bulbazord wrote:
Thanks for being forward-looking. 😄
https://github.com/llvm/llvm-project/pull/105442
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB][SBSaveCore] Add selectable memory regions to SBSaveCore (PR #105442)
@@ -7,6 +7,9 @@ //===--===// #include "lldb/API/SBSaveCoreOptions.h" +#include "lldb/API/SBError.h" +#include "lldb/API/SBFileSpec.h" bulbazord wrote: SBFileSpec is unused right? Shouldn't need this include. https://github.com/llvm/llvm-project/pull/105442 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB][SBSaveCore] Add selectable memory regions to SBSaveCore (PR #105442)
@@ -80,6 +80,17 @@ class LLDB_API SBSaveCoreOptions {
/// \return True if the thread was removed, false if it was not in the list.
bool RemoveThread(lldb::SBThread thread);
+ /// Add a memory region to save in the core file.
+ ///
+ /// \param region The memory region to save.
+ /// \returns An empty SBError upon success, or an error if the region is
+ /// invalid.
+ /// \note Ranges that overlapped with be unioned into a single region this
bulbazord wrote:
`with be` -> `will be`
https://github.com/llvm/llvm-project/pull/105442
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB][SBSaveCore] Add selectable memory regions to SBSaveCore (PR #105442)
@@ -7,6 +7,9 @@ //===--===// #include "lldb/API/SBSaveCoreOptions.h" +#include "lldb/API/SBError.h" +#include "lldb/API/SBFileSpec.h" Jlalond wrote: Good call, I'll try to trim all the unneeded usings now that the header isn't in private interfaces https://github.com/llvm/llvm-project/pull/105442 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][aix] Updating XCOFF, PPC entry in LLDB ArchSpec (PR #105523)
https://github.com/bulbazord approved this pull request. This one looks very straightforward. I haven't been involved in any of the earlier discussions about AIX support so please wait for more involved folks to also take a look. https://github.com/llvm/llvm-project/pull/105523 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] When sending a DAP Output Event break each message into separate lines. (PR #105456)
@@ -311,10 +309,22 @@ void DAP::SendOutput(OutputType o, const llvm::StringRef
output) {
category = "telemetry";
break;
}
- body.try_emplace("category", category);
- EmplaceSafeString(body, "output", output.str());
- event.try_emplace("body", std::move(body));
- SendJSON(llvm::json::Value(std::move(event)));
+
+ // Send each line of output as an individual event, including the newline if
+ // present.
+ ::size_t idx = 0;
+ do {
+::size_t end = output.find('\n', idx);
+if (end == llvm::StringRef::npos)
+ end = output.size() - 1;
+llvm::json::Object event(CreateEventObject("output"));
+llvm::json::Object body;
+body.try_emplace("category", category);
+EmplaceSafeString(body, "output", output.slice(idx, end + 1).str());
+event.try_emplace("body", std::move(body));
+SendJSON(llvm::json::Value(std::move(event)));
+idx = end + 1;
+ } while (idx < output.size());
vogelsgesang wrote:
Thanks for clarifying!
https://github.com/llvm/llvm-project/pull/105456
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb/Interpreter] Introduce `ScriptedStopHook{, Python}Interface` & make use of it (PR #105449)
https://github.com/bulbazord approved this pull request. https://github.com/llvm/llvm-project/pull/105449 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Implement `StepGranularity` for "next" and "step-in" (PR #105464)
https://github.com/vogelsgesang updated
https://github.com/llvm/llvm-project/pull/105464
>From c4178df5541103388e26343f62e96f8e2a65be86 Mon Sep 17 00:00:00 2001
From: Adrian Vogelsgesang
Date: Mon, 12 Aug 2024 23:00:45 +
Subject: [PATCH 1/3] [lldb-dap] Implement `StepGranularity` for "next" and
"step-in"
VS Code requests a `granularity` of `instruction` if the assembly view
is currently focused. By implementing `StepGranularity`, we can hence
properly through assembly code single-step through assembly code.
---
.../test/tools/lldb-dap/dap_server.py | 8 ++---
.../test/tools/lldb-dap/lldbdap_testcase.py | 8 ++---
.../API/tools/lldb-dap/step/TestDAP_step.py | 9 ++
lldb/tools/lldb-dap/lldb-dap.cpp | 31 +--
4 files changed, 45 insertions(+), 11 deletions(-)
diff --git a/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
b/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
index a324af57b61df3..87ebc674f61df6 100644
--- a/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
+++ b/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
@@ -816,17 +816,17 @@ def request_launch(
self.wait_for_event(filter=["process", "initialized"])
return response
-def request_next(self, threadId):
+def request_next(self, threadId, granularity="statement"):
if self.exit_status is not None:
raise ValueError("request_continue called after process exited")
-args_dict = {"threadId": threadId}
+args_dict = {"threadId": threadId, "granularity": granularity}
command_dict = {"command": "next", "type": "request", "arguments":
args_dict}
return self.send_recv(command_dict)
-def request_stepIn(self, threadId, targetId):
+def request_stepIn(self, threadId, targetId, granularity="statement"):
if self.exit_status is not None:
raise ValueError("request_stepIn called after process exited")
-args_dict = {"threadId": threadId, "targetId": targetId}
+args_dict = {"threadId": threadId, "targetId": targetId,
"granularity": granularity}
command_dict = {"command": "stepIn", "type": "request", "arguments":
args_dict}
return self.send_recv(command_dict)
diff --git
a/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/lldbdap_testcase.py
b/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/lldbdap_testcase.py
index a312a88ebd7e58..3257bd14b16fed 100644
--- a/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/lldbdap_testcase.py
+++ b/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/lldbdap_testcase.py
@@ -222,14 +222,14 @@ def set_global(self, name, value, id=None):
"""Set a top level global variable only."""
return self.dap_server.request_setVariable(2, name, str(value), id=id)
-def stepIn(self, threadId=None, targetId=None, waitForStop=True):
-self.dap_server.request_stepIn(threadId=threadId, targetId=targetId)
+def stepIn(self, threadId=None, targetId=None, waitForStop=True,
granularity="statement"):
+self.dap_server.request_stepIn(threadId=threadId, targetId=targetId,
granularity=granularity)
if waitForStop:
return self.dap_server.wait_for_stopped()
return None
-def stepOver(self, threadId=None, waitForStop=True):
-self.dap_server.request_next(threadId=threadId)
+def stepOver(self, threadId=None, waitForStop=True,
granularity="statement"):
+self.dap_server.request_next(threadId=threadId,
granularity=granularity)
if waitForStop:
return self.dap_server.wait_for_stopped()
return None
diff --git a/lldb/test/API/tools/lldb-dap/step/TestDAP_step.py
b/lldb/test/API/tools/lldb-dap/step/TestDAP_step.py
index 8a1bb76340be73..9c8e226827611e 100644
--- a/lldb/test/API/tools/lldb-dap/step/TestDAP_step.py
+++ b/lldb/test/API/tools/lldb-dap/step/TestDAP_step.py
@@ -68,5 +68,14 @@ def test_step(self):
self.assertEqual(x4, x3, "verify step over variable")
self.assertGreater(line4, line3, "verify step over line")
self.assertEqual(src1, src4, "verify step over source")
+
+# Step a single assembly instruction.
+# Unfortunately, there is no portable way to verify the
correct
+# stepping behavior here, because the generated assembly
code
+# depends highly on the compiler, its version, the
operating
+# system, and many more factors.
+self.stepOver(threadId=tid, waitForStop=True,
granularity="instruction")
+self.stepIn(threadId=tid, waitForStop=True,
granularity="instruction")
+
# only step one thread that is at the breakpoint and stop
break
diff --git a/lldb/tools/lldb-dap/lldb-dap.cpp b/lldb/tools/lldb-dap/lldb-dap.cpp
inde
[Lldb-commits] [lldb] [lldb] Change the two remaining SInt64 settings in Target to uint (PR #105460)
https://github.com/JDevlieghere approved this pull request. Sorry for breaking this & thanks for fixing it. https://github.com/llvm/llvm-project/pull/105460 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] 6257a98 - [lldb-dap] Implement `StepGranularity` for "next" and "step-in" (#105464)
Author: Adrian Vogelsgesang
Date: 2024-08-21T20:30:10+02:00
New Revision: 6257a98b258a3f17b78af31bf43009a559c5dd1d
URL:
https://github.com/llvm/llvm-project/commit/6257a98b258a3f17b78af31bf43009a559c5dd1d
DIFF:
https://github.com/llvm/llvm-project/commit/6257a98b258a3f17b78af31bf43009a559c5dd1d.diff
LOG: [lldb-dap] Implement `StepGranularity` for "next" and "step-in" (#105464)
VS Code requests the `instruction` stepping granularity if the assembly
view is currently focused. By implementing `StepGranularity`, we can
hence properly single-step through assembly code.
Added:
Modified:
lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
lldb/packages/Python/lldbsuite/test/tools/lldb-dap/lldbdap_testcase.py
lldb/test/API/tools/lldb-dap/step/TestDAP_step.py
lldb/tools/lldb-dap/lldb-dap.cpp
Removed:
diff --git a/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
b/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
index a324af57b61df3..874383a13e2bb6 100644
--- a/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
+++ b/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
@@ -816,17 +816,21 @@ def request_launch(
self.wait_for_event(filter=["process", "initialized"])
return response
-def request_next(self, threadId):
+def request_next(self, threadId, granularity="statement"):
if self.exit_status is not None:
raise ValueError("request_continue called after process exited")
-args_dict = {"threadId": threadId}
+args_dict = {"threadId": threadId, "granularity": granularity}
command_dict = {"command": "next", "type": "request", "arguments":
args_dict}
return self.send_recv(command_dict)
-def request_stepIn(self, threadId, targetId):
+def request_stepIn(self, threadId, targetId, granularity="statement"):
if self.exit_status is not None:
raise ValueError("request_stepIn called after process exited")
-args_dict = {"threadId": threadId, "targetId": targetId}
+args_dict = {
+"threadId": threadId,
+"targetId": targetId,
+"granularity": granularity,
+}
command_dict = {"command": "stepIn", "type": "request", "arguments":
args_dict}
return self.send_recv(command_dict)
diff --git
a/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/lldbdap_testcase.py
b/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/lldbdap_testcase.py
index a312a88ebd7e58..27545816f20707 100644
--- a/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/lldbdap_testcase.py
+++ b/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/lldbdap_testcase.py
@@ -222,14 +222,18 @@ def set_global(self, name, value, id=None):
"""Set a top level global variable only."""
return self.dap_server.request_setVariable(2, name, str(value), id=id)
-def stepIn(self, threadId=None, targetId=None, waitForStop=True):
-self.dap_server.request_stepIn(threadId=threadId, targetId=targetId)
+def stepIn(
+self, threadId=None, targetId=None, waitForStop=True,
granularity="statement"
+):
+self.dap_server.request_stepIn(
+threadId=threadId, targetId=targetId, granularity=granularity
+)
if waitForStop:
return self.dap_server.wait_for_stopped()
return None
-def stepOver(self, threadId=None, waitForStop=True):
-self.dap_server.request_next(threadId=threadId)
+def stepOver(self, threadId=None, waitForStop=True,
granularity="statement"):
+self.dap_server.request_next(threadId=threadId,
granularity=granularity)
if waitForStop:
return self.dap_server.wait_for_stopped()
return None
diff --git a/lldb/test/API/tools/lldb-dap/step/TestDAP_step.py
b/lldb/test/API/tools/lldb-dap/step/TestDAP_step.py
index 8a1bb76340be73..42a39e3c8c080b 100644
--- a/lldb/test/API/tools/lldb-dap/step/TestDAP_step.py
+++ b/lldb/test/API/tools/lldb-dap/step/TestDAP_step.py
@@ -68,5 +68,18 @@ def test_step(self):
self.assertEqual(x4, x3, "verify step over variable")
self.assertGreater(line4, line3, "verify step over line")
self.assertEqual(src1, src4, "verify step over source")
+
+# Step a single assembly instruction.
+# Unfortunately, there is no portable way to verify the
correct
+# stepping behavior here, because the generated assembly
code
+# depends highly on the compiler, its version, the
operating
+# system, and many more factors.
+self.stepOver(
+threadId=tid, waitForStop=True,
granularity="instruction"
+)
+self.stepIn(
[Lldb-commits] [lldb] [lldb-dap] Implement `StepGranularity` for "next" and "step-in" (PR #105464)
https://github.com/vogelsgesang closed https://github.com/llvm/llvm-project/pull/105464 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Remove redundant symbol lookups in IRExecutionUnit::FindInSymbols (PR #102835)
DmT021 wrote: I'm not sure I understand because this will break the logic that is currently in place. Many nuances in post-processing wouldn't be possible to implement with a simple short-circuit. If a symbol is found in the hinted module, it might be internal. `IRExecutionUnit::FindInSymbols` processes the results by preferring external symbols over internal ones. If I short-circuit the search after the first match in the hinted module `IRExecutionUnit::FindInSymbols` just wouldn't see potentially more preferable results. On the other hand `SymbolContext::FindBestGlobalDataSymbol` prefers symbols of any type from the hinted module over the other symbols. But it still prefers external symbols over internal ones. So the priority order looks like this: `hint external > hint internal > other external > other internal`. Moreover, `SymbolContext::FindBestGlobalDataSymbol` verifies that there are no multiple matches found, but it's tricky as well. It checks if there's a result in the module - it does verification only matches from the module, otherwise it verifies all the results. Perhaps I can't explain all the nuances quite accurately, you should look at the post-processing code itself in these functions. But the most important thing is that we don't have a full understanding of when we can stop inside FindFunction/FindSymbolsWithNameAndType. https://github.com/llvm/llvm-project/pull/102835 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] When sending a DAP Output Event break each message into separate lines. (PR #105456)
https://github.com/walter-erquinigo edited https://github.com/llvm/llvm-project/pull/105456 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] When sending a DAP Output Event break each message into separate lines. (PR #105456)
https://github.com/walter-erquinigo requested changes to this pull request. Just a minor nit and good to go https://github.com/llvm/llvm-project/pull/105456 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] When sending a DAP Output Event break each message into separate lines. (PR #105456)
@@ -399,7 +399,7 @@ void SendProcessEvent(LaunchMethod launch_method) {
// Grab any STDOUT and STDERR from the process and send it up to VS Code
// via an "output" event to the "stdout" and "stderr" categories.
void SendStdOutStdErr(lldb::SBProcess &process) {
- char buffer[1024];
+ char buffer[4096];
walter-erquinigo wrote:
could you also modify that other buffer and have a constant that can be used by
both of them? 4096 should be more than enough for most messages.
After that, this PR should be fine by me.
https://github.com/llvm/llvm-project/pull/105456
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Provide `declarationLocation` for variables (PR #102928)
https://github.com/vogelsgesang updated
https://github.com/llvm/llvm-project/pull/102928
>From 5bdcb821527bf67eead6c42825ea6e559ec749c3 Mon Sep 17 00:00:00 2001
From: Adrian Vogelsgesang
Date: Sat, 10 Aug 2024 23:59:55 +
Subject: [PATCH] [lldb-dap] Implement declaration locations
This commit implements support for the "declaration location" recently
added by microsoft/debug-adapter-protocol#494 to the debug adapter
protocol.
For the `declarationLocationReference` we need a variable ID similar to
the the `variablesReference`. I decided to simply reuse the
`variablesReference` here and renamed `Variables::expandable_variables`
and friends accordingly. Given that almost all variables have a
declaration location, we now assign those variable ids to all variables.
While `declarationLocationReference` effectively supersedes
`$__lldb_extensions.declaration`, I did not remove this extension, yet,
since I assume that there are some closed-source extensions which rely
on it.
I tested this against VS-Code Insiders. However, VS-Code Insiders
currently only supports `valueLoctionReference` and not
`declarationLocationReference`, yet. Locally, I hence published
the declaration locations as value locations, and VS Code Insiders
navigated to the expected places. Looking forward to proper VS Code
support for `declarationLocationReference`.
---
.../test/tools/lldb-dap/dap_server.py | 11 ++
.../API/tools/lldb-dap/locations/Makefile | 3 +
.../lldb-dap/locations/TestDAP_locations.py | 40 +
lldb/test/API/tools/lldb-dap/locations/main.c | 5 +
lldb/tools/lldb-dap/DAP.cpp | 17 +-
lldb/tools/lldb-dap/DAP.h | 10 +-
lldb/tools/lldb-dap/JSONUtils.cpp | 125 ---
lldb/tools/lldb-dap/JSONUtils.h | 31 ++--
lldb/tools/lldb-dap/lldb-dap.cpp | 146 +++---
9 files changed, 286 insertions(+), 102 deletions(-)
create mode 100644 lldb/test/API/tools/lldb-dap/locations/Makefile
create mode 100644 lldb/test/API/tools/lldb-dap/locations/TestDAP_locations.py
create mode 100644 lldb/test/API/tools/lldb-dap/locations/main.c
diff --git a/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
b/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
index 874383a13e2bb6..01ff79ee430902 100644
--- a/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
+++ b/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
@@ -1083,6 +1083,17 @@ def request_setVariable(self, containingVarRef, name,
value, id=None):
}
return self.send_recv(command_dict)
+def request_locations(self, locationReference):
+args_dict = {
+"locationReference": locationReference,
+}
+command_dict = {
+"command": "locations",
+"type": "request",
+"arguments": args_dict,
+}
+return self.send_recv(command_dict)
+
def request_testGetTargetBreakpoints(self):
"""A request packet used in the LLDB test suite to get all currently
set breakpoint infos for all breakpoints currently set in the
diff --git a/lldb/test/API/tools/lldb-dap/locations/Makefile
b/lldb/test/API/tools/lldb-dap/locations/Makefile
new file mode 100644
index 00..10495940055b63
--- /dev/null
+++ b/lldb/test/API/tools/lldb-dap/locations/Makefile
@@ -0,0 +1,3 @@
+C_SOURCES := main.c
+
+include Makefile.rules
diff --git a/lldb/test/API/tools/lldb-dap/locations/TestDAP_locations.py
b/lldb/test/API/tools/lldb-dap/locations/TestDAP_locations.py
new file mode 100644
index 00..76d938d3908492
--- /dev/null
+++ b/lldb/test/API/tools/lldb-dap/locations/TestDAP_locations.py
@@ -0,0 +1,40 @@
+"""
+Test lldb-dap locations request
+"""
+
+
+import dap_server
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+import lldbdap_testcase
+import os
+
+
+class TestDAP_locations(lldbdap_testcase.DAPTestCaseBase):
+@skipIfWindows
+def test_locations(self):
+"""
+Tests the 'locations' request.
+"""
+program = self.getBuildArtifact("a.out")
+self.build_and_launch(program)
+source = "main.c"
+self.source_path = os.path.join(os.getcwd(), source)
+self.set_source_breakpoints(
+source,
+[line_number(source, "// BREAK HERE")],
+)
+self.continue_to_next_stop()
+
+locals = {l["name"]: l for l in self.dap_server.get_local_variables()}
+
+# var1 has a declarationLocation but no valueLocation
+self.assertIn("declarationLocationReference", locals["var1"].keys())
+self.assertNotIn("valueLocationReference", locals["var1"].keys())
+loc_var1 = self.dap_server.request_locations(
+locals["var1"]["declarationLocationReference"]
+)
+self.assertTrue(loc_var1["success"])
+self.as
[Lldb-commits] [lldb] [lldb-dap] Provide `declarationLocation` for variables (PR #102928)
https://github.com/vogelsgesang edited https://github.com/llvm/llvm-project/pull/102928 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Implement value locations for function pointers (PR #104589)
https://github.com/vogelsgesang updated
https://github.com/llvm/llvm-project/pull/104589
>From 5bdcb821527bf67eead6c42825ea6e559ec749c3 Mon Sep 17 00:00:00 2001
From: Adrian Vogelsgesang
Date: Sat, 10 Aug 2024 23:59:55 +
Subject: [PATCH 1/2] [lldb-dap] Implement declaration locations
This commit implements support for the "declaration location" recently
added by microsoft/debug-adapter-protocol#494 to the debug adapter
protocol.
For the `declarationLocationReference` we need a variable ID similar to
the the `variablesReference`. I decided to simply reuse the
`variablesReference` here and renamed `Variables::expandable_variables`
and friends accordingly. Given that almost all variables have a
declaration location, we now assign those variable ids to all variables.
While `declarationLocationReference` effectively supersedes
`$__lldb_extensions.declaration`, I did not remove this extension, yet,
since I assume that there are some closed-source extensions which rely
on it.
I tested this against VS-Code Insiders. However, VS-Code Insiders
currently only supports `valueLoctionReference` and not
`declarationLocationReference`, yet. Locally, I hence published
the declaration locations as value locations, and VS Code Insiders
navigated to the expected places. Looking forward to proper VS Code
support for `declarationLocationReference`.
---
.../test/tools/lldb-dap/dap_server.py | 11 ++
.../API/tools/lldb-dap/locations/Makefile | 3 +
.../lldb-dap/locations/TestDAP_locations.py | 40 +
lldb/test/API/tools/lldb-dap/locations/main.c | 5 +
lldb/tools/lldb-dap/DAP.cpp | 17 +-
lldb/tools/lldb-dap/DAP.h | 10 +-
lldb/tools/lldb-dap/JSONUtils.cpp | 125 ---
lldb/tools/lldb-dap/JSONUtils.h | 31 ++--
lldb/tools/lldb-dap/lldb-dap.cpp | 146 +++---
9 files changed, 286 insertions(+), 102 deletions(-)
create mode 100644 lldb/test/API/tools/lldb-dap/locations/Makefile
create mode 100644 lldb/test/API/tools/lldb-dap/locations/TestDAP_locations.py
create mode 100644 lldb/test/API/tools/lldb-dap/locations/main.c
diff --git a/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
b/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
index 874383a13e2bb6..01ff79ee430902 100644
--- a/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
+++ b/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
@@ -1083,6 +1083,17 @@ def request_setVariable(self, containingVarRef, name,
value, id=None):
}
return self.send_recv(command_dict)
+def request_locations(self, locationReference):
+args_dict = {
+"locationReference": locationReference,
+}
+command_dict = {
+"command": "locations",
+"type": "request",
+"arguments": args_dict,
+}
+return self.send_recv(command_dict)
+
def request_testGetTargetBreakpoints(self):
"""A request packet used in the LLDB test suite to get all currently
set breakpoint infos for all breakpoints currently set in the
diff --git a/lldb/test/API/tools/lldb-dap/locations/Makefile
b/lldb/test/API/tools/lldb-dap/locations/Makefile
new file mode 100644
index 00..10495940055b63
--- /dev/null
+++ b/lldb/test/API/tools/lldb-dap/locations/Makefile
@@ -0,0 +1,3 @@
+C_SOURCES := main.c
+
+include Makefile.rules
diff --git a/lldb/test/API/tools/lldb-dap/locations/TestDAP_locations.py
b/lldb/test/API/tools/lldb-dap/locations/TestDAP_locations.py
new file mode 100644
index 00..76d938d3908492
--- /dev/null
+++ b/lldb/test/API/tools/lldb-dap/locations/TestDAP_locations.py
@@ -0,0 +1,40 @@
+"""
+Test lldb-dap locations request
+"""
+
+
+import dap_server
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+import lldbdap_testcase
+import os
+
+
+class TestDAP_locations(lldbdap_testcase.DAPTestCaseBase):
+@skipIfWindows
+def test_locations(self):
+"""
+Tests the 'locations' request.
+"""
+program = self.getBuildArtifact("a.out")
+self.build_and_launch(program)
+source = "main.c"
+self.source_path = os.path.join(os.getcwd(), source)
+self.set_source_breakpoints(
+source,
+[line_number(source, "// BREAK HERE")],
+)
+self.continue_to_next_stop()
+
+locals = {l["name"]: l for l in self.dap_server.get_local_variables()}
+
+# var1 has a declarationLocation but no valueLocation
+self.assertIn("declarationLocationReference", locals["var1"].keys())
+self.assertNotIn("valueLocationReference", locals["var1"].keys())
+loc_var1 = self.dap_server.request_locations(
+locals["var1"]["declarationLocationReference"]
+)
+self.assertTrue(loc_var1["success"])
+sel
[Lldb-commits] [lldb] Fix dap stacktrace perf issue (PR #104874)
@@ -3091,17 +3093,20 @@ void request_stackTrace(const llvm::json::Object
&request) {
// This will always return an invalid thread when
// libBacktraceRecording.dylib is not loaded or if there is no extended
// backtrace.
-lldb::SBThread queue_backtrace_thread =
-thread.GetExtendedBacktraceThread("libdispatch");
+lldb::SBThread queue_backtrace_thread;
+if (g_dap.enable_display_extended_backtrace)
+ queue_backtrace_thread =
thread.GetExtendedBacktraceThread("libdispatch");
clayborg wrote:
Running an expression every time we stop is not a great thing to do and this is
what is happening right now. Are we running one expression for every thread?
https://github.com/llvm/llvm-project/pull/104874
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Fix dap stacktrace perf issue (PR #104874)
@@ -3091,17 +3093,20 @@ void request_stackTrace(const llvm::json::Object
&request) {
// This will always return an invalid thread when
// libBacktraceRecording.dylib is not loaded or if there is no extended
// backtrace.
-lldb::SBThread queue_backtrace_thread =
-thread.GetExtendedBacktraceThread("libdispatch");
+lldb::SBThread queue_backtrace_thread;
+if (g_dap.enable_display_extended_backtrace)
+ queue_backtrace_thread =
thread.GetExtendedBacktraceThread("libdispatch");
clayborg wrote:
I still will want the option to disable this feature if it is coslty and not
everyone needs it. But if all non mac platforms report
"SBProcess::GetNumExtendedBacktraceTypes() == 0", then this can be a good work
around. If we call this on mac, does
`SBProcess::GetNumExtendedBacktraceTypes()` return 1 and
`SBProcess::GetExtendedBacktraceTypeAtIndex(0)` return `"libdispatch"`? We
definitely shouldn't be trying "libdispatch" on any non mac systems.
https://github.com/llvm/llvm-project/pull/104874
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Pick the correct architecutre when target and core file disagree (PR #105576)
https://github.com/JDevlieghere created
https://github.com/llvm/llvm-project/pull/105576
In f9f3316, Adrian fixed an issue where LLDB wouldn't update the target's
architecture when the process reported a different triple that only differed in
its sub-architecture.
This unintentionally regressed core file debugging when the core file reports
the base architecture (e.g. armv7) while the main binary knows the correct CPU
subtype (e.g. armv7em). After the aforementioned change, we update the target
architecture from armv7em to armv7. Fix the issue by trusting the target
architecture over the ProcessMachCore process.
rdar://133834304
>From b8be6d4a015136607f40d56d8297d027a9fb3fe8 Mon Sep 17 00:00:00 2001
From: Jonas Devlieghere
Date: Wed, 21 Aug 2024 12:17:28 -0700
Subject: [PATCH] [lldb] Pick the correct architecutre when target and core
file disagree
In f9f3316, Adrian fixed an issue where LLDB wouldn't update the
target's architecture when the process reported a different triple that
only differed in its sub-architecture.
This unintentionally regressed core file debugging when the core file
reports the base architecture (e.g. armv7) while the main binary knows
the correct CPU subtype (e.g. armv7em). After the aforementioned change,
we update the target architecture from armv7em to armv7. Fix the issue
by trusting the target architecture over the ProcessMachCore process.
rdar://133834304
---
.../Process/mach-core/ProcessMachCore.cpp | 15 +++--
lldb/test/Shell/Process/Inputs/a.out.yaml | 62 +++
lldb/test/Shell/Process/Inputs/corefile.yaml | 22 +++
.../Shell/Process/ProcessMachCoreArch.test| 8 +++
4 files changed, 102 insertions(+), 5 deletions(-)
create mode 100644 lldb/test/Shell/Process/Inputs/a.out.yaml
create mode 100644 lldb/test/Shell/Process/Inputs/corefile.yaml
create mode 100644 lldb/test/Shell/Process/ProcessMachCoreArch.test
diff --git a/lldb/source/Plugins/Process/mach-core/ProcessMachCore.cpp
b/lldb/source/Plugins/Process/mach-core/ProcessMachCore.cpp
index 930c707604bb38..348b18e38560a6 100644
--- a/lldb/source/Plugins/Process/mach-core/ProcessMachCore.cpp
+++ b/lldb/source/Plugins/Process/mach-core/ProcessMachCore.cpp
@@ -562,17 +562,22 @@ Status ProcessMachCore::DoLoadCore() {
SetCanJIT(false);
- // The corefile's architecture is our best starting point.
- ArchSpec arch(m_core_module_sp->GetArchitecture());
- if (arch.IsValid())
-GetTarget().SetArchitecture(arch);
-
CreateMemoryRegions();
LoadBinariesAndSetDYLD();
CleanupMemoryRegionPermissions();
+ ModuleSP exe_module_sp = GetTarget().GetExecutableModule();
+ if (exe_module_sp && exe_module_sp->GetArchitecture().IsValid()) {
+GetTarget().SetArchitecture(exe_module_sp->GetArchitecture());
+ } else {
+// The corefile's architecture is our best starting point.
+ArchSpec arch(m_core_module_sp->GetArchitecture());
+if (arch.IsValid())
+ GetTarget().SetArchitecture(arch);
+ }
+
AddressableBits addressable_bits = core_objfile->GetAddressableBits();
SetAddressableBitMasks(addressable_bits);
diff --git a/lldb/test/Shell/Process/Inputs/a.out.yaml
b/lldb/test/Shell/Process/Inputs/a.out.yaml
new file mode 100644
index 00..f63457d39824c6
--- /dev/null
+++ b/lldb/test/Shell/Process/Inputs/a.out.yaml
@@ -0,0 +1,62 @@
+--- !mach-o
+FileHeader:
+ magic: 0xFEEDFACE
+ cputype: 0xC
+ cpusubtype: 0x10
+ filetype:0x2
+ ncmds: 3
+ sizeofcmds: 272
+ flags: 0x200085
+LoadCommands:
+ - cmd: LC_SEGMENT
+cmdsize: 56
+segname: __PAGEZERO
+vmaddr: 0
+vmsize: 16384
+fileoff: 0
+filesize:0
+maxprot: 0
+initprot:0
+nsects: 0
+flags: 0
+ - cmd: LC_SEGMENT
+cmdsize: 192
+segname: __TEXT
+vmaddr: 16384
+vmsize: 32768
+fileoff: 0
+filesize:32768
+maxprot: 5
+initprot:5
+nsects: 2
+flags: 0
+Sections:
+ - sectname:__text
+segname: __TEXT
+addr:0xBFB4
+size:4
+offset: 0x7FB4
+align: 1
+reloff: 0x0
+nreloc: 0
+flags: 0x8400
+reserved1: 0x0
+reserved2: 0x0
+reserved3: 0x0
+content: '00207047'
+ - sectname:__unwind_info
+segname: __TEXT
+addr:0xBFB8
+size:72
+offset: 0x7FB8
+align: 2
+reloff: 0x0
+nreloc: 0
+flags: 0x0
+reserved1: 0x0
+reserved2: 0x0
+reserved3: 0x0
+content:
01001C00
[Lldb-commits] [lldb] [lldb] Pick the correct architecutre when target and core file disagree (PR #105576)
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Jonas Devlieghere (JDevlieghere)
Changes
In f9f3316, Adrian fixed an issue where LLDB wouldn't update the target's
architecture when the process reported a different triple that only differed in
its sub-architecture.
This unintentionally regressed core file debugging when the core file reports
the base architecture (e.g. armv7) while the main binary knows the correct CPU
subtype (e.g. armv7em). After the aforementioned change, we update the target
architecture from armv7em to armv7. Fix the issue by trusting the target
architecture over the ProcessMachCore process.
rdar://133834304
---
Full diff: https://github.com/llvm/llvm-project/pull/105576.diff
4 Files Affected:
- (modified) lldb/source/Plugins/Process/mach-core/ProcessMachCore.cpp (+10-5)
- (added) lldb/test/Shell/Process/Inputs/a.out.yaml (+62)
- (added) lldb/test/Shell/Process/Inputs/corefile.yaml (+22)
- (added) lldb/test/Shell/Process/ProcessMachCoreArch.test (+8)
``diff
diff --git a/lldb/source/Plugins/Process/mach-core/ProcessMachCore.cpp
b/lldb/source/Plugins/Process/mach-core/ProcessMachCore.cpp
index 930c707604bb3..348b18e38560a 100644
--- a/lldb/source/Plugins/Process/mach-core/ProcessMachCore.cpp
+++ b/lldb/source/Plugins/Process/mach-core/ProcessMachCore.cpp
@@ -562,17 +562,22 @@ Status ProcessMachCore::DoLoadCore() {
SetCanJIT(false);
- // The corefile's architecture is our best starting point.
- ArchSpec arch(m_core_module_sp->GetArchitecture());
- if (arch.IsValid())
-GetTarget().SetArchitecture(arch);
-
CreateMemoryRegions();
LoadBinariesAndSetDYLD();
CleanupMemoryRegionPermissions();
+ ModuleSP exe_module_sp = GetTarget().GetExecutableModule();
+ if (exe_module_sp && exe_module_sp->GetArchitecture().IsValid()) {
+GetTarget().SetArchitecture(exe_module_sp->GetArchitecture());
+ } else {
+// The corefile's architecture is our best starting point.
+ArchSpec arch(m_core_module_sp->GetArchitecture());
+if (arch.IsValid())
+ GetTarget().SetArchitecture(arch);
+ }
+
AddressableBits addressable_bits = core_objfile->GetAddressableBits();
SetAddressableBitMasks(addressable_bits);
diff --git a/lldb/test/Shell/Process/Inputs/a.out.yaml
b/lldb/test/Shell/Process/Inputs/a.out.yaml
new file mode 100644
index 0..f63457d39824c
--- /dev/null
+++ b/lldb/test/Shell/Process/Inputs/a.out.yaml
@@ -0,0 +1,62 @@
+--- !mach-o
+FileHeader:
+ magic: 0xFEEDFACE
+ cputype: 0xC
+ cpusubtype: 0x10
+ filetype:0x2
+ ncmds: 3
+ sizeofcmds: 272
+ flags: 0x200085
+LoadCommands:
+ - cmd: LC_SEGMENT
+cmdsize: 56
+segname: __PAGEZERO
+vmaddr: 0
+vmsize: 16384
+fileoff: 0
+filesize:0
+maxprot: 0
+initprot:0
+nsects: 0
+flags: 0
+ - cmd: LC_SEGMENT
+cmdsize: 192
+segname: __TEXT
+vmaddr: 16384
+vmsize: 32768
+fileoff: 0
+filesize:32768
+maxprot: 5
+initprot:5
+nsects: 2
+flags: 0
+Sections:
+ - sectname:__text
+segname: __TEXT
+addr:0xBFB4
+size:4
+offset: 0x7FB4
+align: 1
+reloff: 0x0
+nreloc: 0
+flags: 0x8400
+reserved1: 0x0
+reserved2: 0x0
+reserved3: 0x0
+content: '00207047'
+ - sectname:__unwind_info
+segname: __TEXT
+addr:0xBFB8
+size:72
+offset: 0x7FB8
+align: 2
+reloff: 0x0
+nreloc: 0
+flags: 0x0
+reserved1: 0x0
+reserved2: 0x0
+reserved3: 0x0
+content:
01001C001C001C000200B57F34003400BA7F340003000C0001001100
+ - cmd: LC_UUID
+cmdsize: 24
+uuid:C2065535-C63D-3C6A-BF79-19CF960DEF2E
diff --git a/lldb/test/Shell/Process/Inputs/corefile.yaml
b/lldb/test/Shell/Process/Inputs/corefile.yaml
new file mode 100644
index 0..537da8e85cba3
--- /dev/null
+++ b/lldb/test/Shell/Process/Inputs/corefile.yaml
@@ -0,0 +1,22 @@
+--- !mach-o
+FileHeader:
+ magic: 0xFEEDFACF
+ cputype: 0xC
+ cpusubtype: 0x9
+ filetype:0x4
+ ncmds: 1
+ sizeofcmds: 84
+ flags: 0x0
+ reserved:0x0
+LoadCommands:
+ - cmd: LC_THREAD
+cmdsize: 84
+PayloadBytes:[ 0x1, 0x0, 0x0, 0x0, 0x11, 0x0, 0x0, 0x0, 0x0, 0x0,
+ 0x1, 0x0, 0x0,
[Lldb-commits] [lldb] Fix dap stacktrace perf issue (PR #104874)
@@ -3091,17 +3093,20 @@ void request_stackTrace(const llvm::json::Object
&request) {
// This will always return an invalid thread when
// libBacktraceRecording.dylib is not loaded or if there is no extended
// backtrace.
-lldb::SBThread queue_backtrace_thread =
-thread.GetExtendedBacktraceThread("libdispatch");
+lldb::SBThread queue_backtrace_thread;
+if (g_dap.enable_display_extended_backtrace)
+ queue_backtrace_thread =
thread.GetExtendedBacktraceThread("libdispatch");
walter-erquinigo wrote:
According the Jeffrey's profiling, the penalty is up to 1 second in certain
targets. I think that's a very reasonable wait time if that can improve the
debugger experience, as long as it happens once per user action only in the
cases where there's an extended backtrace via `GetNumExtendedBacktraceTypes`.
IIRC, not all stack traces are sent at once to the IDE. Only one stack trace
gets sent and then, the user needs to expand individual threads to see more
stack traces, in which case 1 second seems reasonable under the circumstances
mentioned above.
https://github.com/llvm/llvm-project/pull/104874
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] When sending a DAP Output Event break each message into separate lines. (PR #105456)
https://github.com/ashgti updated
https://github.com/llvm/llvm-project/pull/105456
>From 9246649c24991127b8f54ae1f21121386cef7254 Mon Sep 17 00:00:00 2001
From: John Harrison
Date: Tue, 20 Aug 2024 16:33:14 -0700
Subject: [PATCH 1/3] When sending a DAP Output Event break each message into
separate lines.
Previously, when output like `"hello\nworld\n"` was produced by lldb (or the
process) the message would be sent as a single Output event.
By being a single event this causes VS Code to treat this as a single message
in the console when handling displaying and filtering in the Debug Console.
Instead, with these changes we send each line as its own event. This results in
VS Code representing each line of output from lldb-dap as an individual output
message.
---
.../test/tools/lldb-dap/lldbdap_testcase.py | 5 +++
lldb/test/API/tools/lldb-dap/output/Makefile | 3 ++
.../tools/lldb-dap/output/TestDAP_output.py | 37 +++
lldb/test/API/tools/lldb-dap/output/main.c| 11 ++
lldb/tools/lldb-dap/DAP.cpp | 22 ---
5 files changed, 72 insertions(+), 6 deletions(-)
create mode 100644 lldb/test/API/tools/lldb-dap/output/Makefile
create mode 100644 lldb/test/API/tools/lldb-dap/output/TestDAP_output.py
create mode 100644 lldb/test/API/tools/lldb-dap/output/main.c
diff --git
a/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/lldbdap_testcase.py
b/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/lldbdap_testcase.py
index a312a88ebd7e58..8341bfda748206 100644
--- a/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/lldbdap_testcase.py
+++ b/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/lldbdap_testcase.py
@@ -202,6 +202,11 @@ def collect_console(self, timeout_secs, pattern=None):
"console", timeout_secs=timeout_secs, pattern=pattern
)
+def collect_stdout(self, timeout_secs, pattern=None):
+return self.dap_server.collect_output(
+"stdout", timeout_secs=timeout_secs, pattern=pattern
+)
+
def get_local_as_int(self, name, threadId=None):
value = self.dap_server.get_local_variable_value(name,
threadId=threadId)
# 'value' may have the variable value and summary.
diff --git a/lldb/test/API/tools/lldb-dap/output/Makefile
b/lldb/test/API/tools/lldb-dap/output/Makefile
new file mode 100644
index 00..10495940055b63
--- /dev/null
+++ b/lldb/test/API/tools/lldb-dap/output/Makefile
@@ -0,0 +1,3 @@
+C_SOURCES := main.c
+
+include Makefile.rules
diff --git a/lldb/test/API/tools/lldb-dap/output/TestDAP_output.py
b/lldb/test/API/tools/lldb-dap/output/TestDAP_output.py
new file mode 100644
index 00..08d5f07f224e4c
--- /dev/null
+++ b/lldb/test/API/tools/lldb-dap/output/TestDAP_output.py
@@ -0,0 +1,37 @@
+"""
+Test lldb-dap output events
+"""
+
+import dap_server
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+import lldbdap_testcase
+import re
+
+
+class TestDAP_output(lldbdap_testcase.DAPTestCaseBase):
+def test_output(self):
+program = self.getBuildArtifact("a.out")
+self.build_and_launch(program)
+source = "main.c"
+main_source_path = self.getSourcePath(source)
+lines = [line_number(source, "// breakpoint 1")]
+breakpoint_ids = self.set_source_breakpoints(source, lines)
+self.continue_to_breakpoints(breakpoint_ids)
+
+output = self.collect_stdout(
+timeout_secs=1.0,
+pattern="abcdef"
+)
+self.assertTrue(output and len(output) > 0, "expect no program output")
+
+self.continue_to_exit()
+
+output +=
self.get_stdout(timeout=lldbdap_testcase.DAPTestCaseBase.timeoutval)
+self.assertTrue(output and len(output) > 0, "expect no program output")
+self.assertIn(
+"abcdefghi\r\nhello world\r\n",
+output,
+'full output not found in: ' + output
+)
diff --git a/lldb/test/API/tools/lldb-dap/output/main.c
b/lldb/test/API/tools/lldb-dap/output/main.c
new file mode 100644
index 00..62a3337d865db2
--- /dev/null
+++ b/lldb/test/API/tools/lldb-dap/output/main.c
@@ -0,0 +1,11 @@
+#include
+#include
+#include
+
+int main() {
+ printf("abc");
+ printf("def");
+ printf("ghi\n");
+ printf("hello world\n"); // breakpoint 1
+ return 0;
+}
diff --git a/lldb/tools/lldb-dap/DAP.cpp b/lldb/tools/lldb-dap/DAP.cpp
index c3c70e9d739846..1fd560f21904ab 100644
--- a/lldb/tools/lldb-dap/DAP.cpp
+++ b/lldb/tools/lldb-dap/DAP.cpp
@@ -294,8 +294,6 @@ void DAP::SendOutput(OutputType o, const llvm::StringRef
output) {
if (output.empty())
return;
- llvm::json::Object event(CreateEventObject("output"));
- llvm::json::Object body;
const char *category = nullptr;
switch (o) {
case OutputType::Console:
@@ -311,10 +309,22 @@ void DAP::SendOutput(OutputType o, const llvm::StringRef
outp
[Lldb-commits] [lldb] [lldb-dap] When sending a DAP Output Event break each message into separate lines. (PR #105456)
@@ -399,7 +399,7 @@ void SendProcessEvent(LaunchMethod launch_method) {
// Grab any STDOUT and STDERR from the process and send it up to VS Code
// via an "output" event to the "stdout" and "stderr" categories.
void SendStdOutStdErr(lldb::SBProcess &process) {
- char buffer[1024];
+ char buffer[4096];
ashgti wrote:
Moved this into a constant.
https://github.com/llvm/llvm-project/pull/105456
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] When sending a DAP Output Event break each message into separate lines. (PR #105456)
https://github.com/ashgti updated
https://github.com/llvm/llvm-project/pull/105456
>From 9246649c24991127b8f54ae1f21121386cef7254 Mon Sep 17 00:00:00 2001
From: John Harrison
Date: Tue, 20 Aug 2024 16:33:14 -0700
Subject: [PATCH 1/3] When sending a DAP Output Event break each message into
separate lines.
Previously, when output like `"hello\nworld\n"` was produced by lldb (or the
process) the message would be sent as a single Output event.
By being a single event this causes VS Code to treat this as a single message
in the console when handling displaying and filtering in the Debug Console.
Instead, with these changes we send each line as its own event. This results in
VS Code representing each line of output from lldb-dap as an individual output
message.
---
.../test/tools/lldb-dap/lldbdap_testcase.py | 5 +++
lldb/test/API/tools/lldb-dap/output/Makefile | 3 ++
.../tools/lldb-dap/output/TestDAP_output.py | 37 +++
lldb/test/API/tools/lldb-dap/output/main.c| 11 ++
lldb/tools/lldb-dap/DAP.cpp | 22 ---
5 files changed, 72 insertions(+), 6 deletions(-)
create mode 100644 lldb/test/API/tools/lldb-dap/output/Makefile
create mode 100644 lldb/test/API/tools/lldb-dap/output/TestDAP_output.py
create mode 100644 lldb/test/API/tools/lldb-dap/output/main.c
diff --git
a/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/lldbdap_testcase.py
b/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/lldbdap_testcase.py
index a312a88ebd7e58..8341bfda748206 100644
--- a/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/lldbdap_testcase.py
+++ b/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/lldbdap_testcase.py
@@ -202,6 +202,11 @@ def collect_console(self, timeout_secs, pattern=None):
"console", timeout_secs=timeout_secs, pattern=pattern
)
+def collect_stdout(self, timeout_secs, pattern=None):
+return self.dap_server.collect_output(
+"stdout", timeout_secs=timeout_secs, pattern=pattern
+)
+
def get_local_as_int(self, name, threadId=None):
value = self.dap_server.get_local_variable_value(name,
threadId=threadId)
# 'value' may have the variable value and summary.
diff --git a/lldb/test/API/tools/lldb-dap/output/Makefile
b/lldb/test/API/tools/lldb-dap/output/Makefile
new file mode 100644
index 00..10495940055b63
--- /dev/null
+++ b/lldb/test/API/tools/lldb-dap/output/Makefile
@@ -0,0 +1,3 @@
+C_SOURCES := main.c
+
+include Makefile.rules
diff --git a/lldb/test/API/tools/lldb-dap/output/TestDAP_output.py
b/lldb/test/API/tools/lldb-dap/output/TestDAP_output.py
new file mode 100644
index 00..08d5f07f224e4c
--- /dev/null
+++ b/lldb/test/API/tools/lldb-dap/output/TestDAP_output.py
@@ -0,0 +1,37 @@
+"""
+Test lldb-dap output events
+"""
+
+import dap_server
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+import lldbdap_testcase
+import re
+
+
+class TestDAP_output(lldbdap_testcase.DAPTestCaseBase):
+def test_output(self):
+program = self.getBuildArtifact("a.out")
+self.build_and_launch(program)
+source = "main.c"
+main_source_path = self.getSourcePath(source)
+lines = [line_number(source, "// breakpoint 1")]
+breakpoint_ids = self.set_source_breakpoints(source, lines)
+self.continue_to_breakpoints(breakpoint_ids)
+
+output = self.collect_stdout(
+timeout_secs=1.0,
+pattern="abcdef"
+)
+self.assertTrue(output and len(output) > 0, "expect no program output")
+
+self.continue_to_exit()
+
+output +=
self.get_stdout(timeout=lldbdap_testcase.DAPTestCaseBase.timeoutval)
+self.assertTrue(output and len(output) > 0, "expect no program output")
+self.assertIn(
+"abcdefghi\r\nhello world\r\n",
+output,
+'full output not found in: ' + output
+)
diff --git a/lldb/test/API/tools/lldb-dap/output/main.c
b/lldb/test/API/tools/lldb-dap/output/main.c
new file mode 100644
index 00..62a3337d865db2
--- /dev/null
+++ b/lldb/test/API/tools/lldb-dap/output/main.c
@@ -0,0 +1,11 @@
+#include
+#include
+#include
+
+int main() {
+ printf("abc");
+ printf("def");
+ printf("ghi\n");
+ printf("hello world\n"); // breakpoint 1
+ return 0;
+}
diff --git a/lldb/tools/lldb-dap/DAP.cpp b/lldb/tools/lldb-dap/DAP.cpp
index c3c70e9d739846..1fd560f21904ab 100644
--- a/lldb/tools/lldb-dap/DAP.cpp
+++ b/lldb/tools/lldb-dap/DAP.cpp
@@ -294,8 +294,6 @@ void DAP::SendOutput(OutputType o, const llvm::StringRef
output) {
if (output.empty())
return;
- llvm::json::Object event(CreateEventObject("output"));
- llvm::json::Object body;
const char *category = nullptr;
switch (o) {
case OutputType::Console:
@@ -311,10 +309,22 @@ void DAP::SendOutput(OutputType o, const llvm::StringRef
outp
[Lldb-commits] [lldb] [lldb-dap] When sending a DAP Output Event break each message into separate lines. (PR #105456)
https://github.com/ashgti updated
https://github.com/llvm/llvm-project/pull/105456
>From 9246649c24991127b8f54ae1f21121386cef7254 Mon Sep 17 00:00:00 2001
From: John Harrison
Date: Tue, 20 Aug 2024 16:33:14 -0700
Subject: [PATCH 1/4] When sending a DAP Output Event break each message into
separate lines.
Previously, when output like `"hello\nworld\n"` was produced by lldb (or the
process) the message would be sent as a single Output event.
By being a single event this causes VS Code to treat this as a single message
in the console when handling displaying and filtering in the Debug Console.
Instead, with these changes we send each line as its own event. This results in
VS Code representing each line of output from lldb-dap as an individual output
message.
---
.../test/tools/lldb-dap/lldbdap_testcase.py | 5 +++
lldb/test/API/tools/lldb-dap/output/Makefile | 3 ++
.../tools/lldb-dap/output/TestDAP_output.py | 37 +++
lldb/test/API/tools/lldb-dap/output/main.c| 11 ++
lldb/tools/lldb-dap/DAP.cpp | 22 ---
5 files changed, 72 insertions(+), 6 deletions(-)
create mode 100644 lldb/test/API/tools/lldb-dap/output/Makefile
create mode 100644 lldb/test/API/tools/lldb-dap/output/TestDAP_output.py
create mode 100644 lldb/test/API/tools/lldb-dap/output/main.c
diff --git
a/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/lldbdap_testcase.py
b/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/lldbdap_testcase.py
index a312a88ebd7e58..8341bfda748206 100644
--- a/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/lldbdap_testcase.py
+++ b/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/lldbdap_testcase.py
@@ -202,6 +202,11 @@ def collect_console(self, timeout_secs, pattern=None):
"console", timeout_secs=timeout_secs, pattern=pattern
)
+def collect_stdout(self, timeout_secs, pattern=None):
+return self.dap_server.collect_output(
+"stdout", timeout_secs=timeout_secs, pattern=pattern
+)
+
def get_local_as_int(self, name, threadId=None):
value = self.dap_server.get_local_variable_value(name,
threadId=threadId)
# 'value' may have the variable value and summary.
diff --git a/lldb/test/API/tools/lldb-dap/output/Makefile
b/lldb/test/API/tools/lldb-dap/output/Makefile
new file mode 100644
index 00..10495940055b63
--- /dev/null
+++ b/lldb/test/API/tools/lldb-dap/output/Makefile
@@ -0,0 +1,3 @@
+C_SOURCES := main.c
+
+include Makefile.rules
diff --git a/lldb/test/API/tools/lldb-dap/output/TestDAP_output.py
b/lldb/test/API/tools/lldb-dap/output/TestDAP_output.py
new file mode 100644
index 00..08d5f07f224e4c
--- /dev/null
+++ b/lldb/test/API/tools/lldb-dap/output/TestDAP_output.py
@@ -0,0 +1,37 @@
+"""
+Test lldb-dap output events
+"""
+
+import dap_server
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+import lldbdap_testcase
+import re
+
+
+class TestDAP_output(lldbdap_testcase.DAPTestCaseBase):
+def test_output(self):
+program = self.getBuildArtifact("a.out")
+self.build_and_launch(program)
+source = "main.c"
+main_source_path = self.getSourcePath(source)
+lines = [line_number(source, "// breakpoint 1")]
+breakpoint_ids = self.set_source_breakpoints(source, lines)
+self.continue_to_breakpoints(breakpoint_ids)
+
+output = self.collect_stdout(
+timeout_secs=1.0,
+pattern="abcdef"
+)
+self.assertTrue(output and len(output) > 0, "expect no program output")
+
+self.continue_to_exit()
+
+output +=
self.get_stdout(timeout=lldbdap_testcase.DAPTestCaseBase.timeoutval)
+self.assertTrue(output and len(output) > 0, "expect no program output")
+self.assertIn(
+"abcdefghi\r\nhello world\r\n",
+output,
+'full output not found in: ' + output
+)
diff --git a/lldb/test/API/tools/lldb-dap/output/main.c
b/lldb/test/API/tools/lldb-dap/output/main.c
new file mode 100644
index 00..62a3337d865db2
--- /dev/null
+++ b/lldb/test/API/tools/lldb-dap/output/main.c
@@ -0,0 +1,11 @@
+#include
+#include
+#include
+
+int main() {
+ printf("abc");
+ printf("def");
+ printf("ghi\n");
+ printf("hello world\n"); // breakpoint 1
+ return 0;
+}
diff --git a/lldb/tools/lldb-dap/DAP.cpp b/lldb/tools/lldb-dap/DAP.cpp
index c3c70e9d739846..1fd560f21904ab 100644
--- a/lldb/tools/lldb-dap/DAP.cpp
+++ b/lldb/tools/lldb-dap/DAP.cpp
@@ -294,8 +294,6 @@ void DAP::SendOutput(OutputType o, const llvm::StringRef
output) {
if (output.empty())
return;
- llvm::json::Object event(CreateEventObject("output"));
- llvm::json::Object body;
const char *category = nullptr;
switch (o) {
case OutputType::Console:
@@ -311,10 +309,22 @@ void DAP::SendOutput(OutputType o, const llvm::StringRef
outp
[Lldb-commits] [lldb] [lldb-dap] When sending a DAP Output Event break each message into separate lines. (PR #105456)
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 a16f0dc9c2f0690e28622b0d80bd154fb0e6a30a 106a6bab4972913d989b97108c4f5f25bef2eca3 --extensions cpp,h,c -- lldb/test/API/tools/lldb-dap/output/main.c lldb/tools/lldb-dap/DAP.cpp lldb/tools/lldb-dap/DAP.h lldb/tools/lldb-dap/OutputRedirector.cpp lldb/tools/lldb-dap/lldb-dap.cpp `` View the diff from clang-format here. ``diff diff --git a/lldb/tools/lldb-dap/OutputRedirector.cpp b/lldb/tools/lldb-dap/OutputRedirector.cpp index bba6a9bf5f..2c2f495698 100644 --- a/lldb/tools/lldb-dap/OutputRedirector.cpp +++ b/lldb/tools/lldb-dap/OutputRedirector.cpp @@ -13,10 +13,9 @@ #include #endif -#include "llvm/ADT/StringRef.h" #include "DAP.h" #include "OutputRedirector.h" - +#include "llvm/ADT/StringRef.h" using namespace llvm; `` https://github.com/llvm/llvm-project/pull/105456 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] When sending a DAP Output Event break each message into separate lines. (PR #105456)
https://github.com/ashgti updated
https://github.com/llvm/llvm-project/pull/105456
>From 9246649c24991127b8f54ae1f21121386cef7254 Mon Sep 17 00:00:00 2001
From: John Harrison
Date: Tue, 20 Aug 2024 16:33:14 -0700
Subject: [PATCH 1/5] When sending a DAP Output Event break each message into
separate lines.
Previously, when output like `"hello\nworld\n"` was produced by lldb (or the
process) the message would be sent as a single Output event.
By being a single event this causes VS Code to treat this as a single message
in the console when handling displaying and filtering in the Debug Console.
Instead, with these changes we send each line as its own event. This results in
VS Code representing each line of output from lldb-dap as an individual output
message.
---
.../test/tools/lldb-dap/lldbdap_testcase.py | 5 +++
lldb/test/API/tools/lldb-dap/output/Makefile | 3 ++
.../tools/lldb-dap/output/TestDAP_output.py | 37 +++
lldb/test/API/tools/lldb-dap/output/main.c| 11 ++
lldb/tools/lldb-dap/DAP.cpp | 22 ---
5 files changed, 72 insertions(+), 6 deletions(-)
create mode 100644 lldb/test/API/tools/lldb-dap/output/Makefile
create mode 100644 lldb/test/API/tools/lldb-dap/output/TestDAP_output.py
create mode 100644 lldb/test/API/tools/lldb-dap/output/main.c
diff --git
a/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/lldbdap_testcase.py
b/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/lldbdap_testcase.py
index a312a88ebd7e58..8341bfda748206 100644
--- a/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/lldbdap_testcase.py
+++ b/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/lldbdap_testcase.py
@@ -202,6 +202,11 @@ def collect_console(self, timeout_secs, pattern=None):
"console", timeout_secs=timeout_secs, pattern=pattern
)
+def collect_stdout(self, timeout_secs, pattern=None):
+return self.dap_server.collect_output(
+"stdout", timeout_secs=timeout_secs, pattern=pattern
+)
+
def get_local_as_int(self, name, threadId=None):
value = self.dap_server.get_local_variable_value(name,
threadId=threadId)
# 'value' may have the variable value and summary.
diff --git a/lldb/test/API/tools/lldb-dap/output/Makefile
b/lldb/test/API/tools/lldb-dap/output/Makefile
new file mode 100644
index 00..10495940055b63
--- /dev/null
+++ b/lldb/test/API/tools/lldb-dap/output/Makefile
@@ -0,0 +1,3 @@
+C_SOURCES := main.c
+
+include Makefile.rules
diff --git a/lldb/test/API/tools/lldb-dap/output/TestDAP_output.py
b/lldb/test/API/tools/lldb-dap/output/TestDAP_output.py
new file mode 100644
index 00..08d5f07f224e4c
--- /dev/null
+++ b/lldb/test/API/tools/lldb-dap/output/TestDAP_output.py
@@ -0,0 +1,37 @@
+"""
+Test lldb-dap output events
+"""
+
+import dap_server
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+import lldbdap_testcase
+import re
+
+
+class TestDAP_output(lldbdap_testcase.DAPTestCaseBase):
+def test_output(self):
+program = self.getBuildArtifact("a.out")
+self.build_and_launch(program)
+source = "main.c"
+main_source_path = self.getSourcePath(source)
+lines = [line_number(source, "// breakpoint 1")]
+breakpoint_ids = self.set_source_breakpoints(source, lines)
+self.continue_to_breakpoints(breakpoint_ids)
+
+output = self.collect_stdout(
+timeout_secs=1.0,
+pattern="abcdef"
+)
+self.assertTrue(output and len(output) > 0, "expect no program output")
+
+self.continue_to_exit()
+
+output +=
self.get_stdout(timeout=lldbdap_testcase.DAPTestCaseBase.timeoutval)
+self.assertTrue(output and len(output) > 0, "expect no program output")
+self.assertIn(
+"abcdefghi\r\nhello world\r\n",
+output,
+'full output not found in: ' + output
+)
diff --git a/lldb/test/API/tools/lldb-dap/output/main.c
b/lldb/test/API/tools/lldb-dap/output/main.c
new file mode 100644
index 00..62a3337d865db2
--- /dev/null
+++ b/lldb/test/API/tools/lldb-dap/output/main.c
@@ -0,0 +1,11 @@
+#include
+#include
+#include
+
+int main() {
+ printf("abc");
+ printf("def");
+ printf("ghi\n");
+ printf("hello world\n"); // breakpoint 1
+ return 0;
+}
diff --git a/lldb/tools/lldb-dap/DAP.cpp b/lldb/tools/lldb-dap/DAP.cpp
index c3c70e9d739846..1fd560f21904ab 100644
--- a/lldb/tools/lldb-dap/DAP.cpp
+++ b/lldb/tools/lldb-dap/DAP.cpp
@@ -294,8 +294,6 @@ void DAP::SendOutput(OutputType o, const llvm::StringRef
output) {
if (output.empty())
return;
- llvm::json::Object event(CreateEventObject("output"));
- llvm::json::Object body;
const char *category = nullptr;
switch (o) {
case OutputType::Console:
@@ -311,10 +309,22 @@ void DAP::SendOutput(OutputType o, const llvm::StringRef
outp
[Lldb-commits] [lldb] [lldb-dap] When sending a DAP Output Event break each message into separate lines. (PR #105456)
https://github.com/walter-erquinigo approved this pull request. https://github.com/llvm/llvm-project/pull/105456 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] 30ca06c - [lldb-dap] When sending a DAP Output Event break each message into separate lines. (#105456)
Author: John Harrison
Date: 2024-08-21T13:48:29-07:00
New Revision: 30ca06c4d0d06f67f10a9e19d4333acc2074811b
URL:
https://github.com/llvm/llvm-project/commit/30ca06c4d0d06f67f10a9e19d4333acc2074811b
DIFF:
https://github.com/llvm/llvm-project/commit/30ca06c4d0d06f67f10a9e19d4333acc2074811b.diff
LOG: [lldb-dap] When sending a DAP Output Event break each message into
separate lines. (#105456)
Previously, when output like `"hello\nworld\n"` was produced by lldb (or
the process) the message would be sent as a single Output event. By
being a single event this causes VS Code to treat this as a single
message in the console when handling displaying and filtering in the
Debug Console.
Instead, with these changes we send each line as its own event. This
results in VS Code representing each line of output from lldb-dap as an
individual output message.
Resolves #105444
Added:
lldb/test/API/tools/lldb-dap/output/Makefile
lldb/test/API/tools/lldb-dap/output/TestDAP_output.py
lldb/test/API/tools/lldb-dap/output/main.c
Modified:
lldb/packages/Python/lldbsuite/test/tools/lldb-dap/lldbdap_testcase.py
lldb/tools/lldb-dap/DAP.cpp
lldb/tools/lldb-dap/DAP.h
lldb/tools/lldb-dap/OutputRedirector.cpp
lldb/tools/lldb-dap/lldb-dap.cpp
Removed:
diff --git
a/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/lldbdap_testcase.py
b/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/lldbdap_testcase.py
index 27545816f20707..86eba355da83db 100644
--- a/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/lldbdap_testcase.py
+++ b/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/lldbdap_testcase.py
@@ -202,6 +202,11 @@ def collect_console(self, timeout_secs, pattern=None):
"console", timeout_secs=timeout_secs, pattern=pattern
)
+def collect_stdout(self, timeout_secs, pattern=None):
+return self.dap_server.collect_output(
+"stdout", timeout_secs=timeout_secs, pattern=pattern
+)
+
def get_local_as_int(self, name, threadId=None):
value = self.dap_server.get_local_variable_value(name,
threadId=threadId)
# 'value' may have the variable value and summary.
diff --git a/lldb/test/API/tools/lldb-dap/output/Makefile
b/lldb/test/API/tools/lldb-dap/output/Makefile
new file mode 100644
index 00..10495940055b63
--- /dev/null
+++ b/lldb/test/API/tools/lldb-dap/output/Makefile
@@ -0,0 +1,3 @@
+C_SOURCES := main.c
+
+include Makefile.rules
diff --git a/lldb/test/API/tools/lldb-dap/output/TestDAP_output.py
b/lldb/test/API/tools/lldb-dap/output/TestDAP_output.py
new file mode 100644
index 00..0d40ce993dc31c
--- /dev/null
+++ b/lldb/test/API/tools/lldb-dap/output/TestDAP_output.py
@@ -0,0 +1,31 @@
+"""
+Test lldb-dap output events
+"""
+
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+import lldbdap_testcase
+
+
+class TestDAP_output(lldbdap_testcase.DAPTestCaseBase):
+def test_output(self):
+program = self.getBuildArtifact("a.out")
+self.build_and_launch(program)
+source = "main.c"
+lines = [line_number(source, "// breakpoint 1")]
+breakpoint_ids = self.set_source_breakpoints(source, lines)
+self.continue_to_breakpoints(breakpoint_ids)
+
+# Ensure partial messages are still sent.
+output = self.collect_stdout(timeout_secs=1.0, pattern="abcdef")
+self.assertTrue(output and len(output) > 0, "expect no program output")
+
+self.continue_to_exit()
+
+output +=
self.get_stdout(timeout=lldbdap_testcase.DAPTestCaseBase.timeoutval)
+self.assertTrue(output and len(output) > 0, "expect no program output")
+self.assertIn(
+"abcdefghi\r\nhello world\r\n",
+output,
+'full output not found in: ' + output,
+)
diff --git a/lldb/test/API/tools/lldb-dap/output/main.c
b/lldb/test/API/tools/lldb-dap/output/main.c
new file mode 100644
index 00..0cfcf604aa68f7
--- /dev/null
+++ b/lldb/test/API/tools/lldb-dap/output/main.c
@@ -0,0 +1,12 @@
+#include
+#include
+#include
+
+int main() {
+ // Ensure multiple partial lines are detected and sent.
+ printf("abc");
+ printf("def");
+ printf("ghi\n");
+ printf("hello world\n"); // breakpoint 1
+ return 0;
+}
diff --git a/lldb/tools/lldb-dap/DAP.cpp b/lldb/tools/lldb-dap/DAP.cpp
index c3c70e9d739846..1fd560f21904ab 100644
--- a/lldb/tools/lldb-dap/DAP.cpp
+++ b/lldb/tools/lldb-dap/DAP.cpp
@@ -294,8 +294,6 @@ void DAP::SendOutput(OutputType o, const llvm::StringRef
output) {
if (output.empty())
return;
- llvm::json::Object event(CreateEventObject("output"));
- llvm::json::Object body;
const char *category = nullptr;
switch (o) {
case OutputType::Console:
@@ -311,10 +309,22 @@ void DAP::SendOutput(OutputType o, const llvm::StringRef
output) {
categ
[Lldb-commits] [lldb] [lldb-dap] When sending a DAP Output Event break each message into separate lines. (PR #105456)
https://github.com/ashgti closed https://github.com/llvm/llvm-project/pull/105456 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Provide `declarationLocation` for variables (PR #102928)
walter-erquinigo wrote: @vogelsgesang , the `$__lldb_extensions.declaration` is used by the Mojo extension. Once this change gets it, I'll update the Mojo extension to use the new declaration info and remove `$__lldb_extensions.declaration`. https://github.com/llvm/llvm-project/pull/102928 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Provide `declarationLocation` for variables (PR #102928)
walter-erquinigo wrote: @vogelsgesang , can you show a screenshot of the variables pane after this change? I want to make sure that simple types, like ints, are not displayed as having children. https://github.com/llvm/llvm-project/pull/102928 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Provide `declarationLocation` for variables (PR #102928)
https://github.com/walter-erquinigo edited https://github.com/llvm/llvm-project/pull/102928 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Provide `declarationLocation` for variables (PR #102928)
@@ -0,0 +1,40 @@ +""" +Test lldb-dap locations request +""" + + +import dap_server +from lldbsuite.test.decorators import * +from lldbsuite.test.lldbtest import * +from lldbsuite.test import lldbutil +import lldbdap_testcase +import os + + +class TestDAP_locations(lldbdap_testcase.DAPTestCaseBase): +@skipIfWindows walter-erquinigo wrote: does this fail on windows? Otherwise just test this on Windows. https://github.com/llvm/llvm-project/pull/102928 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Provide `declarationLocation` for variables (PR #102928)
https://github.com/walter-erquinigo commented: This looks good to me, but I'd like @clayborg to have a second look. https://github.com/llvm/llvm-project/pull/102928 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Implement value locations for function pointers (PR #104589)
https://github.com/walter-erquinigo commented: Overall looks very nice, and I want to make sure that this works for the Mojo language after this gets merged. Please rebase this change so that I have a better time reviewing it. Also, happy to chime in on discourse to make sure that the RFC gets approved. I really love this kind of functionality. https://github.com/llvm/llvm-project/pull/104589 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Implement value locations for function pointers (PR #104589)
https://github.com/walter-erquinigo edited https://github.com/llvm/llvm-project/pull/104589 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Implement value locations for function pointers (PR #104589)
@@ -0,0 +1,81 @@ +""" +Test lldb-dap locations request +""" + + +import dap_server +from lldbsuite.test.decorators import * +from lldbsuite.test.lldbtest import * +from lldbsuite.test import lldbutil +import lldbdap_testcase +import os + + +class TestDAP_locations(lldbdap_testcase.DAPTestCaseBase): +@skipIfWindows walter-erquinigo wrote: remove unless you are sure this doesn't work on windows https://github.com/llvm/llvm-project/pull/104589 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Enabling instruction breakpoint support to lldb-dap. (PR #105278)
@@ -0,0 +1,6 @@ +CXX_SOURCES := main-copy.cpp +CXXFLAGS_EXTRAS := -O1 -g walter-erquinigo wrote: why don't you use -O0? https://github.com/llvm/llvm-project/pull/105278 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Enabling instruction breakpoint support to lldb-dap. (PR #105278)
https://github.com/walter-erquinigo commented: This LGTM, but I'd like @clayborg to give a second look. Thanks for this fancy feature, I've been wanting it for a while https://github.com/llvm/llvm-project/pull/105278 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Enabling instruction breakpoint support to lldb-dap. (PR #105278)
@@ -4046,6 +4048,181 @@ void request__testGetTargetBreakpoints(const
llvm::json::Object &request) {
g_dap.SendJSON(llvm::json::Value(std::move(response)));
}
+// SetInstructionBreakpoints request; value of command field is
+// 'setInstructionBreakpoints'. Replaces all existing instruction breakpoints.
+// Typically, instruction breakpoints would be set from a disassembly window.
To
+// clear all instruction breakpoints, specify an empty array. When an
+// instruction breakpoint is hit, a `stopped` event (with reason `instruction
+// breakpoint`) is generated. Clients should only call this request if the
+// corresponding capability `supportsInstructionBreakpoints` is true. interface
+// SetInstructionBreakpointsRequest extends Request {
+// command: 'setInstructionBreakpoints';
+// arguments: SetInstructionBreakpointsArguments;
+// }
+// interface SetInstructionBreakpointsArguments {
+// The instruction references of the breakpoints
+// breakpoints: InstructionBreakpoint[];
+// }
+// "InstructionBreakpoint ": {
+// "type": "object",
+// "description": "Properties of a breakpoint passed to the
+// setInstructionBreakpoints request.", "properties": {
+// "instructionReference": {
+// "type": "string",
+// "description": "The instruction reference of the breakpoint.
+// This should be a memory or instruction pointer reference from an
+// EvaluateResponse, Variable, StackFrame, GotoTarget, or Breakpoint."
+// },
+// "offset": {
+// "type": "number",
+// "description": "The offset from the instruction reference.
+// This can be negative."
+// },
+// "condition": {
+// "type": "string",
+// "description": "An expression for conditional breakpoints.
+// It is only honored by a debug adapter if the corresponding capability
+// supportsConditionalBreakpoints` is true."
+// },
+// "hitCondition": {
+// "type": "string",
+// "description": "An expression that controls how many hits of the
+// breakpoint are ignored. The debug adapter is expected to interpret the
+// expression as needed. The attribute is only honored by a debug adapter
+// if the corresponding capability `supportsHitConditionalBreakpoints` is
+// true."
+// },
+// }
+// interface SetInstructionBreakpointsResponse extends Response {
+// body: {
+// Information about the breakpoints. The array elements correspond to the
+// elements of the `breakpoints` array.
+// breakpoints: Breakpoint[];
+// };
+// }
+// Response to `setInstructionBreakpoints` request.
+// "Breakpoint": {
+// "type": "object",
+// "description": "Response to `setInstructionBreakpoints` request.",
+// "properties": {
+// "id": {
+// "type": "number",
+// "description": "The identifier for the breakpoint. It is needed if
+// breakpoint events are used to update or remove breakpoints."
+// },
+// "verified": {
+// "type": "boolean",
+// "description": "If true, the breakpoint could be set (but not
+// necessarily at the desired location."
+// },
+// "message": {
+// "type": "string",
+// "description": "A message about the state of the breakpoint.
+// This is shown to the user and can be used to explain why a breakpoint
+// could not be verified."
+// },
+// "source": {
+// "type": "Source",
+// "description": "The source where the breakpoint is located."
+// },
+// "line": {
+// "type": "number",
+// "description": "The start line of the actual range covered by the
+// breakpoint."
+// },
+// "column": {
+// "type": "number",
+// "description": "The start column of the actual range covered by the
+// breakpoint."
+// },
+// "endLine": {
+// "type": "number",
+// "description": "The end line of the actual range covered by the
+// breakpoint."
+// },
+// "endColumn": {
+// "type": "number",
+// "description": "The end column of the actual range covered by the
+// breakpoint. If no end line is given, then the end column is assumed to
+// be in the start line."
+// },
+// "instructionReference": {
+// "type": "string",
+// "description": "A memory reference to where the breakpoint is set."
+// },
+// "offset": {
+// "type": "number",
+// "description": "The offset from the instruction reference.
+// This can be negative."
+// },
+// },
+// "required": [ "id", "verified", "line"]
+// }
+void request_setInstructionBreakpoints(const llvm::json::Object &request) {
+ llvm::json::Object response;
+ llvm::json::Array response_breakpoints;
+ llvm::json::Object body;
+ FillResponse(request, response);
+
+ auto arguments = request.getObject("arguments");
+ auto breakpoints = arguments->getArray("breakpoints");
+
+ // It holds active instruc
[Lldb-commits] [lldb] [lldb-dap] Enabling instruction breakpoint support to lldb-dap. (PR #105278)
https://github.com/walter-erquinigo edited https://github.com/llvm/llvm-project/pull/105278 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Mark hidden frames as "subtle" (PR #105457)
petrhosek wrote:
This `subtleFrames` is failing on our builders, would it be possible to take a
look?
```
Script:
--
/b/s/w/ir/x/w/lldb_install/python3/bin/python3
/b/s/w/ir/x/w/llvm-llvm-project/lldb/test/API/dotest.py -u CXXFLAGS -u CFLAGS
--env ARCHIVER=/b/s/w/ir/x/w/cipd/bin/llvm-ar --env
OBJCOPY=/b/s/w/ir/x/w/cipd/bin/llvm-objcopy --env
LLVM_LIBS_DIR=/b/s/w/ir/x/w/llvm_build/./lib --env
LLVM_INCLUDE_DIR=/b/s/w/ir/x/w/llvm_build/include --env
LLVM_TOOLS_DIR=/b/s/w/ir/x/w/llvm_build/./bin --libcxx-include-dir
/b/s/w/ir/x/w/llvm_build/include/c++/v1 --libcxx-include-target-dir
/b/s/w/ir/x/w/llvm_build/include/x86_64-unknown-linux-gnu/c++/v1
--libcxx-library-dir /b/s/w/ir/x/w/llvm_build/./lib/x86_64-unknown-linux-gnu
--arch x86_64 --build-dir /b/s/w/ir/x/w/llvm_build/lldb-test-build.noindex
--lldb-module-cache-dir
/b/s/w/ir/x/w/llvm_build/lldb-test-build.noindex/module-cache-lldb/lldb-api
--clang-module-cache-dir
/b/s/w/ir/x/w/llvm_build/lldb-test-build.noindex/module-cache-clang/lldb-api
--executable /b/s/w/ir/x/w/llvm_build/./bin/lldb --compiler
/b/s/w/ir/x/w/llvm_build/./bin/clang --dsymutil
/b/s/w/ir/x/w/llvm_build/./bin/dsymutil --llvm-tools-dir
/b/s/w/ir/x/w/llvm_build/./bin --lldb-obj-root
/b/s/w/ir/x/w/llvm_build/tools/lldb --lldb-libs-dir
/b/s/w/ir/x/w/llvm_build/./lib --skip-category=pexpect
/b/s/w/ir/x/w/llvm-llvm-project/lldb/test/API/tools/lldb-dap/stackTrace/subtleFrames
-p TestDAP_subtleFrames.py
--
Exit Code: 1
Command Output (stdout):
--
lldb version 20.0.0git (https://llvm.googlesource.com/a/llvm-project revision
90556efaa2f5703920cce4a9c0ee36365e15e2ab)
clang revision 90556efaa2f5703920cce4a9c0ee36365e15e2ab
llvm revision 90556efaa2f5703920cce4a9c0ee36365e15e2ab
Skipping the following test categories: ['pexpect', 'dsym', 'gmodules',
'debugserver', 'objc']
= DEBUG ADAPTER PROTOCOL LOGS =
1724224181.656976938 -->
Content-Length: 344
{
"arguments": {
"adapterID": "lldb-native",
"clientID": "vscode",
"columnsStartAt1": true,
"linesStartAt1": true,
"locale": "en-us",
"pathFormat": "path",
"sourceInitFile": false,
"supportsRunInTerminalRequest": true,
"supportsStartDebuggingRequest": true,
"supportsVariablePaging": true,
"supportsVariableType": true
},
"command": "initialize",
"seq": 1,
"type": "request"
}
1724224181.658302069 <--
Content-Length: 1487
{
"body": {
"__lldb": {
"version": "lldb version 20.0.0git
(https://llvm.googlesource.com/a/llvm-project revision
90556efaa2f5703920cce4a9c0ee36365e15e2ab)\n clang revision
90556efaa2f5703920cce4a9c0ee36365e15e2ab\n llvm revision
90556efaa2f5703920cce4a9c0ee36365e15e2ab"
},
"completionTriggerCharacters": [
".",
" ",
"\t"
],
"exceptionBreakpointFilters": [
{
"default": false,
"filter": "cpp_catch",
"label": "C++ Catch"
},
{
"default": false,
"filter": "cpp_throw",
"label": "C++ Throw"
},
{
"default": false,
"filter": "objc_catch",
"label": "Objective-C Catch"
},
{
"default": false,
"filter": "objc_throw",
"label": "Objective-C Throw"
}
],
"supportTerminateDebuggee": true,
"supportsCompletionsRequest": true,
"supportsConditionalBreakpoints": true,
"supportsConfigurationDoneRequest": true,
"supportsDataBreakpoints": true,
"supportsDelayedStackTraceLoading": true,
"supportsDisassembleRequest": true,
"supportsEvaluateForHovers": true,
"supportsExceptionInfoRequest": true,
"supportsExceptionOptions": true,
"supportsFunctionBreakpoints": true,
"supportsGotoTargetsRequest": false,
"supportsHitConditionalBreakpoints": true,
"supportsLoadedSourcesRequest": false,
"supportsLogPoints": true,
"supportsModulesRequest": true,
"supportsProgressReporting": true,
"supportsRestartFrame": false,
"supportsRestartRequest": true,
"supportsRunInTerminalRequest": true,
"supportsSetVariable": true,
"supportsStepBack": false,
"supportsStepInTargetsRequest": true,
"supportsValueFormattingOptions": true
},
"command": "initialize",
"request_seq": 1,
"seq": 0,
"success": true,
"type": "response"
}
1724224181.658623934 -->
Content-Length: 803
{
"arguments": {
"commandEscapePrefix": null,
"disableASLR": true,
"enableAutoVariableSummaries": false,
"enableSyntheticChildDebugging": false,
"initCommands": [
"settings clear -all",
"settings set symbols.enable-external-lookup false",
"settings set target.inherit-tcc true",
"settings set target.disable-aslr false",
"settings set target.detach-on-error false",
"settings set target.auto-apply-fixits false",
"settings set plugin.process.gdb-remote.packet-timeout 60",
"settings set symbols.clang-modules-cache-path
\"/b/s/w/ir/x/w/llvm_build/lldb-test-build.noin
[Lldb-commits] [lldb] [lldb] Pick the correct architecutre when target and core file disagree (PR #105576)
https://github.com/jasonmolenda approved this pull request. LGTM. https://github.com/llvm/llvm-project/pull/105576 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Fix dap stacktrace perf issue (PR #104874)
jeffreytan81 wrote: @walter-erquinigo, the performance issue is not only showing for 1% rare gigantic target. It is actually reported by a customer's target with 4000 modules with only 3GB of debug info. Disabling this feature significantly improves the stepping experience. To get a sense of the scale, in our company, there are 1/3 targets with debug info > 10GB, and 1/3 targets between 1-10GB, and remaining 1/3 below 1GB. 3GB debug info target is simply a below average target while it is already showing very noticeable stepping slowness for end users. Also, I do not think 1 second stepping performance regression is an acceptable engineering trade off overtime. Note: the profile trace I shared above comes from profiling a hello world target and I have seen similar hot path for lldb-dap running on Mac, but I do not have time to measure Mac's impact. https://github.com/llvm/llvm-project/pull/104874 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Fix dap stacktrace perf issue (PR #104874)
https://github.com/jeffreytan81 updated
https://github.com/llvm/llvm-project/pull/104874
>From 6e84ab9a14e63c58e1facdbf9a695c093882b37b Mon Sep 17 00:00:00 2001
From: jeffreytan81
Date: Mon, 19 Aug 2024 10:57:35 -0700
Subject: [PATCH 1/2] Fix StartDebuggingRequestHandler/ReplModeRequestHandler
in lldb-dap
---
lldb/tools/lldb-dap/DAP.h| 2 --
lldb/tools/lldb-dap/lldb-dap.cpp | 4 ++--
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/lldb/tools/lldb-dap/DAP.h b/lldb/tools/lldb-dap/DAP.h
index 57562a14983519..7828272aa15a7d 100644
--- a/lldb/tools/lldb-dap/DAP.h
+++ b/lldb/tools/lldb-dap/DAP.h
@@ -192,8 +192,6 @@ struct DAP {
std::mutex call_mutex;
std::map
inflight_reverse_requests;
- StartDebuggingRequestHandler start_debugging_request_handler;
- ReplModeRequestHandler repl_mode_request_handler;
ReplMode repl_mode;
std::string command_escape_prefix = "`";
lldb::SBFormat frame_format;
diff --git a/lldb/tools/lldb-dap/lldb-dap.cpp b/lldb/tools/lldb-dap/lldb-dap.cpp
index ea84f31aec3a6c..f50a6c17310739 100644
--- a/lldb/tools/lldb-dap/lldb-dap.cpp
+++ b/lldb/tools/lldb-dap/lldb-dap.cpp
@@ -1627,12 +1627,12 @@ void request_initialize(const llvm::json::Object
&request) {
"lldb-dap", "Commands for managing lldb-dap.");
if (GetBoolean(arguments, "supportsStartDebuggingRequest", false)) {
cmd.AddCommand(
-"startDebugging", &g_dap.start_debugging_request_handler,
+"startDebugging", new StartDebuggingRequestHandler(),
"Sends a startDebugging request from the debug adapter to the client "
"to start a child debug session of the same type as the caller.");
}
cmd.AddCommand(
- "repl-mode", &g_dap.repl_mode_request_handler,
+ "repl-mode", new ReplModeRequestHandler(),
"Get or set the repl behavior of lldb-dap evaluation requests.");
g_dap.progress_event_thread = std::thread(ProgressEventThreadFunction);
>From 00f62e2d4cd067b6c46a7646ff152ceae808b1f4 Mon Sep 17 00:00:00 2001
From: jeffreytan81
Date: Mon, 19 Aug 2024 14:01:54 -0700
Subject: [PATCH 2/2] Fix stackTrace perf issue in lldb-dap
---
lldb/tools/lldb-dap/DAP.cpp | 1 +
lldb/tools/lldb-dap/DAP.h| 1 +
lldb/tools/lldb-dap/lldb-dap.cpp | 15 +++
3 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/lldb/tools/lldb-dap/DAP.cpp b/lldb/tools/lldb-dap/DAP.cpp
index 1fd560f21904ab..57b93c28ce9301 100644
--- a/lldb/tools/lldb-dap/DAP.cpp
+++ b/lldb/tools/lldb-dap/DAP.cpp
@@ -36,6 +36,7 @@ DAP::DAP()
focus_tid(LLDB_INVALID_THREAD_ID), stop_at_entry(false),
is_attach(false),
enable_auto_variable_summaries(false),
enable_synthetic_child_debugging(false),
+ enable_display_extended_backtrace(false),
restarting_process_id(LLDB_INVALID_PROCESS_ID),
configuration_done_sent(false), waiting_for_run_in_terminal(false),
progress_event_reporter(
diff --git a/lldb/tools/lldb-dap/DAP.h b/lldb/tools/lldb-dap/DAP.h
index 27ea6c7ff8423f..0fc77ac1e81683 100644
--- a/lldb/tools/lldb-dap/DAP.h
+++ b/lldb/tools/lldb-dap/DAP.h
@@ -181,6 +181,7 @@ struct DAP {
bool is_attach;
bool enable_auto_variable_summaries;
bool enable_synthetic_child_debugging;
+ bool enable_display_extended_backtrace;
// The process event thread normally responds to process exited events by
// shutting down the entire adapter. When we're restarting, we keep the id of
// the old process here so we can detect this case and keep running.
diff --git a/lldb/tools/lldb-dap/lldb-dap.cpp b/lldb/tools/lldb-dap/lldb-dap.cpp
index 7b83767d1afeab..495ed0256120e8 100644
--- a/lldb/tools/lldb-dap/lldb-dap.cpp
+++ b/lldb/tools/lldb-dap/lldb-dap.cpp
@@ -701,6 +701,8 @@ void request_attach(const llvm::json::Object &request) {
GetBoolean(arguments, "enableAutoVariableSummaries", false);
g_dap.enable_synthetic_child_debugging =
GetBoolean(arguments, "enableSyntheticChildDebugging", false);
+ g_dap.enable_display_extended_backtrace =
+ GetBoolean(arguments, "enableDisplayExtendedBacktrace", false);
g_dap.command_escape_prefix =
GetString(arguments, "commandEscapePrefix", "`");
g_dap.SetFrameFormat(GetString(arguments, "customFrameFormat"));
@@ -1925,6 +1927,8 @@ void request_launch(const llvm::json::Object &request) {
GetBoolean(arguments, "enableAutoVariableSummaries", false);
g_dap.enable_synthetic_child_debugging =
GetBoolean(arguments, "enableSyntheticChildDebugging", false);
+ g_dap.enable_display_extended_backtrace =
+ GetBoolean(arguments, "enableDisplayExtendedBacktrace", false);
g_dap.command_escape_prefix =
GetString(arguments, "commandEscapePrefix", "`");
g_dap.SetFrameFormat(GetString(arguments, "customFrameFormat"));
@@ -3111,8 +3115,9 @@ void request_stackTrace(const llvm::json::Object
&request) {
// This will always return an invalid thread when
// libBacktraceRecording.dylib is not loaded or if there is no exten
[Lldb-commits] [lldb] Fix dap stacktrace perf issue (PR #104874)
@@ -3091,17 +3093,20 @@ void request_stackTrace(const llvm::json::Object
&request) {
// This will always return an invalid thread when
// libBacktraceRecording.dylib is not loaded or if there is no extended
// backtrace.
-lldb::SBThread queue_backtrace_thread =
-thread.GetExtendedBacktraceThread("libdispatch");
+lldb::SBThread queue_backtrace_thread;
+if (g_dap.enable_display_extended_backtrace)
+ queue_backtrace_thread =
thread.GetExtendedBacktraceThread("libdispatch");
jeffreytan81 wrote:
@ashgti, if you look at the profile trace, the hot path does not come from this
call (`thread.GetExtendedBacktraceThread()`) but from
`thread.GetCurrentExceptionBacktrace()` below.
https://github.com/llvm/llvm-project/pull/104874
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Change lldb's breakpoint detection behavior [WIP] (PR #105594)
https://github.com/jasonmolenda created https://github.com/llvm/llvm-project/pull/105594 This is a PR to track the changes I need to make to https://github.com/llvm/llvm-project/pull/96260 to address the CI bot failures when I merged that PR, as well as investigating the windows problem Martin Storsjö saw. There's likely going to be 4-5 additional changes to this PR before it's ready to be merged again, I'll create a new PR with the patches I originally landed and fixing those separate issues in additional commits. Issues: 1. lldb-server armv7/aarch32 stepping-by-breakpoint doesn't verify the pc changed as expected, when reporting a `trace` stop-reason, so it will fail to recognize stepping over a breakpoint correctly. 2. ProcessGDBRemote needs to add a `reason = "breakpoint"` when we have a `swbreak` or `hwbreak` from the remote stub, like it does today for `watch`/`awatch`. https://github.com/llvm/llvm-project/pull/102873 3. debugserver on armv7k watches is doesn't correctly report a "step by breakpoint" as a `trace` event, need to verify that we can step / step past breakpoints correctly on old watches running that old debugserver. 4. fix debuginfo dexter fails because stepping behavior was different. 5. Look into the Martin Storsjö `finish` failure on windows. >From 56ca564185bdceea25162a1ce3b1e8c8fa2641e2 Mon Sep 17 00:00:00 2001 From: Jason Molenda Date: Fri, 19 Jul 2024 17:26:13 -0700 Subject: [PATCH] [lldb] Change lldb's breakpoint handling behavior (#96260) lldb today has two rules: When a thread stops at a BreakpointSite, we set the thread's StopReason to be "breakpoint hit" (regardless if we've actually hit the breakpoint, or if we've merely stopped *at* the breakpoint instruction/point and haven't tripped it yet). And second, when resuming a process, any thread sitting at a BreakpointSite is silently stepped over the BreakpointSite -- because we've already flagged the breakpoint hit when we stopped there originally. In this patch, I change lldb to only set a thread's stop reason to breakpoint-hit when we've actually executed the instruction/triggered the breakpoint. When we resume, we only silently step past a BreakpointSite that we've registered as hit. We preserve this state across inferior function calls that the user may do while stopped, etc. Also, when a user adds a new breakpoint at $pc while stopped, or changes $pc to be the address of a BreakpointSite, we will silently step past that breakpoint when the process resumes. This is purely a UX call, I don't think there's any person who wants to set a breakpoint at $pc and then hit it immediately on resuming. One non-intuitive UX from this change, but I'm convinced it is necessary: If you're stopped at a BreakpointSite that has not yet executed, you `stepi`, you will hit the breakpoint and the pc will not yet advance. This thread has not completed its stepi, and the thread plan is still on the stack. If you then `continue` the thread, lldb will now stop and say, "instruction step completed", one instruction past the BreakpointSite. You can continue a second time to resume execution. I discussed this with Jim, and trying to paper over this behavior will lead to more complicated scenarios behaving non-intuitively. And mostly it's the testsuite that was trying to instruction step past a breakpoint and getting thrown off -- and I changed those tests to expect the new behavior. The bugs driving this change are all from lldb dropping the real stop reason for a thread and setting it to breakpoint-hit when that was not the case. Jim hit one where we have an aarch64 watchpoint that triggers one instruction before a BreakpointSite. On this arch we are notified of the watchpoint hit after the instruction has been unrolled -- we disable the watchpoint, instruction step, re-enable the watchpoint and collect the new value. But now we're on a BreakpointSite so the watchpoint-hit stop reason is lost. Another was reported by ZequanWu in https://discourse.llvm.org/t/lldb-unable-to-break-at-start/78282 we attach to/launch a process with the pc at a BreakpointSite and misbehave. Caroline Tice mentioned it is also a problem they've had with putting a breakpoint on _dl_debug_state. The change to each Process plugin that does execution control is that 1. If we've stopped at a BreakpointSite that has not been executed yet, we will call Thread::SetThreadStoppedAtUnexecutedBP(pc) to record that. When the thread resumes, if the pc is still at the same site, we will continue, hit the breakpoint, and stop again. 2. When we've actually hit a breakpoint (enabled for this thread or not), the Process plugin should call Thread::SetThreadHitBreakpointSite(). When we go to resume the thread, we will push a step-over-breakpoint ThreadPlan before resuming. The biggest set of changes is to StopInfoMachException where we translate a Mach Exception into a stop reason. The Mach exception codes differ in a few places depending on the target (unambiguou
[Lldb-commits] [lldb] [lldb] Change lldb's breakpoint detection behavior [WIP] (PR #105594)
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Jason Molenda (jasonmolenda)
Changes
This is a PR to track the changes I need to make to
https://github.com/llvm/llvm-project/pull/96260
to address the CI bot failures when I merged that PR, as well as investigating
the windows problem Martin Storsjö saw. There's likely going to be 4-5
additional changes to this PR before it's ready to be merged again, I'll create
a new PR with the patches I originally landed and fixing those separate issues
in additional commits.
Issues:
1. lldb-server armv7/aarch32 stepping-by-breakpoint doesn't verify the pc
changed as expected, when reporting a `trace` stop-reason, so it will fail to
recognize stepping over a breakpoint correctly.
2. ProcessGDBRemote needs to add a `reason = "breakpoint"` when we have a
`swbreak` or `hwbreak` from the remote stub, like it does today for
`watch`/`awatch`. https://github.com/llvm/llvm-project/pull/102873
3. debugserver on armv7k watches is doesn't correctly report a "step by
breakpoint" as a `trace` event, need to verify that we can step / step past
breakpoints correctly on old watches running that old debugserver.
4. fix debuginfo dexter fails because stepping behavior was different.
5. Look into the Martin Storsjö `finish` failure on windows.
---
Patch is 35.61 KiB, truncated to 20.00 KiB below, full version:
https://github.com/llvm/llvm-project/pull/105594.diff
9 Files Affected:
- (modified) lldb/include/lldb/Target/Thread.h (+24)
- (modified) lldb/source/Plugins/Process/Utility/StopInfoMachException.cpp
(+148-174)
- (modified) lldb/source/Plugins/Process/Windows/Common/ProcessWindows.cpp
(+12-20)
- (modified) lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
(+31-62)
- (modified) lldb/source/Plugins/Process/scripted/ScriptedThread.cpp (+11)
- (modified) lldb/source/Target/StopInfo.cpp (+2)
- (modified) lldb/source/Target/Thread.cpp (+14-1)
- (modified)
lldb/test/API/functionalities/breakpoint/consecutive_breakpoints/TestConsecutiveBreakpoints.py
(+19-7)
- (modified)
lldb/test/API/functionalities/breakpoint/step_over_breakpoint/TestStepOverBreakpoint.py
(+5-1)
``diff
diff --git a/lldb/include/lldb/Target/Thread.h
b/lldb/include/lldb/Target/Thread.h
index 38b65b2bc58490..22d452c7b4b8a3 100644
--- a/lldb/include/lldb/Target/Thread.h
+++ b/lldb/include/lldb/Target/Thread.h
@@ -131,6 +131,7 @@ class Thread : public std::enable_shared_from_this,
register_backup_sp; // You need to restore the registers, of course...
uint32_t current_inlined_depth;
lldb::addr_t current_inlined_pc;
+lldb::addr_t stopped_at_unexecuted_bp;
};
/// Constructor
@@ -380,6 +381,26 @@ class Thread : public std::enable_shared_from_this,
virtual void SetQueueLibdispatchQueueAddress(lldb::addr_t dispatch_queue_t)
{}
+ /// When a thread stops at an enabled BreakpointSite that has not executed,
+ /// the Process plugin should call SetThreadStoppedAtUnexecutedBP(pc).
+ /// If that BreakpointSite was actually triggered (the instruction was
+ /// executed, for a software breakpoint), regardless of whether the
+ /// breakpoint is valid for this thread, SetThreadHitBreakpointSite()
+ /// should be called to record that fact.
+ ///
+ /// Depending on the structure of the Process plugin, it may be easiest
+ /// to call SetThreadStoppedAtUnexecutedBP(pc) unconditionally when at
+ /// a BreakpointSite, and later when it is known that it was triggered,
+ /// SetThreadHitBreakpointSite() can be called. These two methods
+ /// overwrite the same piece of state in the Thread, the last one
+ /// called on a Thread wins.
+ void SetThreadStoppedAtUnexecutedBP(lldb::addr_t pc) {
+m_stopped_at_unexecuted_bp = pc;
+ }
+ void SetThreadHitBreakpointSite() {
+m_stopped_at_unexecuted_bp = LLDB_INVALID_ADDRESS;
+ }
+
/// Whether this Thread already has all the Queue information cached or not
///
/// A Thread may be associated with a libdispatch work Queue at a given
@@ -1314,6 +1335,9 @@ class Thread : public
std::enable_shared_from_this,
bool m_should_run_before_public_stop; // If this thread has "stop others"
// private work to do, then it will
// set this.
+ lldb::addr_t m_stopped_at_unexecuted_bp; // Set to the address of a
breakpoint
+ // instruction that we have not yet
+ // hit, but will hit when we resume.
const uint32_t m_index_id; ///< A unique 1 based index assigned to each
thread
/// for easy UI/command line access.
lldb::RegisterContextSP m_reg_context_sp; ///< The register context for this
diff --git a/lldb/source/Plugins/Process/Utility/StopInfoMachException.cpp
b/lldb/source/Plugins/Process/Utility/StopInfoMachException.cpp
index 25cee369d7ee3d..f1853be12638ea 100644
--- a/lldb/sourc
[Lldb-commits] [lldb] [lldb] Change lldb's breakpoint handling behavior (PR #96260)
jasonmolenda wrote: I opened a new PR that starts with this PR's patchset which I had to revert, and I will address the issues that need to be fixed there with separate additional commits in preparation for merging it again. https://github.com/llvm/llvm-project/pull/105594 https://github.com/llvm/llvm-project/pull/96260 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Change the two remaining SInt64 settings in Target to uint (PR #105460)
https://github.com/jasonmolenda updated
https://github.com/llvm/llvm-project/pull/105460
>From 5021ef81d8c18a06cbb6d7595845bacd7e99b423 Mon Sep 17 00:00:00 2001
From: Jason Molenda
Date: Tue, 20 Aug 2024 18:29:24 -0700
Subject: [PATCH 1/2] [lldb] Change the two remaining SInt64 settings in Target
to uint
TargetProperties.td had a few settings listed as signed integral
values, but the Target.cpp methods reading those values were reading
them as unsigned. e.g. target.max-memory-read-size, some accesses
of target.max-children-count, still today, previously
target.max-string-summary-length.
After Jonas' change to use templates to read these values in
https://reviews.llvm.org/D149774, when the code tried to fetch these
values, we'd eventually end up calling OptionValue::GetAsUInt64
which checks that the value is actually a UInt64 before returning
it; finding that it was an SInt64, it would drop the user setting
and return the default value. This manifested as a bug that
target.max-memory-read-size is never used for memory read.
target.max-children-count is less straightforward, where one read
of that setting was fetching it as an int64_t, the other as a
uint64_t.
I suspect all of these settings were originally marked as SInt64
so a user could do -1 for "infinite", getting it static_cast to a
UINT64_MAX value along the way. I can't find any documentation for
this behavior, but it seems like something Greg would have done.
We've partially lost that behavior already via
https://github.com/llvm/llvm-project/pull/72233 for
target.max-string-summary-length, and this further removes it.
We're still fetching UInt64's and returning them as uint32_t's
but I'm not overly pressed about someone setting a count/size
limit over 4GB.
I added a simple API test for the memory read setting limit.
More generally speaking, I think our limits on string / children /
bytes are far too low. I don't think people should need to set these
as a regular part of using the commands. I know the danger is
always printing an uninitialized char* and reading 16MB before we
hit a nul byte, or having some ValueObject chain that is following
a circular linked list and never terminates, or dumping 4MB of
memory to console when someone confuses size/count and start address.
But I think I'd prefer much higher limits on all of these, and
having people be annoyed in those cases instead of annoyed when
lldb won't print a paragraph-length c-string, or reading more than
1k of memory.
---
lldb/source/Target/Target.cpp | 2 +-
lldb/source/Target/TargetProperties.td| 4 +--
.../functionalities/memory/big-read/Makefile | 3 ++
.../big-read/TestMemoryReadMaximumSize.py | 31 +++
.../functionalities/memory/big-read/main.c| 9 ++
5 files changed, 46 insertions(+), 3 deletions(-)
create mode 100644 lldb/test/API/functionalities/memory/big-read/Makefile
create mode 100644
lldb/test/API/functionalities/memory/big-read/TestMemoryReadMaximumSize.py
create mode 100644 lldb/test/API/functionalities/memory/big-read/main.c
diff --git a/lldb/source/Target/Target.cpp b/lldb/source/Target/Target.cpp
index 5a5d689e03fbc0..260974bddedf3a 100644
--- a/lldb/source/Target/Target.cpp
+++ b/lldb/source/Target/Target.cpp
@@ -4609,7 +4609,7 @@ uint32_t
TargetProperties::GetMaxZeroPaddingInFloatFormat() const {
uint32_t TargetProperties::GetMaximumNumberOfChildrenToDisplay() const {
const uint32_t idx = ePropertyMaxChildrenCount;
- return GetPropertyAtIndexAs(
+ return GetPropertyAtIndexAs(
idx, g_target_properties[idx].default_uint_value);
}
diff --git a/lldb/source/Target/TargetProperties.td
b/lldb/source/Target/TargetProperties.td
index 421252aa4aea26..7bb5bd53688b14 100644
--- a/lldb/source/Target/TargetProperties.td
+++ b/lldb/source/Target/TargetProperties.td
@@ -92,7 +92,7 @@ let Definition = "target" in {
def MaxZeroPaddingInFloatFormat:
Property<"max-zero-padding-in-float-format", "UInt64">,
DefaultUnsignedValue<6>,
Desc<"The maximum number of zeroes to insert when displaying a very small
float before falling back to scientific notation.">;
- def MaxChildrenCount: Property<"max-children-count", "SInt64">,
+ def MaxChildrenCount: Property<"max-children-count", "UInt64">,
DefaultUnsignedValue<256>,
Desc<"Maximum number of children to expand in any level of depth.">;
def MaxChildrenDepth: Property<"max-children-depth", "UInt64">,
@@ -101,7 +101,7 @@ let Definition = "target" in {
def MaxSummaryLength: Property<"max-string-summary-length", "UInt64">,
DefaultUnsignedValue<1024>,
Desc<"Maximum number of characters to show when using %s in summary
strings.">;
- def MaxMemReadSize: Property<"max-memory-read-size", "SInt64">,
+ def MaxMemReadSize: Property<"max-memory-read-size", "UInt64">,
DefaultUnsignedValue<1024>,
Desc<"Maximum number of bytes that 'memory read' will fetch before --force
must be specified.">;
def BreakpointUse
[Lldb-commits] [lldb] [lldb] Extend frame recognizers to hide frames from backtraces (PR #104523)
petrhosek wrote: The `lldb-api :: lang/cpp/std-function-recognizer/TestStdFunctionRecognizer.py` test has been failing on our builders with the following error: ``` Script: -- /b/s/w/ir/x/w/lldb_install/python3/bin/python3 /b/s/w/ir/x/w/llvm-llvm-project/lldb/test/API/dotest.py -u CXXFLAGS -u CFLAGS --env ARCHIVER=/b/s/w/ir/x/w/cipd/bin/llvm-ar --env OBJCOPY=/b/s/w/ir/x/w/cipd/bin/llvm-objcopy --env LLVM_LIBS_DIR=/b/s/w/ir/x/w/llvm_build/./lib --env LLVM_INCLUDE_DIR=/b/s/w/ir/x/w/llvm_build/include --env LLVM_TOOLS_DIR=/b/s/w/ir/x/w/llvm_build/./bin --libcxx-include-dir /b/s/w/ir/x/w/llvm_build/include/c++/v1 --libcxx-include-target-dir /b/s/w/ir/x/w/llvm_build/include/x86_64-unknown-linux-gnu/c++/v1 --libcxx-library-dir /b/s/w/ir/x/w/llvm_build/./lib/x86_64-unknown-linux-gnu --arch x86_64 --build-dir /b/s/w/ir/x/w/llvm_build/lldb-test-build.noindex --lldb-module-cache-dir /b/s/w/ir/x/w/llvm_build/lldb-test-build.noindex/module-cache-lldb/lldb-api --clang-module-cache-dir /b/s/w/ir/x/w/llvm_build/lldb-test-build.noindex/module-cache-clang/lldb-api --executable /b/s/w/ir/x/w/llvm_build/./bin/lldb --compiler /b/s/w/ir/x/w/llvm_build/./bin/clang --dsymutil /b/s/w/ir/x/w/llvm_build/./bin/dsymutil --llvm-tools-dir /b/s/w/ir/x/w/llvm_build/./bin --lldb-obj-root /b/s/w/ir/x/w/llvm_build/tools/lldb --lldb-libs-dir /b/s/w/ir/x/w/llvm_build/./lib --skip-category=pexpect /b/s/w/ir/x/w/llvm-llvm-project/lldb/test/API/lang/cpp/std-function-recognizer -p TestStdFunctionRecognizer.py -- Exit Code: 1 Command Output (stdout): -- lldb version 20.0.0git (https://llvm.googlesource.com/a/llvm-project revision 90556efaa2f5703920cce4a9c0ee36365e15e2ab) clang revision 90556efaa2f5703920cce4a9c0ee36365e15e2ab llvm revision 90556efaa2f5703920cce4a9c0ee36365e15e2ab Skipping the following test categories: ['pexpect', 'dsym', 'gmodules', 'debugserver', 'objc'] -- Command Output (stderr): -- FAIL: LLDB (/b/s/w/ir/x/w/llvm_build/bin/clang-x86_64) :: test_api (TestStdFunctionRecognizer.LibCxxStdFunctionRecognizerTestCase.test_api) FAIL: LLDB (/b/s/w/ir/x/w/llvm_build/bin/clang-x86_64) :: test_backtrace (TestStdFunctionRecognizer.LibCxxStdFunctionRecognizerTestCase.test_backtrace) FAIL: LLDB (/b/s/w/ir/x/w/llvm_build/bin/clang-x86_64) :: test_up_down (TestStdFunctionRecognizer.LibCxxStdFunctionRecognizerTestCase.test_up_down) == FAIL: test_api (TestStdFunctionRecognizer.LibCxxStdFunctionRecognizerTestCase.test_api) Test that std::function implementation details are skipped -- Traceback (most recent call last): File "/b/s/w/ir/x/w/llvm-llvm-project/lldb/test/API/lang/cpp/std-function-recognizer/TestStdFunctionRecognizer.py", line 83, in test_api self.assertGreater(num_hidden, 0) AssertionError: 0 not greater than 0 Config=x86_64-/b/s/w/ir/x/w/llvm_build/bin/clang == FAIL: test_backtrace (TestStdFunctionRecognizer.LibCxxStdFunctionRecognizerTestCase.test_backtrace) Test that std::function implementation details are hidden in bt -- Traceback (most recent call last): File "/b/s/w/ir/x/w/llvm-llvm-project/lldb/test/API/lang/cpp/std-function-recognizer/TestStdFunctionRecognizer.py", line 27, in test_backtrace self.expect( File "/b/s/w/ir/x/w/llvm-llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 2464, in expect self.fail(log_msg) AssertionError: Ran command: "thread backtrace -u" Got output: * thread #1, name = 'a.out', stop reason = breakpoint 1.1 * frame #0: 0x5593a2b1742a a.out`foo(x=1, y=1) at main.cpp:4:10 frame #1: 0x5593a2b17839 a.out`decltype(std::declval()(std::declval(), std::declval())) std::__2::__invoke[abi:ne20](__f=0x7ffd0bb64e90, __args=0x7ffd0bb64e04, __args=0x7ffd0bb64e00) at invoke.h:149:25 frame #2: 0x5593a2b17805 a.out`int std::__2::__invoke_void_return_wrapper::__call[abi:ne20](__args=0x7ffd0bb64e90, __args=0x7ffd0bb64e04, __args=0x7ffd0bb64e00) at invoke.h:216:12 frame #3: 0x5593a2b177d5 a.out`std::__2::__function::__default_alloc_func::operator()[abi:ne20](this=0x7ffd0bb64e90, __arg=0x7ffd0bb64e04, __arg=0x7ffd0bb64e00) at function.h:210:12 frame #4: 0x5593a2b1777b a.out`int std::__2::__function::__policy_invoker::__call_impl[abi:ne20]>(__buf=0x7ffd0bb64e90, __args=1, __args=1) at function.h:610:12 frame #5: 0x5593a2b178da a.out`std::__2::__function::__policy_func::operator()[abi:ne20](this=0x7ffd0bb64e90, __args=0x7ffd0bb64e54, __args=0x7ffd0bb64e50) const at function.h:716:12 frame #6: 0x5593a2b17513 a.out`std::__2::function::operator()(this=0x7ffd0bb64e90, __arg=1, __arg=1) const at function.h:989:10 frame #7: 0x5593a2b
[Lldb-commits] [lldb] Fix dap stacktrace perf issue (PR #104874)
@@ -3111,17 +3115,20 @@ void request_stackTrace(const llvm::json::Object
&request) {
// This will always return an invalid thread when
// libBacktraceRecording.dylib is not loaded or if there is no extended
// backtrace.
-lldb::SBThread queue_backtrace_thread =
-thread.GetExtendedBacktraceThread("libdispatch");
+lldb::SBThread queue_backtrace_thread;
+if (g_dap.enable_display_extended_backtrace)
+ queue_backtrace_thread =
thread.GetExtendedBacktraceThread("libdispatch");
if (queue_backtrace_thread.IsValid()) {
// One extra frame as a label to mark the enqueued thread.
totalFrames += queue_backtrace_thread.GetNumFrames() + 1;
}
// This will always return an invalid thread when there is no exception in
// the current thread.
-lldb::SBThread exception_backtrace_thread =
-thread.GetCurrentExceptionBacktrace();
+lldb::SBThread exception_backtrace_thread;
+if (g_dap.enable_display_extended_backtrace)
+ exception_backtrace_thread = thread.GetCurrentExceptionBacktrace();
ashgti wrote:
Maybe we should remove this from the stack trace and add this info to the
`exceptionInfo` request
(https://microsoft.github.io/debug-adapter-protocol/specification#Requests_ExceptionInfo)
there is a field for the stack trace in the exception details
(https://microsoft.github.io/debug-adapter-protocol/specification#Types_ExceptionDetails).
https://github.com/llvm/llvm-project/pull/104874
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] 19d3f34 - [lldb] Speculative fix for trap_frame_sym_ctx.test
Author: Adrian Prantl
Date: 2024-08-21T16:53:37-07:00
New Revision: 19d3f3417100dc99caa4394fbd26fc0c4702264e
URL:
https://github.com/llvm/llvm-project/commit/19d3f3417100dc99caa4394fbd26fc0c4702264e
DIFF:
https://github.com/llvm/llvm-project/commit/19d3f3417100dc99caa4394fbd26fc0c4702264e.diff
LOG: [lldb] Speculative fix for trap_frame_sym_ctx.test
Unfortunately I can't actually reproduce this locally.
Added:
Modified:
lldb/test/Shell/Unwind/trap_frame_sym_ctx.test
Removed:
diff --git a/lldb/test/Shell/Unwind/trap_frame_sym_ctx.test
b/lldb/test/Shell/Unwind/trap_frame_sym_ctx.test
index 1bf1fb1d6e85f9..08a26616240e68 100644
--- a/lldb/test/Shell/Unwind/trap_frame_sym_ctx.test
+++ b/lldb/test/Shell/Unwind/trap_frame_sym_ctx.test
@@ -15,7 +15,7 @@ breakpoint set -n bar
process launch
# CHECK: stop reason = breakpoint 1.1
-thread backtrace
+thread backtrace -u
# CHECK: frame #0: {{.*}}`bar
# CHECK: frame #1: {{.*}}`tramp
# CHECK: frame #2: {{.*}}`main
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Fix dap stacktrace perf issue (PR #104874)
@@ -3111,17 +3115,20 @@ void request_stackTrace(const llvm::json::Object
&request) {
// This will always return an invalid thread when
// libBacktraceRecording.dylib is not loaded or if there is no extended
// backtrace.
-lldb::SBThread queue_backtrace_thread =
-thread.GetExtendedBacktraceThread("libdispatch");
+lldb::SBThread queue_backtrace_thread;
+if (g_dap.enable_display_extended_backtrace)
+ queue_backtrace_thread =
thread.GetExtendedBacktraceThread("libdispatch");
if (queue_backtrace_thread.IsValid()) {
// One extra frame as a label to mark the enqueued thread.
totalFrames += queue_backtrace_thread.GetNumFrames() + 1;
}
// This will always return an invalid thread when there is no exception in
// the current thread.
-lldb::SBThread exception_backtrace_thread =
-thread.GetCurrentExceptionBacktrace();
+lldb::SBThread exception_backtrace_thread;
+if (g_dap.enable_display_extended_backtrace)
+ exception_backtrace_thread = thread.GetCurrentExceptionBacktrace();
walter-erquinigo wrote:
This seems like a better option. What do you think @jeffreytan81 ?
https://github.com/llvm/llvm-project/pull/104874
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Fix dap stacktrace perf issue (PR #104874)
@@ -3111,17 +3115,20 @@ void request_stackTrace(const llvm::json::Object
&request) {
// This will always return an invalid thread when
// libBacktraceRecording.dylib is not loaded or if there is no extended
// backtrace.
-lldb::SBThread queue_backtrace_thread =
-thread.GetExtendedBacktraceThread("libdispatch");
+lldb::SBThread queue_backtrace_thread;
+if (g_dap.enable_display_extended_backtrace)
+ queue_backtrace_thread =
thread.GetExtendedBacktraceThread("libdispatch");
if (queue_backtrace_thread.IsValid()) {
// One extra frame as a label to mark the enqueued thread.
totalFrames += queue_backtrace_thread.GetNumFrames() + 1;
}
// This will always return an invalid thread when there is no exception in
// the current thread.
-lldb::SBThread exception_backtrace_thread =
-thread.GetCurrentExceptionBacktrace();
+lldb::SBThread exception_backtrace_thread;
+if (g_dap.enable_display_extended_backtrace)
+ exception_backtrace_thread = thread.GetCurrentExceptionBacktrace();
jeffreytan81 wrote:
This sounds good to me.
@ashgti, feel free to create a PR on top of this one to remove the hot path out
of regular stepping code path.
https://github.com/llvm/llvm-project/pull/104874
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Fix dap stacktrace perf issue (PR #104874)
@@ -3111,17 +3115,20 @@ void request_stackTrace(const llvm::json::Object
&request) {
// This will always return an invalid thread when
// libBacktraceRecording.dylib is not loaded or if there is no extended
// backtrace.
-lldb::SBThread queue_backtrace_thread =
-thread.GetExtendedBacktraceThread("libdispatch");
+lldb::SBThread queue_backtrace_thread;
+if (g_dap.enable_display_extended_backtrace)
+ queue_backtrace_thread =
thread.GetExtendedBacktraceThread("libdispatch");
if (queue_backtrace_thread.IsValid()) {
// One extra frame as a label to mark the enqueued thread.
totalFrames += queue_backtrace_thread.GetNumFrames() + 1;
}
// This will always return an invalid thread when there is no exception in
// the current thread.
-lldb::SBThread exception_backtrace_thread =
-thread.GetCurrentExceptionBacktrace();
+lldb::SBThread exception_backtrace_thread;
+if (g_dap.enable_display_extended_backtrace)
+ exception_backtrace_thread = thread.GetCurrentExceptionBacktrace();
walter-erquinigo wrote:
Given that you are on this, why don't you give it a try, @jeffreytan81 ?
https://github.com/llvm/llvm-project/pull/104874
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] show dialog when executable is not found (PR #104711)
https://github.com/Da-Viper updated
https://github.com/llvm/llvm-project/pull/104711
>From 2cda519a06d46bd6a5ae02e8be8daacb39a49b3e Mon Sep 17 00:00:00 2001
From: Ezike Ebuka
Date: Thu, 22 Aug 2024 01:42:17 +0100
Subject: [PATCH] Rebase and add check dap path on config change
---
.../lldb-dap/src-ts/debug-adapter-factory.ts | 42 ++
lldb/tools/lldb-dap/src-ts/extension.ts | 43 ++-
2 files changed, 74 insertions(+), 11 deletions(-)
diff --git a/lldb/tools/lldb-dap/src-ts/debug-adapter-factory.ts
b/lldb/tools/lldb-dap/src-ts/debug-adapter-factory.ts
index 01c671f41ff782..8a8f441581b29e 100644
--- a/lldb/tools/lldb-dap/src-ts/debug-adapter-factory.ts
+++ b/lldb/tools/lldb-dap/src-ts/debug-adapter-factory.ts
@@ -14,10 +14,52 @@ export class LLDBDapDescriptorFactory
this.lldbDapOptions = lldbDapOptions;
}
+ public static async validateDebugAdapterPath(pathUri: vscode.Uri) {
+try {
+ const fileStats = await vscode.workspace.fs.stat(pathUri);
+ if (!(fileStats.type & vscode.FileType.File)) {
+this.showErrorMessage(pathUri.path);
+ }
+} catch (err) {
+ this.showErrorMessage(pathUri.path);
+}
+ }
+
async createDebugAdapterDescriptor(
session: vscode.DebugSession,
executable: vscode.DebugAdapterExecutable | undefined,
): Promise {
+const config = vscode.workspace.getConfiguration(
+ "lldb-dap",
+ session.workspaceFolder,
+);
+const customPath = config.get("executable-path");
+const path: string = customPath ? customPath : executable!!.command;
+
+await LLDBDapDescriptorFactory.validateDebugAdapterPath(
+ vscode.Uri.file(path),
+);
return this.lldbDapOptions.createDapExecutableCommand(session, executable);
}
+
+ /**
+ * Shows a message box when the debug adapter's path is not found
+ */
+ private static showErrorMessage(path: string) {
+const openSettingsAction = "Open Settings";
+vscode.window
+ .showErrorMessage(
+`Debug adapter path: ${path} is not a valid file`,
+{ modal: false },
+openSettingsAction,
+ )
+ .then((callBackValue) => {
+if (openSettingsAction === callBackValue) {
+ vscode.commands.executeCommand(
+"workbench.action.openSettings",
+"lldb-dap.executable-path",
+ );
+}
+ });
+ }
}
diff --git a/lldb/tools/lldb-dap/src-ts/extension.ts
b/lldb/tools/lldb-dap/src-ts/extension.ts
index 7df09f7a29dad7..12565a8fbe9a0a 100644
--- a/lldb/tools/lldb-dap/src-ts/extension.ts
+++ b/lldb/tools/lldb-dap/src-ts/extension.ts
@@ -14,26 +14,32 @@ function createDefaultLLDBDapOptions(): LLDBDapOptions {
session: vscode.DebugSession,
packageJSONExecutable: vscode.DebugAdapterExecutable | undefined,
): Promise {
- const config = vscode.workspace
-.getConfiguration("lldb-dap", session.workspaceFolder);
+ const config = vscode.workspace.getConfiguration(
+"lldb-dap",
+session.workspaceFolder,
+ );
const path = config.get("executable-path");
const log_path = config.get("log-path");
- let env : { [key: string]: string } = {};
+ let env: { [key: string]: string } = {};
if (log_path) {
env["LLDBDAP_LOG"] = log_path;
}
if (path) {
-return new vscode.DebugAdapterExecutable(path, [], {env});
+return new vscode.DebugAdapterExecutable(path, [], { env });
} else if (packageJSONExecutable) {
-return new
vscode.DebugAdapterExecutable(packageJSONExecutable.command,
packageJSONExecutable.args, {
- ...packageJSONExecutable.options,
- env: {
-...packageJSONExecutable.options?.env,
-...env
- }
-});
+return new vscode.DebugAdapterExecutable(
+ packageJSONExecutable.command,
+ packageJSONExecutable.args,
+ {
+...packageJSONExecutable.options,
+env: {
+ ...packageJSONExecutable.options?.env,
+ ...env,
+},
+ },
+);
} else {
return undefined;
}
@@ -58,6 +64,21 @@ export class LLDBDapExtension extends DisposableContext {
new LLDBDapDescriptorFactory(this.lldbDapOptions),
),
);
+
+this.pushSubscription(
+ vscode.workspace.onDidChangeConfiguration((event) => {
+if (event.affectsConfiguration("lldb-dap.executable-path")) {
+ const dapPath = vscode.workspace
+.getConfiguration("lldb-dap")
+.get("executable-path");
+ if (dapPath) {
+LLDBDapDescriptorFactory.validateDebugAdapterPath(
+ vscode.Uri.file(dapPath),
+);
+ }
+}
+ }),
+);
}
}
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-comm
[Lldb-commits] [lldb] [lldb-dap] show dialog when executable is not found (PR #104711)
https://github.com/walter-erquinigo approved this pull request. cool Don't forget to run `npm run format` before landing this https://github.com/llvm/llvm-project/pull/104711 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] show dialog when executable is not found (PR #104711)
Da-Viper wrote: > cool > > Don't forget to run `npm run format` before landing this Done https://github.com/llvm/llvm-project/pull/104711 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Mark hidden frames as "subtle" (PR #105457)
vogelsgesang wrote: @petrhosek this commit builds on top of #104523 and relies on the frame recognizer introduced as part of it. As soon as [your proposed solutions](https://github.com/llvm/llvm-project/pull/104523#issuecomment-2303287484) was addressed, the `subtleFrames` test case should also be passing. In case this turns out to be not the case, please ping me again https://github.com/llvm/llvm-project/pull/105457 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Implement value locations for function pointers (PR #104589)
@@ -0,0 +1,81 @@ +""" +Test lldb-dap locations request +""" + + +import dap_server +from lldbsuite.test.decorators import * +from lldbsuite.test.lldbtest import * +from lldbsuite.test import lldbutil +import lldbdap_testcase +import os + + +class TestDAP_locations(lldbdap_testcase.DAPTestCaseBase): +@skipIfWindows vogelsgesang wrote: this was a copy-paste mistake :/ https://github.com/llvm/llvm-project/pull/104589 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Implement value locations for function pointers (PR #104589)
https://github.com/vogelsgesang edited https://github.com/llvm/llvm-project/pull/104589 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Enabling instruction breakpoint support to lldb-dap. (PR #105278)
@@ -4046,6 +4048,181 @@ void request__testGetTargetBreakpoints(const
llvm::json::Object &request) {
g_dap.SendJSON(llvm::json::Value(std::move(response)));
}
+// SetInstructionBreakpoints request; value of command field is
+// 'setInstructionBreakpoints'. Replaces all existing instruction breakpoints.
+// Typically, instruction breakpoints would be set from a disassembly window.
To
+// clear all instruction breakpoints, specify an empty array. When an
+// instruction breakpoint is hit, a `stopped` event (with reason `instruction
+// breakpoint`) is generated. Clients should only call this request if the
+// corresponding capability `supportsInstructionBreakpoints` is true. interface
+// SetInstructionBreakpointsRequest extends Request {
+// command: 'setInstructionBreakpoints';
+// arguments: SetInstructionBreakpointsArguments;
+// }
+// interface SetInstructionBreakpointsArguments {
+// The instruction references of the breakpoints
+// breakpoints: InstructionBreakpoint[];
+// }
+// "InstructionBreakpoint ": {
+// "type": "object",
+// "description": "Properties of a breakpoint passed to the
+// setInstructionBreakpoints request.", "properties": {
+// "instructionReference": {
+// "type": "string",
+// "description": "The instruction reference of the breakpoint.
+// This should be a memory or instruction pointer reference from an
+// EvaluateResponse, Variable, StackFrame, GotoTarget, or Breakpoint."
+// },
+// "offset": {
+// "type": "number",
+// "description": "The offset from the instruction reference.
+// This can be negative."
+// },
+// "condition": {
+// "type": "string",
+// "description": "An expression for conditional breakpoints.
+// It is only honored by a debug adapter if the corresponding capability
+// supportsConditionalBreakpoints` is true."
+// },
+// "hitCondition": {
+// "type": "string",
+// "description": "An expression that controls how many hits of the
+// breakpoint are ignored. The debug adapter is expected to interpret the
+// expression as needed. The attribute is only honored by a debug adapter
+// if the corresponding capability `supportsHitConditionalBreakpoints` is
+// true."
+// },
+// }
+// interface SetInstructionBreakpointsResponse extends Response {
+// body: {
+// Information about the breakpoints. The array elements correspond to the
+// elements of the `breakpoints` array.
+// breakpoints: Breakpoint[];
+// };
+// }
vogelsgesang wrote:
we usually copy the JSON schema documentation into the comments, not the
TypeScript interface.
See
https://github.com/microsoft/debug-adapter-protocol/blob/main/debugAdapterProtocol.json
https://github.com/llvm/llvm-project/pull/105278
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Enabling instruction breakpoint support to lldb-dap. (PR #105278)
@@ -4078,6 +4255,9 @@ void RegisterRequestCallbacks() {
g_dap.RegisterRequestCallback("threads", request_threads);
g_dap.RegisterRequestCallback("variables", request_variables);
g_dap.RegisterRequestCallback("disassemble", request_disassemble);
+ // Instruction breapoint request
vogelsgesang wrote:
we also need to update the stopped event to use `reason: instruction
breakpoint` instead of `reason: breakpoint` in case we hit one of those
breakpoints
https://github.com/llvm/llvm-project/pull/105278
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Fix dap stacktrace perf issue (PR #104874)
@@ -3111,17 +3115,20 @@ void request_stackTrace(const llvm::json::Object
&request) {
// This will always return an invalid thread when
// libBacktraceRecording.dylib is not loaded or if there is no extended
// backtrace.
-lldb::SBThread queue_backtrace_thread =
-thread.GetExtendedBacktraceThread("libdispatch");
+lldb::SBThread queue_backtrace_thread;
+if (g_dap.enable_display_extended_backtrace)
+ queue_backtrace_thread =
thread.GetExtendedBacktraceThread("libdispatch");
if (queue_backtrace_thread.IsValid()) {
// One extra frame as a label to mark the enqueued thread.
totalFrames += queue_backtrace_thread.GetNumFrames() + 1;
}
// This will always return an invalid thread when there is no exception in
// the current thread.
-lldb::SBThread exception_backtrace_thread =
-thread.GetCurrentExceptionBacktrace();
+lldb::SBThread exception_backtrace_thread;
+if (g_dap.enable_display_extended_backtrace)
+ exception_backtrace_thread = thread.GetCurrentExceptionBacktrace();
jeffreytan81 wrote:
I don't have time to work on this. My goal is to quickly fix the performance
regression and unblock the business.
Frankly, the original PR should have been reverted initially, as it introduced
the regression.
The reasonable engineering process should involve landing this PR to disable
the performance regression. Then, the author of the original PR can fix it in
the desired way.
https://github.com/llvm/llvm-project/pull/104874
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Provide `declarationLocation` for variables (PR #102928)
@@ -0,0 +1,40 @@ +""" +Test lldb-dap locations request +""" + + +import dap_server +from lldbsuite.test.decorators import * +from lldbsuite.test.lldbtest import * +from lldbsuite.test import lldbutil +import lldbdap_testcase +import os + + +class TestDAP_locations(lldbdap_testcase.DAPTestCaseBase): +@skipIfWindows vogelsgesang wrote: copy-paste error :/ https://github.com/llvm/llvm-project/pull/102928 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Provide `declarationLocation` for variables (PR #102928)
https://github.com/vogelsgesang updated
https://github.com/llvm/llvm-project/pull/102928
>From 5bdcb821527bf67eead6c42825ea6e559ec749c3 Mon Sep 17 00:00:00 2001
From: Adrian Vogelsgesang
Date: Sat, 10 Aug 2024 23:59:55 +
Subject: [PATCH 1/2] [lldb-dap] Implement declaration locations
This commit implements support for the "declaration location" recently
added by microsoft/debug-adapter-protocol#494 to the debug adapter
protocol.
For the `declarationLocationReference` we need a variable ID similar to
the the `variablesReference`. I decided to simply reuse the
`variablesReference` here and renamed `Variables::expandable_variables`
and friends accordingly. Given that almost all variables have a
declaration location, we now assign those variable ids to all variables.
While `declarationLocationReference` effectively supersedes
`$__lldb_extensions.declaration`, I did not remove this extension, yet,
since I assume that there are some closed-source extensions which rely
on it.
I tested this against VS-Code Insiders. However, VS-Code Insiders
currently only supports `valueLoctionReference` and not
`declarationLocationReference`, yet. Locally, I hence published
the declaration locations as value locations, and VS Code Insiders
navigated to the expected places. Looking forward to proper VS Code
support for `declarationLocationReference`.
---
.../test/tools/lldb-dap/dap_server.py | 11 ++
.../API/tools/lldb-dap/locations/Makefile | 3 +
.../lldb-dap/locations/TestDAP_locations.py | 40 +
lldb/test/API/tools/lldb-dap/locations/main.c | 5 +
lldb/tools/lldb-dap/DAP.cpp | 17 +-
lldb/tools/lldb-dap/DAP.h | 10 +-
lldb/tools/lldb-dap/JSONUtils.cpp | 125 ---
lldb/tools/lldb-dap/JSONUtils.h | 31 ++--
lldb/tools/lldb-dap/lldb-dap.cpp | 146 +++---
9 files changed, 286 insertions(+), 102 deletions(-)
create mode 100644 lldb/test/API/tools/lldb-dap/locations/Makefile
create mode 100644 lldb/test/API/tools/lldb-dap/locations/TestDAP_locations.py
create mode 100644 lldb/test/API/tools/lldb-dap/locations/main.c
diff --git a/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
b/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
index 874383a13e2bb6..01ff79ee430902 100644
--- a/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
+++ b/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
@@ -1083,6 +1083,17 @@ def request_setVariable(self, containingVarRef, name,
value, id=None):
}
return self.send_recv(command_dict)
+def request_locations(self, locationReference):
+args_dict = {
+"locationReference": locationReference,
+}
+command_dict = {
+"command": "locations",
+"type": "request",
+"arguments": args_dict,
+}
+return self.send_recv(command_dict)
+
def request_testGetTargetBreakpoints(self):
"""A request packet used in the LLDB test suite to get all currently
set breakpoint infos for all breakpoints currently set in the
diff --git a/lldb/test/API/tools/lldb-dap/locations/Makefile
b/lldb/test/API/tools/lldb-dap/locations/Makefile
new file mode 100644
index 00..10495940055b63
--- /dev/null
+++ b/lldb/test/API/tools/lldb-dap/locations/Makefile
@@ -0,0 +1,3 @@
+C_SOURCES := main.c
+
+include Makefile.rules
diff --git a/lldb/test/API/tools/lldb-dap/locations/TestDAP_locations.py
b/lldb/test/API/tools/lldb-dap/locations/TestDAP_locations.py
new file mode 100644
index 00..76d938d3908492
--- /dev/null
+++ b/lldb/test/API/tools/lldb-dap/locations/TestDAP_locations.py
@@ -0,0 +1,40 @@
+"""
+Test lldb-dap locations request
+"""
+
+
+import dap_server
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+import lldbdap_testcase
+import os
+
+
+class TestDAP_locations(lldbdap_testcase.DAPTestCaseBase):
+@skipIfWindows
+def test_locations(self):
+"""
+Tests the 'locations' request.
+"""
+program = self.getBuildArtifact("a.out")
+self.build_and_launch(program)
+source = "main.c"
+self.source_path = os.path.join(os.getcwd(), source)
+self.set_source_breakpoints(
+source,
+[line_number(source, "// BREAK HERE")],
+)
+self.continue_to_next_stop()
+
+locals = {l["name"]: l for l in self.dap_server.get_local_variables()}
+
+# var1 has a declarationLocation but no valueLocation
+self.assertIn("declarationLocationReference", locals["var1"].keys())
+self.assertNotIn("valueLocationReference", locals["var1"].keys())
+loc_var1 = self.dap_server.request_locations(
+locals["var1"]["declarationLocationReference"]
+)
+self.assertTrue(loc_var1["success"])
+sel
[Lldb-commits] [lldb] Skip the lldb-dap output test on windows, it seems all the lldb-dap tests are disabled on windows. (PR #105604)
https://github.com/ashgti created
https://github.com/llvm/llvm-project/pull/105604
This should fix https://lab.llvm.org/buildbot/#/builders/141/builds/1747
>From 54dcc78eace39c197f1fb762880746b569980955 Mon Sep 17 00:00:00 2001
From: John Harrison
Date: Wed, 21 Aug 2024 18:22:17 -0700
Subject: [PATCH] Skip the lldb-dap output test on windows, it seems all the
lldb-dap tests are disabled on windows.
---
lldb/test/API/tools/lldb-dap/output/TestDAP_output.py | 1 +
1 file changed, 1 insertion(+)
diff --git a/lldb/test/API/tools/lldb-dap/output/TestDAP_output.py
b/lldb/test/API/tools/lldb-dap/output/TestDAP_output.py
index 0d40ce993dc31c..02c34ba10321bd 100644
--- a/lldb/test/API/tools/lldb-dap/output/TestDAP_output.py
+++ b/lldb/test/API/tools/lldb-dap/output/TestDAP_output.py
@@ -8,6 +8,7 @@
class TestDAP_output(lldbdap_testcase.DAPTestCaseBase):
+@skipIfWindows
def test_output(self):
program = self.getBuildArtifact("a.out")
self.build_and_launch(program)
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Skip the lldb-dap output test on windows, it seems all the lldb-dap tests are disabled on windows. (PR #105604)
https://github.com/ashgti edited https://github.com/llvm/llvm-project/pull/105604 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Skip the lldb-dap output test on windows, it seems all the lldb-dap tests are disabled on windows. (PR #105604)
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: John Harrison (ashgti)
Changes
This should fix https://lab.llvm.org/buildbot/#/builders/141/builds/1747
---
Full diff: https://github.com/llvm/llvm-project/pull/105604.diff
1 Files Affected:
- (modified) lldb/test/API/tools/lldb-dap/output/TestDAP_output.py (+1)
``diff
diff --git a/lldb/test/API/tools/lldb-dap/output/TestDAP_output.py
b/lldb/test/API/tools/lldb-dap/output/TestDAP_output.py
index 0d40ce993dc31c..02c34ba10321bd 100644
--- a/lldb/test/API/tools/lldb-dap/output/TestDAP_output.py
+++ b/lldb/test/API/tools/lldb-dap/output/TestDAP_output.py
@@ -8,6 +8,7 @@
class TestDAP_output(lldbdap_testcase.DAPTestCaseBase):
+@skipIfWindows
def test_output(self):
program = self.getBuildArtifact("a.out")
self.build_and_launch(program)
``
https://github.com/llvm/llvm-project/pull/105604
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Fix dap stacktrace perf issue (PR #104874)
@@ -3111,17 +3115,20 @@ void request_stackTrace(const llvm::json::Object
&request) {
// This will always return an invalid thread when
// libBacktraceRecording.dylib is not loaded or if there is no extended
// backtrace.
-lldb::SBThread queue_backtrace_thread =
-thread.GetExtendedBacktraceThread("libdispatch");
+lldb::SBThread queue_backtrace_thread;
+if (g_dap.enable_display_extended_backtrace)
+ queue_backtrace_thread =
thread.GetExtendedBacktraceThread("libdispatch");
if (queue_backtrace_thread.IsValid()) {
// One extra frame as a label to mark the enqueued thread.
totalFrames += queue_backtrace_thread.GetNumFrames() + 1;
}
// This will always return an invalid thread when there is no exception in
// the current thread.
-lldb::SBThread exception_backtrace_thread =
-thread.GetCurrentExceptionBacktrace();
+lldb::SBThread exception_backtrace_thread;
+if (g_dap.enable_display_extended_backtrace)
+ exception_backtrace_thread = thread.GetCurrentExceptionBacktrace();
walter-erquinigo wrote:
🤷
This been broken for a year, and now you are "rushing". You could as well do a
proper fix that works for your company and for everyone else, but well,
probably the open source community is not a priority for you.
https://github.com/llvm/llvm-project/pull/104874
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Skip the lldb-dap output test on windows, it seems all the lldb-dap tests are disabled on windows. (PR #105604)
https://github.com/walter-erquinigo approved this pull request. https://github.com/llvm/llvm-project/pull/105604 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Fix dap stacktrace perf issue (PR #104874)
@@ -3111,17 +3115,20 @@ void request_stackTrace(const llvm::json::Object
&request) {
// This will always return an invalid thread when
// libBacktraceRecording.dylib is not loaded or if there is no extended
// backtrace.
-lldb::SBThread queue_backtrace_thread =
-thread.GetExtendedBacktraceThread("libdispatch");
+lldb::SBThread queue_backtrace_thread;
+if (g_dap.enable_display_extended_backtrace)
+ queue_backtrace_thread =
thread.GetExtendedBacktraceThread("libdispatch");
if (queue_backtrace_thread.IsValid()) {
// One extra frame as a label to mark the enqueued thread.
totalFrames += queue_backtrace_thread.GetNumFrames() + 1;
}
// This will always return an invalid thread when there is no exception in
// the current thread.
-lldb::SBThread exception_backtrace_thread =
-thread.GetCurrentExceptionBacktrace();
+lldb::SBThread exception_backtrace_thread;
+if (g_dap.enable_display_extended_backtrace)
+ exception_backtrace_thread = thread.GetCurrentExceptionBacktrace();
jeffreytan81 wrote:
I do not understand why you are judging people. Everyone has their own priority
and focus. I am doing a favor here to fix a serious performance regression for
the community. Please be respectful in communication.
https://github.com/llvm/llvm-project/pull/104874
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Fix dap stacktrace perf issue (PR #104874)
https://github.com/walter-erquinigo approved this pull request. I'm approving this to unblock. https://github.com/llvm/llvm-project/pull/104874 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] show dialog when executable is not found (PR #104711)
https://github.com/vogelsgesang approved this pull request. Looks good to me! Thanks for this amazing usability improvement! If this would have existed the first time I tried this extension, it would have saved me a lot of time https://github.com/llvm/llvm-project/pull/104711 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
