[Lldb-commits] [lldb] [lldb][debugserver] Read/write SME registers on arm64 (PR #119171)
@@ -93,6 +93,55 @@ DNBArchMachARM64::SoftwareBreakpointOpcode(nub_size_t
byte_size) {
uint32_t DNBArchMachARM64::GetCPUType() { return CPU_TYPE_ARM64; }
+static std::once_flag g_cpu_has_sme_once;
+bool DNBArchMachARM64::CPUHasSME() {
+ static bool g_has_sme = false;
+ std::call_once(g_cpu_has_sme_once, []() {
+int ret = 0;
+size_t size = sizeof(ret);
+if (sysctlbyname("hw.optional.arm.FEAT_SME", &ret, &size, NULL, 0) != -1)
+ g_has_sme = ret == 1;
+ });
+ return g_has_sme;
+}
+
+static std::once_flag g_cpu_has_sme2_once;
+bool DNBArchMachARM64::CPUHasSME2() {
+ static bool g_has_sme2 = false;
+ std::call_once(g_cpu_has_sme2_once, []() {
+int ret = 0;
+size_t size = sizeof(ret);
+if (sysctlbyname("hw.optional.arm.FEAT_SME2", &ret, &size, NULL, 0) != -1)
+ g_has_sme2 = ret == 1;
+ });
+ return g_has_sme2;
+}
+
+static std::once_flag g_sme_max_svl_once;
+unsigned int DNBArchMachARM64::GetSMEMaxSVL() {
+ static unsigned int g_sme_max_svl = 0;
+ std::call_once(g_sme_max_svl_once, []() {
+if (CPUHasSME()) {
+ unsigned int ret = 0;
+ size_t size = sizeof(ret);
+ if (sysctlbyname("hw.optional.arm.sme_max_svl_b", &ret, &size, NULL, 0)
!=
+ -1)
+g_sme_max_svl = ret;
+ else
+g_sme_max_svl = get_svl_bytes();
+}
+ });
+ return g_sme_max_svl;
+}
+
+// This function can only be called on systems with hw.optional.arm.FEAT_SME
+// It will return the maximum SVL length for this process.
+uint16_t __attribute__((target("sme"))) DNBArchMachARM64::get_svl_bytes(void) {
+ uint64_t ret = 0;
+ asm volatile("rdsvl %[ret], #1" : [ret] "=r"(ret));
jasonmolenda wrote:
I had to install a newer kernel with the newly added sysctl to test & confirm
that the sysctl works. I'll remove the "read debugserver's max SVL and use it"
fallback.
https://github.com/llvm/llvm-project/pull/119171
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][debugserver] Read/write SME registers on arm64 (PR #119171)
@@ -312,16 +312,21 @@ struct DNBRegisterValue {
uint64_t uint64;
float float32;
double float64;
-int8_t v_sint8[64];
-int16_t v_sint16[32];
-int32_t v_sint32[16];
-int64_t v_sint64[8];
-uint8_t v_uint8[64];
-uint16_t v_uint16[32];
-uint32_t v_uint32[16];
-uint64_t v_uint64[8];
-float v_float32[16];
-double v_float64[8];
+// AArch64 SME's ZA register max size is 64k, this object must be
+// large enough to hold that much data. The current Apple cores
+// have a much smaller maximum ZA reg size, but there are not
+// multiple copies of this object so increase the static size to
+// maximum possible.
jasonmolenda wrote:
I looked at the `DNBRegisterValue` use a little more, and I think I want to
change it to a heap allocated object, but it's going to touch all of the arch
plugins in debugserver, so I will do it as a separate change from this one. On
the macOS environment, the single 64k register on the stack isn't blowing
anything, but it's not ideal and could cause a problem in our more constrained
environments.
https://github.com/llvm/llvm-project/pull/119171
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [clang] [clang-tools-extra] [lld] [lldb] [llvm] Rework the `Option` library to reduce dynamic relocations (PR #119198)
@@ -53,10 +53,8 @@ class OptTable {
public:
/// Entry for a single option instance in the option data table.
struct Info {
-/// A null terminated array of prefix strings to apply to name while
-/// matching.
-ArrayRef Prefixes;
-StringLiteral PrefixedName;
+unsigned PrefixesOffset;
chandlerc wrote:
FWIW, I put together a simple abstraction here:
https://github.com/llvm/llvm-project/pull/119488
Happy for suggestions on a stronger one, a different API, etc.
My preference would be to land independently and then connect. But if you'd
like to see one or the other land first and roll in, let me know.
https://github.com/llvm/llvm-project/pull/119198
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][debugserver] Read/write SME registers on arm64 (PR #119171)
@@ -0,0 +1,163 @@
+import lldb
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test.decorators import *
+import lldbsuite.test.lldbutil as lldbutil
+import os
+
+
+class TestSMERegistersDarwin(TestBase):
+NO_DEBUG_INFO_TESTCASE = True
+mydir = TestBase.compute_mydir(__file__)
+
+@skipIfRemote
+@skipUnlessDarwin
+@skipUnlessFeature("hw.optional.arm.FEAT_SME")
+@skipUnlessFeature("hw.optional.arm.FEAT_SME2")
+# thread_set_state/thread_get_state only avail in macOS 15.4+
+@skipIf(macos_version=["<", "15.4"])
+def test(self):
+"""Test that we can read the contents of the SME/SVE registers on
Darwin"""
+self.build()
+(target, process, thread, bkpt) = lldbutil.run_to_source_breakpoint(
+self, "break here", lldb.SBFileSpec("main.c")
+)
+frame = thread.GetFrameAtIndex(0)
+self.assertTrue(frame.IsValid())
+
+if self.TraceOn():
+self.runCmd("reg read -a")
+
+svl_reg = frame.register["svl"]
+svl = svl_reg.GetValueAsUnsigned()
+
+# SSVE and SME modes should be enabled (reflecting PSTATE.SM and
PSTATE.ZA)
+svcr = frame.register["svcr"]
+self.assertEqual(svcr.GetValueAsUnsigned(), 3)
+
+z0 = frame.register["z0"]
+self.assertEqual(z0.GetNumChildren(), svl)
+self.assertEqual(z0.GetChildAtIndex(0).GetValueAsUnsigned(), 0x1)
+self.assertEqual(z0.GetChildAtIndex(svl - 1).GetValueAsUnsigned(), 0x1)
+
+z31 = frame.register["z31"]
+self.assertEqual(z31.GetNumChildren(), svl)
+self.assertEqual(z31.GetChildAtIndex(0).GetValueAsUnsigned(), 32)
+self.assertEqual(z31.GetChildAtIndex(svl - 1).GetValueAsUnsigned(), 32)
+
+p0 = frame.register["p0"]
+self.assertEqual(p0.GetNumChildren(), svl / 8)
+self.assertEqual(p0.GetChildAtIndex(0).GetValueAsUnsigned(), 0xFF)
+self.assertEqual(
+p0.GetChildAtIndex(p0.GetNumChildren() - 1).GetValueAsUnsigned(),
0xFF
+)
+
+p15 = frame.register["p15"]
+self.assertEqual(p15.GetNumChildren(), svl / 8)
+self.assertEqual(p15.GetChildAtIndex(0).GetValueAsUnsigned(), 0xFF)
+self.assertEqual(
+p15.GetChildAtIndex(p15.GetNumChildren() -
1).GetValueAsUnsigned(), 0xFF
+)
+
+za = frame.register["za"]
+self.assertEqual(za.GetNumChildren(), (svl * svl))
+za_0 = za.GetChildAtIndex(0)
+self.assertEqual(za_0.GetValueAsUnsigned(), 4)
+za_final = za.GetChildAtIndex(za.GetNumChildren() - 1)
+self.assertEqual(za_final.GetValueAsUnsigned(), 67)
+
+zt0 = frame.register["zt0"]
+self.assertEqual(zt0.GetNumChildren(), 64)
+zt0_0 = zt0.GetChildAtIndex(0)
+self.assertEqual(zt0_0.GetValueAsUnsigned(), 0)
+zt0_final = zt0.GetChildAtIndex(63)
+self.assertEqual(zt0_final.GetValueAsUnsigned(), 63)
+
+z0_old_values = []
+z0_new_str = '"{'
+for i in range(svl):
+z0_old_values.append(z0.GetChildAtIndex(i).GetValueAsUnsigned())
+z0_new_str = z0_new_str + ("0x%02x " % (z0_old_values[i] + 5))
+z0_new_str = z0_new_str + '}"'
+self.runCmd("reg write z0 %s" % z0_new_str)
+
+z31_old_values = []
+z31_new_str = '"{'
+for i in range(svl):
+z31_old_values.append(z31.GetChildAtIndex(i).GetValueAsUnsigned())
+z31_new_str = z31_new_str + ("0x%02x " % (z31_old_values[i] + 3))
+z31_new_str = z31_new_str + '}"'
+self.runCmd("reg write z31 %s" % z31_new_str)
+
+p0_old_values = []
+p0_new_str = '"{'
+for i in range(int(svl / 8)):
+p0_old_values.append(p0.GetChildAtIndex(i).GetValueAsUnsigned())
+p0_new_str = p0_new_str + ("0x%02x " % (p0_old_values[i] - 5))
+p0_new_str = p0_new_str + '}"'
+self.runCmd("reg write p0 %s" % p0_new_str)
+
+p15_old_values = []
+p15_new_str = '"{'
+for i in range(int(svl / 8)):
+p15_old_values.append(p15.GetChildAtIndex(i).GetValueAsUnsigned())
+p15_new_str = p15_new_str + ("0x%02x " % (p15_old_values[i] - 8))
+p15_new_str = p15_new_str + '}"'
+self.runCmd("reg write p15 %s" % p15_new_str)
+
+za_old_values = []
+za_new_str = '"{'
+for i in range(svl * svl):
+za_old_values.append(za.GetChildAtIndex(i).GetValueAsUnsigned())
+za_new_str = za_new_str + ("0x%02x " % (za_old_values[i] + 7))
+za_new_str = za_new_str + '}"'
+self.runCmd("reg write za %s" % za_new_str)
+
+zt0_old_values = []
+zt0_new_str = '"{'
+for i in range(64):
+zt0_old_values.append(zt0.GetChildAtIndex(i).GetValueAsUnsigned())
+zt0_new_str = zt0_new_str + ("0x%02x " % (zt0_old_values[i] + 2))
+zt0_new_str = zt0_new_str + '}"'
+self.runCmd("reg writ
[Lldb-commits] [lldb] [lldb] Add ability to rate-limit progress reports (PR #119377)
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 ce7771902dc50d900de639d499a60486b83f70e0
a5aced42bb0742d44f5fdae51b77c291c95da340 --extensions cpp,h --
lldb/include/lldb/Core/Progress.h lldb/source/Core/Progress.cpp
lldb/source/Plugins/SymbolFile/DWARF/ManualDWARFIndex.cpp
lldb/unittests/Core/ProgressReportTest.cpp
``
View the diff from clang-format here.
``diff
diff --git a/lldb/source/Core/Progress.cpp b/lldb/source/Core/Progress.cpp
index 14b05a3d96..ed8dfb8563 100644
--- a/lldb/source/Core/Progress.cpp
+++ b/lldb/source/Core/Progress.cpp
@@ -89,7 +89,6 @@ void Progress::Increment(uint64_t amount,
std::memory_order_relaxed));
}
-
std::lock_guard guard(m_mutex);
if (updated_detail)
m_details = std::move(updated_detail.value());
diff --git a/lldb/unittests/Core/ProgressReportTest.cpp
b/lldb/unittests/Core/ProgressReportTest.cpp
index e99b1b84a2..7e745c1e9c 100644
--- a/lldb/unittests/Core/ProgressReportTest.cpp
+++ b/lldb/unittests/Core/ProgressReportTest.cpp
@@ -313,7 +313,6 @@ TEST_F(ProgressReportTest, TestMinimumReportTime) {
ASSERT_FALSE(listener_sp->GetEvent(event_sp, TIMEOUT));
}
-
TEST_F(ProgressReportTest, TestProgressManager) {
ListenerSP listener_sp =
CreateListenerFor(lldb::eBroadcastBitProgressCategory);
``
https://github.com/llvm/llvm-project/pull/119377
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add ability to rate-limit progress reports (PR #119377)
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Pavel Labath (labath)
Changes
For high-frequency multithreaded progress reports, the contention of taking the
progress mutex and the overhead of generating event can significantly slow down
the operation whose progress we are reporting.
This patch adds an (optional) capability to rate-limit them. It's optional
because this approach has one drawback: if the progress reporting has a pattern
where it generates a burst of activity and then blocks (without reporting
anything) for a large amount of time, it can appear as if less progress was
made that it actually was (because we only reported the first event from the
burst and dropped the other ones).
I've also made a small refactor of the Progress class to better distinguish
between const (don't need protection), atomic (are used on the hot path) and
other (need mutex protection) members.
---
Full diff: https://github.com/llvm/llvm-project/pull/119377.diff
4 Files Affected:
- (modified) lldb/include/lldb/Core/Progress.h (+26-13)
- (modified) lldb/source/Core/Progress.cpp (+53-30)
- (modified) lldb/source/Plugins/SymbolFile/DWARF/ManualDWARFIndex.cpp (+2-1)
- (modified) lldb/unittests/Core/ProgressReportTest.cpp (+106)
``diff
diff --git a/lldb/include/lldb/Core/Progress.h
b/lldb/include/lldb/Core/Progress.h
index 421e435a9e685a..f6cea282842e1c 100644
--- a/lldb/include/lldb/Core/Progress.h
+++ b/lldb/include/lldb/Core/Progress.h
@@ -10,6 +10,7 @@
#define LLDB_CORE_PROGRESS_H
#include "lldb/Host/Alarm.h"
+#include "lldb/Utility/Timeout.h"
#include "lldb/lldb-forward.h"
#include "lldb/lldb-types.h"
#include "llvm/ADT/StringMap.h"
@@ -81,7 +82,8 @@ class Progress {
/// progress is to be reported only to specific debuggers.
Progress(std::string title, std::string details = {},
std::optional total = std::nullopt,
- lldb_private::Debugger *debugger = nullptr);
+ lldb_private::Debugger *debugger = nullptr,
+ Timeout minimum_report_time = std::nullopt);
/// Destroy the progress object.
///
@@ -121,21 +123,32 @@ class Progress {
private:
void ReportProgress();
static std::atomic g_id;
- /// More specific information about the current file being displayed in the
- /// report.
- std::string m_details;
- /// How much work ([0...m_total]) that has been completed.
- uint64_t m_completed;
+
/// Total amount of work, use a std::nullopt in the constructor for non
/// deterministic progress.
- uint64_t m_total;
- std::mutex m_mutex;
- /// Set to true when progress has been reported where m_completed == m_total
- /// to ensure that we don't send progress updates after progress has
- /// completed.
- bool m_complete = false;
+ const uint64_t m_total;
+
+ // Minimum amount of time between two progress reports.
+ const Timeout m_minimum_report_time;
+
/// Data needed by the debugger to broadcast a progress event.
- ProgressData m_progress_data;
+ const ProgressData m_progress_data;
+
+ /// How much work ([0...m_total]) that has been completed.
+ std::atomic m_completed = 0;
+
+ /// Time (in nanoseconds since epoch) of the last progress report.
+ std::atomic m_last_report_time_ns;
+
+ /// Guards non-const non-atomic members of the class.
+ std::mutex m_mutex;
+
+ /// More specific information about the current file being displayed in the
+ /// report.
+ std::string m_details;
+
+ /// The "completed" value of the last reported event.
+ std::optional m_prev_completed;
};
/// A class used to group progress reports by category. This is done by using a
diff --git a/lldb/source/Core/Progress.cpp b/lldb/source/Core/Progress.cpp
index c9a556472c06b6..14b05a3d96ab43 100644
--- a/lldb/source/Core/Progress.cpp
+++ b/lldb/source/Core/Progress.cpp
@@ -11,7 +11,8 @@
#include "lldb/Core/Debugger.h"
#include "lldb/Utility/StreamString.h"
#include "llvm/Support/Signposts.h"
-
+#include
+#include
#include
#include
#include
@@ -26,17 +27,18 @@ static llvm::ManagedStatic
g_progress_signposts;
Progress::Progress(std::string title, std::string details,
std::optional total,
- lldb_private::Debugger *debugger)
-: m_details(details), m_completed(0),
- m_total(Progress::kNonDeterministicTotal),
+ lldb_private::Debugger *debugger,
+ Timeout minimum_report_time)
+: m_total(total.value_or(Progress::kNonDeterministicTotal)),
+ m_minimum_report_time(minimum_report_time),
m_progress_data{title, ++g_id,
- /*m_progress_data.debugger_id=*/std::nullopt} {
- if (total)
-m_total = *total;
-
- if (debugger)
-m_progress_data.debugger_id = debugger->GetID();
-
+ debugger ? std::optional(debugger->GetID())
+ : std::nullopt},
+ m_last_report_time_ns(
+ std::chrono::nanoseconds(
+ std::chrono::steady_clock::now().t
[Lldb-commits] [lldb] [lldb] Reduce the frequency of DWARF index progress reporting (PR #118953)
labath wrote:
> I would like to say I would love for this improvement to land :).
>
> I have observed that on Windows with a fair number (4K+) of small compile
> units the progress reporting completely dominates indexing time due to
> contention (presumably not just in the lock but also the IO layers), to the
> point that disabling it resulted in **very** large speedups (an operation
> which previously took 5s+ now was almost instant).
Thanks. I think that in your case we're limited by the speed of console updates
rather than the progress mutex. We've gotten similar reports for high ("high")
latency ssh connections and unusual console setups, and that's the angle I've
started working this from before I realized the it was bottlenecking the
parallelism. If you have some time, I'd be grateful if you could test this
patch out. The thing want the see is whether this completely resolves your
issue or if you still see a difference between disabled&enabled progress
reports. The reason I'm asking that is that I have a prototype which should
specifically help with the slow console issue, and I'm wondering if that is
necessary, or if this patch is sufficient.
https://github.com/llvm/llvm-project/pull/118953
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Reduce the frequency of DWARF index progress reporting (PR #118953)
labath wrote: > this patch or the other patch (https://github.com/llvm/llvm-project/pull/119377). Either is fine for the thing I want to see. https://github.com/llvm/llvm-project/pull/118953 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Implement a formatter bytecode interpreter in C++ (PR #114333)
@@ -0,0 +1,41 @@
+// A bare-bones llvm::Optional reimplementation.
+
+template struct MyOptionalStorage {
+ MyOptionalStorage(T val) : value(val), hasVal(true) {}
+ MyOptionalStorage() {}
+ T value;
+ bool hasVal = false;
+};
+
+template struct MyOptional {
+ MyOptionalStorage Storage;
+ MyOptional(T val) : Storage(val) {}
+ MyOptional() {}
+ T &operator*() { return Storage.value; }
+};
+
+void stop() {}
+
+int main(int argc, char **argv) {
+ MyOptional x, y = 42;
+ stop(); // break here
+ return *y;
+}
+
+__attribute__((used, section("__DATA_CONST,__lldbformatters"))) unsigned char
+_MyOptional_type_summary[] =
+"\x01" // version
+"\xa4" // record size
+"\x01" // record size
+"\x10" // type name size
+"^MyOptional<.+>$" // type name
+"\x00" // flags
+"\x00" // sig_summary
+"\x8d" // program size
+"\x01" // program size
+"\x1\x22\x7Storage#\x12\x60\x1,C\x10\x1\x5\x11\x2\x1\x22\x6hasVal#"
+"\x12\x60\x1,\x10\x1e\x2\x22\x1b\x10G#!\x60
"
+"\x0P\x10\x6\x22\x4None\x10\x36\x1#\x15\x60 "
+"\x0#\x16\x60\x5\x22\x5value#\x12\x60\x5#\x17\x60\x1,"
+"\x10\x6\x22\x4None\x10\x11\x1#\x0\x60\x1#R\x60\x10\x3# "
+"\x60\x10\x1\x2\x12\x12\x12\x12"; // summary function
kastiglione wrote:
did you write this with assembly? could you include that in the tests? It'll be
hard to modify such tests if we have to work with the bytecode directly.
https://github.com/llvm/llvm-project/pull/114333
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Implement a formatter bytecode interpreter in C++ (PR #114333)
https://github.com/adrian-prantl updated
https://github.com/llvm/llvm-project/pull/114333
>From 1a650fde4a885420c6f2991b41039c4b16ff42e1 Mon Sep 17 00:00:00 2001
From: Dave Lee
Date: Wed, 24 Jan 2024 12:42:45 -0800
Subject: [PATCH 1/2] [lldb] Load embedded type summary section (#7859) (#8040)
Add support for type summaries embedded into the binary.
These embedded summaries will typically be generated by Swift macros,
but can also be generated by any other means.
rdar://115184658
---
lldb/include/lldb/lldb-enumerations.h | 1 +
lldb/source/Core/Section.cpp | 3 +
.../Plugins/ObjectFile/ELF/ObjectFileELF.cpp | 1 +
.../ObjectFile/Mach-O/ObjectFileMachO.cpp | 4 +
.../ObjectFile/PECOFF/ObjectFilePECOFF.cpp| 1 +
lldb/source/Symbol/ObjectFile.cpp | 1 +
lldb/source/Target/Target.cpp | 74 +++
.../data-formatter/embedded-summary/Makefile | 2 +
.../TestEmbeddedTypeSummary.py| 12 +++
.../data-formatter/embedded-summary/main.c| 22 ++
10 files changed, 121 insertions(+)
create mode 100644
lldb/test/API/functionalities/data-formatter/embedded-summary/Makefile
create mode 100644
lldb/test/API/functionalities/data-formatter/embedded-summary/TestEmbeddedTypeSummary.py
create mode 100644
lldb/test/API/functionalities/data-formatter/embedded-summary/main.c
diff --git a/lldb/include/lldb/lldb-enumerations.h
b/lldb/include/lldb/lldb-enumerations.h
index a9a66ea2662f39..e00ec7f17c5cb8 100644
--- a/lldb/include/lldb/lldb-enumerations.h
+++ b/lldb/include/lldb/lldb-enumerations.h
@@ -763,6 +763,7 @@ enum SectionType {
eSectionTypeDWARFDebugLocListsDwo,
eSectionTypeDWARFDebugTuIndex,
eSectionTypeCTF,
+ eSectionTypeLLDBTypeSummaries,
eSectionTypeSwiftModules,
};
diff --git a/lldb/source/Core/Section.cpp b/lldb/source/Core/Section.cpp
index 0763e88d4608f4..ee01b4ce06ca1e 100644
--- a/lldb/source/Core/Section.cpp
+++ b/lldb/source/Core/Section.cpp
@@ -147,6 +147,8 @@ const char *Section::GetTypeAsCString() const {
return "dwarf-gnu-debugaltlink";
case eSectionTypeCTF:
return "ctf";
+ case eSectionTypeLLDBTypeSummaries:
+return "lldb-type-summaries";
case eSectionTypeOther:
return "regular";
case eSectionTypeSwiftModules:
@@ -457,6 +459,7 @@ bool Section::ContainsOnlyDebugInfo() const {
case eSectionTypeDWARFAppleObjC:
case eSectionTypeDWARFGNUDebugAltLink:
case eSectionTypeCTF:
+ case eSectionTypeLLDBTypeSummaries:
case eSectionTypeSwiftModules:
return true;
}
diff --git a/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
b/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
index eac9ab4577d3eb..a8249cf103833e 100644
--- a/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
+++ b/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
@@ -1696,6 +1696,7 @@ static SectionType GetSectionTypeFromName(llvm::StringRef
Name) {
.Case(".gnu_debugaltlink", eSectionTypeDWARFGNUDebugAltLink)
.Case(".gosymtab", eSectionTypeGoSymtab)
.Case(".text", eSectionTypeCode)
+ .Case(".lldbsummaries", lldb::eSectionTypeLLDBTypeSummaries)
.Case(".swift_ast", eSectionTypeSwiftModules)
.Default(eSectionTypeOther);
}
diff --git a/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
b/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
index daffa1379fe575..7e17fd8c53cd01 100644
--- a/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
+++ b/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
@@ -1209,6 +1209,7 @@ AddressClass
ObjectFileMachO::GetAddressClass(lldb::addr_t file_addr) {
case eSectionTypeDWARFAppleObjC:
case eSectionTypeDWARFGNUDebugAltLink:
case eSectionTypeCTF:
+case eSectionTypeLLDBTypeSummaries:
case eSectionTypeSwiftModules:
return AddressClass::eDebug;
@@ -1484,6 +1485,7 @@ static lldb::SectionType GetSectionType(uint32_t flags,
static ConstString g_sect_name_data("__data");
static ConstString g_sect_name_go_symtab("__gosymtab");
static ConstString g_sect_name_ctf("__ctf");
+ static ConstString g_sect_name_lldb_summaries("__lldbsummaries");
static ConstString g_sect_name_swift_ast("__swift_ast");
if (section_name == g_sect_name_dwarf_debug_abbrev)
@@ -1564,6 +1566,8 @@ static lldb::SectionType GetSectionType(uint32_t flags,
return eSectionTypeGoSymtab;
if (section_name == g_sect_name_ctf)
return eSectionTypeCTF;
+ if (section_name == g_sect_name_lldb_summaries)
+return lldb::eSectionTypeLLDBTypeSummaries;
if (section_name == g_sect_name_swift_ast)
return eSectionTypeSwiftModules;
if (section_name == g_sect_name_objc_data ||
diff --git a/lldb/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp
b/lldb/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp
index 8d9c919bc9b101..bb712da7f6d67d 100644
--- a/lldb/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp
+++ b/lldb/s
[Lldb-commits] [lldb] 1a650fd - [lldb] Load embedded type summary section (#7859) (#8040)
Author: Dave Lee
Date: 2024-12-10T09:36:38-08:00
New Revision: 1a650fde4a885420c6f2991b41039c4b16ff42e1
URL:
https://github.com/llvm/llvm-project/commit/1a650fde4a885420c6f2991b41039c4b16ff42e1
DIFF:
https://github.com/llvm/llvm-project/commit/1a650fde4a885420c6f2991b41039c4b16ff42e1.diff
LOG: [lldb] Load embedded type summary section (#7859) (#8040)
Add support for type summaries embedded into the binary.
These embedded summaries will typically be generated by Swift macros,
but can also be generated by any other means.
rdar://115184658
Added:
lldb/test/API/functionalities/data-formatter/embedded-summary/Makefile
lldb/test/API/functionalities/data-formatter/embedded-summary/TestEmbeddedTypeSummary.py
lldb/test/API/functionalities/data-formatter/embedded-summary/main.c
Modified:
lldb/include/lldb/lldb-enumerations.h
lldb/source/Core/Section.cpp
lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
lldb/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp
lldb/source/Symbol/ObjectFile.cpp
lldb/source/Target/Target.cpp
Removed:
diff --git a/lldb/include/lldb/lldb-enumerations.h
b/lldb/include/lldb/lldb-enumerations.h
index a9a66ea2662f39..e00ec7f17c5cb8 100644
--- a/lldb/include/lldb/lldb-enumerations.h
+++ b/lldb/include/lldb/lldb-enumerations.h
@@ -763,6 +763,7 @@ enum SectionType {
eSectionTypeDWARFDebugLocListsDwo,
eSectionTypeDWARFDebugTuIndex,
eSectionTypeCTF,
+ eSectionTypeLLDBTypeSummaries,
eSectionTypeSwiftModules,
};
diff --git a/lldb/source/Core/Section.cpp b/lldb/source/Core/Section.cpp
index 0763e88d4608f4..ee01b4ce06ca1e 100644
--- a/lldb/source/Core/Section.cpp
+++ b/lldb/source/Core/Section.cpp
@@ -147,6 +147,8 @@ const char *Section::GetTypeAsCString() const {
return "dwarf-gnu-debugaltlink";
case eSectionTypeCTF:
return "ctf";
+ case eSectionTypeLLDBTypeSummaries:
+return "lldb-type-summaries";
case eSectionTypeOther:
return "regular";
case eSectionTypeSwiftModules:
@@ -457,6 +459,7 @@ bool Section::ContainsOnlyDebugInfo() const {
case eSectionTypeDWARFAppleObjC:
case eSectionTypeDWARFGNUDebugAltLink:
case eSectionTypeCTF:
+ case eSectionTypeLLDBTypeSummaries:
case eSectionTypeSwiftModules:
return true;
}
diff --git a/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
b/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
index eac9ab4577d3eb..a8249cf103833e 100644
--- a/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
+++ b/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
@@ -1696,6 +1696,7 @@ static SectionType GetSectionTypeFromName(llvm::StringRef
Name) {
.Case(".gnu_debugaltlink", eSectionTypeDWARFGNUDebugAltLink)
.Case(".gosymtab", eSectionTypeGoSymtab)
.Case(".text", eSectionTypeCode)
+ .Case(".lldbsummaries", lldb::eSectionTypeLLDBTypeSummaries)
.Case(".swift_ast", eSectionTypeSwiftModules)
.Default(eSectionTypeOther);
}
diff --git a/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
b/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
index daffa1379fe575..7e17fd8c53cd01 100644
--- a/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
+++ b/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
@@ -1209,6 +1209,7 @@ AddressClass
ObjectFileMachO::GetAddressClass(lldb::addr_t file_addr) {
case eSectionTypeDWARFAppleObjC:
case eSectionTypeDWARFGNUDebugAltLink:
case eSectionTypeCTF:
+case eSectionTypeLLDBTypeSummaries:
case eSectionTypeSwiftModules:
return AddressClass::eDebug;
@@ -1484,6 +1485,7 @@ static lldb::SectionType GetSectionType(uint32_t flags,
static ConstString g_sect_name_data("__data");
static ConstString g_sect_name_go_symtab("__gosymtab");
static ConstString g_sect_name_ctf("__ctf");
+ static ConstString g_sect_name_lldb_summaries("__lldbsummaries");
static ConstString g_sect_name_swift_ast("__swift_ast");
if (section_name == g_sect_name_dwarf_debug_abbrev)
@@ -1564,6 +1566,8 @@ static lldb::SectionType GetSectionType(uint32_t flags,
return eSectionTypeGoSymtab;
if (section_name == g_sect_name_ctf)
return eSectionTypeCTF;
+ if (section_name == g_sect_name_lldb_summaries)
+return lldb::eSectionTypeLLDBTypeSummaries;
if (section_name == g_sect_name_swift_ast)
return eSectionTypeSwiftModules;
if (section_name == g_sect_name_objc_data ||
diff --git a/lldb/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp
b/lldb/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp
index 8d9c919bc9b101..bb712da7f6d67d 100644
--- a/lldb/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp
+++ b/lldb/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp
@@ -1010,6 +1010,7 @@ SectionType
ObjectFilePECOFF::GetSectionType(llvm::StringRef se
[Lldb-commits] [lldb] 9a9c1d4 - [lldb] Implement a formatter bytecode interpreter in C++
Author: Adrian Prantl
Date: 2024-12-10T09:36:38-08:00
New Revision: 9a9c1d4a6155a96ce9be494cec7e25731d36b33e
URL:
https://github.com/llvm/llvm-project/commit/9a9c1d4a6155a96ce9be494cec7e25731d36b33e
DIFF:
https://github.com/llvm/llvm-project/commit/9a9c1d4a6155a96ce9be494cec7e25731d36b33e.diff
LOG: [lldb] Implement a formatter bytecode interpreter in C++
Compared to the python version, this also does type checking and error
handling, so it's slightly longer, however, it's still comfortably
under 500 lines.
Added:
lldb/include/lldb/DataFormatters/FormatterSection.h
lldb/source/DataFormatters/FormatterBytecode.cpp
lldb/source/DataFormatters/FormatterBytecode.def
lldb/source/DataFormatters/FormatterBytecode.h
lldb/source/DataFormatters/FormatterSection.cpp
lldb/test/API/functionalities/data-formatter/bytecode-summary/Makefile
lldb/test/API/functionalities/data-formatter/bytecode-summary/TestBytecodeSummary.py
lldb/test/API/functionalities/data-formatter/bytecode-summary/main.cpp
lldb/unittests/DataFormatter/FormatterBytecodeTest.cpp
Modified:
lldb/include/lldb/DataFormatters/FormattersHelpers.h
lldb/include/lldb/DataFormatters/TypeSummary.h
lldb/include/lldb/lldb-enumerations.h
lldb/source/API/SBTypeSummary.cpp
lldb/source/Core/Section.cpp
lldb/source/DataFormatters/CMakeLists.txt
lldb/source/DataFormatters/TypeSummary.cpp
lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
lldb/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp
lldb/source/Symbol/ObjectFile.cpp
lldb/source/Target/Target.cpp
lldb/unittests/DataFormatter/CMakeLists.txt
Removed:
diff --git a/lldb/include/lldb/DataFormatters/FormatterSection.h
b/lldb/include/lldb/DataFormatters/FormatterSection.h
new file mode 100644
index 00..0613fba6c3a602
--- /dev/null
+++ b/lldb/include/lldb/DataFormatters/FormatterSection.h
@@ -0,0 +1,26 @@
+//===-- FormattersSection.h -*- C++
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef LLDB_DATAFORMATTERS_FORMATTERSECTION_H
+#define LLDB_DATAFORMATTERS_FORMATTERSECTION_H
+
+#include "lldb/lldb-enumerations.h"
+#include "lldb/lldb-forward.h"
+
+namespace lldb_private {
+/// Load type summaries embedded in the binary. These are type summaries
+/// provided by the authors of the code.
+void LoadTypeSummariesForModule(lldb::ModuleSP module_sp);
+
+/// Load data formatters embedded in the binary. These are formatters provided
+/// by the authors of the code using LLDB formatter bytecode.
+void LoadFormattersForModule(lldb::ModuleSP module_sp);
+
+} // namespace lldb_private
+
+#endif // LLDB_DATAFORMATTERS_FORMATTERSECTION_H
diff --git a/lldb/include/lldb/DataFormatters/FormattersHelpers.h
b/lldb/include/lldb/DataFormatters/FormattersHelpers.h
index a2e8521d96651b..a98042fd40f93a 100644
--- a/lldb/include/lldb/DataFormatters/FormattersHelpers.h
+++ b/lldb/include/lldb/DataFormatters/FormattersHelpers.h
@@ -1,5 +1,4 @@
-//===-- FormattersHelpers.h --*- C++
-//-*-===//
+//===-- FormattersHelpers.h -*- C++
-*-===//
//
// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
// See https://llvm.org/LICENSE.txt for license information.
diff --git a/lldb/include/lldb/DataFormatters/TypeSummary.h
b/lldb/include/lldb/DataFormatters/TypeSummary.h
index 382824aa2813da..f4d5563516ecb8 100644
--- a/lldb/include/lldb/DataFormatters/TypeSummary.h
+++ b/lldb/include/lldb/DataFormatters/TypeSummary.h
@@ -22,6 +22,10 @@
#include "lldb/Utility/Status.h"
#include "lldb/Utility/StructuredData.h"
+namespace llvm {
+class MemoryBuffer;
+}
+
namespace lldb_private {
class TypeSummaryOptions {
public:
@@ -44,7 +48,7 @@ class TypeSummaryOptions {
class TypeSummaryImpl {
public:
- enum class Kind { eSummaryString, eScript, eCallback, eInternal };
+ enum class Kind { eSummaryString, eScript, eBytecode, eCallback, eInternal };
virtual ~TypeSummaryImpl() = default;
@@ -409,6 +413,23 @@ struct ScriptSummaryFormat : public TypeSummaryImpl {
ScriptSummaryFormat(const ScriptSummaryFormat &) = delete;
const ScriptSummaryFormat &operator=(const ScriptSummaryFormat &) = delete;
};
+
+/// A summary formatter that is defined in LLDB formmater bytecode.
+class BytecodeSummaryFormat : public TypeSummaryImpl {
+ std::unique_ptr m_bytecode;
+
+public:
+ BytecodeSummaryFormat(const TypeSummaryImpl::Flags &flags,
+std::unique_ptr bytecode);
+ bool For
[Lldb-commits] [lldb] [lldb] Implement a formatter bytecode interpreter in C++ (PR #114333)
https://github.com/adrian-prantl closed https://github.com/llvm/llvm-project/pull/114333 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Implement a formatter bytecode interpreter in C++ (PR #114333)
@@ -0,0 +1,41 @@
+// A bare-bones llvm::Optional reimplementation.
+
+template struct MyOptionalStorage {
+ MyOptionalStorage(T val) : value(val), hasVal(true) {}
+ MyOptionalStorage() {}
+ T value;
+ bool hasVal = false;
+};
+
+template struct MyOptional {
+ MyOptionalStorage Storage;
+ MyOptional(T val) : Storage(val) {}
+ MyOptional() {}
+ T &operator*() { return Storage.value; }
+};
+
+void stop() {}
+
+int main(int argc, char **argv) {
+ MyOptional x, y = 42;
+ stop(); // break here
+ return *y;
+}
+
+__attribute__((used, section("__DATA_CONST,__lldbformatters"))) unsigned char
+_MyOptional_type_summary[] =
+"\x01" // version
+"\xa4" // record size
+"\x01" // record size
+"\x10" // type name size
+"^MyOptional<.+>$" // type name
+"\x00" // flags
+"\x00" // sig_summary
+"\x8d" // program size
+"\x01" // program size
+"\x1\x22\x7Storage#\x12\x60\x1,C\x10\x1\x5\x11\x2\x1\x22\x6hasVal#"
+"\x12\x60\x1,\x10\x1e\x2\x22\x1b\x10G#!\x60
"
+"\x0P\x10\x6\x22\x4None\x10\x36\x1#\x15\x60 "
+"\x0#\x16\x60\x5\x22\x5value#\x12\x60\x5#\x17\x60\x1,"
+"\x10\x6\x22\x4None\x10\x11\x1#\x0\x60\x1#R\x60\x10\x3# "
+"\x60\x10\x1\x2\x12\x12\x12\x12"; // summary function
adrian-prantl wrote:
Good point! I'll add a reference to the assembler.
https://github.com/llvm/llvm-project/pull/114333
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] e2bb474 - [lldb] Add comment
Author: Adrian Prantl
Date: 2024-12-10T09:39:51-08:00
New Revision: e2bb47443d2e5c022c7851dd6029e3869fc8835c
URL:
https://github.com/llvm/llvm-project/commit/e2bb47443d2e5c022c7851dd6029e3869fc8835c
DIFF:
https://github.com/llvm/llvm-project/commit/e2bb47443d2e5c022c7851dd6029e3869fc8835c.diff
LOG: [lldb] Add comment
Added:
Modified:
lldb/test/API/functionalities/data-formatter/bytecode-summary/main.cpp
Removed:
diff --git
a/lldb/test/API/functionalities/data-formatter/bytecode-summary/main.cpp
b/lldb/test/API/functionalities/data-formatter/bytecode-summary/main.cpp
index 36cbd988029fdb..35406acd6d0c4e 100644
--- a/lldb/test/API/functionalities/data-formatter/bytecode-summary/main.cpp
+++ b/lldb/test/API/functionalities/data-formatter/bytecode-summary/main.cpp
@@ -22,6 +22,8 @@ int main(int argc, char **argv) {
return *y;
}
+// Produced from the assembler in
+// Shell/ScriptInterpreter/Python/Inputs/FormatterBytecode/formatter.py
__attribute__((used, section("__DATA_CONST,__lldbformatters"))) unsigned char
_MyOptional_type_summary[] =
"\x01" // version
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Implement a formatter bytecode interpreter in C++ (PR #114333)
adrian-prantl wrote: @sylvestre Also your revert was incomplete, and you broke a bunch of other lldb bots :-) I reverted your revert with a fix for https://github.com/llvm/llvm-project/issues/119467 https://github.com/llvm/llvm-project/pull/114333 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Implement a formatter bytecode interpreter in C++ (PR #114333)
adrian-prantl wrote: See https://lab.llvm.org/buildbot/#/builders/59/builds/9599 https://github.com/llvm/llvm-project/pull/114333 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] 87659a1 - Reland: [lldb] Implement a formatter bytecode interpreter in C++
Author: Adrian Prantl
Date: 2024-12-10T16:37:53-08:00
New Revision: 87659a17d0703c1244211d9f8d1f0c21e816f0e1
URL:
https://github.com/llvm/llvm-project/commit/87659a17d0703c1244211d9f8d1f0c21e816f0e1
DIFF:
https://github.com/llvm/llvm-project/commit/87659a17d0703c1244211d9f8d1f0c21e816f0e1.diff
LOG: Reland: [lldb] Implement a formatter bytecode interpreter in C++
Compared to the python version, this also does type checking and error
handling, so it's slightly longer, however, it's still comfortably
under 500 lines.
Relanding with more explicit type conversions.
Added:
lldb/include/lldb/DataFormatters/FormatterSection.h
lldb/source/DataFormatters/FormatterBytecode.cpp
lldb/source/DataFormatters/FormatterBytecode.def
lldb/source/DataFormatters/FormatterBytecode.h
lldb/source/DataFormatters/FormatterSection.cpp
lldb/test/API/functionalities/data-formatter/bytecode-summary/Makefile
lldb/test/API/functionalities/data-formatter/bytecode-summary/TestBytecodeSummary.py
lldb/test/API/functionalities/data-formatter/bytecode-summary/main.cpp
lldb/unittests/DataFormatter/FormatterBytecodeTest.cpp
Modified:
lldb/include/lldb/DataFormatters/FormattersHelpers.h
lldb/include/lldb/DataFormatters/TypeSummary.h
lldb/include/lldb/lldb-enumerations.h
lldb/source/API/SBTypeSummary.cpp
lldb/source/Core/Section.cpp
lldb/source/DataFormatters/CMakeLists.txt
lldb/source/DataFormatters/TypeSummary.cpp
lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
lldb/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp
lldb/source/Symbol/ObjectFile.cpp
lldb/source/Target/Target.cpp
lldb/unittests/DataFormatter/CMakeLists.txt
Removed:
diff --git a/lldb/include/lldb/DataFormatters/FormatterSection.h
b/lldb/include/lldb/DataFormatters/FormatterSection.h
new file mode 100644
index 00..0613fba6c3a602
--- /dev/null
+++ b/lldb/include/lldb/DataFormatters/FormatterSection.h
@@ -0,0 +1,26 @@
+//===-- FormattersSection.h -*- C++
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef LLDB_DATAFORMATTERS_FORMATTERSECTION_H
+#define LLDB_DATAFORMATTERS_FORMATTERSECTION_H
+
+#include "lldb/lldb-enumerations.h"
+#include "lldb/lldb-forward.h"
+
+namespace lldb_private {
+/// Load type summaries embedded in the binary. These are type summaries
+/// provided by the authors of the code.
+void LoadTypeSummariesForModule(lldb::ModuleSP module_sp);
+
+/// Load data formatters embedded in the binary. These are formatters provided
+/// by the authors of the code using LLDB formatter bytecode.
+void LoadFormattersForModule(lldb::ModuleSP module_sp);
+
+} // namespace lldb_private
+
+#endif // LLDB_DATAFORMATTERS_FORMATTERSECTION_H
diff --git a/lldb/include/lldb/DataFormatters/FormattersHelpers.h
b/lldb/include/lldb/DataFormatters/FormattersHelpers.h
index a2e8521d96651b..a98042fd40f93a 100644
--- a/lldb/include/lldb/DataFormatters/FormattersHelpers.h
+++ b/lldb/include/lldb/DataFormatters/FormattersHelpers.h
@@ -1,5 +1,4 @@
-//===-- FormattersHelpers.h --*- C++
-//-*-===//
+//===-- FormattersHelpers.h -*- C++
-*-===//
//
// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
// See https://llvm.org/LICENSE.txt for license information.
diff --git a/lldb/include/lldb/DataFormatters/TypeSummary.h
b/lldb/include/lldb/DataFormatters/TypeSummary.h
index 382824aa2813da..f4d5563516ecb8 100644
--- a/lldb/include/lldb/DataFormatters/TypeSummary.h
+++ b/lldb/include/lldb/DataFormatters/TypeSummary.h
@@ -22,6 +22,10 @@
#include "lldb/Utility/Status.h"
#include "lldb/Utility/StructuredData.h"
+namespace llvm {
+class MemoryBuffer;
+}
+
namespace lldb_private {
class TypeSummaryOptions {
public:
@@ -44,7 +48,7 @@ class TypeSummaryOptions {
class TypeSummaryImpl {
public:
- enum class Kind { eSummaryString, eScript, eCallback, eInternal };
+ enum class Kind { eSummaryString, eScript, eBytecode, eCallback, eInternal };
virtual ~TypeSummaryImpl() = default;
@@ -409,6 +413,23 @@ struct ScriptSummaryFormat : public TypeSummaryImpl {
ScriptSummaryFormat(const ScriptSummaryFormat &) = delete;
const ScriptSummaryFormat &operator=(const ScriptSummaryFormat &) = delete;
};
+
+/// A summary formatter that is defined in LLDB formmater bytecode.
+class BytecodeSummaryFormat : public TypeSummaryImpl {
+ std::unique_ptr m_bytecode;
+
+public:
+ BytecodeSummaryFormat(const TypeSummaryImpl::Flags &flags,
+
[Lldb-commits] [lldb] [lldb] Implement basic support for reverse-continue (PR #112079)
@@ -652,7 +652,7 @@ def assert_match(self, asserter, accumulated_output,
context):
if not accumulated_output:
raise Exception("accumulated_output cannot be none")
if not context:
-raise Exception("context cannot be none")
+raise Exception("context cannot be nvalione")
jimingham wrote:
Is this a typo?
https://github.com/llvm/llvm-project/pull/112079
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Implement a formatter bytecode interpreter in C++ (PR #114333)
dyung wrote:
@adrian-prantl at least one bot still seems to be failing (more missing
explicit type conversions?):
https://lab.llvm.org/buildbot/#/builders/181/builds/10128
```
FAILED:
tools/lldb/source/DataFormatters/CMakeFiles/lldbDataFormatters.dir/FormatterBytecode.cpp.o
/opt/ccache/bin/g++ -DGTEST_HAS_RTTI=0 -DHAVE_ROUND -D_DEBUG
-D_GLIBCXX_ASSERTIONS -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS
-D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
-I/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu/build/tools/lldb/source/DataFormatters
-I/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu/llvm-project/lldb/source/DataFormatters
-I/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu/llvm-project/lldb/include
-I/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu/build/tools/lldb/include
-I/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu/build/include
-I/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu/llvm-project/llvm/include
-I/usr/include/python3.8
-I/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu/llvm-project/llvm/../clang/include
-I/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu/build/tools/lldb/../clang/include
-I/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu/llvm-project/lldb/source
-I/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu/build/tools/lldb/source
-isystem /usr/include/libxml2 -fPIC -fno-semantic-interposition
-fvisibility-inlines-hidden -Werror=date-time -fno-lifetime-dse -Wall -Wextra
-Wno-unused-parameter -Wwrite-strings -Wcast-qual
-Wno-missing-field-initializers -pedantic -Wno-long-long -Wimplicit-fallthrough
-Wno-uninitialized -Wno-nonnull -Wno-class-memaccess -Wno-redundant-move
-Wno-pessimizing-move -Wno-noexcept-type -Wdelete-non-virtual-dtor
-Wsuggest-override -Wno-comment -Wno-misleading-indentation -fdiagnostics-color
-ffunction-sections -fdata-sections -Wno-unknown-pragmas -Wno-strict-aliasing
-Wno-stringop-truncation -O3 -DNDEBUG -fno-exceptions -funwind-tables
-fno-rtti -UNDEBUG -std=c++17 -MD -MT
tools/lldb/source/DataFormatters/CMakeFiles/lldbDataFormatters.dir/FormatterBytecode.cpp.o
-MF
tools/lldb/source/DataFormatters/CMakeFiles/lldbDataFormatters.dir/FormatterBytecode.cpp.o.d
-o
tools/lldb/source/DataFormatters/CMakeFiles/lldbDataFormatters.dir/FormatterBytecode.cpp.o
-c
/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu/llvm-project/lldb/source/DataFormatters/FormatterBytecode.cpp
/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu/llvm-project/lldb/source/DataFormatters/FormatterBytecode.cpp:
In function ‘llvm::Error
lldb_private::FormatterBytecode::Interpret(std::vector&,
lldb_private::FormatterBytecode::DataStack&,
lldb_private::FormatterBytecode::Selectors)’:
/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu/llvm-project/lldb/source/DataFormatters/FormatterBytecode.cpp:342:43:
error: cannot convert ‘long long unsigned int’ to
‘lldb_private::FormatterBytecode::DataStackElement’ {aka
‘std::variant,
std::allocator >, long unsigned int, long int,
std::shared_ptr, lldb_private::CompilerType,
lldb_private::FormatterBytecode::Selectors>’}
342 | data.Push(data.Pop() ? 0ULL : 1ULL);
| ~~^
| |
| long long unsigned int
In file included from
/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu/llvm-project/lldb/source/DataFormatters/FormatterBytecode.cpp:9:
/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu/llvm-project/lldb/source/DataFormatters/FormatterBytecode.h:44:30:
note: initializing argument 1 of ‘void
lldb_private::FormatterBytecode::DataStack::Push(lldb_private::FormatterBytecode::DataStackElement)’
44 | void Push(DataStackElement el) { push_back(el); }
| ~^~
/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu/llvm-project/lldb/source/DataFormatters/FormatterBytecode.cpp:395:13:
warning: comparison of unsigned expression < 0 is always false [-Wtype-limits]
395 | if (y < 0)
\
| ~~^~~
/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu/llvm-project/lldb/source/DataFormatters/FormatterBytecode.cpp:401:7:
note: in expansion of macro ‘SHIFTOP’
401 | SHIFTOP(<<);
| ^~~
/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu/llvm-project/lldb/source/DataFormatters/FormatterBytecode.cpp:395:13:
warning: comparison of unsigned expression < 0 is always false [-Wtype-limits]
395 | if (y < 0)
\
| ~~^~~
/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu/llvm-project/lldb/source/DataFormatters/FormatterBytecode.cpp:404:7:
note: in expansion of macro ‘SHIFTOP’
404 |
[Lldb-commits] [lldb] [lldb] Implement basic support for reverse-continue (PR #112079)
@@ -236,11 +236,18 @@ ProcessWindows::DoAttachToProcessWithID(lldb::pid_t pid,
return error;
}
-Status ProcessWindows::DoResume() {
+Status ProcessWindows::DoResume(RunDirection direction) {
Log *log = GetLog(WindowsLog::Process);
llvm::sys::ScopedLock lock(m_mutex);
Status error;
+ if (direction == RunDirection::eRunReverse) {
jimingham wrote:
It might be nicer to have a Process::SupportsReverseContinue, then we could
check this in PrivateResume before calling DoResume. That seems more natural
than having each plugin return an error in their DoResume.
https://github.com/llvm/llvm-project/pull/112079
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Implement a formatter bytecode interpreter in C++ (PR #114333)
adrian-prantl wrote: @dyung checking... https://github.com/llvm/llvm-project/pull/114333 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] 1593f36 - [lldb] Add explicit type conversion
Author: Adrian Prantl
Date: 2024-12-10T17:01:51-08:00
New Revision: 1593f36935edc97bede71bd1d722edf83eaf16a4
URL:
https://github.com/llvm/llvm-project/commit/1593f36935edc97bede71bd1d722edf83eaf16a4
DIFF:
https://github.com/llvm/llvm-project/commit/1593f36935edc97bede71bd1d722edf83eaf16a4.diff
LOG: [lldb] Add explicit type conversion
Added:
Modified:
lldb/source/DataFormatters/FormatterBytecode.cpp
Removed:
diff --git a/lldb/source/DataFormatters/FormatterBytecode.cpp
b/lldb/source/DataFormatters/FormatterBytecode.cpp
index 21e90e75202f68..a8975494b83670 100644
--- a/lldb/source/DataFormatters/FormatterBytecode.cpp
+++ b/lldb/source/DataFormatters/FormatterBytecode.cpp
@@ -339,7 +339,7 @@ llvm::Error Interpret(std::vector
&control,
}
case op_is_null: {
TYPE_CHECK(Object);
- data.Push(data.Pop() ? 0ULL : 1ULL);
+ data.Push(data.Pop() ? (uint64_t)0 : (uint64_t)1);
continue;
}
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Implement a formatter bytecode interpreter in C++ (PR #114333)
adrian-prantl wrote: My bad. I literally forgot to git-add that patch to my remand. Pushed as a separate commit now. https://github.com/llvm/llvm-project/pull/114333 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Implement a formatter bytecode interpreter in C++ (PR #114333)
adrian-prantl wrote: The other lldb bots on the dashboard seem to have turned green again. (Windows is still building, but it was fine before). https://github.com/llvm/llvm-project/pull/114333 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Convert the StackFrameList mutex to a shared mutex. (PR #117252)
@@ -93,25 +94,37 @@ class StackFrameList {
bool show_frame_info, uint32_t num_frames_with_source,
bool show_unique = false, bool show_hidden = false,
const char *frame_marker = nullptr);
+
+ /// Returns whether we have currently fetched all the frames of a stack.
+ bool WereAllFramesFetched() const;
protected:
friend class Thread;
friend class ScriptedThread;
+ /// Use this API to build a stack frame list (used for scripted threads, for
+ /// instance.) This API is not meant for StackFrameLists that have unwinders
+ /// and partake in lazy stack filling (using GetFramesUpTo). Rather if you
+ /// are building StackFrameLists with this API, you should build the entire
+ /// list before making it available for use.
bool SetFrameAtIndex(uint32_t idx, lldb::StackFrameSP &frame_sp);
- /// Realizes frames up to (and including) end_idx (which can be greater than
- /// the actual number of frames.)
+ /// Ensures that frames up to (and including) `end_idx` are realized in the
+ /// StackFrameList. `end_idx` can be larger than the actual number of
frames,
+ /// in which case all the frames will be fetched. Acquires the writer end of
+ /// the list mutex.
/// Returns true if the function was interrupted, false otherwise.
- bool GetFramesUpTo(uint32_t end_idx,
- InterruptionControl allow_interrupt = AllowInterruption);
-
- void GetOnlyConcreteFramesUpTo(uint32_t end_idx, Unwind &unwinder);
-
- void SynthesizeTailCallFrames(StackFrame &next_frame);
-
- bool GetAllFramesFetched() { return m_concrete_frames_fetched == UINT32_MAX;
}
+ /// Callers should first check (under the shared mutex) whether we need to
+ /// fetch frames or not.
jimingham wrote:
The two uses of GetFramesUpTo figure out whether they can get what they need
w/o adding new frames in different ways. In general, I like that the immediate
callers can figure out by their own lights whether they have the frames they
need, and then only call GetFramesUpTo if you need to fetch more frames. That
seems clearer to me.
https://github.com/llvm/llvm-project/pull/117252
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Convert the StackFrameList mutex to a shared mutex. (PR #117252)
@@ -578,58 +607,36 @@ void StackFrameList::Dump(Stream *s) {
StackFrameSP StackFrameList::GetFrameAtIndex(uint32_t idx) {
StackFrameSP frame_sp;
- std::lock_guard guard(m_mutex);
uint32_t original_idx = idx;
- uint32_t inlined_depth = GetCurrentInlinedDepth();
- if (inlined_depth != UINT32_MAX)
-idx += inlined_depth;
+ // We're going to consult the m_frames.size, but if there are already
+ // enough frames for our request we don't want to block other readers, so
+ // first acquire the shared lock:
+ { // Scope for shared lock:
+std::shared_lock guard(m_list_mutex);
+
+uint32_t inlined_depth = GetCurrentInlinedDepth();
+if (inlined_depth != UINT32_MAX)
+ idx += inlined_depth;
- if (idx < m_frames.size())
-frame_sp = m_frames[idx];
+if (idx < m_frames.size())
+ frame_sp = m_frames[idx];
- if (frame_sp)
-return frame_sp;
+if (frame_sp)
+ return frame_sp;
jimingham wrote:
I don't think that helps much. Of the current two uses, GetNumFrames doesn't
return the frame of the index passed in, and GetFrameAtIndex has a fallback
that would still require the shared lock.
https://github.com/llvm/llvm-project/pull/117252
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][debugserver] Read/write SME registers on arm64 (PR #119171)
jasonmolenda wrote: Updated the API test case as per David's suggestions, and remove the code that was using debugserver's SVL as the hardware maximum, depending entirely on the newer sysctl to get the correct value instead. https://github.com/llvm/llvm-project/pull/119171 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][debugserver] Read/write SME registers on arm64 (PR #119171)
https://github.com/jasonmolenda updated https://github.com/llvm/llvm-project/pull/119171 >From 2e3738eb7ed356fe4f9ee24a31af55a01b18bd08 Mon Sep 17 00:00:00 2001 From: Jason Molenda Date: Sun, 8 Dec 2024 22:21:22 -0800 Subject: [PATCH 1/4] [lldb][debugserver] Read/write SME registers on arm64 The Apple M4 line of cores includes the Scalable Matrix Extension (SME) feature. The M4s do not implement Scalable Vector Extension (SVE), although the processor is in Streaming SVE Mode when the SME is being used. The most obvious side effects of being in SSVE Mode are that (on the M4 cores) NEON instructions cannot be used, and watchpoints may get false positives, the address comparisons are done at a lowered granularity. When SSVE mode is enabled, the kernel will provide the Streaming Vector Length register, which is a maximum of 64 bytes with the M4. Also provided are SVCR (with bits indicating if SSVE mode and SME mode are enabled), TPIDR2, SVL. Then the SVE registers Z0..31 (SVL bytes long), P0..15 (SVL/8 bytes), the ZA matrix register (SVL*SVL bytes), and the M4 supports SME2, so the ZT0 register (64 bytes). When SSVE/SME are disabled, none of these registers are provided by the kernel - reads and writes of them will fail. Unlike Linux, lldb cannot modify the SVL through a thread_set_state call, or change the processor state's SSVE/SME status. There is also no way for a process to request a lowered SVL size today, so the work that David did to handle VL/SVL changing while stepping through a process is not an issue on Darwin today. But debugserver should be providing everything necessary so we can reuse all of David's work on resizing the register contexts in lldb if it happens in the future. debugbserver sends svl, svcr, and tpidr2 in the expedited registers when a thread stops, if SSVE|SME mode are enabled (if the kernel allows it to read the ARM_SME_STATE register set). While the maximum SVL is 64 bytes on M4, the AArch64 maximum possible SVL is 256; this would give us a 65k ZA register. If debugserver sized all of its register contexts assuming the largest possible SVL, we could easily use 2MB more memory for the register contexts of all threads in a process -- and on iOS et al, processes must run within a small memory allotment and this would push us over that. Much of the work in debugserver was changing the arm64 register context from being a static compile-time array of register sets, to being initialized at runtime if debugserver is running on a machine with SME. The ZA is only created to the machine's actual maximum SVL. The size of the 32 SVE Z registers is less significant so I am statically allocating those to the architecturally largest possible SVL value today. Also, debugserver includes information about registers that share the same part of the register file. e.g. S0 and D0 are the lower parts of the NEON 128-bit V0 register. And when running on an SME machine, v0 is the lower 128 bits of the SVE Z0 register. So the register maps used when defining the VFP registers must differ depending on the runtime state of the cpu. I also changed register reading in debugserver, where formerly when debugserver was asked to read a register, and the thread_get_state read of that register failed, it would return all zero's. This is necessary when constructing a `g` packet that gets all registers - because there is no separation between register bytes, the offsets are fixed. But when we are asking for a single register (e.g. Z0) when not in SSVE/SME mode, this should return an error. This does mean that when you're running on an SME capabable machine, but not in SME mode, and do `register read -a`, lldb will report that 48 SVE registers were unavailable and 5 SME registers were unavailable. But that's only when `-a` is used. The register reading and writing depends on new register flavor support in thread_get_state/thread_set_state in the kernel, which is not yet in a release. The test case I wrote is skipped on current OSes. I pilfered the SME register setup from some of David's existing SME test files; there were a few Linux specific details in those tests that they weren't easy to reuse on Darwin. rdar://121608074 --- .../AArch64/ArchitectureAArch64.cpp | 19 + lldb/test/API/macosx/sme-registers/Makefile | 5 + .../sme-registers/TestSMERegistersDarwin.py | 164 lldb/test/API/macosx/sme-registers/main.c | 123 +++ lldb/tools/debugserver/source/DNBDefs.h | 25 +- .../source/MacOSX/arm64/DNBArchImplARM64.cpp | 906 ++ .../source/MacOSX/arm64/DNBArchImplARM64.h| 73 +- .../source/MacOSX/arm64/sme_thread_status.h | 86 ++ lldb/tools/debugserver/source/RNBRemote.cpp | 87 +- 9 files changed, 1247 insertions(+), 241 deletions(-) create mode 100644 lldb/test/API/macosx/sme-registers/Makefile create mode 100644 lldb/test/API/macosx/sme-registers/TestSMERegistersDarwin.py create mode 100644 lldb/test/API/macosx/sme-registers
[Lldb-commits] [lldb] [lldb] Implement basic support for reverse-continue (PR #112079)
@@ -2674,6 +2680,9 @@ void PruneThreadPlans();
const AddressRange &range, size_t alignment,
Status &error);
+ lldb::RunDirection GetBaseDirection() const { return m_base_direction; }
jimingham wrote:
These need some comments. What is a "BaseDirection". And how is it different
from the "RunDirection"?
https://github.com/llvm/llvm-project/pull/112079
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Implement a formatter bytecode interpreter in C++ (PR #114333)
adrian-prantl wrote: On which bot did you see this? I watched the lldb linux arm bot go green earlier today. In any case it looks like there was just one more explicit type conversion missing. https://github.com/llvm/llvm-project/pull/114333 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Implement basic support for reverse-continue (PR #112079)
@@ -2674,6 +2680,9 @@ void PruneThreadPlans();
const AddressRange &range, size_t alignment,
Status &error);
+ lldb::RunDirection GetBaseDirection() const { return m_base_direction; }
jimingham wrote:
Somewhere you should say what your basic strategy is. This is one good place,
or you can add a sequel to the novella in ThreadPlan.h if that's more
appropriate.
https://github.com/llvm/llvm-project/pull/112079
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add ability to rate-limit progress reports (PR #119377)
@@ -208,6 +209,110 @@ TEST_F(ProgressReportTest,
TestReportDestructionWithPartialProgress) {
EXPECT_EQ(data->GetMessage(), "Infinite progress: Report 2");
}
+TEST_F(ProgressReportTest, TestFiniteOverflow) {
+ ListenerSP listener_sp = CreateListenerFor(lldb::eBroadcastBitProgress);
+ EventSP event_sp;
+ const ProgressEventData *data;
+
+ // Increment the report beyond its limit and make sure we only get one
+ // completed event.
+ {
+Progress progress("Finite progress", "Report 1", 10);
+progress.Increment(11);
+progress.Increment(47);
+ }
+
+ ASSERT_TRUE(listener_sp->GetEvent(event_sp, TIMEOUT));
+ data = ProgressEventData::GetEventDataFromEvent(event_sp.get());
+ EXPECT_TRUE(data->IsFinite());
+ EXPECT_EQ(data->GetCompleted(), 0);
+ EXPECT_EQ(data->GetTotal(), 10);
+
+ ASSERT_TRUE(listener_sp->GetEvent(event_sp, TIMEOUT));
+ data = ProgressEventData::GetEventDataFromEvent(event_sp.get());
+ EXPECT_TRUE(data->IsFinite());
+ EXPECT_EQ(data->GetCompleted(), 10);
+ EXPECT_EQ(data->GetTotal(), 10);
+
+ ASSERT_FALSE(listener_sp->GetEvent(event_sp, TIMEOUT));
+}
+
+TEST_F(ProgressReportTest, TestNonDeterministicOverflow) {
+ ListenerSP listener_sp = CreateListenerFor(lldb::eBroadcastBitProgress);
+ EventSP event_sp;
+ const ProgressEventData *data;
+ constexpr uint64_t max_minus_1 = std::numeric_limits::max() - 1;
+
+ // Increment the report beyond its limit and make sure we only get one
+ // completed event. The event which overflows the counter should be ignored.
+ {
+Progress progress("Finite progress", "Report 1");
chelcassanova wrote:
Super tiny nit: should this be "non-deterministic progress" or something of the
sort since we don't have a total set here?
https://github.com/llvm/llvm-project/pull/119377
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add ability to rate-limit progress reports (PR #119377)
https://github.com/chelcassanova approved this pull request. LGTM! https://github.com/llvm/llvm-project/pull/119377 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Implement a formatter bytecode interpreter in C++ (PR #114333)
sylvestre wrote: it also caused https://github.com/llvm/llvm-project/issues/119467 I am sorry but I pushed a revert of this PR 9a9c1d4a6155a96ce9be494cec7e25731d36b33e and your followup patches: e2bb47443d2e5c022c7851dd6029e3869fc8835c 0be33484853557bc0fd9dfb94e0b6c15dda136ce d300337e93da4ed96b044557e4b0a30001967cf0 f6012a209dca6b1866d00e6b4f96279469884320 https://github.com/llvm/llvm-project/pull/114333 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] f6012a2 - [lldb] Add cast to fix compile error on 32-bit platforms
Author: Adrian Prantl
Date: 2024-12-10T10:28:14-08:00
New Revision: f6012a209dca6b1866d00e6b4f96279469884320
URL:
https://github.com/llvm/llvm-project/commit/f6012a209dca6b1866d00e6b4f96279469884320
DIFF:
https://github.com/llvm/llvm-project/commit/f6012a209dca6b1866d00e6b4f96279469884320.diff
LOG: [lldb] Add cast to fix compile error on 32-bit platforms
Added:
Modified:
lldb/source/DataFormatters/FormatterBytecode.cpp
Removed:
diff --git a/lldb/source/DataFormatters/FormatterBytecode.cpp
b/lldb/source/DataFormatters/FormatterBytecode.cpp
index 02b2684485a92d..21e90e75202f68 100644
--- a/lldb/source/DataFormatters/FormatterBytecode.cpp
+++ b/lldb/source/DataFormatters/FormatterBytecode.cpp
@@ -551,7 +551,7 @@ llvm::Error Interpret(std::vector
&control,
}
case sel_strlen: {
TYPE_CHECK(String);
-data.Push(data.Pop().size());
+data.Push((uint64_t)data.Pop().size());
break;
}
case sel_fmt: {
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Convert the StackFrameList mutex to a shared mutex. (PR #117252)
@@ -119,6 +120,7 @@ bool StackFrameList::DecrementCurrentInlinedDepth() {
uint32_t current_inlined_depth = GetCurrentInlinedDepth();
if (current_inlined_depth != UINT32_MAX) {
if (current_inlined_depth > 0) {
+std::lock_guard guard(m_inlined_depth_mutex);
jimingham wrote:
That switch was necessitated by the change of `m_list_mutex` from a recursive
to a non-recursive mutex. This code often gets executed under some frame that
has the list mutex. So you can't just leave it as is.
The control of this feature isn't really well modeled by mutexes. I think they
were just there because recursive mutexes make it easy to reflexively put them
around anything...
But the inlined depth of the current stack frame has to be set before we
present the StackFrameList - it doesn't really make sense to do it otherwise.
BTW, that doesn't violate the "lazy stack frame building" aim because we only
compute this for the inlined frames below the first concrete frame, which we
always fetch.
So by the time any clients see the StackFrameList, the inlined depth should
have been set. It's not as simple as "has to be done in the constructor"
because we also need to reset it at the point where we decide that we can
implement a "step in" by just changing the inlined stack counter. We do that
without rebuilding the stack frame.
Currently this isn't a problem because we wrote the code so that it sets the
inlined depth in the right place. So perhaps we should just drop this mutex
altogether and rely on this getting set and accessed in the right order, as
currently happens? But I'd rather do that as a separate patch.
https://github.com/llvm/llvm-project/pull/117252
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Reduce the frequency of DWARF index progress reporting (PR #118953)
labath wrote: > What is the resolution if we switch to "time since epoch" in an atomic value? > Can we use some casting to cast a double back into a uint64_t for storage in > an atomic? > That's not a problem. I was referring to the time_point::time_since_epoch() (which returns arbitrary precision), not the unix "seconds since epoch" concept. I've created an alternative implementation in #119377 https://github.com/llvm/llvm-project/pull/118953 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add ability to rate-limit progress reports (PR #119377)
https://github.com/labath created
https://github.com/llvm/llvm-project/pull/119377
For high-frequency multithreaded progress reports, the contention of taking the
progress mutex and the overhead of generating event can significantly slow down
the operation whose progress we are reporting.
This patch adds an (optional) capability to rate-limit them. It's optional
because this approach has one drawback: if the progress reporting has a pattern
where it generates a burst of activity and then blocks (without reporting
anything) for a large amount of time, it can appear as if less progress was
made that it actually was (because we only reported the first event from the
burst and dropped the other ones).
I've also made a small refactor of the Progress class to better distinguish
between const (don't need protection), atomic (are used on the hot path) and
other (need mutex protection) members.
>From a5aced42bb0742d44f5fdae51b77c291c95da340 Mon Sep 17 00:00:00 2001
From: Pavel Labath
Date: Tue, 10 Dec 2024 13:36:29 +0100
Subject: [PATCH] [lldb] Add ability to rate-limit progress reports
For high-frequency multithreaded progress reports, the contention of
taking the progress mutex and the overhead of generating event can
significantly slow down the operation whose progress we are reporting.
This patch adds an (optional) capability to rate-limit them. It's
optional because this approach has one drawback: if the progress
reporting has a pattern where it generates a burst of activity and then
blocks (without reporting anything) for a large amount of time, it can
appear as if less progress was made that it actually was (because we
only reported the first event from the burst and dropped the other
ones).
I've also made a small refactor of the Progress class to better
distinguish between const (don't need protection), atomic (are used on
the hot path) and other (need mutex protection) members.
---
lldb/include/lldb/Core/Progress.h | 39 ---
lldb/source/Core/Progress.cpp | 83 +-
.../SymbolFile/DWARF/ManualDWARFIndex.cpp | 3 +-
lldb/unittests/Core/ProgressReportTest.cpp| 106 ++
4 files changed, 187 insertions(+), 44 deletions(-)
diff --git a/lldb/include/lldb/Core/Progress.h
b/lldb/include/lldb/Core/Progress.h
index 421e435a9e685a..f6cea282842e1c 100644
--- a/lldb/include/lldb/Core/Progress.h
+++ b/lldb/include/lldb/Core/Progress.h
@@ -10,6 +10,7 @@
#define LLDB_CORE_PROGRESS_H
#include "lldb/Host/Alarm.h"
+#include "lldb/Utility/Timeout.h"
#include "lldb/lldb-forward.h"
#include "lldb/lldb-types.h"
#include "llvm/ADT/StringMap.h"
@@ -81,7 +82,8 @@ class Progress {
/// progress is to be reported only to specific debuggers.
Progress(std::string title, std::string details = {},
std::optional total = std::nullopt,
- lldb_private::Debugger *debugger = nullptr);
+ lldb_private::Debugger *debugger = nullptr,
+ Timeout minimum_report_time = std::nullopt);
/// Destroy the progress object.
///
@@ -121,21 +123,32 @@ class Progress {
private:
void ReportProgress();
static std::atomic g_id;
- /// More specific information about the current file being displayed in the
- /// report.
- std::string m_details;
- /// How much work ([0...m_total]) that has been completed.
- uint64_t m_completed;
+
/// Total amount of work, use a std::nullopt in the constructor for non
/// deterministic progress.
- uint64_t m_total;
- std::mutex m_mutex;
- /// Set to true when progress has been reported where m_completed == m_total
- /// to ensure that we don't send progress updates after progress has
- /// completed.
- bool m_complete = false;
+ const uint64_t m_total;
+
+ // Minimum amount of time between two progress reports.
+ const Timeout m_minimum_report_time;
+
/// Data needed by the debugger to broadcast a progress event.
- ProgressData m_progress_data;
+ const ProgressData m_progress_data;
+
+ /// How much work ([0...m_total]) that has been completed.
+ std::atomic m_completed = 0;
+
+ /// Time (in nanoseconds since epoch) of the last progress report.
+ std::atomic m_last_report_time_ns;
+
+ /// Guards non-const non-atomic members of the class.
+ std::mutex m_mutex;
+
+ /// More specific information about the current file being displayed in the
+ /// report.
+ std::string m_details;
+
+ /// The "completed" value of the last reported event.
+ std::optional m_prev_completed;
};
/// A class used to group progress reports by category. This is done by using a
diff --git a/lldb/source/Core/Progress.cpp b/lldb/source/Core/Progress.cpp
index c9a556472c06b6..14b05a3d96ab43 100644
--- a/lldb/source/Core/Progress.cpp
+++ b/lldb/source/Core/Progress.cpp
@@ -11,7 +11,8 @@
#include "lldb/Core/Debugger.h"
#include "lldb/Utility/StreamString.h"
#include "llvm/Support/Signposts.h"
-
+#include
+#include
#include
#include
#include
@@ -26,17 +27,18 @@ stat
[Lldb-commits] [lldb] [lldb] Add ability to rate-limit progress reports (PR #119377)
https://github.com/labath updated
https://github.com/llvm/llvm-project/pull/119377
>From 92fb3703c697d376d95217a48e9c32b920006bd0 Mon Sep 17 00:00:00 2001
From: Pavel Labath
Date: Tue, 10 Dec 2024 13:36:29 +0100
Subject: [PATCH] [lldb] Add ability to rate-limit progress reports
For high-frequency multithreaded progress reports, the contention of
taking the progress mutex and the overhead of generating event can
significantly slow down the operation whose progress we are reporting.
This patch adds an (optional) capability to rate-limit them. It's
optional because this approach has one drawback: if the progress
reporting has a pattern where it generates a burst of activity and then
blocks (without reporting anything) for a large amount of time, it can
appear as if less progress was made that it actually was (because we
only reported the first event from the burst and dropped the other
ones).
I've also made a small refactor of the Progress class to better
distinguish between const (don't need protection), atomic (are used on
the hot path) and other (need mutex protection) members.
---
lldb/include/lldb/Core/Progress.h | 39 ---
lldb/source/Core/Progress.cpp | 82 +-
.../SymbolFile/DWARF/ManualDWARFIndex.cpp | 3 +-
lldb/unittests/Core/ProgressReportTest.cpp| 105 ++
4 files changed, 185 insertions(+), 44 deletions(-)
diff --git a/lldb/include/lldb/Core/Progress.h
b/lldb/include/lldb/Core/Progress.h
index 421e435a9e685a..f6cea282842e1c 100644
--- a/lldb/include/lldb/Core/Progress.h
+++ b/lldb/include/lldb/Core/Progress.h
@@ -10,6 +10,7 @@
#define LLDB_CORE_PROGRESS_H
#include "lldb/Host/Alarm.h"
+#include "lldb/Utility/Timeout.h"
#include "lldb/lldb-forward.h"
#include "lldb/lldb-types.h"
#include "llvm/ADT/StringMap.h"
@@ -81,7 +82,8 @@ class Progress {
/// progress is to be reported only to specific debuggers.
Progress(std::string title, std::string details = {},
std::optional total = std::nullopt,
- lldb_private::Debugger *debugger = nullptr);
+ lldb_private::Debugger *debugger = nullptr,
+ Timeout minimum_report_time = std::nullopt);
/// Destroy the progress object.
///
@@ -121,21 +123,32 @@ class Progress {
private:
void ReportProgress();
static std::atomic g_id;
- /// More specific information about the current file being displayed in the
- /// report.
- std::string m_details;
- /// How much work ([0...m_total]) that has been completed.
- uint64_t m_completed;
+
/// Total amount of work, use a std::nullopt in the constructor for non
/// deterministic progress.
- uint64_t m_total;
- std::mutex m_mutex;
- /// Set to true when progress has been reported where m_completed == m_total
- /// to ensure that we don't send progress updates after progress has
- /// completed.
- bool m_complete = false;
+ const uint64_t m_total;
+
+ // Minimum amount of time between two progress reports.
+ const Timeout m_minimum_report_time;
+
/// Data needed by the debugger to broadcast a progress event.
- ProgressData m_progress_data;
+ const ProgressData m_progress_data;
+
+ /// How much work ([0...m_total]) that has been completed.
+ std::atomic m_completed = 0;
+
+ /// Time (in nanoseconds since epoch) of the last progress report.
+ std::atomic m_last_report_time_ns;
+
+ /// Guards non-const non-atomic members of the class.
+ std::mutex m_mutex;
+
+ /// More specific information about the current file being displayed in the
+ /// report.
+ std::string m_details;
+
+ /// The "completed" value of the last reported event.
+ std::optional m_prev_completed;
};
/// A class used to group progress reports by category. This is done by using a
diff --git a/lldb/source/Core/Progress.cpp b/lldb/source/Core/Progress.cpp
index c9a556472c06b6..ed8dfb85639b71 100644
--- a/lldb/source/Core/Progress.cpp
+++ b/lldb/source/Core/Progress.cpp
@@ -11,7 +11,8 @@
#include "lldb/Core/Debugger.h"
#include "lldb/Utility/StreamString.h"
#include "llvm/Support/Signposts.h"
-
+#include
+#include
#include
#include
#include
@@ -26,17 +27,18 @@ static llvm::ManagedStatic
g_progress_signposts;
Progress::Progress(std::string title, std::string details,
std::optional total,
- lldb_private::Debugger *debugger)
-: m_details(details), m_completed(0),
- m_total(Progress::kNonDeterministicTotal),
+ lldb_private::Debugger *debugger,
+ Timeout minimum_report_time)
+: m_total(total.value_or(Progress::kNonDeterministicTotal)),
+ m_minimum_report_time(minimum_report_time),
m_progress_data{title, ++g_id,
- /*m_progress_data.debugger_id=*/std::nullopt} {
- if (total)
-m_total = *total;
-
- if (debugger)
-m_progress_data.debugger_id = debugger->GetID();
-
+ debugger ? std::optional(debugger->GetID())
+
[Lldb-commits] [lldb] [LLDB] Add SBProgress so Python scripts can also report progress (PR #119052)
labath wrote: > The counter-argument is that nothing can prevent users from reporting > arbitrary data and making it look like it originates from LLDB. I think we need to distinguish two kinds of users here. The first one are the ones that sit "outside" of lldb and use the SB API to debug something (in a scripted manner). For these, I think I'd agree with you. It's gets trickier with the other kind -- the ones running "inside" lldb. Here I include all the data formatters, stop hooks and other kinds of (python) callbacks. I can see how one would may want to report progress from inside these and have it go wherever the usual progress reports go (meaning, the console, if you're running lldb CLI; the dap connection if you happen to be running in lldb-dap; or whatever happens in xcode). That said, I can also see how the consumer might want to treat these progress events differently from "core" lldb events, so using a different bit for these makes sense as well. For example, the consumer may want/need to be prepared to handle progress objects that never terminate (the complete event is never sent). At that point, I suppose one can ask the question whether this functionality should be built on top of the Progress class (as opposed to e.g. direct SBListener/SBEvent broadcasts). For me, it's main value lies in its RAII nature (*), but that's something we can't guarantee for python anyway. So yeah, I think an RFC would be nice. (*) https://github.com/llvm/llvm-project/pull/119377 changes that somewhat, but I would hope that no python script is emitting events at such a frequency that this would be needed -- or if it is, I'd hope it could be implemented in a more traditional manner (i.e., with a mutex). https://github.com/llvm/llvm-project/pull/119052 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] do not show misleading error when there is no frame (PR #119103)
https://github.com/oltolm updated
https://github.com/llvm/llvm-project/pull/119103
>From c2e92f6ac1b724f6f43ecea70886b2b6ad4febce Mon Sep 17 00:00:00 2001
From: oltolm
Date: Sat, 7 Dec 2024 17:24:07 +0100
Subject: [PATCH] lldb: do not show misleading error when there is no frame
---
lldb/source/API/SBFrame.cpp | 27 +++
.../python_api/run_locker/TestRunLocker.py| 4 +--
2 files changed, 11 insertions(+), 20 deletions(-)
diff --git a/lldb/source/API/SBFrame.cpp b/lldb/source/API/SBFrame.cpp
index 2300bec4d685d2..5b69cf1ee26414 100644
--- a/lldb/source/API/SBFrame.cpp
+++ b/lldb/source/API/SBFrame.cpp
@@ -1012,33 +1012,26 @@ bool SBFrame::GetDescription(SBStream &description) {
SBValue SBFrame::EvaluateExpression(const char *expr) {
LLDB_INSTRUMENT_VA(this, expr);
- SBValue result;
std::unique_lock lock;
ExecutionContext exe_ctx(m_opaque_sp.get(), lock);
StackFrame *frame = exe_ctx.GetFramePtr();
Target *target = exe_ctx.GetTargetPtr();
+ SBExpressionOptions options;
if (frame && target) {
-SBExpressionOptions options;
lldb::DynamicValueType fetch_dynamic_value =
frame->CalculateTarget()->GetPreferDynamicValue();
options.SetFetchDynamicValue(fetch_dynamic_value);
-options.SetUnwindOnError(true);
-options.SetIgnoreBreakpoints(true);
-SourceLanguage language = target->GetLanguage();
-if (!language)
- language = frame->GetLanguage();
-options.SetLanguage((SBSourceLanguageName)language.name, language.version);
-return EvaluateExpression(expr, options);
- } else {
-Status error;
-error = Status::FromErrorString("can't evaluate expressions when the "
-"process is running.");
-ValueObjectSP error_val_sp =
-ValueObjectConstResult::Create(nullptr, std::move(error));
-result.SetSP(error_val_sp, false);
}
- return result;
+ options.SetUnwindOnError(true);
+ options.SetIgnoreBreakpoints(true);
+ SourceLanguage language;
+ if (target)
+language = target->GetLanguage();
+ if (!language && frame)
+language = frame->GetLanguage();
+ options.SetLanguage((SBSourceLanguageName)language.name, language.version);
+ return EvaluateExpression(expr, options);
}
SBValue
diff --git a/lldb/test/API/python_api/run_locker/TestRunLocker.py
b/lldb/test/API/python_api/run_locker/TestRunLocker.py
index d525bbf6b406f1..b7b4941214e863 100644
--- a/lldb/test/API/python_api/run_locker/TestRunLocker.py
+++ b/lldb/test/API/python_api/run_locker/TestRunLocker.py
@@ -107,6 +107,4 @@ def runlocker_test(self, stop_at_entry):
"script var = lldb.frame.EvaluateExpression('SomethingToCall()');
var.GetError().GetCString()",
result,
)
-self.assertIn(
-"can't evaluate expressions when the process is running",
result.GetOutput()
-)
+self.assertIn("sbframe object is not valid", result.GetOutput())
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] do not show misleading error when there is no frame (PR #119103)
@@ -18,11 +17,8 @@ #include "lldb/Core/Address.h" #include "lldb/Core/Debugger.h" #include "lldb/Expression/ExpressionVariable.h" -#include "lldb/Expression/UserExpression.h" oltolm wrote: done https://github.com/llvm/llvm-project/pull/119103 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] do not show misleading error when there is no frame (PR #119103)
@@ -1012,33 +1006,26 @@ bool SBFrame::GetDescription(SBStream &description) {
SBValue SBFrame::EvaluateExpression(const char *expr) {
LLDB_INSTRUMENT_VA(this, expr);
- SBValue result;
std::unique_lock lock;
ExecutionContext exe_ctx(m_opaque_sp.get(), lock);
StackFrame *frame = exe_ctx.GetFramePtr();
Target *target = exe_ctx.GetTargetPtr();
+ SBExpressionOptions options;
if (frame && target) {
oltolm wrote:
Then I'd leave it as is. Everywhere else it is done in the same way. E.g.
```
if (frame && target) {
lldb::DynamicValueType use_dynamic =
frame->CalculateTarget()->GetPreferDynamicValue();
sb_value = GetValueForVariablePath(var_path, use_dynamic);
}
```
or
```
if (frame && target) {
lldb::DynamicValueType use_dynamic =
frame->CalculateTarget()->GetPreferDynamicValue();
value = FindVariable(name, use_dynamic);
}
```
and so on.
https://github.com/llvm/llvm-project/pull/119103
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Convert the StackFrameList mutex to a shared mutex. (PR #117252)
https://github.com/labath edited https://github.com/llvm/llvm-project/pull/117252 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Convert the StackFrameList mutex to a shared mutex. (PR #117252)
@@ -594,7 +643,7 @@ StackFrameSP StackFrameList::GetFrameAtIndex(uint32_t idx) {
// GetFramesUpTo will fill m_frames with as many frames as you asked for, if
// there are that many. If there weren't then you asked for too many frames.
// GetFramesUpTo returns true if interrupted:
- if (GetFramesUpTo(idx)) {
+ if (GetFramesUpTo(idx, AllowInterruption, guard)) {
Log *log = GetLog(LLDBLog::Thread);
LLDB_LOG(log, "GetFrameAtIndex was interrupted");
return {};
labath wrote:
Sounds good. Thanks.
That said, I think the code below still needs a read lock as it's accessing
m_frames. I think that might be avoidable if `GetFramesUpTo` returned the frame
it was asked for (see other suggestions).
https://github.com/llvm/llvm-project/pull/117252
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Convert the StackFrameList mutex to a shared mutex. (PR #117252)
@@ -578,58 +607,36 @@ void StackFrameList::Dump(Stream *s) {
StackFrameSP StackFrameList::GetFrameAtIndex(uint32_t idx) {
StackFrameSP frame_sp;
- std::lock_guard guard(m_mutex);
uint32_t original_idx = idx;
- uint32_t inlined_depth = GetCurrentInlinedDepth();
- if (inlined_depth != UINT32_MAX)
-idx += inlined_depth;
+ // We're going to consult the m_frames.size, but if there are already
+ // enough frames for our request we don't want to block other readers, so
+ // first acquire the shared lock:
+ { // Scope for shared lock:
+std::shared_lock guard(m_list_mutex);
+
+uint32_t inlined_depth = GetCurrentInlinedDepth();
+if (inlined_depth != UINT32_MAX)
+ idx += inlined_depth;
- if (idx < m_frames.size())
-frame_sp = m_frames[idx];
+if (idx < m_frames.size())
+ frame_sp = m_frames[idx];
- if (frame_sp)
-return frame_sp;
+if (frame_sp)
+ return frame_sp;
labath wrote:
(optional, idea) If `GetFramesUpTo` somehow returned the frame at the given
index then there wouldn't be a need for this block here. I'm thinking about
this in conjunction with my other suggestion to have a read-locked fastpath in
`GetFramesUpTo`.
https://github.com/llvm/llvm-project/pull/117252
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Convert the StackFrameList mutex to a shared mutex. (PR #117252)
@@ -534,33 +569,27 @@ bool StackFrameList::GetFramesUpTo(uint32_t end_idx,
// We are done with the old stack frame list, we can release it now.
m_prev_frames_sp.reset();
}
-
-#if defined(DEBUG_STACK_FRAMES)
- s.PutCString("\n\nNew frames:\n");
- Dump(&s);
- s.EOL();
-#endif
// Don't report interrupted if we happen to have gotten all the frames:
if (!GetAllFramesFetched())
return was_interrupted;
return false;
}
uint32_t StackFrameList::GetNumFrames(bool can_create) {
- std::lock_guard guard(m_mutex);
-
- if (can_create) {
+ if (!WereAllFramesFetched() && can_create) {
// Don't allow interrupt or we might not return the correct count
-GetFramesUpTo(UINT32_MAX, DoNotAllowInterruption);
+GetFramesUpTo(UINT32_MAX, DoNotAllowInterruption);
}
+ // Formally we should acquire the shared lock here, but since we've forced
+ // fetching all the frames, it can't change anymore so that's not required.
labath wrote:
This is only true if `can_create==true`. I think you'll still need the read
lock here.
https://github.com/llvm/llvm-project/pull/117252
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Convert the StackFrameList mutex to a shared mutex. (PR #117252)
https://github.com/labath commented: Thank you. Despite the number of comments, I think this looks much better. I've made some suggestions that I think could reduce the number of times the mutex is taken (not so much for the performance, but for the readability benefit). I've marked them as optional, but I think they'd could improve things, and shouldn't be too hard to implement. https://github.com/llvm/llvm-project/pull/117252 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Convert the StackFrameList mutex to a shared mutex. (PR #117252)
@@ -25,6 +25,7 @@ #include "lldb/Target/Unwind.h" #include "lldb/Utility/LLDBLog.h" #include "lldb/Utility/Log.h" +#include "llvm/ADT/ScopeExit.h" labath wrote: Not used anymore? https://github.com/llvm/llvm-project/pull/117252 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Convert the StackFrameList mutex to a shared mutex. (PR #117252)
@@ -93,25 +94,37 @@ class StackFrameList {
bool show_frame_info, uint32_t num_frames_with_source,
bool show_unique = false, bool show_hidden = false,
const char *frame_marker = nullptr);
+
+ /// Returns whether we have currently fetched all the frames of a stack.
+ bool WereAllFramesFetched() const;
protected:
friend class Thread;
friend class ScriptedThread;
+ /// Use this API to build a stack frame list (used for scripted threads, for
+ /// instance.) This API is not meant for StackFrameLists that have unwinders
+ /// and partake in lazy stack filling (using GetFramesUpTo). Rather if you
+ /// are building StackFrameLists with this API, you should build the entire
+ /// list before making it available for use.
bool SetFrameAtIndex(uint32_t idx, lldb::StackFrameSP &frame_sp);
- /// Realizes frames up to (and including) end_idx (which can be greater than
- /// the actual number of frames.)
+ /// Ensures that frames up to (and including) `end_idx` are realized in the
+ /// StackFrameList. `end_idx` can be larger than the actual number of
frames,
+ /// in which case all the frames will be fetched. Acquires the writer end of
+ /// the list mutex.
/// Returns true if the function was interrupted, false otherwise.
- bool GetFramesUpTo(uint32_t end_idx,
- InterruptionControl allow_interrupt = AllowInterruption);
-
- void GetOnlyConcreteFramesUpTo(uint32_t end_idx, Unwind &unwinder);
-
- void SynthesizeTailCallFrames(StackFrame &next_frame);
-
- bool GetAllFramesFetched() { return m_concrete_frames_fetched == UINT32_MAX;
}
+ /// Callers should first check (under the shared mutex) whether we need to
+ /// fetch frames or not.
labath wrote:
(optional) I'd consider putting the read-locked check into the function itself.
I think then you wouldn't need the `WereAllFramesFetched` check in
`GetNumFrames`, and I don't think it should hurt the other callers.
https://github.com/llvm/llvm-project/pull/117252
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Convert the StackFrameList mutex to a shared mutex. (PR #117252)
@@ -119,6 +120,7 @@ bool StackFrameList::DecrementCurrentInlinedDepth() {
uint32_t current_inlined_depth = GetCurrentInlinedDepth();
if (current_inlined_depth != UINT32_MAX) {
if (current_inlined_depth > 0) {
+std::lock_guard guard(m_inlined_depth_mutex);
labath wrote:
I'm also very suspicious of code like this. It may be enough to make thread
sanitizer happy (as there to longer a *data* race on the variable), but I doubt
that it makes the code surrounding this this function race-free. Like, if there
are multiple callers of this function they could both conclude that
`current_inlined_depth` is greater than zero, and then both decrement (and
overflow) it. And if there can't be multiple parallel callers, then what's the
mutex for?
At the very least, I think the mutex should cover the whole function, but maybe
this even needs synchronization at a higher level. Also, I know this is somehow
related to the mutex switch in `ResetCurrentInlinedDepth`, but is there any way
this could be a separate patch?
https://github.com/llvm/llvm-project/pull/117252
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Convert the StackFrameList mutex to a shared mutex. (PR #117252)
@@ -803,13 +819,12 @@ uint32_t
StackFrameList::SetSelectedFrame(lldb_private::StackFrame *frame) {
break;
}
}
-
SetDefaultFileAndLineToSelectedFrame();
- return *m_selected_frame_idx;
+ result = *m_selected_frame_idx;
labath wrote:
What's up with the result variable? C++ guarantees that the result will be
computed before the destructors are run precisely so that code like `return
protected_object->some_operation()` is safe.
https://github.com/llvm/llvm-project/pull/117252
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Convert the StackFrameList mutex to a shared mutex. (PR #117252)
@@ -1449,7 +1449,7 @@ void Thread::ClearStackFrames() {
// frames:
// FIXME: At some point we can try to splice in the frames we have fetched
// into the new frame as we make it, but let's not try that now.
- if (m_curr_frames_sp && m_curr_frames_sp->GetAllFramesFetched())
+ if (m_curr_frames_sp && m_curr_frames_sp->WereAllFramesFetched())
labath wrote:
I like the past tense touch
https://github.com/llvm/llvm-project/pull/117252
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Convert the StackFrameList mutex to a shared mutex. (PR #117252)
@@ -675,19 +682,24 @@ StackFrameSP StackFrameList::GetFrameWithStackID(const
StackID &stack_id) {
StackFrameSP frame_sp;
if (stack_id.IsValid()) {
-std::lock_guard guard(m_mutex);
uint32_t frame_idx = 0;
-// Do a binary search in case the stack frame is already in our cache
-collection::const_iterator begin = m_frames.begin();
-collection::const_iterator end = m_frames.end();
-if (begin != end) {
- collection::const_iterator pos =
- std::lower_bound(begin, end, stack_id, CompareStackID);
- if (pos != end) {
-if ((*pos)->GetStackID() == stack_id)
- return *pos;
+{
+ // First see if the frame is already realized. This is the scope for
+ // the shared mutex:
+ std::shared_lock guard(m_list_mutex);
+ // Do a binary search in case the stack frame is already in our cache
+ collection::const_iterator begin = m_frames.begin();
+ collection::const_iterator end = m_frames.end();
+ if (begin != end) {
+collection::const_iterator pos =
+std::lower_bound(begin, end, stack_id, CompareStackID);
+if (pos != end) {
+ if ((*pos)->GetStackID() == stack_id)
+return *pos;
+}
labath wrote:
```suggestion
collection::const_iterator pos =
llvm::lower_bound(m_frames, CompareStackID);
if (pos != m_frames.end() && (*pos)->GetStackID() == stack_id)
return *pos;
```
Optional, but would be a nice way to compensate for the increase in the nesting
level.
https://github.com/llvm/llvm-project/pull/117252
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB][Process/Utility] Introduce NativeRegisterContextDBReg class (PR #118043)
@@ -0,0 +1,401 @@
+//===-- NativeRegisterContextDBReg.cpp
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "NativeRegisterContextDBReg.h"
+
+#include "lldb/Utility/LLDBLog.h"
+#include "lldb/Utility/Log.h"
+#include "lldb/Utility/RegisterValue.h"
+
+using namespace lldb_private;
+
+uint32_t NativeRegisterContextDBReg::NumSupportedHardwareBreakpoints() {
+ Log *log = GetLog(LLDBLog::Breakpoints);
+
+ // Read hardware breakpoint and watchpoint information.
+ Status error = ReadHardwareDebugInfo();
+
+ if (error.Fail()) {
+LLDB_LOG(log, "failed to read debug registers");
+return 0;
+ }
+
+ LLDB_LOG(log, "{0}", m_max_hbp_supported);
+ return m_max_hbp_supported;
+}
+
+uint32_t NativeRegisterContextDBReg::SetHardwareBreakpoint(lldb::addr_t addr,
+ size_t size) {
+ Log *log = GetLog(LLDBLog::Breakpoints);
+ LLDB_LOG(log, "addr: {0:x}, size: {1:x}", addr, size);
+
+ // Read hardware breakpoint and watchpoint information.
+ Status error = ReadHardwareDebugInfo();
+ if (error.Fail()) {
+LLDB_LOG(log,
+ "unable to set breakpoint: failed to read debug registers: {0}");
+return LLDB_INVALID_INDEX32;
+ }
+
+ uint32_t control_value = 0, bp_index = 0;
+
+ // Check hardware breakpoint size and address.
DavidSpickett wrote:
This comment is redundant.
https://github.com/llvm/llvm-project/pull/118043
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB][Process/Utility] Introduce NativeRegisterContextDBReg class (PR #118043)
https://github.com/DavidSpickett commented: This passed all tests. Some remaining cosmetic issues but otherwise looks good. We could go more into the style issues here but 1. This code was like that before, you just moved it, so it's not actually a regression. 2. I don't want to get into refactoring and break tests again. If we want to do that we can do it in small pieces later. Going to look again at the follow up PR as well. https://github.com/llvm/llvm-project/pull/118043 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB][Process/Utility] Introduce NativeRegisterContextDBReg class (PR #118043)
@@ -0,0 +1,401 @@
+//===-- NativeRegisterContextDBReg.cpp
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "NativeRegisterContextDBReg.h"
+
+#include "lldb/Utility/LLDBLog.h"
+#include "lldb/Utility/Log.h"
+#include "lldb/Utility/RegisterValue.h"
+
+using namespace lldb_private;
+
+uint32_t NativeRegisterContextDBReg::NumSupportedHardwareBreakpoints() {
+ Log *log = GetLog(LLDBLog::Breakpoints);
+
+ // Read hardware breakpoint and watchpoint information.
+ Status error = ReadHardwareDebugInfo();
+
+ if (error.Fail()) {
+LLDB_LOG(log, "failed to read debug registers");
+return 0;
+ }
+
+ LLDB_LOG(log, "{0}", m_max_hbp_supported);
+ return m_max_hbp_supported;
+}
+
+uint32_t NativeRegisterContextDBReg::SetHardwareBreakpoint(lldb::addr_t addr,
+ size_t size) {
+ Log *log = GetLog(LLDBLog::Breakpoints);
+ LLDB_LOG(log, "addr: {0:x}, size: {1:x}", addr, size);
+
+ // Read hardware breakpoint and watchpoint information.
+ Status error = ReadHardwareDebugInfo();
+ if (error.Fail()) {
+LLDB_LOG(log,
+ "unable to set breakpoint: failed to read debug registers: {0}");
+return LLDB_INVALID_INDEX32;
+ }
+
+ uint32_t control_value = 0, bp_index = 0;
+
+ // Check hardware breakpoint size and address.
+ if (!ValidateBreakpoint(size, addr))
+return LLDB_INVALID_INDEX32;
+
+ // Setup control value
DavidSpickett wrote:
Comment is now redundant.
https://github.com/llvm/llvm-project/pull/118043
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB][Process/Utility] Introduce NativeRegisterContextDBReg class (PR #118043)
@@ -0,0 +1,90 @@
+//===-- NativeRegisterContextDBReg.h *- C++
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef lldb_NativeRegisterContextDBReg_h
+#define lldb_NativeRegisterContextDBReg_h
+
+#include "Plugins/Process/Utility/NativeRegisterContextRegisterInfo.h"
+
+#include
+
+namespace lldb_private {
+
+class NativeRegisterContextDBReg
+: public virtual NativeRegisterContextRegisterInfo {
+public:
+ uint32_t NumSupportedHardwareBreakpoints() override;
+
+ uint32_t SetHardwareBreakpoint(lldb::addr_t addr, size_t size) override;
+
+ bool ClearHardwareBreakpoint(uint32_t hw_idx) override;
+
+ Status ClearAllHardwareBreakpoints() override;
+
+ Status GetHardwareBreakHitIndex(uint32_t &bp_index,
+ lldb::addr_t trap_addr) override;
+
+ uint32_t NumSupportedHardwareWatchpoints() override;
+
+ uint32_t SetHardwareWatchpoint(lldb::addr_t addr, size_t size,
+ uint32_t watch_flags) override;
+
+ bool ClearHardwareWatchpoint(uint32_t hw_index) override;
+
+ Status ClearAllHardwareWatchpoints() override;
+
+ Status GetWatchpointHitIndex(uint32_t &wp_index,
+ lldb::addr_t trap_addr) override;
+
+ lldb::addr_t GetWatchpointHitAddress(uint32_t wp_index) override;
+
+ lldb::addr_t GetWatchpointAddress(uint32_t wp_index) override;
+
+protected:
+ // Debug register type select
+ enum DREGType { eDREGTypeWATCH = 0, eDREGTypeBREAK };
+
+ /// Debug register info for hardware breakpoints and watchpoints management.
+ struct DREG {
+lldb::addr_t address; // Breakpoint/watchpoint address value.
+lldb::addr_t hit_addr; // Address at which last watchpoint trigger
exception
+ // occurred.
+lldb::addr_t real_addr; // Address value that should cause target to stop.
+uint32_t control; // Breakpoint/watchpoint control value.
+ };
+
+ std::array m_hbp_regs; // hardware breakpoints
+ std::array m_hwp_regs; // hardware watchpoints
+
+ uint32_t m_max_hbp_supported;
+ uint32_t m_max_hwp_supported;
+ uint32_t m_hw_dbg_enable_bit;
+
+ bool WatchpointIsEnabled(uint32_t wp_index);
+ bool BreakpointIsEnabled(uint32_t bp_index);
+
+ // Default hardware breakpoint length size is 4.
+ // Default hardware breakpoint target address must 4-byte alignment.
+ virtual bool ValidateBreakpoint(size_t size, lldb::addr_t addr) {
+return (size == 4) && !(addr & 0x3);
DavidSpickett wrote:
Any response here, are the checks the same for AArch64 and LoongArch? If so,
just update the comment above this to say "On AArch64 and LoongArch...".
https://github.com/llvm/llvm-project/pull/118043
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB][Process/Utility] Introduce NativeRegisterContextDBReg class (PR #118043)
@@ -234,9 +234,9 @@ class NativeRegisterContextLinux_arm64
size_t GetFPMRBufferSize() { return sizeof(m_fpmr_reg); }
- llvm::Error ReadHardwareDebugInfo() override;
+ Status ReadHardwareDebugInfo() override;
DavidSpickett wrote:
@wangleiat can you explain why this switched from Status to llvm::Error? Was it
that one copy of the code used Status and the other llvm::Erorr?
https://github.com/llvm/llvm-project/pull/118043
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][AIX] Header Parsing for XCOFF Object File in AIX (PR #116338)
@@ -98,9 +98,20 @@ class ObjectFileXCOFF : public lldb_private::ObjectFile {
const lldb::ProcessSP &process_sp, lldb::addr_t header_addr);
protected:
+ typedef struct llvm::object::XCOFFFileHeader64 xcoff_header_t;
+
+ typedef struct llvm::object::XCOFFAuxiliaryHeader64 xcoff_aux_header_t;
+
static lldb::WritableDataBufferSP
MapFileDataWritable(const lldb_private::FileSpec &file, uint64_t Size,
uint64_t Offset);
+
+private:
+ bool CreateBinary();
+
+ xcoff_header_t m_xcoff_header = {};
+ xcoff_aux_header_t m_xcoff_aux_header = {};
labath wrote:
What's the issue with calling those functions? It can't be performance, as
these functions merely return a pointer the the member inside the llvm object
file. If you find too `m_binary->auxiliaryHeader64()` long/repetitive, I'd
suggest wrapping that in an accessor functions -- though that will only save a
few chars, so I'm not sure if its worth it (it may be better to have an
accessor for the fields of the header that are used often -- that would also be
a way to abstract the 64/32 difference). And if you're worried about the
`m_binary` pointer being null, then I'd suggest setting up the code in a way
that its non-nullness is guaranteed (for example, by creating the
XCOFFObjectFile in the CreateInstance function and passing it to the
constructor.
Bottom line: I still believe there's no need for this member and there's a
better way to achieve what you're trying to do. I'm not sure what it is,
because I'm don't know what exactly you are trying to achieve.
https://github.com/llvm/llvm-project/pull/116338
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB][Process/Utility] Introduce NativeRegisterContextDBReg class (PR #118043)
@@ -180,7 +180,8 @@
NativeRegisterContextLinux_arm64::NativeRegisterContextLinux_arm64(
std::unique_ptr register_info_up)
: NativeRegisterContextRegisterInfo(native_thread,
register_info_up.release()),
- NativeRegisterContextLinux(native_thread) {
+ NativeRegisterContextLinux(native_thread),
+ NativeRegisterContextDBReg_arm64(1U) {
wangleiat wrote:
Thank you, I will add the parameter annotations.
https://github.com/llvm/llvm-project/pull/118043
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB][Process/Utility] Introduce NativeRegisterContextDBReg class (PR #118043)
@@ -0,0 +1,401 @@
+//===-- NativeRegisterContextDBReg.cpp
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "NativeRegisterContextDBReg.h"
+
+#include "lldb/Utility/LLDBLog.h"
+#include "lldb/Utility/Log.h"
+#include "lldb/Utility/RegisterValue.h"
+
+using namespace lldb_private;
+
+uint32_t NativeRegisterContextDBReg::NumSupportedHardwareBreakpoints() {
+ Log *log = GetLog(LLDBLog::Breakpoints);
+
+ // Read hardware breakpoint and watchpoint information.
+ Status error = ReadHardwareDebugInfo();
+
+ if (error.Fail()) {
+LLDB_LOG(log, "failed to read debug registers");
+return 0;
+ }
+
+ LLDB_LOG(log, "{0}", m_max_hbp_supported);
+ return m_max_hbp_supported;
+}
+
+uint32_t NativeRegisterContextDBReg::SetHardwareBreakpoint(lldb::addr_t addr,
+ size_t size) {
+ Log *log = GetLog(LLDBLog::Breakpoints);
+ LLDB_LOG(log, "addr: {0:x}, size: {1:x}", addr, size);
+
+ // Read hardware breakpoint and watchpoint information.
+ Status error = ReadHardwareDebugInfo();
+ if (error.Fail()) {
+LLDB_LOG(log,
+ "unable to set breakpoint: failed to read debug registers: {0}");
+return LLDB_INVALID_INDEX32;
+ }
+
+ uint32_t control_value = 0, bp_index = 0;
+
+ // Check hardware breakpoint size and address.
wangleiat wrote:
Thank you, I will remove the redundant comments.
https://github.com/llvm/llvm-project/pull/118043
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB][Process/Utility] Introduce NativeRegisterContextDBReg class (PR #118043)
@@ -234,9 +234,9 @@ class NativeRegisterContextLinux_arm64
size_t GetFPMRBufferSize() { return sizeof(m_fpmr_reg); }
- llvm::Error ReadHardwareDebugInfo() override;
+ Status ReadHardwareDebugInfo() override;
wangleiat wrote:
Because I noticed that the function calling it returns a `Status` (`virtual
Status ClearAllHardwareWatchpoints()` in file
lldb/include/lldb/Host/common/NativeRegisterContext.h), and other
architectures, such as ARM (not AArch64) and PPC, also return a Status.
Should consistency be maintained here? If `llvm::Error` is required, I will
revert it. I also made a mistake—the definition in this file
`NativeRegisterContextFreeBSD_arm64.h` hasn't been updated yet. I apologize for
my carelessness.
https://github.com/llvm/llvm-project/pull/118043
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] 0be3348 - [lldb] Improve log message to include missing strings
Author: Adrian Prantl
Date: 2024-12-10T09:54:36-08:00
New Revision: 0be33484853557bc0fd9dfb94e0b6c15dda136ce
URL:
https://github.com/llvm/llvm-project/commit/0be33484853557bc0fd9dfb94e0b6c15dda136ce
DIFF:
https://github.com/llvm/llvm-project/commit/0be33484853557bc0fd9dfb94e0b6c15dda136ce.diff
LOG: [lldb] Improve log message to include missing strings
Added:
Modified:
lldb/source/DataFormatters/FormatterSection.cpp
Removed:
diff --git a/lldb/source/DataFormatters/FormatterSection.cpp
b/lldb/source/DataFormatters/FormatterSection.cpp
index 7316990f66a109..f70f41fdeb736f 100644
--- a/lldb/source/DataFormatters/FormatterSection.cpp
+++ b/lldb/source/DataFormatters/FormatterSection.cpp
@@ -103,8 +103,9 @@ void LoadTypeSummariesForModule(ModuleSP module_sp) {
}
if (type_name.empty() || summary_string.empty()) {
LLDB_LOG(GetLog(LLDBLog::DataFormatters),
- "Missing string(s) in embedded type summary in {0}.",
- module_sp->GetFileSpec());
+ "Missing string(s) in embedded type summary in {0}, "
+ "type_name={1}, summary={2}",
+ module_sp->GetFileSpec(), type_name, summary_string);
return;
}
TypeSummaryImpl::Flags flags;
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Load embedded type summary section (#7859) (#8040) (PR #113743)
adrian-prantl wrote: Superseded by https://github.com/llvm/llvm-project/pull/114333 https://github.com/llvm/llvm-project/pull/113743 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Load embedded type summary section (#7859) (#8040) (PR #113743)
adrian-prantl wrote: I believe I also addressed all outstanding review feedback. https://github.com/llvm/llvm-project/pull/113743 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] d300337 - [lldb] Add cast to fix compile error on 32-but platforms
Author: Adrian Prantl
Date: 2024-12-10T10:00:54-08:00
New Revision: d300337e93da4ed96b044557e4b0a30001967cf0
URL:
https://github.com/llvm/llvm-project/commit/d300337e93da4ed96b044557e4b0a30001967cf0
DIFF:
https://github.com/llvm/llvm-project/commit/d300337e93da4ed96b044557e4b0a30001967cf0.diff
LOG: [lldb] Add cast to fix compile error on 32-but platforms
Added:
Modified:
lldb/source/DataFormatters/FormatterBytecode.cpp
Removed:
diff --git a/lldb/source/DataFormatters/FormatterBytecode.cpp
b/lldb/source/DataFormatters/FormatterBytecode.cpp
index 7cad3474edebd3..02b2684485a92d 100644
--- a/lldb/source/DataFormatters/FormatterBytecode.cpp
+++ b/lldb/source/DataFormatters/FormatterBytecode.cpp
@@ -486,7 +486,7 @@ llvm::Error Interpret(std::vector
&control,
TYPE_CHECK(Object, String);
auto name = data.Pop();
POP_VALOBJ(valobj);
-data.Push(valobj->GetIndexOfChildWithName(name));
+data.Push((uint64_t)valobj->GetIndexOfChildWithName(name));
break;
}
case sel_get_type: {
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Load embedded type summary section (#7859) (#8040) (PR #113743)
https://github.com/adrian-prantl closed https://github.com/llvm/llvm-project/pull/113743 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Convert the StackFrameList mutex to a shared mutex. (PR #117252)
@@ -803,13 +819,12 @@ uint32_t
StackFrameList::SetSelectedFrame(lldb_private::StackFrame *frame) {
break;
}
}
-
SetDefaultFileAndLineToSelectedFrame();
- return *m_selected_frame_idx;
+ result = *m_selected_frame_idx;
jimingham wrote:
That was left over from a previous refactoring.
https://github.com/llvm/llvm-project/pull/117252
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Convert the StackFrameList mutex to a shared mutex. (PR #117252)
@@ -25,6 +25,7 @@ #include "lldb/Target/Unwind.h" #include "lldb/Utility/LLDBLog.h" #include "lldb/Utility/Log.h" +#include "llvm/ADT/ScopeExit.h" jimingham wrote: True, that. https://github.com/llvm/llvm-project/pull/117252 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Implement a formatter bytecode interpreter in C++ (PR #114333)
aaronpuchert wrote:
Looks like this caused build errors, e.g.
https://lab.llvm.org/buildbot/#/changes/20131:
```
FAILED: tools/lldb/source/Target/CMakeFiles/lldbTarget.dir/Target.cpp.o
[...]
/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu/llvm-project/lldb/source/Target/Target.cpp:27:10:
fatal error: lldb/Core/ValueObject.h: No such file or directory
27 | #include "lldb/Core/ValueObject.h"
| ^
```
and https://lab.llvm.org/buildbot/#/builders/181/builds/10112:
```
FAILED:
tools/lldb/source/DataFormatters/CMakeFiles/lldbDataFormatters.dir/FormatterBytecode.cpp.o
[...]
/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu/llvm-project/lldb/source/DataFormatters/FormatterBytecode.cpp:
In function ‘llvm::Error
lldb_private::FormatterBytecode::Interpret(std::vector&,
lldb_private::FormatterBytecode::DataStack&,
lldb_private::FormatterBytecode::Selectors)’:
/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu/llvm-project/lldb/source/DataFormatters/FormatterBytecode.cpp:342:43:
error: cannot convert ‘long long unsigned int’ to
‘lldb_private::FormatterBytecode::DataStackElement’ {aka
‘std::variant,
std::allocator >, long unsigned int, long int,
std::shared_ptr, lldb_private::CompilerType,
lldb_private::FormatterBytecode::Selectors>’}
342 | data.Push(data.Pop() ? 0ULL : 1ULL);
| ~~^
| |
| long long unsigned int
In file included from
/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu/llvm-project/lldb/source/DataFormatters/FormatterBytecode.cpp:9:
/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu/llvm-project/lldb/source/DataFormatters/FormatterBytecode.h:44:30:
note: initializing argument 1 of ‘void
lldb_private::FormatterBytecode::DataStack::Push(lldb_private::FormatterBytecode::DataStackElement)’
44 | void Push(DataStackElement el) { push_back(el); }
| ~^~
/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu/llvm-project/lldb/source/DataFormatters/FormatterBytecode.cpp:395:13:
warning: comparison of unsigned expression < 0 is always false [-Wtype-limits]
395 | if (y < 0)
\
| ~~^~~
/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu/llvm-project/lldb/source/DataFormatters/FormatterBytecode.cpp:401:7:
note: in expansion of macro ‘SHIFTOP’
401 | SHIFTOP(<<);
| ^~~
/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu/llvm-project/lldb/source/DataFormatters/FormatterBytecode.cpp:395:13:
warning: comparison of unsigned expression < 0 is always false [-Wtype-limits]
395 | if (y < 0)
\
| ~~^~~
/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu/llvm-project/lldb/source/DataFormatters/FormatterBytecode.cpp:404:7:
note: in expansion of macro ‘SHIFTOP’
404 | SHIFTOP(<<);
| ^~~
```
https://github.com/llvm/llvm-project/pull/114333
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Reduce the frequency of DWARF index progress reporting (PR #118953)
SingleAccretion wrote:
> I think that in your case we're limited by the speed of console updates
> rather than the progress mutex.
Agreed.
> If you have some time, I'd be grateful if you could test this patch out. The
> thing want the see is whether this completely resolves your issue or if you
> still see a difference between disabled&enabled progress reports.
I can confirm it does!
Without the patch, I see a ~25x slowdown when enabling progress reporting
("LLDB time" goes from < 1 second to ~20 seconds), with this patch, the
difference is not measurable.
https://github.com/llvm/llvm-project/pull/118953
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB][Process/Utility] Introduce NativeRegisterContextDBReg class (PR #118043)
@@ -180,7 +180,8 @@
NativeRegisterContextLinux_arm64::NativeRegisterContextLinux_arm64(
std::unique_ptr register_info_up)
: NativeRegisterContextRegisterInfo(native_thread,
register_info_up.release()),
- NativeRegisterContextLinux(native_thread) {
+ NativeRegisterContextLinux(native_thread),
+ NativeRegisterContextDBReg_arm64(1U) {
DavidSpickett wrote:
Please add the parameter name like:
```
NativeRegisterContextDBReg_arm64(/*enable_bit=*/1U)
```
https://github.com/llvm/llvm-project/pull/118043
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][debugserver] Read/write SME registers on arm64 (PR #119171)
@@ -312,16 +312,21 @@ struct DNBRegisterValue {
uint64_t uint64;
float float32;
double float64;
-int8_t v_sint8[64];
-int16_t v_sint16[32];
-int32_t v_sint32[16];
-int64_t v_sint64[8];
-uint8_t v_uint8[64];
-uint16_t v_uint16[32];
-uint32_t v_uint32[16];
-uint64_t v_uint64[8];
-float v_float32[16];
-double v_float64[8];
+// AArch64 SME's ZA register max size is 64k, this object must be
+// large enough to hold that much data. The current Apple cores
+// have a much smaller maximum ZA reg size, but there are not
+// multiple copies of this object so increase the static size to
+// maximum possible.
DavidSpickett wrote:
I think for Linux we were also stack allocating the register value and I didn't
want 64k stack frames everywhere we used one.
https://github.com/llvm/llvm-project/commit/d99d9d8b74ffcb8ac418fcdafa750b07f2bd9935
in case any of the concerns apply to debugserver also.
(I am also very aware of these issues because in a previous job when we added
MIPS MSA support we accidentally turned every register object into 512 bits,
even the 8 and 16 bit ones we read from non-MIPS DSP chips)
https://github.com/llvm/llvm-project/pull/119171
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][AIX] Added base files for NativeProcess Support for AIX (PR #118160)
https://github.com/DhruvSrivastavaX updated
https://github.com/llvm/llvm-project/pull/118160
>From 03a290e9c748540b69ca6df7fa9c4481f9cdd3d0 Mon Sep 17 00:00:00 2001
From: Dhruv-Srivastava
Date: Sat, 30 Nov 2024 01:14:15 -0600
Subject: [PATCH 1/5] Added base files for NativeProcess for AIX
---
.../source/Plugins/Process/AIX/CMakeLists.txt | 14 +
.../Plugins/Process/AIX/NativeProcessAIX.cpp | 288 ++
.../Plugins/Process/AIX/NativeProcessAIX.h| 134
lldb/source/Plugins/Process/CMakeLists.txt| 3 +
4 files changed, 439 insertions(+)
create mode 100644 lldb/source/Plugins/Process/AIX/CMakeLists.txt
create mode 100644 lldb/source/Plugins/Process/AIX/NativeProcessAIX.cpp
create mode 100644 lldb/source/Plugins/Process/AIX/NativeProcessAIX.h
diff --git a/lldb/source/Plugins/Process/AIX/CMakeLists.txt
b/lldb/source/Plugins/Process/AIX/CMakeLists.txt
new file mode 100644
index 00..4fabbe93022870
--- /dev/null
+++ b/lldb/source/Plugins/Process/AIX/CMakeLists.txt
@@ -0,0 +1,14 @@
+add_lldb_library(lldbPluginProcessAIX
+ NativeProcessAIX.cpp
+
+ LINK_LIBS
+lldbCore
+lldbHost
+lldbSymbol
+lldbTarget
+lldbUtility
+lldbPluginProcessPOSIX
+lldbPluginProcessUtility
+ LINK_COMPONENTS
+Support
+ )
diff --git a/lldb/source/Plugins/Process/AIX/NativeProcessAIX.cpp
b/lldb/source/Plugins/Process/AIX/NativeProcessAIX.cpp
new file mode 100644
index 00..6661693b2fc02b
--- /dev/null
+++ b/lldb/source/Plugins/Process/AIX/NativeProcessAIX.cpp
@@ -0,0 +1,288 @@
+//===-- NativeProcessAIX.cpp ===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "NativeProcessAIX.h"
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "NativeThreadAIX.h"
+#include "Plugins/Process/POSIX/ProcessPOSIXLog.h"
+#include "lldb/Core/ModuleSpec.h"
+#include "lldb/Host/Host.h"
+#include "lldb/Host/HostProcess.h"
+#include "lldb/Host/ProcessLaunchInfo.h"
+#include "lldb/Host/PseudoTerminal.h"
+#include "lldb/Host/ThreadLauncher.h"
+#include "lldb/Host/common/NativeRegisterContext.h"
+#include "lldb/Host/aix/Ptrace.h"
+#include "lldb/Host/posix/ProcessLauncherPosixFork.h"
+#include "lldb/Symbol/ObjectFile.h"
+#include "lldb/Target/Process.h"
+#include "lldb/Target/Target.h"
+#include "lldb/Utility/LLDBAssert.h"
+#include "lldb/Utility/LLDBLog.h"
+#include "lldb/Utility/RegisterValue.h"
+#include "lldb/Utility/State.h"
+#include "lldb/Utility/Status.h"
+#include "lldb/Utility/StringExtractor.h"
+#include "llvm/ADT/ScopeExit.h"
+#include "llvm/Support/Errno.h"
+#include "llvm/Support/Error.h"
+#include "llvm/Support/FileSystem.h"
+#include "llvm/Support/Threading.h"
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#ifdef __aarch64__
+#include
+#include
+#endif
+
+// Support hardware breakpoints in case it has not been defined
+#ifndef TRAP_HWBKPT
+#define TRAP_HWBKPT 4
+#endif
+
+#ifndef HWCAP2_MTE
+#define HWCAP2_MTE (1 << 18)
+#endif
+
+using namespace lldb;
+using namespace lldb_private;
+using namespace lldb_private::process_aix;
+using namespace llvm;
+
+static constexpr unsigned k_ptrace_word_size = sizeof(void *);
+static_assert(sizeof(long) >= k_ptrace_word_size,
+ "Size of long must be larger than ptrace word size");
+
+// Simple helper function to ensure flags are enabled on the given file
+// descriptor.
+static Status EnsureFDFlags(int fd, int flags) {
+ Status error;
+
+ int status = fcntl(fd, F_GETFL);
+ if (status == -1) {
+error = Status::FromErrno();
+return error;
+ }
+
+ if (fcntl(fd, F_SETFL, status | flags) == -1) {
+error = Status::FromErrno();
+return error;
+ }
+
+ return error;
+}
+
+NativeProcessAIX::Manager::Manager(MainLoop &mainloop)
+: NativeProcessProtocol::Manager(mainloop) {
+ Status status;
+ m_sigchld_handle = mainloop.RegisterSignal(
+ SIGCHLD, [this](MainLoopBase &) { SigchldHandler(); }, status);
+ assert(m_sigchld_handle && status.Success());
+}
+
+// Public Static Methods
+
+llvm::Expected>
+NativeProcessAIX::Manager::Launch(ProcessLaunchInfo &launch_info,
+NativeDelegate &native_delegate) {
+ Log *log = GetLog(POSIXLog::Process);
+
+ Status status;
+ ::pid_t pid = ProcessLauncherPosixFork()
+.LaunchProcess(launch_info, status)
+.GetProcessId();
+ LLDB_LOG(log, "pid = {0:x}", pid);
+ if (status.Fail()) {
+LLDB_LOG(log, "failed to launch process: {0}", status);
+return status.ToError();
+ }
+
+ // Wait for the child process to trap on its call to execve.
+ int wstatus = 0;
+ ::p
[Lldb-commits] [lldb] [lldb][AIX] Added base files for NativeProcess Support for AIX (PR #118160)
DhruvSrivastavaX wrote: Addressed your comments in this commit to keep track of the changes. https://github.com/llvm/llvm-project/pull/118160 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][debugserver] Read/write SME registers on arm64 (PR #119171)
@@ -0,0 +1,111 @@
+/// BUILT with
+///xcrun -sdk macosx.internal clang -mcpu=apple-m4 -g sme.c -o sme
+
+#include
+#include
+#include
+
+void write_sve_regs() {
+ asm volatile("ptrue p0.b\n\t");
+ asm volatile("ptrue p1.h\n\t");
+ asm volatile("ptrue p2.s\n\t");
+ asm volatile("ptrue p3.d\n\t");
+ asm volatile("pfalse p4.b\n\t");
+ asm volatile("ptrue p5.b\n\t");
+ asm volatile("ptrue p6.h\n\t");
+ asm volatile("ptrue p7.s\n\t");
+ asm volatile("ptrue p8.d\n\t");
+ asm volatile("pfalse p9.b\n\t");
+ asm volatile("ptrue p10.b\n\t");
+ asm volatile("ptrue p11.h\n\t");
+ asm volatile("ptrue p12.s\n\t");
+ asm volatile("ptrue p13.d\n\t");
+ asm volatile("pfalse p14.b\n\t");
+ asm volatile("ptrue p15.b\n\t");
+
+ asm volatile("cpy z0.b, p0/z, #1\n\t");
+ asm volatile("cpy z1.b, p5/z, #2\n\t");
+ asm volatile("cpy z2.b, p10/z, #3\n\t");
+ asm volatile("cpy z3.b, p15/z, #4\n\t");
+ asm volatile("cpy z4.b, p0/z, #5\n\t");
+ asm volatile("cpy z5.b, p5/z, #6\n\t");
+ asm volatile("cpy z6.b, p10/z, #7\n\t");
+ asm volatile("cpy z7.b, p15/z, #8\n\t");
+ asm volatile("cpy z8.b, p0/z, #9\n\t");
+ asm volatile("cpy z9.b, p5/z, #10\n\t");
+ asm volatile("cpy z10.b, p10/z, #11\n\t");
+ asm volatile("cpy z11.b, p15/z, #12\n\t");
+ asm volatile("cpy z12.b, p0/z, #13\n\t");
+ asm volatile("cpy z13.b, p5/z, #14\n\t");
+ asm volatile("cpy z14.b, p10/z, #15\n\t");
+ asm volatile("cpy z15.b, p15/z, #16\n\t");
+ asm volatile("cpy z16.b, p0/z, #17\n\t");
+ asm volatile("cpy z17.b, p5/z, #18\n\t");
+ asm volatile("cpy z18.b, p10/z, #19\n\t");
+ asm volatile("cpy z19.b, p15/z, #20\n\t");
+ asm volatile("cpy z20.b, p0/z, #21\n\t");
+ asm volatile("cpy z21.b, p5/z, #22\n\t");
+ asm volatile("cpy z22.b, p10/z, #23\n\t");
+ asm volatile("cpy z23.b, p15/z, #24\n\t");
+ asm volatile("cpy z24.b, p0/z, #25\n\t");
+ asm volatile("cpy z25.b, p5/z, #26\n\t");
+ asm volatile("cpy z26.b, p10/z, #27\n\t");
+ asm volatile("cpy z27.b, p15/z, #28\n\t");
+ asm volatile("cpy z28.b, p0/z, #29\n\t");
+ asm volatile("cpy z29.b, p5/z, #30\n\t");
+ asm volatile("cpy z30.b, p10/z, #31\n\t");
+ asm volatile("cpy z31.b, p15/z, #32\n\t");
+}
+
+#define MAX_VL_BYTES 256
+void set_za_register(int svl, int value_offset) {
+ uint8_t data[MAX_VL_BYTES];
+
+ // ldr za will actually wrap the selected vector row, by the number of rows
+ // you have. So setting one that didn't exist would actually set one that
did.
+ // That's why we need the streaming vector length here.
+ for (int i = 0; i < svl; ++i) {
+// This may involve instructions that require the smefa64 extension.
+for (int j = 0; j < MAX_VL_BYTES; j++)
+ data[j] = i + value_offset;
+// Each one of these loads a VL sized row of ZA.
+asm volatile("mov w12, %w0\n\t"
+ "ldr za[w12, 0], [%1]\n\t" ::"r"(i),
+ "r"(&data)
+ : "w12");
+ }
+}
+
+static uint16_t arm_sme_svl_b(void) {
+ uint64_t ret = 0;
+ asm volatile("rdsvl %[ret], #1" : [ret] "=r"(ret));
+ return (uint16_t)ret;
+}
+
+void arm_sme2_set_zt0() {
+#define ZTO_LEN (512 / 8)
+ uint8_t data[ZTO_LEN];
+ for (unsigned i = 0; i < ZTO_LEN; ++i)
+data[i] = i + 0;
+
+ asm volatile("ldr zt0, [%0]" ::"r"(&data));
+#undef ZT0_LEN
+}
+
+int main() {
+ printf("Enable SME mode\n");
+
+ asm volatile("smstart");
+
+ write_sve_regs();
+
+ set_za_register(arm_sme_svl_b(), 4);
+
+ arm_sme2_set_zt0();
+
+ int c = 10; // break here
+ c += 5;
+ c += 5;
DavidSpickett wrote:
Ok right I didn't think about that.
Does this mean that executing expressions in streaming mode is patchy at best?
We're reliant on Clang not to choose the wrong thing.
https://github.com/llvm/llvm-project/pull/119171
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB][Process/Utility] Introduce NativeRegisterContextDBReg class (PR #118043)
https://github.com/DavidSpickett edited https://github.com/llvm/llvm-project/pull/118043 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][AIX] Header Parsing for XCOFF Object File in AIX (PR #116338)
@@ -98,9 +98,20 @@ class ObjectFileXCOFF : public lldb_private::ObjectFile {
const lldb::ProcessSP &process_sp, lldb::addr_t header_addr);
protected:
+ typedef struct llvm::object::XCOFFFileHeader64 xcoff_header_t;
+
+ typedef struct llvm::object::XCOFFAuxiliaryHeader64 xcoff_aux_header_t;
+
static lldb::WritableDataBufferSP
MapFileDataWritable(const lldb_private::FileSpec &file, uint64_t Size,
uint64_t Offset);
+
+private:
+ bool CreateBinary();
+
+ xcoff_header_t m_xcoff_header = {};
+ xcoff_aux_header_t m_xcoff_aux_header = {};
DhruvSrivastavaX wrote:
The reason to keep these is for the ease of access and avoid calling the
functions like `(file|auxiliary)Header(32|64)` functions repetitively whenever
the values are required in different functions.
https://github.com/llvm/llvm-project/pull/116338
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][AIX] Header Parsing for XCOFF Object File in AIX (PR #116338)
@@ -136,13 +169,42 @@ bool ObjectFileXCOFF::MagicBytesMatch(DataBufferSP
&data_sp,
return XCOFFHeaderSizeFromMagic(magic) != 0;
}
-bool ObjectFileXCOFF::ParseHeader() { return false; }
+bool ObjectFileXCOFF::ParseHeader() {
+
+ bool retVal = false;
+ ModuleSP module_sp(GetModule());
+ if (module_sp) {
+std::lock_guard guard(module_sp->GetMutex());
+
+const auto *fileHeaderPtr = m_binary->fileHeader64();
+m_xcoff_header = *fileHeaderPtr;
+if (m_xcoff_header.Magic != 0) {
+ if (m_xcoff_header.AuxHeaderSize > 0) {
+const auto *fileAuxHeader = m_binary->auxiliaryHeader64();
+m_xcoff_aux_header = *fileAuxHeader;
+ }
+ retVal = true;
+}
+ }
+
+ return retVal;
+}
ByteOrder ObjectFileXCOFF::GetByteOrder() const { return eByteOrderBig; }
bool ObjectFileXCOFF::IsExecutable() const { return true; }
-uint32_t ObjectFileXCOFF::GetAddressByteSize() const { return 8; }
+uint32_t ObjectFileXCOFF::GetAddressByteSize() const {
+ if (m_xcoff_header.Magic == XCOFF::XCOFF64)
+return 8;
+ else if (m_xcoff_header.Magic == XCOFF::XCOFF32)
+return 4;
+ return 4;
+}
DhruvSrivastavaX wrote:
Yes sure. 32 bit support is anyway a future item.
https://github.com/llvm/llvm-project/pull/116338
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][debugserver] Read/write SME registers on arm64 (PR #119171)
@@ -93,6 +93,55 @@ DNBArchMachARM64::SoftwareBreakpointOpcode(nub_size_t
byte_size) {
uint32_t DNBArchMachARM64::GetCPUType() { return CPU_TYPE_ARM64; }
+static std::once_flag g_cpu_has_sme_once;
+bool DNBArchMachARM64::CPUHasSME() {
+ static bool g_has_sme = false;
+ std::call_once(g_cpu_has_sme_once, []() {
+int ret = 0;
+size_t size = sizeof(ret);
+if (sysctlbyname("hw.optional.arm.FEAT_SME", &ret, &size, NULL, 0) != -1)
+ g_has_sme = ret == 1;
+ });
+ return g_has_sme;
+}
+
+static std::once_flag g_cpu_has_sme2_once;
+bool DNBArchMachARM64::CPUHasSME2() {
+ static bool g_has_sme2 = false;
+ std::call_once(g_cpu_has_sme2_once, []() {
+int ret = 0;
+size_t size = sizeof(ret);
+if (sysctlbyname("hw.optional.arm.FEAT_SME2", &ret, &size, NULL, 0) != -1)
+ g_has_sme2 = ret == 1;
+ });
+ return g_has_sme2;
+}
+
+static std::once_flag g_sme_max_svl_once;
+unsigned int DNBArchMachARM64::GetSMEMaxSVL() {
+ static unsigned int g_sme_max_svl = 0;
+ std::call_once(g_sme_max_svl_once, []() {
+if (CPUHasSME()) {
+ unsigned int ret = 0;
+ size_t size = sizeof(ret);
+ if (sysctlbyname("hw.optional.arm.sme_max_svl_b", &ret, &size, NULL, 0)
!=
+ -1)
+g_sme_max_svl = ret;
+ else
+g_sme_max_svl = get_svl_bytes();
+}
+ });
+ return g_sme_max_svl;
+}
+
+// This function can only be called on systems with hw.optional.arm.FEAT_SME
+// It will return the maximum SVL length for this process.
+uint16_t __attribute__((target("sme"))) DNBArchMachARM64::get_svl_bytes(void) {
+ uint64_t ret = 0;
+ asm volatile("rdsvl %[ret], #1" : [ret] "=r"(ret));
DavidSpickett wrote:
That would be my concern, older debug server - newer CPU with a wider SME unit.
You could leave it in as a last resort but I wonder if it would even be
understandable for users. If the kernel returns the registers in a buffer end
to end, and they're 128 byte but debugserver thinks they're 64 byte. It'll
likely 1. fail to read at all or 2. Show the first ZA row as the first two ZA
rows.
As opposed to what might be useful in some very niche scenario, where you could
see the bottom few bytes of each register.
Not that SME/SVE in its raw form is that useful to begin with.
https://github.com/llvm/llvm-project/pull/119171
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][AIX] Added base files for NativeProcess Support for AIX (PR #118160)
@@ -0,0 +1,248 @@ +//===-- NativeProcessAIX.cpp ===// +// +// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +// See https://llvm.org/LICENSE.txt for license information. +// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception +// +//===--===// + +#include "NativeProcessAIX.h" +#include "NativeThreadAIX.h" DhruvSrivastavaX wrote: I think the base ones in that regard will be HostInfo and Platform plugins. We are already discussing on the Host part, I will create another one with the Platform changes although even that is Linux derived as well, so maybe a minimal one for that as well might be a good idea? https://github.com/llvm/llvm-project/pull/118160 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB][Process/Utility] Introduce NativeRegisterContextDBReg class (PR #118043)
@@ -0,0 +1,90 @@
+//===-- NativeRegisterContextDBReg.h *- C++
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef lldb_NativeRegisterContextDBReg_h
+#define lldb_NativeRegisterContextDBReg_h
+
+#include "Plugins/Process/Utility/NativeRegisterContextRegisterInfo.h"
+
+#include
+
+namespace lldb_private {
+
+class NativeRegisterContextDBReg
+: public virtual NativeRegisterContextRegisterInfo {
+public:
+ uint32_t NumSupportedHardwareBreakpoints() override;
+
+ uint32_t SetHardwareBreakpoint(lldb::addr_t addr, size_t size) override;
+
+ bool ClearHardwareBreakpoint(uint32_t hw_idx) override;
+
+ Status ClearAllHardwareBreakpoints() override;
+
+ Status GetHardwareBreakHitIndex(uint32_t &bp_index,
+ lldb::addr_t trap_addr) override;
+
+ uint32_t NumSupportedHardwareWatchpoints() override;
+
+ uint32_t SetHardwareWatchpoint(lldb::addr_t addr, size_t size,
+ uint32_t watch_flags) override;
+
+ bool ClearHardwareWatchpoint(uint32_t hw_index) override;
+
+ Status ClearAllHardwareWatchpoints() override;
+
+ Status GetWatchpointHitIndex(uint32_t &wp_index,
+ lldb::addr_t trap_addr) override;
+
+ lldb::addr_t GetWatchpointHitAddress(uint32_t wp_index) override;
+
+ lldb::addr_t GetWatchpointAddress(uint32_t wp_index) override;
+
+protected:
+ // Debug register type select
+ enum DREGType { eDREGTypeWATCH = 0, eDREGTypeBREAK };
+
+ /// Debug register info for hardware breakpoints and watchpoints management.
+ struct DREG {
+lldb::addr_t address; // Breakpoint/watchpoint address value.
+lldb::addr_t hit_addr; // Address at which last watchpoint trigger
exception
+ // occurred.
+lldb::addr_t real_addr; // Address value that should cause target to stop.
+uint32_t control; // Breakpoint/watchpoint control value.
+ };
+
+ std::array m_hbp_regs; // hardware breakpoints
+ std::array m_hwp_regs; // hardware watchpoints
+
+ uint32_t m_max_hbp_supported;
+ uint32_t m_max_hwp_supported;
+ uint32_t m_hw_dbg_enable_bit;
+
+ bool WatchpointIsEnabled(uint32_t wp_index);
+ bool BreakpointIsEnabled(uint32_t bp_index);
+
+ // Default hardware breakpoint length size is 4.
+ // Default hardware breakpoint target address must 4-byte alignment.
+ virtual bool ValidateBreakpoint(size_t size, lldb::addr_t addr) {
+return (size == 4) && !(addr & 0x3);
wangleiat wrote:
Yes, it's the same. I will update the comments. Thank you!
https://github.com/llvm/llvm-project/pull/118043
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB][Process/Utility] Introduce NativeRegisterContextDBReg class (PR #118043)
wangleiat wrote: > This passed all tests. Some remaining cosmetic issues but otherwise looks > good. > > We could go more into the style issues here but > > 1. This code was like that before, you just moved it, so it's not actually a > regression. > 2. I don't want to get into refactoring and break tests again. If we want to > do that we can do it in small pieces later. > > Going to look again at the follow up PR as well. Do you mean submitting the subsequent changes in a new PR? Since the `llvm::Error -> Status` modification is incomplete, it will cause a compilation error in `NativeRegisterContextFreeBSD_arm64.cpp`. Can I continue making modifications in this PR? https://github.com/llvm/llvm-project/pull/118043 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] c00a708 - [lldb] Eliminate dead code (NFC)
Author: Adrian Prantl
Date: 2024-12-10T17:09:44-08:00
New Revision: c00a708fc954f450679bf0e171029f8da4841cfb
URL:
https://github.com/llvm/llvm-project/commit/c00a708fc954f450679bf0e171029f8da4841cfb
DIFF:
https://github.com/llvm/llvm-project/commit/c00a708fc954f450679bf0e171029f8da4841cfb.diff
LOG: [lldb] Eliminate dead code (NFC)
Added:
Modified:
lldb/source/DataFormatters/FormatterBytecode.cpp
Removed:
diff --git a/lldb/source/DataFormatters/FormatterBytecode.cpp
b/lldb/source/DataFormatters/FormatterBytecode.cpp
index a8975494b83670..f344fbaff6f02a 100644
--- a/lldb/source/DataFormatters/FormatterBytecode.cpp
+++ b/lldb/source/DataFormatters/FormatterBytecode.cpp
@@ -392,8 +392,6 @@ llvm::Error Interpret(std::vector
&control,
int64_t x = data.Pop();
\
if (y > 64)
\
return error("shift out of bounds");
\
- if (y < 0)
\
-return error("shift out of bounds");
\
data.Push(x OP y);
\
} else
\
return error("unsupported data types");
\
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Implement basic support for reverse-continue (PR #112079)
@@ -1265,14 +1280,11 @@ Status ProcessGDBRemote::DoResume() {
} else
continue_packet_error = true;
-if (continue_packet_error) {
+if (direction == RunDirection::eRunForward && continue_packet_error) {
// Either no vCont support, or we tried to use part of the vCont packet
- // that wasn't supported by the remote GDB server. We need to try and
- // make a simple packet that can do our continue
- const size_t num_continue_c_tids = m_continue_c_tids.size();
- const size_t num_continue_C_tids = m_continue_C_tids.size();
- const size_t num_continue_s_tids = m_continue_s_tids.size();
- const size_t num_continue_S_tids = m_continue_S_tids.size();
+ // that wasn't supported by the remote GDB server, or it's the reverse
jimingham wrote:
It's a bit weird to have this comment here, since this is commenting after an
if test that rules out reverse continuing. If you wanted to describe the
general strategy of "first try forward direction: (a) vCont first, then (b)
without vCont then backwards" that should go before you start doing any of
this.
https://github.com/llvm/llvm-project/pull/112079
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Implement basic support for reverse-continue (PR #112079)
@@ -1363,9 +1375,51 @@ Status ProcessGDBRemote::DoResume() {
}
}
+if (direction == RunDirection::eRunReverse && continue_packet_error) {
jimingham wrote:
Why do you care about continue_packet_error here? That was being manipulated
by the code that tried to go forward. But you're going backwards here, so you
shouldn't have gotten into any of that code, nor should you care what value the
forward going code set this to.
https://github.com/llvm/llvm-project/pull/112079
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Implement basic support for reverse-continue (PR #112079)
@@ -1363,9 +1375,51 @@ Status ProcessGDBRemote::DoResume() {
}
}
+if (direction == RunDirection::eRunReverse && continue_packet_error) {
+ if (num_continue_C_tids > 0 || num_continue_S_tids > 0) {
+LLDB_LOGF(log,
+ "ProcessGDBRemote::DoResumeReverse: Signals not supported");
+return Status::FromErrorString(
+"can't deliver signals while running in reverse");
+ }
+
+ if (num_continue_s_tids > 0) {
+if (num_continue_s_tids > 1) {
+ LLDB_LOGF(
+ log,
+ "ProcessGDBRemote::DoResumeReverse: can't step multiple
threads");
+ return Status::FromErrorString(
+ "can't step multiple threads while reverse-stepping");
+}
+
+if (!m_gdb_comm.GetReverseStepSupported()) {
jimingham wrote:
I think this should be checked first. It's kind of goofy if you try to do a
"reverse step with signal" and get told that "can't deliver signals while
running in reverse", so then you say "okay just do the reverse step" and get
told that the target doesn't in fact support reverse continue at all...
https://github.com/llvm/llvm-project/pull/112079
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Implement basic support for reverse-continue (PR #112079)
@@ -1363,9 +1375,51 @@ Status ProcessGDBRemote::DoResume() {
}
}
+if (direction == RunDirection::eRunReverse && continue_packet_error) {
+ if (num_continue_C_tids > 0 || num_continue_S_tids > 0) {
+LLDB_LOGF(log,
+ "ProcessGDBRemote::DoResumeReverse: Signals not supported");
+return Status::FromErrorString(
+"can't deliver signals while running in reverse");
+ }
+
+ if (num_continue_s_tids > 0) {
+if (num_continue_s_tids > 1) {
+ LLDB_LOGF(
+ log,
+ "ProcessGDBRemote::DoResumeReverse: can't step multiple
threads");
+ return Status::FromErrorString(
+ "can't step multiple threads while reverse-stepping");
+}
+
+if (!m_gdb_comm.GetReverseStepSupported()) {
jimingham wrote:
You could actually just hoist this check right after the `if (direction ==
RunDirection::eRunReverse` and you wouldn't have to repeat it below.
https://github.com/llvm/llvm-project/pull/112079
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Implement a formatter bytecode interpreter in C++ (PR #114333)
adrian-prantl wrote: @dyung https://lab.llvm.org/buildbot/#/builders/181/builds/10131 is green again, too. https://github.com/llvm/llvm-project/pull/114333 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Implement basic support for reverse-continue (PR #112079)
@@ -2318,6 +2376,8 @@ StateType
ProcessGDBRemote::SetThreadStopInfo(StringExtractor &stop_packet) {
description = std::string(ostr.GetString());
} else if (key.compare("swbreak") == 0 || key.compare("hwbreak") == 0) {
reason = "breakpoint";
+ } else if (key.compare("replaylog") == 0) {
+reason = "replaylog";
jimingham wrote:
This is a string that will get shown to users in the stop reporting.
"replaylog" is a bit opaque.
https://github.com/llvm/llvm-project/pull/112079
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Implement basic support for reverse-continue (PR #112079)
@@ -182,10 +182,16 @@ void ScriptedProcess::DidResume() {
m_pid = GetInterface().GetProcessID();
}
-Status ScriptedProcess::DoResume() {
+Status ScriptedProcess::DoResume(RunDirection direction) {
LLDB_LOGF(GetLog(LLDBLog::Process), "ScriptedProcess::%s resuming process",
__FUNCTION__);
- return GetInterface().Resume();
+ if (direction == RunDirection::eRunForward) {
+return GetInterface().Resume();
+ } else {
+return Status::FromErrorStringWithFormatv(
jimingham wrote:
I don't expect you to support this, but can you put a
// FIXME: Pipe reverse continue through Scripted Processes
here. There's no reason why scripted processes couldn't support reverse
continue.
https://github.com/llvm/llvm-project/pull/112079
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Implement basic support for reverse-continue (PR #112079)
@@ -3239,6 +3241,14 @@ Status Process::ConnectRemote(llvm::StringRef
remote_url) {
return error;
}
+void Process::SetRunDirection(RunDirection direction) {
+ if (m_base_direction == direction) {
+return;
+ }
+ m_thread_list.DiscardThreadPlans();
jimingham wrote:
Somewhere we should say that we're allowing ourselves the simplification that
the ThreadPlanStacks have to be homogeneous in direction, but that we should be
able to relax that in the future. Maybe here or maybe there should be a more
general comment describing your strategy here.
https://github.com/llvm/llvm-project/pull/112079
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Implement basic support for reverse-continue (PR #112079)
@@ -3265,18 +3275,25 @@ Status Process::PrivateResume() {
// (suspended/running/stepping). Threads should also check their resume
// signal in lldb::Thread::GetResumeSignal() to see if they are supposed to
// start back up with a signal.
-if (m_thread_list.WillResume()) {
+RunDirection direction;
jimingham wrote:
I think it would be a lot cleaner to have Process::CanReverseContinue, and
check that before WillResume or anything. If you are asked to go in reverse
and it's not supported, we should do as little work as possible before
returning an error.
https://github.com/llvm/llvm-project/pull/112079
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [clang] [lldb] [Serialization] Support loading template specializations lazily (PR #119333)
https://github.com/ChuanqiXu9 closed https://github.com/llvm/llvm-project/pull/119333 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] 20e9049 - [Serialization] Support loading template specializations lazily (#119333)
Author: Chuanqi Xu
Date: 2024-12-11T09:40:47+08:00
New Revision: 20e904950967c125abc1e91f57e5a373987ff016
URL:
https://github.com/llvm/llvm-project/commit/20e904950967c125abc1e91f57e5a373987ff016
DIFF:
https://github.com/llvm/llvm-project/commit/20e904950967c125abc1e91f57e5a373987ff016.diff
LOG: [Serialization] Support loading template specializations lazily (#119333)
Reland https://github.com/llvm/llvm-project/pull/83237
---
(Original comments)
Currently all the specializations of a template (including
instantiation, specialization and partial specializations) will be
loaded at once if we want to instantiate another instance for the
template, or find instantiation for the template, or just want to
complete the redecl chain.
This means basically we need to load every specializations for the
template once the template declaration got loaded. This is bad since
when we load a specialization, we need to load all of its template
arguments. Then we have to deserialize a lot of unnecessary
declarations.
For example,
```
// M.cppm
export module M;
export template
class A {};
export class ShouldNotBeLoaded {};
export class Temp {
A AS;
};
// use.cpp
import M;
A a;
```
We have a specialization ` A` in `M.cppm` and we
instantiate the template `A` in `use.cpp`. Then we will deserialize
`ShouldNotBeLoaded` surprisingly when compiling `use.cpp`. And this
patch tries to avoid that.
Given that the templates are heavily used in C++, this is a pain point
for the performance.
This patch adds MultiOnDiskHashTable for specializations in the
ASTReader. Then we will only deserialize the specializations with the
same template arguments. We made that by using ODRHash for the template
arguments as the key of the hash table.
To review this patch, I think `ASTReaderDecl::AddLazySpecializations`
may be a good entry point.
Added:
clang/lib/Serialization/TemplateArgumentHasher.cpp
clang/lib/Serialization/TemplateArgumentHasher.h
clang/test/Modules/recursive-instantiations.cppm
clang/unittests/Serialization/LoadSpecLazilyTest.cpp
Modified:
clang/include/clang/AST/DeclTemplate.h
clang/include/clang/AST/ExternalASTSource.h
clang/include/clang/Sema/MultiplexExternalSemaSource.h
clang/include/clang/Serialization/ASTBitCodes.h
clang/include/clang/Serialization/ASTReader.h
clang/include/clang/Serialization/ASTWriter.h
clang/lib/AST/DeclTemplate.cpp
clang/lib/AST/ExternalASTSource.cpp
clang/lib/AST/ODRHash.cpp
clang/lib/Sema/MultiplexExternalSemaSource.cpp
clang/lib/Serialization/ASTCommon.h
clang/lib/Serialization/ASTReader.cpp
clang/lib/Serialization/ASTReaderDecl.cpp
clang/lib/Serialization/ASTReaderInternals.h
clang/lib/Serialization/ASTWriter.cpp
clang/lib/Serialization/ASTWriterDecl.cpp
clang/lib/Serialization/CMakeLists.txt
clang/test/Modules/cxx-templates.cpp
clang/test/Modules/odr_hash.cpp
clang/test/OpenMP/target_parallel_ast_print.cpp
clang/test/OpenMP/target_teams_ast_print.cpp
clang/test/OpenMP/task_ast_print.cpp
clang/test/OpenMP/teams_ast_print.cpp
clang/unittests/Serialization/CMakeLists.txt
lldb/source/Plugins/ExpressionParser/Clang/ASTUtils.h
Removed:
diff --git a/clang/include/clang/AST/DeclTemplate.h
b/clang/include/clang/AST/DeclTemplate.h
index e4bf54c3d77b7f..dd92d40b804232 100644
--- a/clang/include/clang/AST/DeclTemplate.h
+++ b/clang/include/clang/AST/DeclTemplate.h
@@ -735,6 +735,7 @@ class RedeclarableTemplateDecl : public TemplateDecl,
}
void anchor() override;
+
protected:
template struct SpecEntryTraits {
using DeclType = EntryType;
@@ -775,13 +776,22 @@ class RedeclarableTemplateDecl : public TemplateDecl,
return SpecIterator(isEnd ? Specs.end() : Specs.begin());
}
- void loadLazySpecializationsImpl() const;
+ void loadLazySpecializationsImpl(bool OnlyPartial = false) const;
+
+ bool loadLazySpecializationsImpl(llvm::ArrayRef Args,
+ TemplateParameterList *TPL = nullptr) const;
template
typename SpecEntryTraits::DeclType*
findSpecializationImpl(llvm::FoldingSetVector &Specs,
void *&InsertPos, ProfileArguments &&...ProfileArgs);
+ template
+ typename SpecEntryTraits::DeclType *
+ findSpecializationLocally(llvm::FoldingSetVector &Specs,
+void *&InsertPos,
+ProfileArguments &&...ProfileArgs);
+
template
void addSpecializationImpl(llvm::FoldingSetVector &Specs,
EntryType *Entry, void *InsertPos);
@@ -796,13 +806,6 @@ class RedeclarableTemplateDecl : public TemplateDecl,
/// was explicitly specialized.
llvm::PointerIntPair
InstantiatedFromMember;
-
-/// If non-null, points to an array of specializations (including
-/// partial specializations) known only by their
[Lldb-commits] [lldb] [lldb] Implement basic support for reverse-continue (PR #112079)
@@ -617,25 +617,26 @@ void Thread::WillStop() {
current_plan->WillStop();
}
-void Thread::SetupForResume() {
+bool Thread::StepOverBreakpointIfNeeded(RunDirection direction) {
jimingham wrote:
That name no longer describes what this function does. It checks more things
than just whether we need to step over a breakpoint, like whether this thread
is suspended so we don't need to do anything, or if this is going to be a
virtual step so we don't need to resume either.
SetUpForResume is a little too vague, but it's worse to say the function only
does certain things when that's not in fact true.
https://github.com/llvm/llvm-project/pull/112079
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [clang] [lldb] [Serialization] Support loading template specializations lazily (PR #119333)
ChuanqiXu9 wrote: Thanks. Given the change in lldb is trivial, I'd like to land it to see what happens. https://github.com/llvm/llvm-project/pull/119333 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB][Process/Utility] Introduce NativeRegisterContextDBReg class (PR #118043)
https://github.com/wangleiat updated
https://github.com/llvm/llvm-project/pull/118043
>From a7cba7ef089a6f2004b1879d30675652729370e5 Mon Sep 17 00:00:00 2001
From: wanglei
Date: Fri, 29 Nov 2024 10:43:31 +0800
Subject: [PATCH 1/2] =?UTF-8?q?[=F0=9D=98=80=F0=9D=97=BD=F0=9D=97=BF]=20in?=
=?UTF-8?q?itial=20version?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Created using spr 1.3.5-bogner
---
...NativeRegisterContextLinux_loongarch64.cpp | 484 ++
.../NativeRegisterContextLinux_loongarch64.h | 60 +++
.../GDBRemoteCommunicationServerCommon.cpp| 3 +-
lldb/source/Target/Process.cpp| 3 +-
4 files changed, 548 insertions(+), 2 deletions(-)
diff --git
a/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_loongarch64.cpp
b/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_loongarch64.cpp
index f4d1bb297049da..1f73bd0467962d 100644
---
a/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_loongarch64.cpp
+++
b/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_loongarch64.cpp
@@ -11,7 +11,9 @@
#include "NativeRegisterContextLinux_loongarch64.h"
#include "lldb/Host/HostInfo.h"
+#include "lldb/Host/linux/Ptrace.h"
#include "lldb/Utility/DataBufferHeap.h"
+#include "lldb/Utility/LLDBLog.h"
#include "lldb/Utility/Log.h"
#include "lldb/Utility/RegisterValue.h"
#include "lldb/Utility/Status.h"
@@ -32,6 +34,19 @@ using namespace lldb;
using namespace lldb_private;
using namespace lldb_private::process_linux;
+// CTRL_PLV3_ENABLE, used to enable breakpoint/watchpoint
+constexpr uint32_t g_enable_bit = 0x10;
+
+// Returns appropriate control register bits for the specified size
+// size encoded:
+// case 1 : 0b11
+// case 2 : 0b10
+// case 4 : 0b01
+// case 8 : 0b00
+static inline uint64_t GetSizeBits(int size) {
+ return (3 - llvm::Log2_32(size)) << 10;
+}
+
std::unique_ptr
NativeRegisterContextLinux::CreateHostNativeRegisterContextLinux(
const ArchSpec &target_arch, NativeThreadLinux &native_thread) {
@@ -61,6 +76,8 @@
NativeRegisterContextLinux_loongarch64::NativeRegisterContextLinux_loongarch64(
NativeRegisterContextLinux(native_thread) {
::memset(&m_fpr, 0, sizeof(m_fpr));
::memset(&m_gpr, 0, sizeof(m_gpr));
+ ::memset(&m_hwp_regs, 0, sizeof(m_hwp_regs));
+ ::memset(&m_hbp_regs, 0, sizeof(m_hbp_regs));
m_gpr_is_valid = false;
m_fpu_is_valid = false;
@@ -337,4 +354,471 @@
NativeRegisterContextLinux_loongarch64::GetExpeditedRegisters(
return expedited_reg_nums;
}
+uint32_t
+NativeRegisterContextLinux_loongarch64::NumSupportedHardwareBreakpoints() {
+ Log *log = GetLog(LLDBLog::Breakpoints);
+
+ // Read hardware breakpoint and watchpoint information.
+ Status error = ReadHardwareDebugInfo();
+
+ if (error.Fail()) {
+LLDB_LOG(log, "failed to read debug registers");
+return 0;
+ }
+
+ LLDB_LOG(log, "{0}", m_max_hbp_supported);
+ return m_max_hbp_supported;
+}
+
+uint32_t
+NativeRegisterContextLinux_loongarch64::SetHardwareBreakpoint(lldb::addr_t
addr,
+ size_t size) {
+ Log *log = GetLog(LLDBLog::Breakpoints);
+ LLDB_LOG(log, "addr: {0:x}, size: {1:x}", addr, size);
+
+ // Read hardware breakpoint and watchpoint information.
+ Status error = ReadHardwareDebugInfo();
+ if (error.Fail()) {
+LLDB_LOG(log, "unable to set breakpoint: failed to read debug registers");
+return LLDB_INVALID_INDEX32;
+ }
+
+ uint32_t bp_index = 0;
+
+ // Check if size has a valid hardware breakpoint length.
+ if (size != 4)
+return LLDB_INVALID_INDEX32; // Invalid size for a LoongArch hardware
+ // breakpoint
+
+ // Check 4-byte alignment for hardware breakpoint target address.
+ if (addr & 0x03)
+return LLDB_INVALID_INDEX32; // Invalid address, should be 4-byte aligned.
+
+ // Iterate over stored breakpoints and find a free bp_index
+ bp_index = LLDB_INVALID_INDEX32;
+ for (uint32_t i = 0; i < m_max_hbp_supported; i++) {
+if (!BreakpointIsEnabled(i))
+ bp_index = i; // Mark last free slot
+else if (m_hbp_regs[i].address == addr)
+ return LLDB_INVALID_INDEX32; // We do not support duplicate breakpoints.
+ }
+
+ if (bp_index == LLDB_INVALID_INDEX32)
+return LLDB_INVALID_INDEX32;
+
+ // Update breakpoint in local cache
+ m_hbp_regs[bp_index].address = addr;
+ m_hbp_regs[bp_index].control = g_enable_bit;
+
+ // PTRACE call to set corresponding hardware breakpoint register.
+ error = WriteHardwareDebugRegs(eDREGTypeBREAK);
+
+ if (error.Fail()) {
+m_hbp_regs[bp_index].address = 0;
+m_hbp_regs[bp_index].control = 0;
+
+LLDB_LOG(log, "unable to set breakpoint: failed to write debug registers");
+return LLDB_INVALID_INDEX32;
+ }
+
+ return bp_index;
+}
+bool NativeRegisterContextLinux_loongarch64::ClearHardwareBreakpoint(
+uint32_t hw_idx) {
+ Log *log = GetLog(LLDBLog::Breakpoin
