[Lldb-commits] [lldb] [lldb] fix vFile:open, vFile:unlink error codes (PR #106950)
DavidSpickett wrote: Yes working to the standard is good, but in the minority of cases where you do get a strange errno, `GDB_EUNKNOWN` is zero help and then you're working out the `lldb-server gdbserver --log-channels` etc. command to get it to print the real number. So far that hasn't been annoying enough to enough people for anyone to add a side channel to send the unmodified errno. https://github.com/llvm/llvm-project/pull/106950 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][AArch64] Add register fields for the fpmr register (PR #109934)
https://github.com/omjavaid approved this pull request. Looks good to me but I have not tested this. https://github.com/llvm/llvm-project/pull/109934 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] 0e24611 - [lldb][AArch64] Add register fields for the fpmr register (#109934)
Author: David Spickett
Date: 2024-09-26T11:44:01+01:00
New Revision: 0e24611f5703d56a93fc2f7e46c73fabf2e3a8fe
URL:
https://github.com/llvm/llvm-project/commit/0e24611f5703d56a93fc2f7e46c73fabf2e3a8fe
DIFF:
https://github.com/llvm/llvm-project/commit/0e24611f5703d56a93fc2f7e46c73fabf2e3a8fe.diff
LOG: [lldb][AArch64] Add register fields for the fpmr register (#109934)
The FP8 formats have a "_" in the name so that they are:
1. Easier to read.
2. Possible to use in register expressions if/when they are supported.
Some other bits do have defined meanings but they are not simple to
name. Better that folks read the manual for those.
See this page for the full details:
https://developer.arm.com/documentation/ddi0601/2024-06/AArch64-Registers/FPMR--Floating-point-Mode-Register
Added:
Modified:
lldb/source/Plugins/Process/Utility/RegisterFlagsDetector_arm64.cpp
lldb/source/Plugins/Process/Utility/RegisterFlagsDetector_arm64.h
lldb/test/API/linux/aarch64/fpmr/TestAArch64LinuxFPMR.py
Removed:
diff --git
a/lldb/source/Plugins/Process/Utility/RegisterFlagsDetector_arm64.cpp
b/lldb/source/Plugins/Process/Utility/RegisterFlagsDetector_arm64.cpp
index 7c8dba3680938d..72ced42a158233 100644
--- a/lldb/source/Plugins/Process/Utility/RegisterFlagsDetector_arm64.cpp
+++ b/lldb/source/Plugins/Process/Utility/RegisterFlagsDetector_arm64.cpp
@@ -23,9 +23,33 @@
#define HWCAP2_AFP (1ULL << 20)
#define HWCAP2_SME (1ULL << 23)
#define HWCAP2_EBF16 (1ULL << 32)
+#define HWCAP2_FPMR (1UL << 48)
using namespace lldb_private;
+Arm64RegisterFlagsDetector::Fields
+Arm64RegisterFlagsDetector::DetectFPMRFields(uint64_t hwcap, uint64_t hwcap2) {
+ (void)hwcap;
+
+ if (!(hwcap2 & HWCAP2_FPMR))
+return {};
+
+ static const FieldEnum fp8_format_enum("fp8_format_enum", {
+{0,
"FP8_E5M2"},
+{1,
"FP8_E4M3"},
+});
+ return {
+ {"LSCALE2", 32, 37},
+ {"NSCALE", 24, 31},
+ {"LSCALE", 16, 22},
+ {"OSC", 15},
+ {"OSM", 14},
+ {"F8D", 6, 8, &fp8_format_enum},
+ {"F8S2", 3, 5, &fp8_format_enum},
+ {"F8S1", 0, 2, &fp8_format_enum},
+ };
+}
+
Arm64RegisterFlagsDetector::Fields
Arm64RegisterFlagsDetector::DetectSVCRFields(uint64_t hwcap, uint64_t hwcap2) {
(void)hwcap;
diff --git a/lldb/source/Plugins/Process/Utility/RegisterFlagsDetector_arm64.h
b/lldb/source/Plugins/Process/Utility/RegisterFlagsDetector_arm64.h
index a5bb38670b9cdf..0f3d53d93892bd 100644
--- a/lldb/source/Plugins/Process/Utility/RegisterFlagsDetector_arm64.h
+++ b/lldb/source/Plugins/Process/Utility/RegisterFlagsDetector_arm64.h
@@ -60,6 +60,7 @@ class Arm64RegisterFlagsDetector {
static Fields DetectFPCRFields(uint64_t hwcap, uint64_t hwcap2);
static Fields DetectMTECtrlFields(uint64_t hwcap, uint64_t hwcap2);
static Fields DetectSVCRFields(uint64_t hwcap, uint64_t hwcap2);
+ static Fields DetectFPMRFields(uint64_t hwcap, uint64_t hwcap2);
struct RegisterEntry {
RegisterEntry(llvm::StringRef name, unsigned size, DetectorFn detector)
@@ -69,12 +70,13 @@ class Arm64RegisterFlagsDetector {
llvm::StringRef m_name;
RegisterFlags m_flags;
DetectorFn m_detector;
- } m_registers[5] = {
+ } m_registers[6] = {
RegisterEntry("cpsr", 4, DetectCPSRFields),
RegisterEntry("fpsr", 4, DetectFPSRFields),
RegisterEntry("fpcr", 4, DetectFPCRFields),
RegisterEntry("mte_ctrl", 8, DetectMTECtrlFields),
RegisterEntry("svcr", 8, DetectSVCRFields),
+ RegisterEntry("fpmr", 8, DetectFPMRFields),
};
// Becomes true once field detection has been run for all registers.
diff --git a/lldb/test/API/linux/aarch64/fpmr/TestAArch64LinuxFPMR.py
b/lldb/test/API/linux/aarch64/fpmr/TestAArch64LinuxFPMR.py
index 5a3b8f501095e9..d022c8eb3d6cc4 100644
--- a/lldb/test/API/linux/aarch64/fpmr/TestAArch64LinuxFPMR.py
+++ b/lldb/test/API/linux/aarch64/fpmr/TestAArch64LinuxFPMR.py
@@ -45,6 +45,11 @@ def test_fpmr_register(self):
substrs=["Floating Point Mode Register", f"fpmr =
{expected_fpmr:#018x}"],
)
+if self.hasXMLSupport():
+self.expect(
+"register read fpmr", substrs=["LSCALE2 = 42", "F8S1 =
FP8_E4M3 | 0x4"]
+)
+
# Write a value for the program to find. Same fields but with bit
values
# inverted.
new_fpmr = (0b010101 << 32) | 0b010
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][AArch64] Read fpmr register from core files (PR #110104)
https://github.com/DavidSpickett created
https://github.com/llvm/llvm-project/pull/110104
None
>From 58911927a59557aab167792f62f2c9ba9a86fa0d Mon Sep 17 00:00:00 2001
From: David Spickett
Date: Thu, 29 Aug 2024 16:18:56 +0100
Subject: [PATCH] [lldb][AArch64] Read fpmr register from core files
---
.../RegisterContextPOSIXCore_arm64.cpp| 13 +++
.../elf-core/RegisterContextPOSIXCore_arm64.h | 1 +
.../Process/elf-core/RegisterUtilities.h | 4 +++
.../aarch64/fpmr/TestAArch64LinuxFPMR.py | 32 ++
lldb/test/API/linux/aarch64/fpmr/corefile | Bin 0 -> 20480 bytes
lldb/test/API/linux/aarch64/fpmr/main.c | 5 ++-
6 files changed, 48 insertions(+), 7 deletions(-)
create mode 100644 lldb/test/API/linux/aarch64/fpmr/corefile
diff --git
a/lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_arm64.cpp
b/lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_arm64.cpp
index 413bf1bbdb2a58..2ddf8440aeb035 100644
--- a/lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_arm64.cpp
+++ b/lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_arm64.cpp
@@ -64,6 +64,11 @@ RegisterContextCorePOSIX_arm64::Create(Thread &thread, const
ArchSpec &arch,
if (zt_data.GetByteSize() >= 64)
opt_regsets.Set(RegisterInfoPOSIX_arm64::eRegsetMaskZT);
+ DataExtractor fpmr_data =
+ getRegset(notes, arch.GetTriple(), AARCH64_FPMR_Desc);
+ if (fpmr_data.GetByteSize() >= sizeof(uint64_t))
+opt_regsets.Set(RegisterInfoPOSIX_arm64::eRegsetMaskFPMR);
+
auto register_info_up =
std::make_unique(arch, opt_regsets);
return std::unique_ptr(
@@ -128,6 +133,9 @@
RegisterContextCorePOSIX_arm64::RegisterContextCorePOSIX_arm64(
if (m_register_info_up->IsZTPresent())
m_zt_data = getRegset(notes, target_triple, AARCH64_ZT_Desc);
+ if (m_register_info_up->IsFPMRPresent())
+m_fpmr_data = getRegset(notes, target_triple, AARCH64_FPMR_Desc);
+
ConfigureRegisterContext();
}
@@ -370,6 +378,11 @@ bool RegisterContextCorePOSIX_arm64::ReadRegister(const
RegisterInfo *reg_info,
*reg_info, reinterpret_cast(&m_sme_pseudo_regs) + offset,
reg_info->byte_size, lldb_private::endian::InlHostByteOrder(),
error);
}
+ } else if (IsFPMR(reg)) {
+offset = reg_info->byte_offset - m_register_info_up->GetFPMROffset();
+assert(offset < m_fpmr_data.GetByteSize());
+value.SetFromMemoryData(*reg_info, m_fpmr_data.GetDataStart() + offset,
+reg_info->byte_size, lldb::eByteOrderLittle,
error);
} else
return false;
diff --git
a/lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_arm64.h
b/lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_arm64.h
index ff94845e58d602..35588c40c2eb1a 100644
--- a/lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_arm64.h
+++ b/lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_arm64.h
@@ -62,6 +62,7 @@ class RegisterContextCorePOSIX_arm64 : public
RegisterContextPOSIX_arm64 {
lldb_private::DataExtractor m_za_data;
lldb_private::DataExtractor m_mte_data;
lldb_private::DataExtractor m_zt_data;
+ lldb_private::DataExtractor m_fpmr_data;
SVEState m_sve_state = SVEState::Unknown;
uint16_t m_sve_vector_length = 0;
diff --git a/lldb/source/Plugins/Process/elf-core/RegisterUtilities.h
b/lldb/source/Plugins/Process/elf-core/RegisterUtilities.h
index 12aa5f72371c51..b97279b0d735b8 100644
--- a/lldb/source/Plugins/Process/elf-core/RegisterUtilities.h
+++ b/lldb/source/Plugins/Process/elf-core/RegisterUtilities.h
@@ -144,6 +144,10 @@ constexpr RegsetDesc AARCH64_MTE_Desc[] = {
llvm::ELF::NT_ARM_TAGGED_ADDR_CTRL},
};
+constexpr RegsetDesc AARCH64_FPMR_Desc[] = {
+{llvm::Triple::Linux, llvm::Triple::aarch64, llvm::ELF::NT_ARM_FPMR},
+};
+
constexpr RegsetDesc PPC_VMX_Desc[] = {
{llvm::Triple::FreeBSD, llvm::Triple::UnknownArch, llvm::ELF::NT_PPC_VMX},
{llvm::Triple::Linux, llvm::Triple::UnknownArch, llvm::ELF::NT_PPC_VMX},
diff --git a/lldb/test/API/linux/aarch64/fpmr/TestAArch64LinuxFPMR.py
b/lldb/test/API/linux/aarch64/fpmr/TestAArch64LinuxFPMR.py
index d022c8eb3d6cc4..7f8dc811c5df36 100644
--- a/lldb/test/API/linux/aarch64/fpmr/TestAArch64LinuxFPMR.py
+++ b/lldb/test/API/linux/aarch64/fpmr/TestAArch64LinuxFPMR.py
@@ -11,9 +11,13 @@
class AArch64LinuxFPMR(TestBase):
NO_DEBUG_INFO_TESTCASE = True
+# The value set by the inferior.
+EXPECTED_FPMR = (0b101010 << 32) | 0b101
+EXPECTED_FPMR_FIELDS = ["LSCALE2 = 42", "F8S1 = FP8_E4M3 | 0x4"]
+
@skipUnlessArch("aarch64")
@skipUnlessPlatform(["linux"])
-def test_fpmr_register(self):
+def test_fpmr_register_live(self):
if not self.isAArch64FPMR():
self.skipTest("FPMR must be present.")
@@ -39,16 +43,16 @@ def test_fpmr_register(self):
)
# This has been set by the program.
-expected_fpmr = (0b101010 << 32) | 0b101
[Lldb-commits] [lldb] [lldb][AArch64] Read fpmr register from core files (PR #110104)
https://github.com/DavidSpickett edited https://github.com/llvm/llvm-project/pull/110104 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][AArch64] Read fpmr register from core files (PR #110104)
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: David Spickett (DavidSpickett)
Changes
---
Full diff: https://github.com/llvm/llvm-project/pull/110104.diff
6 Files Affected:
- (modified)
lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_arm64.cpp (+13)
- (modified)
lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_arm64.h (+1)
- (modified) lldb/source/Plugins/Process/elf-core/RegisterUtilities.h (+4)
- (modified) lldb/test/API/linux/aarch64/fpmr/TestAArch64LinuxFPMR.py (+26-6)
- (added) lldb/test/API/linux/aarch64/fpmr/corefile ()
- (modified) lldb/test/API/linux/aarch64/fpmr/main.c (+4-1)
``diff
diff --git
a/lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_arm64.cpp
b/lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_arm64.cpp
index 413bf1bbdb2a58..2ddf8440aeb035 100644
--- a/lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_arm64.cpp
+++ b/lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_arm64.cpp
@@ -64,6 +64,11 @@ RegisterContextCorePOSIX_arm64::Create(Thread &thread, const
ArchSpec &arch,
if (zt_data.GetByteSize() >= 64)
opt_regsets.Set(RegisterInfoPOSIX_arm64::eRegsetMaskZT);
+ DataExtractor fpmr_data =
+ getRegset(notes, arch.GetTriple(), AARCH64_FPMR_Desc);
+ if (fpmr_data.GetByteSize() >= sizeof(uint64_t))
+opt_regsets.Set(RegisterInfoPOSIX_arm64::eRegsetMaskFPMR);
+
auto register_info_up =
std::make_unique(arch, opt_regsets);
return std::unique_ptr(
@@ -128,6 +133,9 @@
RegisterContextCorePOSIX_arm64::RegisterContextCorePOSIX_arm64(
if (m_register_info_up->IsZTPresent())
m_zt_data = getRegset(notes, target_triple, AARCH64_ZT_Desc);
+ if (m_register_info_up->IsFPMRPresent())
+m_fpmr_data = getRegset(notes, target_triple, AARCH64_FPMR_Desc);
+
ConfigureRegisterContext();
}
@@ -370,6 +378,11 @@ bool RegisterContextCorePOSIX_arm64::ReadRegister(const
RegisterInfo *reg_info,
*reg_info, reinterpret_cast(&m_sme_pseudo_regs) + offset,
reg_info->byte_size, lldb_private::endian::InlHostByteOrder(),
error);
}
+ } else if (IsFPMR(reg)) {
+offset = reg_info->byte_offset - m_register_info_up->GetFPMROffset();
+assert(offset < m_fpmr_data.GetByteSize());
+value.SetFromMemoryData(*reg_info, m_fpmr_data.GetDataStart() + offset,
+reg_info->byte_size, lldb::eByteOrderLittle,
error);
} else
return false;
diff --git
a/lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_arm64.h
b/lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_arm64.h
index ff94845e58d602..35588c40c2eb1a 100644
--- a/lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_arm64.h
+++ b/lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_arm64.h
@@ -62,6 +62,7 @@ class RegisterContextCorePOSIX_arm64 : public
RegisterContextPOSIX_arm64 {
lldb_private::DataExtractor m_za_data;
lldb_private::DataExtractor m_mte_data;
lldb_private::DataExtractor m_zt_data;
+ lldb_private::DataExtractor m_fpmr_data;
SVEState m_sve_state = SVEState::Unknown;
uint16_t m_sve_vector_length = 0;
diff --git a/lldb/source/Plugins/Process/elf-core/RegisterUtilities.h
b/lldb/source/Plugins/Process/elf-core/RegisterUtilities.h
index 12aa5f72371c51..b97279b0d735b8 100644
--- a/lldb/source/Plugins/Process/elf-core/RegisterUtilities.h
+++ b/lldb/source/Plugins/Process/elf-core/RegisterUtilities.h
@@ -144,6 +144,10 @@ constexpr RegsetDesc AARCH64_MTE_Desc[] = {
llvm::ELF::NT_ARM_TAGGED_ADDR_CTRL},
};
+constexpr RegsetDesc AARCH64_FPMR_Desc[] = {
+{llvm::Triple::Linux, llvm::Triple::aarch64, llvm::ELF::NT_ARM_FPMR},
+};
+
constexpr RegsetDesc PPC_VMX_Desc[] = {
{llvm::Triple::FreeBSD, llvm::Triple::UnknownArch, llvm::ELF::NT_PPC_VMX},
{llvm::Triple::Linux, llvm::Triple::UnknownArch, llvm::ELF::NT_PPC_VMX},
diff --git a/lldb/test/API/linux/aarch64/fpmr/TestAArch64LinuxFPMR.py
b/lldb/test/API/linux/aarch64/fpmr/TestAArch64LinuxFPMR.py
index d022c8eb3d6cc4..7f8dc811c5df36 100644
--- a/lldb/test/API/linux/aarch64/fpmr/TestAArch64LinuxFPMR.py
+++ b/lldb/test/API/linux/aarch64/fpmr/TestAArch64LinuxFPMR.py
@@ -11,9 +11,13 @@
class AArch64LinuxFPMR(TestBase):
NO_DEBUG_INFO_TESTCASE = True
+# The value set by the inferior.
+EXPECTED_FPMR = (0b101010 << 32) | 0b101
+EXPECTED_FPMR_FIELDS = ["LSCALE2 = 42", "F8S1 = FP8_E4M3 | 0x4"]
+
@skipUnlessArch("aarch64")
@skipUnlessPlatform(["linux"])
-def test_fpmr_register(self):
+def test_fpmr_register_live(self):
if not self.isAArch64FPMR():
self.skipTest("FPMR must be present.")
@@ -39,16 +43,16 @@ def test_fpmr_register(self):
)
# This has been set by the program.
-expected_fpmr = (0b101010 << 32) | 0b101
self.expect(
"register read --all",
-substrs=["Floating Point Mode Register", f"fpmr =
{expected_fpmr:
[Lldb-commits] [lldb] [lldb][AArch64] Read fpmr register from core files (PR #110104)
@@ -61,3 +65,19 @@ def test_fpmr_register(self):
# 0 means the program found the new value in the sysreg as expected.
self.expect("continue", substrs=["exited with status = 0"])
+
+@skipIfLLVMTargetMissing("AArch64")
+def test_fpmr_register_core(self):
+if not self.isAArch64FPMR():
+self.skipTest("FPMR must be present.")
+
+self.runCmd("target create --core corefile")
+
+self.expect(
+"register read --all",
+substrs=[
+"Floating Point Mode Register",
+f"fpmr = {self.EXPECTED_FPMR:#018x}",
+],
+)
+self.expect("register read fpmr", substrs=self.EXPECTED_FPMR_FIELDS)
DavidSpickett wrote:
Note that for core file debug we aren't sending the register info via XML, so I
don't need to skip this if XML support is not enabled.
https://github.com/llvm/llvm-project/pull/110104
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][AArch64] Read fpmr register from core files (PR #110104)
https://github.com/DavidSpickett updated
https://github.com/llvm/llvm-project/pull/110104
>From 58911927a59557aab167792f62f2c9ba9a86fa0d Mon Sep 17 00:00:00 2001
From: David Spickett
Date: Thu, 29 Aug 2024 16:18:56 +0100
Subject: [PATCH 1/2] [lldb][AArch64] Read fpmr register from core files
---
.../RegisterContextPOSIXCore_arm64.cpp| 13 +++
.../elf-core/RegisterContextPOSIXCore_arm64.h | 1 +
.../Process/elf-core/RegisterUtilities.h | 4 +++
.../aarch64/fpmr/TestAArch64LinuxFPMR.py | 32 ++
lldb/test/API/linux/aarch64/fpmr/corefile | Bin 0 -> 20480 bytes
lldb/test/API/linux/aarch64/fpmr/main.c | 5 ++-
6 files changed, 48 insertions(+), 7 deletions(-)
create mode 100644 lldb/test/API/linux/aarch64/fpmr/corefile
diff --git
a/lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_arm64.cpp
b/lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_arm64.cpp
index 413bf1bbdb2a58..2ddf8440aeb035 100644
--- a/lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_arm64.cpp
+++ b/lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_arm64.cpp
@@ -64,6 +64,11 @@ RegisterContextCorePOSIX_arm64::Create(Thread &thread, const
ArchSpec &arch,
if (zt_data.GetByteSize() >= 64)
opt_regsets.Set(RegisterInfoPOSIX_arm64::eRegsetMaskZT);
+ DataExtractor fpmr_data =
+ getRegset(notes, arch.GetTriple(), AARCH64_FPMR_Desc);
+ if (fpmr_data.GetByteSize() >= sizeof(uint64_t))
+opt_regsets.Set(RegisterInfoPOSIX_arm64::eRegsetMaskFPMR);
+
auto register_info_up =
std::make_unique(arch, opt_regsets);
return std::unique_ptr(
@@ -128,6 +133,9 @@
RegisterContextCorePOSIX_arm64::RegisterContextCorePOSIX_arm64(
if (m_register_info_up->IsZTPresent())
m_zt_data = getRegset(notes, target_triple, AARCH64_ZT_Desc);
+ if (m_register_info_up->IsFPMRPresent())
+m_fpmr_data = getRegset(notes, target_triple, AARCH64_FPMR_Desc);
+
ConfigureRegisterContext();
}
@@ -370,6 +378,11 @@ bool RegisterContextCorePOSIX_arm64::ReadRegister(const
RegisterInfo *reg_info,
*reg_info, reinterpret_cast(&m_sme_pseudo_regs) + offset,
reg_info->byte_size, lldb_private::endian::InlHostByteOrder(),
error);
}
+ } else if (IsFPMR(reg)) {
+offset = reg_info->byte_offset - m_register_info_up->GetFPMROffset();
+assert(offset < m_fpmr_data.GetByteSize());
+value.SetFromMemoryData(*reg_info, m_fpmr_data.GetDataStart() + offset,
+reg_info->byte_size, lldb::eByteOrderLittle,
error);
} else
return false;
diff --git
a/lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_arm64.h
b/lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_arm64.h
index ff94845e58d602..35588c40c2eb1a 100644
--- a/lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_arm64.h
+++ b/lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_arm64.h
@@ -62,6 +62,7 @@ class RegisterContextCorePOSIX_arm64 : public
RegisterContextPOSIX_arm64 {
lldb_private::DataExtractor m_za_data;
lldb_private::DataExtractor m_mte_data;
lldb_private::DataExtractor m_zt_data;
+ lldb_private::DataExtractor m_fpmr_data;
SVEState m_sve_state = SVEState::Unknown;
uint16_t m_sve_vector_length = 0;
diff --git a/lldb/source/Plugins/Process/elf-core/RegisterUtilities.h
b/lldb/source/Plugins/Process/elf-core/RegisterUtilities.h
index 12aa5f72371c51..b97279b0d735b8 100644
--- a/lldb/source/Plugins/Process/elf-core/RegisterUtilities.h
+++ b/lldb/source/Plugins/Process/elf-core/RegisterUtilities.h
@@ -144,6 +144,10 @@ constexpr RegsetDesc AARCH64_MTE_Desc[] = {
llvm::ELF::NT_ARM_TAGGED_ADDR_CTRL},
};
+constexpr RegsetDesc AARCH64_FPMR_Desc[] = {
+{llvm::Triple::Linux, llvm::Triple::aarch64, llvm::ELF::NT_ARM_FPMR},
+};
+
constexpr RegsetDesc PPC_VMX_Desc[] = {
{llvm::Triple::FreeBSD, llvm::Triple::UnknownArch, llvm::ELF::NT_PPC_VMX},
{llvm::Triple::Linux, llvm::Triple::UnknownArch, llvm::ELF::NT_PPC_VMX},
diff --git a/lldb/test/API/linux/aarch64/fpmr/TestAArch64LinuxFPMR.py
b/lldb/test/API/linux/aarch64/fpmr/TestAArch64LinuxFPMR.py
index d022c8eb3d6cc4..7f8dc811c5df36 100644
--- a/lldb/test/API/linux/aarch64/fpmr/TestAArch64LinuxFPMR.py
+++ b/lldb/test/API/linux/aarch64/fpmr/TestAArch64LinuxFPMR.py
@@ -11,9 +11,13 @@
class AArch64LinuxFPMR(TestBase):
NO_DEBUG_INFO_TESTCASE = True
+# The value set by the inferior.
+EXPECTED_FPMR = (0b101010 << 32) | 0b101
+EXPECTED_FPMR_FIELDS = ["LSCALE2 = 42", "F8S1 = FP8_E4M3 | 0x4"]
+
@skipUnlessArch("aarch64")
@skipUnlessPlatform(["linux"])
-def test_fpmr_register(self):
+def test_fpmr_register_live(self):
if not self.isAArch64FPMR():
self.skipTest("FPMR must be present.")
@@ -39,16 +43,16 @@ def test_fpmr_register(self):
)
# This has been set by the program.
-expected_fpmr = (0b101010 << 32) | 0b101
s
[Lldb-commits] [lldb] [lldb][AArch64] Read fpmr register from core files (PR #110104)
DavidSpickett wrote: Last one for FPMR. I'll push the release notes directly. Thanks for reviewing! https://github.com/llvm/llvm-project/pull/110104 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][AArch64] Add register fields for the fpmr register (PR #109934)
https://github.com/DavidSpickett closed https://github.com/llvm/llvm-project/pull/109934 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Don't flush llvm::raw_string_ostream (NFC) (PR #110128)
https://github.com/JDevlieghere approved this pull request. https://github.com/llvm/llvm-project/pull/110128 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [DWARF]Set uuid for symbol file spec (PR #110066)
kevinfrei wrote: The DWP tests I tried to land turned into a nightmare of "your change to test infra requires you learn about all the wacky ways obscure test infra may or may not be configured" so there *are* tests, but they're disabled. If folks are okay with using yaml2obj as a mechanism to test .dwp+corefiles, that would be doable, but the API tests that use DWP aren't enabled, currently... https://github.com/llvm/llvm-project/pull/110066 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] f35719f - [lldb] Don't flush llvm::raw_string_ostream (NFC) (#110128)
Author: Youngsuk Kim
Date: 2024-09-26T12:29:14-04:00
New Revision: f35719ff670521454c8dfd83ec9d55dde65a5c3d
URL:
https://github.com/llvm/llvm-project/commit/f35719ff670521454c8dfd83ec9d55dde65a5c3d
DIFF:
https://github.com/llvm/llvm-project/commit/f35719ff670521454c8dfd83ec9d55dde65a5c3d.diff
LOG: [lldb] Don't flush llvm::raw_string_ostream (NFC) (#110128)
Don't call raw_string_ostream::flush(), which is essentially a no-op. As
specified in the docs, raw_string_ostream is always unbuffered. (
65b13610a5226b84889b923bae884ba395ad084d for further reference )
Added:
Modified:
lldb/source/Plugins/ExpressionParser/Clang/ASTResultSynthesizer.cpp
lldb/source/Plugins/ExpressionParser/Clang/ClangASTImporter.cpp
lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
lldb/source/Plugins/ExpressionParser/Clang/ClangUtil.cpp
lldb/source/Plugins/Process/Windows/Common/DebuggerThread.cpp
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServer.cpp
lldb/source/Utility/UUID.cpp
lldb/unittests/Process/minidump/MinidumpParserTest.cpp
Removed:
diff --git
a/lldb/source/Plugins/ExpressionParser/Clang/ASTResultSynthesizer.cpp
b/lldb/source/Plugins/ExpressionParser/Clang/ASTResultSynthesizer.cpp
index 3e2c208bd2018e..fd965d0127a2df 100644
--- a/lldb/source/Plugins/ExpressionParser/Clang/ASTResultSynthesizer.cpp
+++ b/lldb/source/Plugins/ExpressionParser/Clang/ASTResultSynthesizer.cpp
@@ -129,8 +129,6 @@ bool
ASTResultSynthesizer::SynthesizeFunctionResult(FunctionDecl *FunDecl) {
function_decl->print(os);
-os.flush();
-
LLDB_LOGF(log, "Untransformed function AST:\n%s", s.c_str());
}
@@ -145,8 +143,6 @@ bool
ASTResultSynthesizer::SynthesizeFunctionResult(FunctionDecl *FunDecl) {
function_decl->print(os);
-os.flush();
-
LLDB_LOGF(log, "Transformed function AST:\n%s", s.c_str());
}
@@ -169,8 +165,6 @@ bool ASTResultSynthesizer::SynthesizeObjCMethodResult(
MethodDecl->print(os);
-os.flush();
-
LLDB_LOGF(log, "Untransformed method AST:\n%s", s.c_str());
}
@@ -189,8 +183,6 @@ bool ASTResultSynthesizer::SynthesizeObjCMethodResult(
MethodDecl->print(os);
-os.flush();
-
LLDB_LOGF(log, "Transformed method AST:\n%s", s.c_str());
}
@@ -476,7 +468,6 @@ void ASTResultSynthesizer::CommitPersistentDecls() {
std::string s;
llvm::raw_string_ostream ss(s);
decl->dump(ss);
-ss.flush();
LLDB_LOGF(log, "Couldn't commit persistent decl: %s\n", s.c_str());
}
diff --git a/lldb/source/Plugins/ExpressionParser/Clang/ClangASTImporter.cpp
b/lldb/source/Plugins/ExpressionParser/Clang/ClangASTImporter.cpp
index adf13ff736adc2..630ad7e20ab7e0 100644
--- a/lldb/source/Plugins/ExpressionParser/Clang/ClangASTImporter.cpp
+++ b/lldb/source/Plugins/ExpressionParser/Clang/ClangASTImporter.cpp
@@ -1162,7 +1162,6 @@ void
ClangASTImporter::ASTImporterDelegate::ImportDefinitionTo(
if (NamedDecl *from_named_decl = dyn_cast(from)) {
llvm::raw_string_ostream name_stream(name_string);
from_named_decl->printName(name_stream);
- name_stream.flush();
}
LLDB_LOG(log_ast,
" [ClangASTImporter][TUDecl: {0:x}] Imported "
@@ -1292,7 +1291,6 @@ void
ClangASTImporter::ASTImporterDelegate::Imported(clang::Decl *from,
std::string name_string;
llvm::raw_string_ostream name_stream(name_string);
from_named_decl->printName(name_stream);
- name_stream.flush();
LLDB_LOG(
log,
diff --git
a/lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
b/lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
index 2fe3c0460aa7f8..4eeac372a2e657 100644
--- a/lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
+++ b/lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
@@ -210,7 +210,6 @@ class ClangDiagnosticManagerAdapter : public
clang::DiagnosticConsumer {
// Render diagnostic message to m_output.
m_output.clear();
m_passthrough->HandleDiagnostic(DiagLevel, Info);
-m_os->flush();
lldb::Severity severity;
bool make_new_diagnostic = true;
diff --git a/lldb/source/Plugins/ExpressionParser/Clang/ClangUtil.cpp
b/lldb/source/Plugins/ExpressionParser/Clang/ClangUtil.cpp
index 2e0bb318cb5076..4cda426e727049 100644
--- a/lldb/source/Plugins/ExpressionParser/Clang/ClangUtil.cpp
+++ b/lldb/source/Plugins/ExpressionParser/Clang/ClangUtil.cpp
@@ -74,7 +74,6 @@ std::string ClangUtil::DumpDecl(const clang::Decl *d) {
bool deserialize = false;
d->dump(stream, deserialize);
- stream.flush();
return result;
}
diff --git a/lldb/source/Plugins/Process/Windows/Common/DebuggerThread.cpp
b/lldb/sourc
[Lldb-commits] [lldb] [lldb] Don't flush llvm::raw_string_ostream (NFC) (PR #110128)
https://github.com/JOE1994 closed https://github.com/llvm/llvm-project/pull/110128 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Inline expression evaluator error visualization (PR #106470)
https://github.com/adrian-prantl updated
https://github.com/llvm/llvm-project/pull/106470
>From 9f4ba3fdb8b144736e51134ced3019a2c57ca861 Mon Sep 17 00:00:00 2001
From: Adrian Prantl
Date: Wed, 28 Aug 2024 10:04:33 -0700
Subject: [PATCH 1/2] [lldb] Store expression evaluator diagnostics in an
llvm::Error (NFC)
This patch is a reworking of Pete Lawrence's (@PortalPete) proposal
for better expression evaluator error messages:
https://github.com/llvm/llvm-project/pull/80938
This patch is preparatory patch for improving the rendering of
expression evaluator diagnostics. Currently diagnostics are rendered
into a string and the command interpreter layer then textually parses
words like "error:" to (sometimes) color the output accordingly. In
order to enable user interfaces to do better with diagnostics, we need
to store them in a machine-readable fromat. This patch does this by
adding a new llvm::Error kind wrapping a DiagnosticDetail struct that
is used when the error type is eErrorTypeExpression. Multiple
diagnostics are modeled using llvm::ErrorList.
Right now the extra information is not used by the CommandInterpreter,
this will be added in a follow-up patch!
---
.../lldb/Expression/DiagnosticManager.h | 89 +++
lldb/include/lldb/Utility/Status.h| 23 ++--
lldb/source/Breakpoint/BreakpointLocation.cpp | 11 +-
lldb/source/Expression/DiagnosticManager.cpp | 103 +++---
lldb/source/Expression/ExpressionParser.cpp | 5 +-
lldb/source/Expression/UserExpression.cpp | 49 +
lldb/source/Expression/UtilityFunction.cpp| 18 +--
.../ExpressionParser/Clang/ClangDiagnostic.h | 5 +-
.../Clang/ClangExpressionParser.cpp | 69
.../Clang/ClangUserExpression.h | 2 +
.../Plugins/Platform/POSIX/PlatformPOSIX.cpp | 12 +-
.../Platform/Windows/PlatformWindows.cpp | 12 +-
lldb/source/Target/Target.cpp | 3 +-
lldb/source/Utility/Status.cpp| 29 +
.../TestModulesCompileError.py| 2 +-
.../Expression/DiagnosticManagerTest.cpp | 22 +++-
16 files changed, 292 insertions(+), 162 deletions(-)
diff --git a/lldb/include/lldb/Expression/DiagnosticManager.h
b/lldb/include/lldb/Expression/DiagnosticManager.h
index d49b7c99b114fb..3e363ee5c0139c 100644
--- a/lldb/include/lldb/Expression/DiagnosticManager.h
+++ b/lldb/include/lldb/Expression/DiagnosticManager.h
@@ -12,6 +12,9 @@
#include "lldb/lldb-defines.h"
#include "lldb/lldb-types.h"
+#include "lldb/Utility/FileSpec.h"
+#include "lldb/Utility/Status.h"
+
#include "llvm/ADT/STLExtras.h"
#include "llvm/ADT/StringRef.h"
@@ -20,6 +23,53 @@
namespace lldb_private {
+/// A compiler-independent representation of a Diagnostic. Expression
+/// evaluation failures often have more than one diagnostic that a UI
+/// layer might want to render differently, for example to colorize
+/// it.
+///
+/// Running example:
+/// (lldb) expr 1+foo
+/// error: :1:3: use of undeclared identifier 'foo'
+/// 1+foo
+/// ^
+struct DiagnosticDetail {
+ struct SourceLocation {
+FileSpec file;
+unsigned line = 0;
+uint16_t column = 0;
+uint16_t length = 0;
+bool in_user_input = false;
+ };
+ /// Contains {{}, 1, 3, 3, true} in the example above.
+ std::optional source_location;
+ /// Contains eSeverityError in the example above.
+ lldb::Severity severity = lldb::eSeverityInfo;
+ /// Contains "use of undeclared identifier 'x'" in the example above.
+ std::string message;
+ /// Contains the fully rendered error message.
+ std::string rendered;
+};
+
+/// An llvm::Error used to communicate diagnostics in Status. Multiple
+/// diagnostics may be chained in an llvm::ErrorList.
+class ExpressionError
+: public llvm::ErrorInfo {
+ std::string m_message;
+ std::vector m_details;
+
+public:
+ static char ID;
+ using llvm::ErrorInfo::ErrorInfo;
+ ExpressionError(lldb::ExpressionResults result, std::string msg,
+ std::vector details = {});
+ std::string message() const override;
+ llvm::ArrayRef GetDetail() const { return m_details; }
+ std::error_code convertToErrorCode() const override;
+ void log(llvm::raw_ostream &OS) const override;
+ std::unique_ptr Clone() const override;
+};
+
enum DiagnosticOrigin {
eDiagnosticOriginUnknown = 0,
eDiagnosticOriginLLDB,
@@ -49,37 +99,28 @@ class Diagnostic {
}
}
- Diagnostic(llvm::StringRef message, lldb::Severity severity,
- DiagnosticOrigin origin, uint32_t compiler_id)
- : m_message(message), m_severity(severity), m_origin(origin),
-m_compiler_id(compiler_id) {}
-
- Diagnostic(const Diagnostic &rhs)
- : m_message(rhs.m_message), m_severity(rhs.m_severity),
-m_origin(rhs.m_origin), m_compiler_id(rhs.m_compiler_id) {}
+ Diagnostic(DiagnosticOrigin origin, uint32_t compiler_id,
+ DiagnosticDetail detail)
+ : m_origin(origin), m_compiler_id(com
[Lldb-commits] [lldb] [LLDB][ProcessELFCore] Add Description to ProcessELFCore/ELFThread stop reasons (PR #110065)
https://github.com/Jlalond updated
https://github.com/llvm/llvm-project/pull/110065
>From 0e31c0ad2b9db1ba9055bb4b984557100c0a9feb Mon Sep 17 00:00:00 2001
From: Jacob Lalonde
Date: Tue, 24 Sep 2024 17:42:49 -0700
Subject: [PATCH 1/4] Add the addr info when appropriate for NIX' crash signals
---
.../Process/elf-core/ProcessElfCore.cpp | 1 +
.../Process/elf-core/ThreadElfCore.cpp| 44 ---
.../Plugins/Process/elf-core/ThreadElfCore.h | 18 ++--
.../postmortem/elf-core/TestLinuxCore.py | 17 +++
.../elf-core/linux-x86_64-sigsev.yaml | 8
5 files changed, 80 insertions(+), 8 deletions(-)
create mode 100644
lldb/test/API/functionalities/postmortem/elf-core/linux-x86_64-sigsev.yaml
diff --git a/lldb/source/Plugins/Process/elf-core/ProcessElfCore.cpp
b/lldb/source/Plugins/Process/elf-core/ProcessElfCore.cpp
index 7955594bf5d94c..468a3b8934e741 100644
--- a/lldb/source/Plugins/Process/elf-core/ProcessElfCore.cpp
+++ b/lldb/source/Plugins/Process/elf-core/ProcessElfCore.cpp
@@ -931,6 +931,7 @@ llvm::Error
ProcessElfCore::parseLinuxNotes(llvm::ArrayRef notes) {
return status.ToError();
thread_data.signo = siginfo.si_signo;
thread_data.code = siginfo.si_code;
+ thread_data.description = siginfo.GetDescription();
break;
}
case ELF::NT_FILE: {
diff --git a/lldb/source/Plugins/Process/elf-core/ThreadElfCore.cpp
b/lldb/source/Plugins/Process/elf-core/ThreadElfCore.cpp
index 52b96052bdbeca..3260caabd70ac6 100644
--- a/lldb/source/Plugins/Process/elf-core/ThreadElfCore.cpp
+++ b/lldb/source/Plugins/Process/elf-core/ThreadElfCore.cpp
@@ -6,9 +6,11 @@
//
//===--===//
+#include "Plugins/Process/POSIX/CrashReason.h"
#include "lldb/Target/RegisterContext.h"
#include "lldb/Target/StopInfo.h"
#include "lldb/Target/Target.h"
+#include "lldb/Target/UnixSignals.h"
#include "lldb/Target/Unwind.h"
#include "lldb/Utility/DataExtractor.h"
#include "lldb/Utility/LLDBLog.h"
@@ -41,6 +43,7 @@
#include "RegisterContextPOSIXCore_x86_64.h"
#include "ThreadElfCore.h"
+#include "bits/types/siginfo_t.h"
#include
using namespace lldb;
@@ -49,8 +52,8 @@ using namespace lldb_private;
// Construct a Thread object with given data
ThreadElfCore::ThreadElfCore(Process &process, const ThreadData &td)
: Thread(process, td.tid), m_thread_name(td.name), m_thread_reg_ctx_sp(),
- m_signo(td.signo), m_code(td.code), m_gpregset_data(td.gpregset),
- m_notes(td.notes) {}
+ m_signo(td.signo), m_code(td.code), m_sig_description(td.description),
+ m_gpregset_data(td.gpregset), m_notes(td.notes) {}
ThreadElfCore::~ThreadElfCore() { DestroyThread(); }
@@ -241,7 +244,7 @@ bool ThreadElfCore::CalculateStopInfo() {
return false;
SetStopInfo(StopInfo::CreateStopReasonWithSignal(
- *this, m_signo, /*description=*/nullptr, m_code));
+ *this, m_signo, m_sig_description.c_str(), m_code));
return true;
}
@@ -543,7 +546,8 @@ size_t ELFLinuxSigInfo::GetSize(const
lldb_private::ArchSpec &arch) {
Status ELFLinuxSigInfo::Parse(const DataExtractor &data, const ArchSpec &arch)
{
Status error;
- if (GetSize(arch) > data.GetByteSize()) {
+ uint64_t size = GetSize(arch);
+ if (size > data.GetByteSize()) {
error = Status::FromErrorStringWithFormat(
"NT_SIGINFO size should be %zu, but the remaining bytes are: %" PRIu64,
GetSize(arch), data.GetByteSize());
@@ -556,6 +560,36 @@ Status ELFLinuxSigInfo::Parse(const DataExtractor &data,
const ArchSpec &arch) {
si_signo = data.GetU32(&offset);
si_errno = data.GetU32(&offset);
si_code = data.GetU32(&offset);
+ // 64b ELF have a 4 byte pad.
+ if (data.GetAddressByteSize() == 8)
+offset += 4;
+ switch (si_signo) {
+case SIGFPE:
+case SIGILL:
+case SIGSEGV:
+case SIGBUS:
+case SIGTRAP:
+ addr = (void*)data.GetAddress(&offset);
+ addr_lsb = data.GetU16(&offset);
+ return error;
+default:
+ return error;
+ }
+}
- return error;
+std::string ELFLinuxSigInfo::GetDescription() {
+ switch (si_signo) {
+case SIGFPE:
+case SIGILL:
+case SIGSEGV:
+case SIGBUS:
+case SIGTRAP:
+ return lldb_private::UnixSignals::CreateForHost()->GetSignalDescription(
+si_signo, si_code,
+reinterpret_cast(addr));
+default:
+ return lldb_private::UnixSignals::CreateForHost()->GetSignalDescription(
+si_signo, si_code
+ );
+ }
}
diff --git a/lldb/source/Plugins/Process/elf-core/ThreadElfCore.h
b/lldb/source/Plugins/Process/elf-core/ThreadElfCore.h
index 3fa0b8b0eedb0b..0dc21a10ded5e5 100644
--- a/lldb/source/Plugins/Process/elf-core/ThreadElfCore.h
+++ b/lldb/source/Plugins/Process/elf-core/ThreadElfCore.h
@@ -75,16 +75,25 @@ struct ELFLinuxPrStatus {
static_assert(sizeof(ELFLinuxPrStatus) == 112,
"sizeof ELFLinuxPrStatus is not correct!");
[Lldb-commits] [lldb] [lldb][test] Support remote run of Shell tests (PR #95986)
@@ -235,6 +235,8 @@ if (CMAKE_SIZEOF_VOID_P EQUAL 8) set(LLDB_IS_64_BITS 1) endif() +set(LLDB_SHELL_TESTS_DISABLE_REMOTE OFF CACHE BOOL "Disable remote Shell tests execution") DavidSpickett wrote: Ok and that means you can still use a single `ninja check-lldb` command instead of having to split it up. Seems like it will get limited use, but it's always good to have an escape hatch and this is not expensive to have. https://github.com/llvm/llvm-project/pull/95986 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Don't flush llvm::raw_string_ostream (NFC) (PR #110128)
https://github.com/JOE1994 created
https://github.com/llvm/llvm-project/pull/110128
Don't call raw_string_ostream::flush(), which is essentially a no-op. As
specified in the docs, raw_string_ostream is always unbuffered. (
65b13610a5226b84889b923bae884ba395ad084d for further reference )
>From e69c4a54403aae94d08302f4a33f25d7c70e7a37 Mon Sep 17 00:00:00 2001
From: Youngsuk Kim
Date: Thu, 26 Sep 2024 09:39:33 -0500
Subject: [PATCH] [lldb] Don't flush llvm::raw_string_ostream (NFC)
Don't call raw_string_ostream::flush(), which is essentially a no-op.
As specified in the docs, raw_string_ostream is always unbuffered.
( 65b13610a5226b84889b923bae884ba395ad084d for further reference )
---
.../ExpressionParser/Clang/ASTResultSynthesizer.cpp | 9 -
.../Plugins/ExpressionParser/Clang/ClangASTImporter.cpp | 2 --
.../ExpressionParser/Clang/ClangExpressionParser.cpp | 1 -
lldb/source/Plugins/ExpressionParser/Clang/ClangUtil.cpp | 1 -
.../Plugins/Process/Windows/Common/DebuggerThread.cpp| 1 -
.../Process/gdb-remote/GDBRemoteCommunicationClient.cpp | 1 -
.../Process/gdb-remote/GDBRemoteCommunicationServer.cpp | 1 -
lldb/source/Utility/UUID.cpp | 1 -
lldb/unittests/Process/minidump/MinidumpParserTest.cpp | 2 --
9 files changed, 19 deletions(-)
diff --git
a/lldb/source/Plugins/ExpressionParser/Clang/ASTResultSynthesizer.cpp
b/lldb/source/Plugins/ExpressionParser/Clang/ASTResultSynthesizer.cpp
index 3e2c208bd2018e..fd965d0127a2df 100644
--- a/lldb/source/Plugins/ExpressionParser/Clang/ASTResultSynthesizer.cpp
+++ b/lldb/source/Plugins/ExpressionParser/Clang/ASTResultSynthesizer.cpp
@@ -129,8 +129,6 @@ bool
ASTResultSynthesizer::SynthesizeFunctionResult(FunctionDecl *FunDecl) {
function_decl->print(os);
-os.flush();
-
LLDB_LOGF(log, "Untransformed function AST:\n%s", s.c_str());
}
@@ -145,8 +143,6 @@ bool
ASTResultSynthesizer::SynthesizeFunctionResult(FunctionDecl *FunDecl) {
function_decl->print(os);
-os.flush();
-
LLDB_LOGF(log, "Transformed function AST:\n%s", s.c_str());
}
@@ -169,8 +165,6 @@ bool ASTResultSynthesizer::SynthesizeObjCMethodResult(
MethodDecl->print(os);
-os.flush();
-
LLDB_LOGF(log, "Untransformed method AST:\n%s", s.c_str());
}
@@ -189,8 +183,6 @@ bool ASTResultSynthesizer::SynthesizeObjCMethodResult(
MethodDecl->print(os);
-os.flush();
-
LLDB_LOGF(log, "Transformed method AST:\n%s", s.c_str());
}
@@ -476,7 +468,6 @@ void ASTResultSynthesizer::CommitPersistentDecls() {
std::string s;
llvm::raw_string_ostream ss(s);
decl->dump(ss);
-ss.flush();
LLDB_LOGF(log, "Couldn't commit persistent decl: %s\n", s.c_str());
}
diff --git a/lldb/source/Plugins/ExpressionParser/Clang/ClangASTImporter.cpp
b/lldb/source/Plugins/ExpressionParser/Clang/ClangASTImporter.cpp
index adf13ff736adc2..630ad7e20ab7e0 100644
--- a/lldb/source/Plugins/ExpressionParser/Clang/ClangASTImporter.cpp
+++ b/lldb/source/Plugins/ExpressionParser/Clang/ClangASTImporter.cpp
@@ -1162,7 +1162,6 @@ void
ClangASTImporter::ASTImporterDelegate::ImportDefinitionTo(
if (NamedDecl *from_named_decl = dyn_cast(from)) {
llvm::raw_string_ostream name_stream(name_string);
from_named_decl->printName(name_stream);
- name_stream.flush();
}
LLDB_LOG(log_ast,
" [ClangASTImporter][TUDecl: {0:x}] Imported "
@@ -1292,7 +1291,6 @@ void
ClangASTImporter::ASTImporterDelegate::Imported(clang::Decl *from,
std::string name_string;
llvm::raw_string_ostream name_stream(name_string);
from_named_decl->printName(name_stream);
- name_stream.flush();
LLDB_LOG(
log,
diff --git
a/lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
b/lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
index 2fe3c0460aa7f8..4eeac372a2e657 100644
--- a/lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
+++ b/lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
@@ -210,7 +210,6 @@ class ClangDiagnosticManagerAdapter : public
clang::DiagnosticConsumer {
// Render diagnostic message to m_output.
m_output.clear();
m_passthrough->HandleDiagnostic(DiagLevel, Info);
-m_os->flush();
lldb::Severity severity;
bool make_new_diagnostic = true;
diff --git a/lldb/source/Plugins/ExpressionParser/Clang/ClangUtil.cpp
b/lldb/source/Plugins/ExpressionParser/Clang/ClangUtil.cpp
index 2e0bb318cb5076..4cda426e727049 100644
--- a/lldb/source/Plugins/ExpressionParser/Clang/ClangUtil.cpp
+++ b/lldb/source/Plugins/ExpressionParser/Clang/ClangUtil.cpp
@@ -74,7 +74,6 @@ std::string ClangUtil::DumpDecl(const clang::Decl *d) {
bool deserialize = false;
d->dump(stream, deserialize);
- stream.flush();
return result;
}
diff --git a/lldb/source/Plugins/Process/Windows/Commo
[Lldb-commits] [lldb] [lldb] Don't flush llvm::raw_string_ostream (NFC) (PR #110128)
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Youngsuk Kim (JOE1994)
Changes
Don't call raw_string_ostream::flush(), which is essentially a no-op. As
specified in the docs, raw_string_ostream is always unbuffered. (
65b13610a5226b84889b923bae884ba395ad084d for further reference )
---
Full diff: https://github.com/llvm/llvm-project/pull/110128.diff
9 Files Affected:
- (modified)
lldb/source/Plugins/ExpressionParser/Clang/ASTResultSynthesizer.cpp (-9)
- (modified) lldb/source/Plugins/ExpressionParser/Clang/ClangASTImporter.cpp
(-2)
- (modified)
lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp (-1)
- (modified) lldb/source/Plugins/ExpressionParser/Clang/ClangUtil.cpp (-1)
- (modified) lldb/source/Plugins/Process/Windows/Common/DebuggerThread.cpp (-1)
- (modified)
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp (-1)
- (modified)
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServer.cpp (-1)
- (modified) lldb/source/Utility/UUID.cpp (-1)
- (modified) lldb/unittests/Process/minidump/MinidumpParserTest.cpp (-2)
``diff
diff --git
a/lldb/source/Plugins/ExpressionParser/Clang/ASTResultSynthesizer.cpp
b/lldb/source/Plugins/ExpressionParser/Clang/ASTResultSynthesizer.cpp
index 3e2c208bd2018e..fd965d0127a2df 100644
--- a/lldb/source/Plugins/ExpressionParser/Clang/ASTResultSynthesizer.cpp
+++ b/lldb/source/Plugins/ExpressionParser/Clang/ASTResultSynthesizer.cpp
@@ -129,8 +129,6 @@ bool
ASTResultSynthesizer::SynthesizeFunctionResult(FunctionDecl *FunDecl) {
function_decl->print(os);
-os.flush();
-
LLDB_LOGF(log, "Untransformed function AST:\n%s", s.c_str());
}
@@ -145,8 +143,6 @@ bool
ASTResultSynthesizer::SynthesizeFunctionResult(FunctionDecl *FunDecl) {
function_decl->print(os);
-os.flush();
-
LLDB_LOGF(log, "Transformed function AST:\n%s", s.c_str());
}
@@ -169,8 +165,6 @@ bool ASTResultSynthesizer::SynthesizeObjCMethodResult(
MethodDecl->print(os);
-os.flush();
-
LLDB_LOGF(log, "Untransformed method AST:\n%s", s.c_str());
}
@@ -189,8 +183,6 @@ bool ASTResultSynthesizer::SynthesizeObjCMethodResult(
MethodDecl->print(os);
-os.flush();
-
LLDB_LOGF(log, "Transformed method AST:\n%s", s.c_str());
}
@@ -476,7 +468,6 @@ void ASTResultSynthesizer::CommitPersistentDecls() {
std::string s;
llvm::raw_string_ostream ss(s);
decl->dump(ss);
-ss.flush();
LLDB_LOGF(log, "Couldn't commit persistent decl: %s\n", s.c_str());
}
diff --git a/lldb/source/Plugins/ExpressionParser/Clang/ClangASTImporter.cpp
b/lldb/source/Plugins/ExpressionParser/Clang/ClangASTImporter.cpp
index adf13ff736adc2..630ad7e20ab7e0 100644
--- a/lldb/source/Plugins/ExpressionParser/Clang/ClangASTImporter.cpp
+++ b/lldb/source/Plugins/ExpressionParser/Clang/ClangASTImporter.cpp
@@ -1162,7 +1162,6 @@ void
ClangASTImporter::ASTImporterDelegate::ImportDefinitionTo(
if (NamedDecl *from_named_decl = dyn_cast(from)) {
llvm::raw_string_ostream name_stream(name_string);
from_named_decl->printName(name_stream);
- name_stream.flush();
}
LLDB_LOG(log_ast,
" [ClangASTImporter][TUDecl: {0:x}] Imported "
@@ -1292,7 +1291,6 @@ void
ClangASTImporter::ASTImporterDelegate::Imported(clang::Decl *from,
std::string name_string;
llvm::raw_string_ostream name_stream(name_string);
from_named_decl->printName(name_stream);
- name_stream.flush();
LLDB_LOG(
log,
diff --git
a/lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
b/lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
index 2fe3c0460aa7f8..4eeac372a2e657 100644
--- a/lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
+++ b/lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
@@ -210,7 +210,6 @@ class ClangDiagnosticManagerAdapter : public
clang::DiagnosticConsumer {
// Render diagnostic message to m_output.
m_output.clear();
m_passthrough->HandleDiagnostic(DiagLevel, Info);
-m_os->flush();
lldb::Severity severity;
bool make_new_diagnostic = true;
diff --git a/lldb/source/Plugins/ExpressionParser/Clang/ClangUtil.cpp
b/lldb/source/Plugins/ExpressionParser/Clang/ClangUtil.cpp
index 2e0bb318cb5076..4cda426e727049 100644
--- a/lldb/source/Plugins/ExpressionParser/Clang/ClangUtil.cpp
+++ b/lldb/source/Plugins/ExpressionParser/Clang/ClangUtil.cpp
@@ -74,7 +74,6 @@ std::string ClangUtil::DumpDecl(const clang::Decl *d) {
bool deserialize = false;
d->dump(stream, deserialize);
- stream.flush();
return result;
}
diff --git a/lldb/source/Plugins/Process/Windows/Common/DebuggerThread.cpp
b/lldb/source/Plugins/Process/Windows/Common/DebuggerThread.cpp
index d62eb26ca1a293..ca8e9c078e1f99 100644
--- a/lldb/source/Plugins/Process/Windows/Common/DebuggerThread.
[Lldb-commits] [lldb] [lldb] Don't flush llvm::raw_string_ostream (NFC) (PR #110128)
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 3e0d31c97cf27d46c464bf5a2712b28b69fa0503
e69c4a54403aae94d08302f4a33f25d7c70e7a37 --extensions cpp --
lldb/source/Plugins/ExpressionParser/Clang/ASTResultSynthesizer.cpp
lldb/source/Plugins/ExpressionParser/Clang/ClangASTImporter.cpp
lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
lldb/source/Plugins/ExpressionParser/Clang/ClangUtil.cpp
lldb/source/Plugins/Process/Windows/Common/DebuggerThread.cpp
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServer.cpp
lldb/source/Utility/UUID.cpp
lldb/unittests/Process/minidump/MinidumpParserTest.cpp
``
View the diff from clang-format here.
``diff
diff --git a/lldb/unittests/Process/minidump/MinidumpParserTest.cpp
b/lldb/unittests/Process/minidump/MinidumpParserTest.cpp
index a6d015e79a..537c65427d 100644
--- a/lldb/unittests/Process/minidump/MinidumpParserTest.cpp
+++ b/lldb/unittests/Process/minidump/MinidumpParserTest.cpp
@@ -83,7 +83,7 @@ Streams:
Content: DEADBEEFBAADF00D
)");
- ASSERT_TRUE(llvm::yaml::convertYAML(YIn, os, [](const llvm::Twine &Msg){}));
+ ASSERT_TRUE(llvm::yaml::convertYAML(YIn, os, [](const llvm::Twine &Msg) {}));
auto data_buffer_sp = std::make_shared(
duplicate_streams.data(), duplicate_streams.size());
ASSERT_THAT_EXPECTED(MinidumpParser::Create(data_buffer_sp), llvm::Failed());
``
https://github.com/llvm/llvm-project/pull/110128
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Don't flush llvm::raw_string_ostream (NFC) (PR #110128)
JOE1994 wrote: > ⚠️ C/C++ code formatter, clang-format found issues in your code. ⚠️ > > You can test this locally with the following command: > View the diff from clang-format here. clang-format is complaining about an adjacent line that is untouched by this revision. To simplify patch diff, I'd prefer not to follow suggestion from clang-format here. https://github.com/llvm/llvm-project/pull/110128 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [llvm] [lldb][DWARF] Replace lldb's DWARFDebugArangeSet with llvm's (PR #110058)
@@ -7,65 +7,45 @@
//===--===//
#include "DWARFDebugAranges.h"
-#include "DWARFDebugArangeSet.h"
#include "DWARFUnit.h"
#include "LogChannelDWARF.h"
#include "lldb/Utility/Log.h"
#include "lldb/Utility/Timer.h"
+#include "llvm/DebugInfo/DWARF/DWARFDebugArangeSet.h"
using namespace lldb;
using namespace lldb_private;
using namespace lldb_private::plugin::dwarf;
+using llvm::DWARFDebugArangeSet;
// Constructor
DWARFDebugAranges::DWARFDebugAranges() : m_aranges() {}
-// CountArangeDescriptors
-class CountArangeDescriptors {
-public:
- CountArangeDescriptors(uint32_t &count_ref) : count(count_ref) {
-// printf("constructor CountArangeDescriptors()\n");
- }
- void operator()(const DWARFDebugArangeSet &set) {
-count += set.NumDescriptors();
- }
- uint32_t &count;
-};
-
// Extract
void DWARFDebugAranges::extract(const DWARFDataExtractor &debug_aranges_data) {
+ llvm::DWARFDataExtractor llvm_dwarf_data =
+ debug_aranges_data.GetAsLLVMDWARF();
lldb::offset_t offset = 0;
DWARFDebugArangeSet set;
Range range;
- while (debug_aranges_data.ValidOffset(offset)) {
+ while (llvm_dwarf_data.isValidOffset(offset)) {
const lldb::offset_t set_offset = offset;
-if (llvm::Error error = set.extract(debug_aranges_data, &offset)) {
+if (llvm::Error error = set.extract(llvm_dwarf_data, &offset, nullptr)) {
Log *log = GetLog(DWARFLog::DebugInfo);
LLDB_LOG_ERROR(log, std::move(error),
"DWARFDebugAranges::extract failed to extract "
".debug_aranges set at offset {1:x}: {0}",
set_offset);
-} else {
- const uint32_t num_descriptors = set.NumDescriptors();
- if (num_descriptors > 0) {
-const dw_offset_t cu_offset = set.GetHeader().cu_offset;
-
-for (uint32_t i = 0; i < num_descriptors; ++i) {
- const DWARFDebugArangeSet::Descriptor &descriptor =
- set.GetDescriptorRef(i);
- m_aranges.Append(RangeToDIE::Entry(descriptor.address,
- descriptor.length, cu_offset));
-}
- }
+ set.clear();
+ return;
+}
+uint64_t cu_offset = set.getCompileUnitDIEOffset();
JDevlieghere wrote:
Nit: `const`
https://github.com/llvm/llvm-project/pull/110058
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [llvm] [lldb][DWARF] Replace lldb's DWARFDebugArangeSet with llvm's (PR #110058)
@@ -73,6 +73,12 @@ class DWARFDebugArangeSet {
return desc_iterator_range(ArangeDescriptors.begin(),
ArangeDescriptors.end());
}
+
+ size_t getDescriptorsSize() const { return ArangeDescriptors.size(); }
+
+ const Descriptor &getDescriptiorRef(uint32_t I) const {
JDevlieghere wrote:
Should we add an `assert(I < ArangeDescriptors.size())`?
https://github.com/llvm/llvm-project/pull/110058
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [llvm] [lldb][DWARF] Replace lldb's DWARFDebugArangeSet with llvm's (PR #110058)
@@ -7,65 +7,45 @@
//===--===//
#include "DWARFDebugAranges.h"
-#include "DWARFDebugArangeSet.h"
#include "DWARFUnit.h"
#include "LogChannelDWARF.h"
#include "lldb/Utility/Log.h"
#include "lldb/Utility/Timer.h"
+#include "llvm/DebugInfo/DWARF/DWARFDebugArangeSet.h"
using namespace lldb;
using namespace lldb_private;
using namespace lldb_private::plugin::dwarf;
+using llvm::DWARFDebugArangeSet;
// Constructor
DWARFDebugAranges::DWARFDebugAranges() : m_aranges() {}
-// CountArangeDescriptors
-class CountArangeDescriptors {
-public:
- CountArangeDescriptors(uint32_t &count_ref) : count(count_ref) {
-// printf("constructor CountArangeDescriptors()\n");
- }
- void operator()(const DWARFDebugArangeSet &set) {
-count += set.NumDescriptors();
- }
- uint32_t &count;
-};
-
// Extract
void DWARFDebugAranges::extract(const DWARFDataExtractor &debug_aranges_data) {
+ llvm::DWARFDataExtractor llvm_dwarf_data =
+ debug_aranges_data.GetAsLLVMDWARF();
lldb::offset_t offset = 0;
DWARFDebugArangeSet set;
Range range;
- while (debug_aranges_data.ValidOffset(offset)) {
+ while (llvm_dwarf_data.isValidOffset(offset)) {
const lldb::offset_t set_offset = offset;
-if (llvm::Error error = set.extract(debug_aranges_data, &offset)) {
+if (llvm::Error error = set.extract(llvm_dwarf_data, &offset, nullptr)) {
JDevlieghere wrote:
Nit: What's the `nullptr`? Can you add an inline comment with the argument
name? Same thing below.
https://github.com/llvm/llvm-project/pull/110058
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][test] Support remote run of Shell tests (PR #95986)
https://github.com/dzhidzhoev updated
https://github.com/llvm/llvm-project/pull/95986
>From da63c0b7439358942b379776715a2369acc56593 Mon Sep 17 00:00:00 2001
From: Vladislav Dzhidzhoev
Date: Fri, 31 May 2024 21:39:56 +
Subject: [PATCH 1/8] [lldb][test] Support remote run of Shell tests
1. This commit adds LLDB_TEST_PLATFORM_URL, LLDB_TEST_SYSROOT,
LLDB_TEST_PLATFORM_WORKING_DIR, LLDB_SHELL_TESTS_DISABLE_REMOTE cmake flags
to pass arguments for cross-compilation and remote running of both Shell&API
tests.
2. To run Shell tests remotely, it adds 'platform select' and 'platform
connect' commands to %lldb
substitution.
3. 'remote-linux' feature added to lit to disable tests failing with remote
execution.
4. A separate working directory is assigned to each test to avoid
conflicts during parallel test execution.
5. Remote Shell testing is run only when LLDB_TEST_SYSROOT is set for
building test sources. Recommended compiler for that is Clang.
---
lldb/docs/resources/test.rst | 20 +++---
lldb/test/API/lit.cfg.py | 7 ++
lldb/test/API/lit.site.cfg.py.in | 3 +
lldb/test/CMakeLists.txt | 1 +
.../test/Shell/Settings/TestEchoCommands.test | 2 +
lldb/test/Shell/Target/target-label.test | 20 +++---
lldb/test/Shell/helper/toolchain.py | 67 ++-
lldb/test/Shell/lit.cfg.py| 9 ++-
lldb/test/Shell/lit.site.cfg.py.in| 7 +-
9 files changed, 112 insertions(+), 24 deletions(-)
diff --git a/lldb/docs/resources/test.rst b/lldb/docs/resources/test.rst
index 906e687cb13b13..310c7c9e535306 100644
--- a/lldb/docs/resources/test.rst
+++ b/lldb/docs/resources/test.rst
@@ -592,15 +592,17 @@ test suite, but there are two things to have in mind:
multiple connections. For more information on how to setup remote debugging
see the Remote debugging page.
2. You must tell the test-suite how to connect to the remote system. This is
- achieved using the ``--platform-name``, ``--platform-url`` and
- ``--platform-working-dir`` parameters to ``dotest.py``. These parameters
- correspond to the platform select and platform connect LLDB commands. You
- will usually also need to specify the compiler and architecture for the
- remote system.
-
-Currently, running the remote test suite is supported only with ``dotest.py``
(or
-dosep.py with a single thread), but we expect this issue to be addressed in the
-near future.
+ achieved using the ``LLDB_TEST_PLATFORM_URL``,
``LLDB_TEST_PLATFORM_WORKING_DIR``
+ flags to cmake, and ``--platform-name`` parameter to ``dotest.py``.
+ These parameters correspond to the platform select and platform connect
+ LLDB commands. You will usually also need to specify the compiler and
+ architecture for the remote system.
+3. Remote Shell tests execution is currently supported only for Linux target
+ platform. It's triggered when ``LLDB_TEST_SYSROOT`` is provided for building
+ test sources. It can be disabled by setting
``LLDB_SHELL_TESTS_DISABLE_REMOTE=On``.
+ Shell tests are not guaranteed to pass against remote target if the compiler
+ being used is other than Clang.
+
Running tests in QEMU System Emulation Environment
``
diff --git a/lldb/test/API/lit.cfg.py b/lldb/test/API/lit.cfg.py
index 96520c7c826246..6a0a1b0a766755 100644
--- a/lldb/test/API/lit.cfg.py
+++ b/lldb/test/API/lit.cfg.py
@@ -303,6 +303,13 @@ def delete_module_cache(path):
# In particular, (1) is visited at the top of the file, since the script
# derives other information from it.
+if is_configured("lldb_platform_url"):
+dotest_cmd += ["--platform-url", config.lldb_platform_url]
+if is_configured("lldb_platform_working_dir"):
+dotest_cmd += ["--platform-working-dir", config.lldb_platform_working_dir]
+if is_configured("cmake_sysroot"):
+dotest_cmd += ["--sysroot", config.cmake_sysroot]
+
if is_configured("dotest_user_args_str"):
dotest_cmd.extend(config.dotest_user_args_str.split(";"))
diff --git a/lldb/test/API/lit.site.cfg.py.in b/lldb/test/API/lit.site.cfg.py.in
index 8b2d09ae41cd2a..db3cd2971f347a 100644
--- a/lldb/test/API/lit.site.cfg.py.in
+++ b/lldb/test/API/lit.site.cfg.py.in
@@ -24,6 +24,9 @@ config.lua_executable = "@Lua_EXECUTABLE@"
config.lua_test_entry = "TestLuaAPI.py"
config.dotest_common_args_str =
lit_config.substitute("@LLDB_TEST_COMMON_ARGS@")
config.dotest_user_args_str = lit_config.substitute("@LLDB_TEST_USER_ARGS@")
+config.lldb_platform_url = lit_config.substitute("@LLDB_TEST_PLATFORM_URL@")
+config.lldb_platform_working_dir =
lit_config.substitute("@LLDB_TEST_PLATFORM_WORKING_DIR@")
+config.cmake_sysroot = lit_config.substitute("@LLDB_TEST_SYSROOT@" or
"@DEFAULT_SYSROOT@")
config.lldb_enable_python = @LLDB_ENABLE_PYTHON@
config.dotest_lit_args_str = None
config.enabled_plugins = []
diff --git a/lldb/test/CMakeLists.txt b/lldb/test/C
[Lldb-commits] [lldb] 3eaaf7c - [lldb][AArch64] Fix crash loading core files on 32 bit systems
Author: David Spickett Date: 2024-09-26T12:06:23Z New Revision: 3eaaf7c4d062976901c79b523e9f3cc606943119 URL: https://github.com/llvm/llvm-project/commit/3eaaf7c4d062976901c79b523e9f3cc606943119 DIFF: https://github.com/llvm/llvm-project/commit/3eaaf7c4d062976901c79b523e9f3cc606943119.diff LOG: [lldb][AArch64] Fix crash loading core files on 32 bit systems https://github.com/llvm/llvm-project/pull/109934 added FPMR which uses a bit in hwcaps greater than 31. So it marked the 1 with UL which is fine on 64 bit systems but for 32 bit UL is 4 bytes. Use ULL so we aren't invoking undefined behaviour. Added: Modified: lldb/source/Plugins/Process/Utility/RegisterFlagsDetector_arm64.cpp Removed: diff --git a/lldb/source/Plugins/Process/Utility/RegisterFlagsDetector_arm64.cpp b/lldb/source/Plugins/Process/Utility/RegisterFlagsDetector_arm64.cpp index 72ced42a158233..9f82c935c0e7ed 100644 --- a/lldb/source/Plugins/Process/Utility/RegisterFlagsDetector_arm64.cpp +++ b/lldb/source/Plugins/Process/Utility/RegisterFlagsDetector_arm64.cpp @@ -23,7 +23,7 @@ #define HWCAP2_AFP (1ULL << 20) #define HWCAP2_SME (1ULL << 23) #define HWCAP2_EBF16 (1ULL << 32) -#define HWCAP2_FPMR (1UL << 48) +#define HWCAP2_FPMR (1ULL << 48) using namespace lldb_private; ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][test] Support remote run of Shell tests (PR #95986)
@@ -60,7 +60,8 @@ something like ``target.BreakpointCreateByName`` [#]_. A good rule of thumb is to prefer shell tests when what is being tested is relatively simple. Expressivity is limited compared to the API tests, which means that you have to have a well-defined test scenario that you can easily -match with ``FileCheck``. +match with ``FileCheck``. Though Shell tests can be run remotely, remote DavidSpickett wrote: I think this would be a little clearer: "Though Shell tests can be run remotely, behavior specific to remote debugging must be tested with API tests instead." So that remote specifics are tested only using API tests not in addition to shell tests. https://github.com/llvm/llvm-project/pull/95986 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][test] Support remote run of Shell tests (PR #95986)
@@ -60,7 +60,8 @@ something like ``target.BreakpointCreateByName`` [#]_. A good rule of thumb is to prefer shell tests when what is being tested is relatively simple. Expressivity is limited compared to the API tests, which means that you have to have a well-defined test scenario that you can easily -match with ``FileCheck``. +match with ``FileCheck``. Though Shell tests can be run remotely, remote dzhidzhoev wrote: Fixed. https://github.com/llvm/llvm-project/pull/95986 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][test] Support remote run of Shell tests (PR #95986)
@@ -235,6 +235,8 @@ if (CMAKE_SIZEOF_VOID_P EQUAL 8) set(LLDB_IS_64_BITS 1) endif() +set(LLDB_SHELL_TESTS_DISABLE_REMOTE OFF CACHE BOOL "Disable remote Shell tests execution") DavidSpickett wrote: Remind me again what this does (probably the third time I've asked this, I keep forgetting :) ). When would I disable remote for this and what happens if I do? Also should this be LLDB_TEST_SHELL_TESTS_DISABLE_REMOTE? So it sorts next to all the other ones? https://github.com/llvm/llvm-project/pull/95986 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][test] Support remote run of Shell tests (PR #95986)
dzhidzhoev wrote: Rebased & added a line to documentation about the usage of API tests for remote testing. https://github.com/llvm/llvm-project/pull/95986 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][test] Support remote run of Shell tests (PR #95986)
https://github.com/dzhidzhoev updated
https://github.com/llvm/llvm-project/pull/95986
>From da63c0b7439358942b379776715a2369acc56593 Mon Sep 17 00:00:00 2001
From: Vladislav Dzhidzhoev
Date: Fri, 31 May 2024 21:39:56 +
Subject: [PATCH 1/9] [lldb][test] Support remote run of Shell tests
1. This commit adds LLDB_TEST_PLATFORM_URL, LLDB_TEST_SYSROOT,
LLDB_TEST_PLATFORM_WORKING_DIR, LLDB_SHELL_TESTS_DISABLE_REMOTE cmake flags
to pass arguments for cross-compilation and remote running of both Shell&API
tests.
2. To run Shell tests remotely, it adds 'platform select' and 'platform
connect' commands to %lldb
substitution.
3. 'remote-linux' feature added to lit to disable tests failing with remote
execution.
4. A separate working directory is assigned to each test to avoid
conflicts during parallel test execution.
5. Remote Shell testing is run only when LLDB_TEST_SYSROOT is set for
building test sources. Recommended compiler for that is Clang.
---
lldb/docs/resources/test.rst | 20 +++---
lldb/test/API/lit.cfg.py | 7 ++
lldb/test/API/lit.site.cfg.py.in | 3 +
lldb/test/CMakeLists.txt | 1 +
.../test/Shell/Settings/TestEchoCommands.test | 2 +
lldb/test/Shell/Target/target-label.test | 20 +++---
lldb/test/Shell/helper/toolchain.py | 67 ++-
lldb/test/Shell/lit.cfg.py| 9 ++-
lldb/test/Shell/lit.site.cfg.py.in| 7 +-
9 files changed, 112 insertions(+), 24 deletions(-)
diff --git a/lldb/docs/resources/test.rst b/lldb/docs/resources/test.rst
index 906e687cb13b13..310c7c9e535306 100644
--- a/lldb/docs/resources/test.rst
+++ b/lldb/docs/resources/test.rst
@@ -592,15 +592,17 @@ test suite, but there are two things to have in mind:
multiple connections. For more information on how to setup remote debugging
see the Remote debugging page.
2. You must tell the test-suite how to connect to the remote system. This is
- achieved using the ``--platform-name``, ``--platform-url`` and
- ``--platform-working-dir`` parameters to ``dotest.py``. These parameters
- correspond to the platform select and platform connect LLDB commands. You
- will usually also need to specify the compiler and architecture for the
- remote system.
-
-Currently, running the remote test suite is supported only with ``dotest.py``
(or
-dosep.py with a single thread), but we expect this issue to be addressed in the
-near future.
+ achieved using the ``LLDB_TEST_PLATFORM_URL``,
``LLDB_TEST_PLATFORM_WORKING_DIR``
+ flags to cmake, and ``--platform-name`` parameter to ``dotest.py``.
+ These parameters correspond to the platform select and platform connect
+ LLDB commands. You will usually also need to specify the compiler and
+ architecture for the remote system.
+3. Remote Shell tests execution is currently supported only for Linux target
+ platform. It's triggered when ``LLDB_TEST_SYSROOT`` is provided for building
+ test sources. It can be disabled by setting
``LLDB_SHELL_TESTS_DISABLE_REMOTE=On``.
+ Shell tests are not guaranteed to pass against remote target if the compiler
+ being used is other than Clang.
+
Running tests in QEMU System Emulation Environment
``
diff --git a/lldb/test/API/lit.cfg.py b/lldb/test/API/lit.cfg.py
index 96520c7c826246..6a0a1b0a766755 100644
--- a/lldb/test/API/lit.cfg.py
+++ b/lldb/test/API/lit.cfg.py
@@ -303,6 +303,13 @@ def delete_module_cache(path):
# In particular, (1) is visited at the top of the file, since the script
# derives other information from it.
+if is_configured("lldb_platform_url"):
+dotest_cmd += ["--platform-url", config.lldb_platform_url]
+if is_configured("lldb_platform_working_dir"):
+dotest_cmd += ["--platform-working-dir", config.lldb_platform_working_dir]
+if is_configured("cmake_sysroot"):
+dotest_cmd += ["--sysroot", config.cmake_sysroot]
+
if is_configured("dotest_user_args_str"):
dotest_cmd.extend(config.dotest_user_args_str.split(";"))
diff --git a/lldb/test/API/lit.site.cfg.py.in b/lldb/test/API/lit.site.cfg.py.in
index 8b2d09ae41cd2a..db3cd2971f347a 100644
--- a/lldb/test/API/lit.site.cfg.py.in
+++ b/lldb/test/API/lit.site.cfg.py.in
@@ -24,6 +24,9 @@ config.lua_executable = "@Lua_EXECUTABLE@"
config.lua_test_entry = "TestLuaAPI.py"
config.dotest_common_args_str =
lit_config.substitute("@LLDB_TEST_COMMON_ARGS@")
config.dotest_user_args_str = lit_config.substitute("@LLDB_TEST_USER_ARGS@")
+config.lldb_platform_url = lit_config.substitute("@LLDB_TEST_PLATFORM_URL@")
+config.lldb_platform_working_dir =
lit_config.substitute("@LLDB_TEST_PLATFORM_WORKING_DIR@")
+config.cmake_sysroot = lit_config.substitute("@LLDB_TEST_SYSROOT@" or
"@DEFAULT_SYSROOT@")
config.lldb_enable_python = @LLDB_ENABLE_PYTHON@
config.dotest_lit_args_str = None
config.enabled_plugins = []
diff --git a/lldb/test/CMakeLists.txt b/lldb/test/C
[Lldb-commits] [lldb] [lldb][test] Support remote run of Shell tests (PR #95986)
@@ -235,6 +235,8 @@ if (CMAKE_SIZEOF_VOID_P EQUAL 8) set(LLDB_IS_64_BITS 1) endif() +set(LLDB_SHELL_TESTS_DISABLE_REMOTE OFF CACHE BOOL "Disable remote Shell tests execution") dzhidzhoev wrote: > Also should this be LLDB_TEST_SHELL_TESTS_DISABLE_REMOTE? So it sorts next to > all the other ones? Renamed it to LLDB_TEST_SHELL_DISABLE_REMOTE, so as not to duplicate TEST. > Remind me again what this does (probably the third time I've asked this, I > keep forgetting :) ). When would I disable remote for this and what happens > if I do? In case tests fail due to unsupported compiler/toolchain used, i.e. not clang, for building test executables. If set, this flag should cause Shell tests to be compiled and run against the local (host machine) target. https://github.com/llvm/llvm-project/pull/95986 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][test] Support remote run of Shell tests (PR #95986)
https://github.com/dzhidzhoev updated
https://github.com/llvm/llvm-project/pull/95986
>From da63c0b7439358942b379776715a2369acc56593 Mon Sep 17 00:00:00 2001
From: Vladislav Dzhidzhoev
Date: Fri, 31 May 2024 21:39:56 +
Subject: [PATCH 01/11] [lldb][test] Support remote run of Shell tests
1. This commit adds LLDB_TEST_PLATFORM_URL, LLDB_TEST_SYSROOT,
LLDB_TEST_PLATFORM_WORKING_DIR, LLDB_SHELL_TESTS_DISABLE_REMOTE cmake flags
to pass arguments for cross-compilation and remote running of both Shell&API
tests.
2. To run Shell tests remotely, it adds 'platform select' and 'platform
connect' commands to %lldb
substitution.
3. 'remote-linux' feature added to lit to disable tests failing with remote
execution.
4. A separate working directory is assigned to each test to avoid
conflicts during parallel test execution.
5. Remote Shell testing is run only when LLDB_TEST_SYSROOT is set for
building test sources. Recommended compiler for that is Clang.
---
lldb/docs/resources/test.rst | 20 +++---
lldb/test/API/lit.cfg.py | 7 ++
lldb/test/API/lit.site.cfg.py.in | 3 +
lldb/test/CMakeLists.txt | 1 +
.../test/Shell/Settings/TestEchoCommands.test | 2 +
lldb/test/Shell/Target/target-label.test | 20 +++---
lldb/test/Shell/helper/toolchain.py | 67 ++-
lldb/test/Shell/lit.cfg.py| 9 ++-
lldb/test/Shell/lit.site.cfg.py.in| 7 +-
9 files changed, 112 insertions(+), 24 deletions(-)
diff --git a/lldb/docs/resources/test.rst b/lldb/docs/resources/test.rst
index 906e687cb13b13..310c7c9e535306 100644
--- a/lldb/docs/resources/test.rst
+++ b/lldb/docs/resources/test.rst
@@ -592,15 +592,17 @@ test suite, but there are two things to have in mind:
multiple connections. For more information on how to setup remote debugging
see the Remote debugging page.
2. You must tell the test-suite how to connect to the remote system. This is
- achieved using the ``--platform-name``, ``--platform-url`` and
- ``--platform-working-dir`` parameters to ``dotest.py``. These parameters
- correspond to the platform select and platform connect LLDB commands. You
- will usually also need to specify the compiler and architecture for the
- remote system.
-
-Currently, running the remote test suite is supported only with ``dotest.py``
(or
-dosep.py with a single thread), but we expect this issue to be addressed in the
-near future.
+ achieved using the ``LLDB_TEST_PLATFORM_URL``,
``LLDB_TEST_PLATFORM_WORKING_DIR``
+ flags to cmake, and ``--platform-name`` parameter to ``dotest.py``.
+ These parameters correspond to the platform select and platform connect
+ LLDB commands. You will usually also need to specify the compiler and
+ architecture for the remote system.
+3. Remote Shell tests execution is currently supported only for Linux target
+ platform. It's triggered when ``LLDB_TEST_SYSROOT`` is provided for building
+ test sources. It can be disabled by setting
``LLDB_SHELL_TESTS_DISABLE_REMOTE=On``.
+ Shell tests are not guaranteed to pass against remote target if the compiler
+ being used is other than Clang.
+
Running tests in QEMU System Emulation Environment
``
diff --git a/lldb/test/API/lit.cfg.py b/lldb/test/API/lit.cfg.py
index 96520c7c826246..6a0a1b0a766755 100644
--- a/lldb/test/API/lit.cfg.py
+++ b/lldb/test/API/lit.cfg.py
@@ -303,6 +303,13 @@ def delete_module_cache(path):
# In particular, (1) is visited at the top of the file, since the script
# derives other information from it.
+if is_configured("lldb_platform_url"):
+dotest_cmd += ["--platform-url", config.lldb_platform_url]
+if is_configured("lldb_platform_working_dir"):
+dotest_cmd += ["--platform-working-dir", config.lldb_platform_working_dir]
+if is_configured("cmake_sysroot"):
+dotest_cmd += ["--sysroot", config.cmake_sysroot]
+
if is_configured("dotest_user_args_str"):
dotest_cmd.extend(config.dotest_user_args_str.split(";"))
diff --git a/lldb/test/API/lit.site.cfg.py.in b/lldb/test/API/lit.site.cfg.py.in
index 8b2d09ae41cd2a..db3cd2971f347a 100644
--- a/lldb/test/API/lit.site.cfg.py.in
+++ b/lldb/test/API/lit.site.cfg.py.in
@@ -24,6 +24,9 @@ config.lua_executable = "@Lua_EXECUTABLE@"
config.lua_test_entry = "TestLuaAPI.py"
config.dotest_common_args_str =
lit_config.substitute("@LLDB_TEST_COMMON_ARGS@")
config.dotest_user_args_str = lit_config.substitute("@LLDB_TEST_USER_ARGS@")
+config.lldb_platform_url = lit_config.substitute("@LLDB_TEST_PLATFORM_URL@")
+config.lldb_platform_working_dir =
lit_config.substitute("@LLDB_TEST_PLATFORM_WORKING_DIR@")
+config.cmake_sysroot = lit_config.substitute("@LLDB_TEST_SYSROOT@" or
"@DEFAULT_SYSROOT@")
config.lldb_enable_python = @LLDB_ENABLE_PYTHON@
config.dotest_lit_args_str = None
config.enabled_plugins = []
diff --git a/lldb/test/CMakeLists.txt b/lldb/test
[Lldb-commits] [lldb] [lldb] Fix minor runCmd error message formatting (PR #110150)
https://github.com/kastiglione created
https://github.com/llvm/llvm-project/pull/110150
None
>From fb0c5eefa9d3f3500a4767a727a0c39f2dff01d2 Mon Sep 17 00:00:00 2001
From: Dave Lee
Date: Wed, 25 Sep 2024 15:07:34 -0700
Subject: [PATCH] [lldb] Fix minor runCmd error message formatting
---
lldb/packages/Python/lldbsuite/test/lldbtest.py | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/lldb/packages/Python/lldbsuite/test/lldbtest.py
b/lldb/packages/Python/lldbsuite/test/lldbtest.py
index c6b7ce84109c09..8884ef5933ada8 100644
--- a/lldb/packages/Python/lldbsuite/test/lldbtest.py
+++ b/lldb/packages/Python/lldbsuite/test/lldbtest.py
@@ -172,9 +172,9 @@
WATCHPOINT_CREATED = "Watchpoint created successfully"
-def CMD_MSG(str):
+def CMD_MSG(command):
"""A generic "Command '%s' did not return successfully" message
generator."""
-return "Command '%s' did not return successfully" % str
+return f"Command '{command}' did not return successfully"
def COMPLETION_MSG(str_before, str_after, completions):
@@ -990,16 +990,14 @@ def runCmd(self, cmd, msg=None, check=True, trace=False,
inHistory=False):
print("Command '" + cmd + "' failed!", file=sbuf)
if check:
+if not msg:
+msg = CMD_MSG(cmd)
output = ""
if self.res.GetOutput():
output += "\nCommand output:\n" + self.res.GetOutput()
if self.res.GetError():
output += "\nError output:\n" + self.res.GetError()
-if msg:
-msg += output
-if cmd:
-cmd += output
-self.assertTrue(self.res.Succeeded(), msg if (msg) else
CMD_MSG(cmd))
+self.assertTrue(self.res.Succeeded(), msg + output)
def HideStdout(self):
"""Hide output to stdout from the user.
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Fix minor runCmd error message formatting (PR #110150)
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Dave Lee (kastiglione)
Changes
---
Full diff: https://github.com/llvm/llvm-project/pull/110150.diff
1 Files Affected:
- (modified) lldb/packages/Python/lldbsuite/test/lldbtest.py (+5-7)
``diff
diff --git a/lldb/packages/Python/lldbsuite/test/lldbtest.py
b/lldb/packages/Python/lldbsuite/test/lldbtest.py
index c6b7ce84109c09..8884ef5933ada8 100644
--- a/lldb/packages/Python/lldbsuite/test/lldbtest.py
+++ b/lldb/packages/Python/lldbsuite/test/lldbtest.py
@@ -172,9 +172,9 @@
WATCHPOINT_CREATED = "Watchpoint created successfully"
-def CMD_MSG(str):
+def CMD_MSG(command):
"""A generic "Command '%s' did not return successfully" message
generator."""
-return "Command '%s' did not return successfully" % str
+return f"Command '{command}' did not return successfully"
def COMPLETION_MSG(str_before, str_after, completions):
@@ -990,16 +990,14 @@ def runCmd(self, cmd, msg=None, check=True, trace=False,
inHistory=False):
print("Command '" + cmd + "' failed!", file=sbuf)
if check:
+if not msg:
+msg = CMD_MSG(cmd)
output = ""
if self.res.GetOutput():
output += "\nCommand output:\n" + self.res.GetOutput()
if self.res.GetError():
output += "\nError output:\n" + self.res.GetError()
-if msg:
-msg += output
-if cmd:
-cmd += output
-self.assertTrue(self.res.Succeeded(), msg if (msg) else
CMD_MSG(cmd))
+self.assertTrue(self.res.Succeeded(), msg + output)
def HideStdout(self):
"""Hide output to stdout from the user.
``
https://github.com/llvm/llvm-project/pull/110150
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Fix minor runCmd error message formatting (PR #110150)
https://github.com/kastiglione edited https://github.com/llvm/llvm-project/pull/110150 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [llvm] [lldb][DWARF] Replace lldb's DWARFDebugArangeSet with llvm's (PR #110058)
https://github.com/ZequanWu updated
https://github.com/llvm/llvm-project/pull/110058
>From 8e1c59729905fb89a8764ace3dfa0d04119d273e Mon Sep 17 00:00:00 2001
From: Zequan Wu
Date: Wed, 25 Sep 2024 15:59:29 -0700
Subject: [PATCH 1/3] [lldb][DWARF] Replace lldb's DWARFDebugArangeSet with
llvm's
---
.../Plugins/SymbolFile/DWARF/CMakeLists.txt | 1 -
.../SymbolFile/DWARF/DWARFDebugArangeSet.cpp | 176 --
.../SymbolFile/DWARF/DWARFDebugArangeSet.h| 70 ---
.../SymbolFile/DWARF/DWARFDebugAranges.cpp| 47 ++---
.../SymbolFile/DWARF/SymbolFileDWARFTests.cpp | 56 +++---
.../DebugInfo/DWARF/DWARFDebugArangeSet.h | 6 +
.../DebugInfo/DWARF/DWARFDebugArangeSet.cpp | 12 +-
7 files changed, 55 insertions(+), 313 deletions(-)
delete mode 100644 lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugArangeSet.cpp
delete mode 100644 lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugArangeSet.h
diff --git a/lldb/source/Plugins/SymbolFile/DWARF/CMakeLists.txt
b/lldb/source/Plugins/SymbolFile/DWARF/CMakeLists.txt
index 0e4fd5b995d1ba..83c4f1a4cf892c 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/CMakeLists.txt
+++ b/lldb/source/Plugins/SymbolFile/DWARF/CMakeLists.txt
@@ -18,7 +18,6 @@ add_lldb_library(lldbPluginSymbolFileDWARF PLUGIN
DWARFContext.cpp
DWARFDataExtractor.cpp
DWARFDebugAranges.cpp
- DWARFDebugArangeSet.cpp
DWARFDebugInfo.cpp
DWARFDebugInfoEntry.cpp
DWARFDebugMacro.cpp
diff --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugArangeSet.cpp
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugArangeSet.cpp
deleted file mode 100644
index 8461b94abca630..00
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugArangeSet.cpp
+++ /dev/null
@@ -1,176 +0,0 @@
-//===-- DWARFDebugArangeSet.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 "DWARFDebugArangeSet.h"
-#include "DWARFDataExtractor.h"
-#include "LogChannelDWARF.h"
-#include "llvm/Object/Error.h"
-#include
-
-using namespace lldb_private;
-using namespace lldb_private::plugin::dwarf;
-
-DWARFDebugArangeSet::DWARFDebugArangeSet()
-: m_offset(DW_INVALID_OFFSET), m_next_offset(DW_INVALID_OFFSET) {}
-
-void DWARFDebugArangeSet::Clear() {
- m_offset = DW_INVALID_OFFSET;
- m_next_offset = DW_INVALID_OFFSET;
- m_header.length = 0;
- m_header.version = 0;
- m_header.cu_offset = 0;
- m_header.addr_size = 0;
- m_header.seg_size = 0;
- m_arange_descriptors.clear();
-}
-
-llvm::Error DWARFDebugArangeSet::extract(const DWARFDataExtractor &data,
- lldb::offset_t *offset_ptr) {
- assert(data.ValidOffset(*offset_ptr));
-
- m_arange_descriptors.clear();
- m_offset = *offset_ptr;
-
- // 7.20 Address Range Table
- //
- // Each set of entries in the table of address ranges contained in the
- // .debug_aranges section begins with a header consisting of: a 4-byte
- // length containing the length of the set of entries for this compilation
- // unit, not including the length field itself; a 2-byte version identifier
- // containing the value 2 for DWARF Version 2; a 4-byte offset into
- // the.debug_infosection; a 1-byte unsigned integer containing the size in
- // bytes of an address (or the offset portion of an address for segmented
- // addressing) on the target system; and a 1-byte unsigned integer
- // containing the size in bytes of a segment descriptor on the target
- // system. This header is followed by a series of tuples. Each tuple
- // consists of an address and a length, each in the size appropriate for an
- // address on the target architecture.
- m_header.length = data.GetDWARFInitialLength(offset_ptr);
- // The length could be 4 bytes or 12 bytes, so use the current offset to
- // determine the next offset correctly.
- if (m_header.length > 0)
-m_next_offset = *offset_ptr + m_header.length;
- else
-m_next_offset = DW_INVALID_OFFSET;
- m_header.version = data.GetU16(offset_ptr);
- m_header.cu_offset = data.GetDWARFOffset(offset_ptr);
- m_header.addr_size = data.GetU8(offset_ptr);
- m_header.seg_size = data.GetU8(offset_ptr);
-
- // Try to avoid reading invalid arange sets by making sure:
- // 1 - the version looks good
- // 2 - the address byte size looks plausible
- // 3 - the length seems to make sense
- // 4 - size looks plausible
- // 5 - the arange tuples do not contain a segment field
- if (m_header.version < 2 || m_header.version > 5)
-return llvm::make_error(
-"Invalid arange header version");
-
- if (m_header.addr_size != 4 && m_header.addr_size != 8)
-return llvm::make_error(
-"Invalid arange header address size");
-
- if (m_header.length == 0)
-return llvm:
[Lldb-commits] [lldb] [llvm] [lldb][DWARF] Replace lldb's DWARFDebugArangeSet with llvm's (PR #110058)
@@ -7,65 +7,45 @@
//===--===//
#include "DWARFDebugAranges.h"
-#include "DWARFDebugArangeSet.h"
#include "DWARFUnit.h"
#include "LogChannelDWARF.h"
#include "lldb/Utility/Log.h"
#include "lldb/Utility/Timer.h"
+#include "llvm/DebugInfo/DWARF/DWARFDebugArangeSet.h"
using namespace lldb;
using namespace lldb_private;
using namespace lldb_private::plugin::dwarf;
+using llvm::DWARFDebugArangeSet;
// Constructor
DWARFDebugAranges::DWARFDebugAranges() : m_aranges() {}
-// CountArangeDescriptors
-class CountArangeDescriptors {
-public:
- CountArangeDescriptors(uint32_t &count_ref) : count(count_ref) {
-// printf("constructor CountArangeDescriptors()\n");
- }
- void operator()(const DWARFDebugArangeSet &set) {
-count += set.NumDescriptors();
- }
- uint32_t &count;
-};
-
// Extract
void DWARFDebugAranges::extract(const DWARFDataExtractor &debug_aranges_data) {
+ llvm::DWARFDataExtractor llvm_dwarf_data =
+ debug_aranges_data.GetAsLLVMDWARF();
lldb::offset_t offset = 0;
DWARFDebugArangeSet set;
Range range;
- while (debug_aranges_data.ValidOffset(offset)) {
+ while (llvm_dwarf_data.isValidOffset(offset)) {
const lldb::offset_t set_offset = offset;
-if (llvm::Error error = set.extract(debug_aranges_data, &offset)) {
+if (llvm::Error error = set.extract(llvm_dwarf_data, &offset, nullptr)) {
ZequanWu wrote:
It's a warning handler function. I leave it to nullptr on purpose to preserve
lldb's current behaviour so that it doesn't emit extra warnings.
I change the third parameter on `llvm::DWARFDebugArangeSet::extract` to be
nullptr be default. So, we can omit it.
https://github.com/llvm/llvm-project/pull/110058
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Support frame recognizer regexp on mangled names. (PR #105756)
adrian-prantl wrote: > @adrian-prantl Now that #105695 is merged, do you still want to open a > follow-up pull request to change the assert-recognizer and the > verbose-trap-recognizer to use `ePreferMangled`? That would be a nice improvement! https://github.com/llvm/llvm-project/pull/105756 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [DWARF]Set uuid for symbol file spec (PR #110066)
clayborg wrote: Change looks good to me, but we should find a way to test. We just need a test file + .dwp file and load that into lldb and force it to try and find the symbols right? Shouldn't require a core file. Then both the executable + .dwp file can be obj2yaml'ed https://github.com/llvm/llvm-project/pull/110066 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Fix minor runCmd error message formatting (PR #110150)
https://github.com/JDevlieghere approved this pull request. https://github.com/llvm/llvm-project/pull/110150 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Fix minor runCmd error message formatting (PR #110150)
https://github.com/bulbazord approved this pull request. https://github.com/llvm/llvm-project/pull/110150 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Inline expression evaluator error visualization (PR #106470)
adrian-prantl wrote: Done. @labath, you can now opt into the inline diagnostics with `show-inline-diagnostics` which `tools/driver` sets. https://github.com/llvm/llvm-project/pull/106470 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Add docs describing how the thread plan stack affects stepping (PR #110167)
https://github.com/jimingham created https://github.com/llvm/llvm-project/pull/110167 This is a convenient little feature of lldb, but if you didn't know it was there you'd likely never discover it. >From 0f79f9cf1820b46199fe587cafc67532136ed04b Mon Sep 17 00:00:00 2001 From: Jim Ingham Date: Thu, 26 Sep 2024 13:31:57 -0700 Subject: [PATCH] Add docs describing how the thread plan stack affects stepping --- lldb/docs/use/tutorial.rst | 27 +++ 1 file changed, 27 insertions(+) diff --git a/lldb/docs/use/tutorial.rst b/lldb/docs/use/tutorial.rst index 00e7befdd087a4..57bf6c4479801e 100644 --- a/lldb/docs/use/tutorial.rst +++ b/lldb/docs/use/tutorial.rst @@ -536,6 +536,33 @@ This command will run the thread in the current frame until it reaches line 100 in this frame or stops if it leaves the current frame. This is a pretty close equivalent to GDB's ``until`` command. +One other useful thing to note about the lldb stepping commands is that they +are implemented as a stack of interruptible operations. Until the operation - +e.g. step to the next line - is completed, the operation will remain on the +stack. If it is interrupted, new stepping commands will result in their +operations being pushed onto the stack, each of them retired as they are completed. + +Suppose, for instance, you ``step-over`` a source line, and hit a breakpoint +in a function called by the code of the line you are stepping over. Since the step-over +operation remains on the stack, you can examine the state at +the point of the breakpoint hit, step around in that frame, step in to other +frames, hit other breakpoints, etc. Then when you are done, a simple ``continue`` +will resume the original ``step-over`` operation, only ending when the desired line is reached. +This saves you from having to manually issue some number of ``step-out`` commands +to get back to the frame you were stepping over. + +Hand-called functions using the ``expr`` command are also implemented by +operations on this same stack. So if you are calling some code with the ``expr`` command, +and hit a breakpoint during the evaluation of that code, you can examine +the state where you stopped, step around at your convenience, and then issue a +``continue`` which will finish the expression evaluation operation and print the function +result. + +You can examine the state of the operations stack using the ``thread plan list`` +command, and if, for instance, you decide you don't actually want that outermost +next to continue running, you can remove it with the ``thread plan discard`` +command. + A process, by default, will share the LLDB terminal with the inferior process. When in this mode, much like when debugging with GDB, when the process is running anything you type will go to the ``STDIN`` of the inferior process. To ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Add docs describing how the thread plan stack affects stepping (PR #110167)
llvmbot wrote: @llvm/pr-subscribers-lldb Author: None (jimingham) Changes This is a convenient little feature of lldb, but if you didn't know it was there you'd likely never discover it. --- Full diff: https://github.com/llvm/llvm-project/pull/110167.diff 1 Files Affected: - (modified) lldb/docs/use/tutorial.rst (+27) ``diff diff --git a/lldb/docs/use/tutorial.rst b/lldb/docs/use/tutorial.rst index 00e7befdd087a4..57bf6c4479801e 100644 --- a/lldb/docs/use/tutorial.rst +++ b/lldb/docs/use/tutorial.rst @@ -536,6 +536,33 @@ This command will run the thread in the current frame until it reaches line 100 in this frame or stops if it leaves the current frame. This is a pretty close equivalent to GDB's ``until`` command. +One other useful thing to note about the lldb stepping commands is that they +are implemented as a stack of interruptible operations. Until the operation - +e.g. step to the next line - is completed, the operation will remain on the +stack. If it is interrupted, new stepping commands will result in their +operations being pushed onto the stack, each of them retired as they are completed. + +Suppose, for instance, you ``step-over`` a source line, and hit a breakpoint +in a function called by the code of the line you are stepping over. Since the step-over +operation remains on the stack, you can examine the state at +the point of the breakpoint hit, step around in that frame, step in to other +frames, hit other breakpoints, etc. Then when you are done, a simple ``continue`` +will resume the original ``step-over`` operation, only ending when the desired line is reached. +This saves you from having to manually issue some number of ``step-out`` commands +to get back to the frame you were stepping over. + +Hand-called functions using the ``expr`` command are also implemented by +operations on this same stack. So if you are calling some code with the ``expr`` command, +and hit a breakpoint during the evaluation of that code, you can examine +the state where you stopped, step around at your convenience, and then issue a +``continue`` which will finish the expression evaluation operation and print the function +result. + +You can examine the state of the operations stack using the ``thread plan list`` +command, and if, for instance, you decide you don't actually want that outermost +next to continue running, you can remove it with the ``thread plan discard`` +command. + A process, by default, will share the LLDB terminal with the inferior process. When in this mode, much like when debugging with GDB, when the process is running anything you type will go to the ``STDIN`` of the inferior process. To `` https://github.com/llvm/llvm-project/pull/110167 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Improve type lookup using .debug_names parent chain (PR #108907)
https://github.com/kusmour commented: Just some nits https://github.com/llvm/llvm-project/pull/108907 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Improve type lookup using .debug_names parent chain (PR #108907)
https://github.com/kusmour edited https://github.com/llvm/llvm-project/pull/108907 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Improve type lookup using .debug_names parent chain (PR #108907)
@@ -115,6 +122,11 @@ class DWARFIndex {
bool
GetFullyQualifiedTypeImpl(const DWARFDeclContext &context, DWARFDIE die,
llvm::function_ref callback);
+
+ /// Check if the type \a die can meet the requirements of \a query.
+ bool
+ ProcessTypeDieMatchQuery(TypeQuery &query, DWARFDIE die,
kusmour wrote:
Looks like other function names use all cap for DIE
```suggestion
ProcessTypeDIEMatchQuery(TypeQuery &query, DWARFDIE die,
```
https://github.com/llvm/llvm-project/pull/108907
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Improve type lookup using .debug_names parent chain (PR #108907)
@@ -118,6 +122,36 @@ class DebugNamesDWARFIndex : public DWARFIndex {
bool SameParentChain(llvm::ArrayRef parent_names,
llvm::ArrayRef parent_entries) const;
+ bool SameParentChain(llvm::ArrayRef parent_names,
kusmour wrote:
```suggestion
bool SameParentChain(llvm::ArrayRef parent_contexts,
```
https://github.com/llvm/llvm-project/pull/108907
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Fix minor runCmd error message formatting (PR #110150)
https://github.com/kastiglione closed https://github.com/llvm/llvm-project/pull/110150 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] bfe2994 - [lldb] Fix minor runCmd error message formatting (#110150)
Author: Dave Lee
Date: 2024-09-26T13:39:54-07:00
New Revision: bfe29945603e2040cc56d9e30f05da0627c819cd
URL:
https://github.com/llvm/llvm-project/commit/bfe29945603e2040cc56d9e30f05da0627c819cd
DIFF:
https://github.com/llvm/llvm-project/commit/bfe29945603e2040cc56d9e30f05da0627c819cd.diff
LOG: [lldb] Fix minor runCmd error message formatting (#110150)
This tweaks the construction of the error message when using `expect`/`runCmd`.
With
this change, the stdout/stderr is placed after the message "Command ''
did not
return successfully".
Before:
```
AssertionError: False is not True : Command 'p whatever
Error output:
error:
' did not return successfully
```
After:
```
AssertionError: False is not True : Command 'p whatever' did not return
successfully
Error output:
error:
```
Added:
Modified:
lldb/packages/Python/lldbsuite/test/lldbtest.py
Removed:
diff --git a/lldb/packages/Python/lldbsuite/test/lldbtest.py
b/lldb/packages/Python/lldbsuite/test/lldbtest.py
index c6b7ce84109c09..8884ef5933ada8 100644
--- a/lldb/packages/Python/lldbsuite/test/lldbtest.py
+++ b/lldb/packages/Python/lldbsuite/test/lldbtest.py
@@ -172,9 +172,9 @@
WATCHPOINT_CREATED = "Watchpoint created successfully"
-def CMD_MSG(str):
+def CMD_MSG(command):
"""A generic "Command '%s' did not return successfully" message
generator."""
-return "Command '%s' did not return successfully" % str
+return f"Command '{command}' did not return successfully"
def COMPLETION_MSG(str_before, str_after, completions):
@@ -990,16 +990,14 @@ def runCmd(self, cmd, msg=None, check=True, trace=False,
inHistory=False):
print("Command '" + cmd + "' failed!", file=sbuf)
if check:
+if not msg:
+msg = CMD_MSG(cmd)
output = ""
if self.res.GetOutput():
output += "\nCommand output:\n" + self.res.GetOutput()
if self.res.GetError():
output += "\nError output:\n" + self.res.GetError()
-if msg:
-msg += output
-if cmd:
-cmd += output
-self.assertTrue(self.res.Succeeded(), msg if (msg) else
CMD_MSG(cmd))
+self.assertTrue(self.res.Succeeded(), msg + output)
def HideStdout(self):
"""Hide output to stdout from the user.
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Add docs describing how the thread plan stack affects stepping (PR #110167)
@@ -536,6 +536,33 @@ This command will run the thread in the current frame until it reaches line 100 in this frame or stops if it leaves the current frame. This is a pretty close equivalent to GDB's ``until`` command. +One other useful thing to note about the lldb stepping commands is that they +are implemented as a stack of interruptible operations. Until the operation - +e.g. step to the next line - is completed, the operation will remain on the +stack. If it is interrupted, new stepping commands will result in their bulbazord wrote: I'm not 100% clear on what this sentence means. To confirm my understanding, you're trying to say something like "Interrupting a thread's execution doesn't clear the stack and running further stepping commands after that will push more operations to the stack". Is that right? https://github.com/llvm/llvm-project/pull/110167 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Add docs describing how the thread plan stack affects stepping (PR #110167)
@@ -536,6 +536,33 @@ This command will run the thread in the current frame until it reaches line 100 in this frame or stops if it leaves the current frame. This is a pretty close equivalent to GDB's ``until`` command. +One other useful thing to note about the lldb stepping commands is that they +are implemented as a stack of interruptible operations. Until the operation - +e.g. step to the next line - is completed, the operation will remain on the +stack. If it is interrupted, new stepping commands will result in their +operations being pushed onto the stack, each of them retired as they are completed. + +Suppose, for instance, you ``step-over`` a source line, and hit a breakpoint +in a function called by the code of the line you are stepping over. Since the step-over +operation remains on the stack, you can examine the state at +the point of the breakpoint hit, step around in that frame, step in to other +frames, hit other breakpoints, etc. Then when you are done, a simple ``continue`` +will resume the original ``step-over`` operation, only ending when the desired line is reached. +This saves you from having to manually issue some number of ``step-out`` commands +to get back to the frame you were stepping over. + +Hand-called functions using the ``expr`` command are also implemented by +operations on this same stack. So if you are calling some code with the ``expr`` command, +and hit a breakpoint during the evaluation of that code, you can examine +the state where you stopped, step around at your convenience, and then issue a +``continue`` which will finish the expression evaluation operation and print the function +result. + +You can examine the state of the operations stack using the ``thread plan list`` +command, and if, for instance, you decide you don't actually want that outermost +next to continue running, you can remove it with the ``thread plan discard`` +command. + bulbazord wrote: Suggestion: Perhaps mention the thread plan logging channel? `thread plan list` and `thread plan discard` are obviously more accessible but the logging channel shows the changes to the stack as they occur. https://github.com/llvm/llvm-project/pull/110167 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Add docs describing how the thread plan stack affects stepping (PR #110167)
https://github.com/bulbazord edited https://github.com/llvm/llvm-project/pull/110167 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Add docs describing how the thread plan stack affects stepping (PR #110167)
https://github.com/bulbazord approved this pull request. LGTM, a few minor suggestions but nothing of great importance. Thanks for writing this up! https://github.com/llvm/llvm-project/pull/110167 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Add docs describing how the thread plan stack affects stepping (PR #110167)
@@ -536,6 +536,33 @@ This command will run the thread in the current frame until it reaches line 100 in this frame or stops if it leaves the current frame. This is a pretty close equivalent to GDB's ``until`` command. +One other useful thing to note about the lldb stepping commands is that they +are implemented as a stack of interruptible operations. Until the operation - +e.g. step to the next line - is completed, the operation will remain on the +stack. If it is interrupted, new stepping commands will result in their +operations being pushed onto the stack, each of them retired as they are completed. + +Suppose, for instance, you ``step-over`` a source line, and hit a breakpoint +in a function called by the code of the line you are stepping over. Since the step-over bulbazord wrote: There's a lot of qualifiers in the second clause of the first sentence. I think you could rephrase it as something like this. Suggestion: ``` Suppose, for instance, you `step-over` a source line with a function call. If there is a breakpoint placed in that function, LLDB will stop there with the `step-over` operation still on the stack. ``` https://github.com/llvm/llvm-project/pull/110167 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Add docs describing how the thread plan stack affects stepping (PR #110167)
@@ -536,6 +536,33 @@ This command will run the thread in the current frame until it reaches line 100 in this frame or stops if it leaves the current frame. This is a pretty close equivalent to GDB's ``until`` command. +One other useful thing to note about the lldb stepping commands is that they +are implemented as a stack of interruptible operations. Until the operation - +e.g. step to the next line - is completed, the operation will remain on the bulbazord wrote: Suggestion: `Until the operation - ... - is completed, it will remain ...` You have `the operation` written multiple times here, I think it will flow better if you shorten that one. https://github.com/llvm/llvm-project/pull/110167 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Introduce an always-on system log category/channel (PR #108495)
https://github.com/labath approved this pull request. https://github.com/llvm/llvm-project/pull/108495 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Introduce an always-on system log category/channel (PR #108495)
@@ -272,6 +272,12 @@ class Log final {
void VAFormatf(llvm::StringRef file, llvm::StringRef function,
const char *format, va_list args);
+ void Enable(const std::shared_ptr &handler_sp,
+ uint32_t options = 0,
+ MaskType flags = std::numeric_limits::max());
labath wrote:
The log channels have a concept of a default set of categories, so if we're
going to have a default here, it better be it. That could be achieved by making
this an `optional` (and then you can also simplify the code in
`EnableLogChannel`).
https://github.com/llvm/llvm-project/pull/108495
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Introduce an always-on system log category/channel (PR #108495)
@@ -83,6 +85,9 @@ llvm::Error SystemInitializerFull::Initialize() {
// Use the Debugger's LLDBAssert callback.
SetLLDBAssertCallback(Debugger::AssertCallback);
+ // Log the LLDB version to the system log.
labath wrote:
I don't think this tells us anything new.
https://github.com/llvm/llvm-project/pull/108495
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Improve type lookup using .debug_names parent chain (PR #108907)
https://github.com/jeffreytan81 updated
https://github.com/llvm/llvm-project/pull/108907
>From 6e84ab9a14e63c58e1facdbf9a695c093882b37b Mon Sep 17 00:00:00 2001
From: jeffreytan81
Date: Mon, 19 Aug 2024 10:57:35 -0700
Subject: [PATCH 1/2] Fix StartDebuggingRequestHandler/ReplModeRequestHandler
in lldb-dap
---
lldb/tools/lldb-dap/DAP.h| 2 --
lldb/tools/lldb-dap/lldb-dap.cpp | 4 ++--
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/lldb/tools/lldb-dap/DAP.h b/lldb/tools/lldb-dap/DAP.h
index 57562a14983519..7828272aa15a7d 100644
--- a/lldb/tools/lldb-dap/DAP.h
+++ b/lldb/tools/lldb-dap/DAP.h
@@ -192,8 +192,6 @@ struct DAP {
std::mutex call_mutex;
std::map
inflight_reverse_requests;
- StartDebuggingRequestHandler start_debugging_request_handler;
- ReplModeRequestHandler repl_mode_request_handler;
ReplMode repl_mode;
std::string command_escape_prefix = "`";
lldb::SBFormat frame_format;
diff --git a/lldb/tools/lldb-dap/lldb-dap.cpp b/lldb/tools/lldb-dap/lldb-dap.cpp
index ea84f31aec3a6c..f50a6c17310739 100644
--- a/lldb/tools/lldb-dap/lldb-dap.cpp
+++ b/lldb/tools/lldb-dap/lldb-dap.cpp
@@ -1627,12 +1627,12 @@ void request_initialize(const llvm::json::Object
&request) {
"lldb-dap", "Commands for managing lldb-dap.");
if (GetBoolean(arguments, "supportsStartDebuggingRequest", false)) {
cmd.AddCommand(
-"startDebugging", &g_dap.start_debugging_request_handler,
+"startDebugging", new StartDebuggingRequestHandler(),
"Sends a startDebugging request from the debug adapter to the client "
"to start a child debug session of the same type as the caller.");
}
cmd.AddCommand(
- "repl-mode", &g_dap.repl_mode_request_handler,
+ "repl-mode", new ReplModeRequestHandler(),
"Get or set the repl behavior of lldb-dap evaluation requests.");
g_dap.progress_event_thread = std::thread(ProgressEventThreadFunction);
>From 750362e2c5e5cba7f7cd385698ff6c95c025f5c8 Mon Sep 17 00:00:00 2001
From: jeffreytan81
Date: Mon, 23 Sep 2024 16:40:16 -0700
Subject: [PATCH 2/2] Improve type query using .debug_names parent chain
---
.../Plugins/SymbolFile/DWARF/DWARFIndex.cpp | 25
.../Plugins/SymbolFile/DWARF/DWARFIndex.h | 12 ++
.../SymbolFile/DWARF/DebugNamesDWARFIndex.cpp | 123 +-
.../SymbolFile/DWARF/DebugNamesDWARFIndex.h | 34 +
.../SymbolFile/DWARF/SymbolFileDWARF.cpp | 5 +-
5 files changed, 196 insertions(+), 3 deletions(-)
diff --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFIndex.cpp
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFIndex.cpp
index eafddbad03f57b..dee90804c52584 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFIndex.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFIndex.cpp
@@ -126,3 +126,28 @@ bool DWARFIndex::GetFullyQualifiedTypeImpl(
return callback(die);
return true;
}
+
+void DWARFIndex::GetTypesWithQuery(
+TypeQuery &query, llvm::function_ref callback) {
+ GetTypes(query.GetTypeBasename(), [&](DWARFDIE die) {
+return ProcessTypeDIEMatchQuery(query, die, callback);
+ });
+}
+
+bool DWARFIndex::ProcessTypeDIEMatchQuery(
+TypeQuery &query, DWARFDIE die,
+llvm::function_ref callback) {
+ // Nothing to match from query
+ if (query.GetContextRef().size() <= 1)
+return callback(die);
+
+ std::vector die_context;
+ if (query.GetModuleSearch())
+die_context = die.GetDeclContext();
+ else
+die_context = die.GetTypeLookupContext();
+
+ if (!query.ContextMatches(die_context))
+return true;
+ return callback(die);
+}
diff --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFIndex.h
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFIndex.h
index cb3ae8a06d7885..fea3a4fd697389 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFIndex.h
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFIndex.h
@@ -64,6 +64,13 @@ class DWARFIndex {
virtual void
GetNamespaces(ConstString name,
llvm::function_ref callback) = 0;
+ /// Get type DIEs meeting requires of \a query.
+ /// in its decl parent chain as subset. A base implementation is provided,
+ /// Specializations should override this if they are able to provide a faster
+ /// implementation.
+ virtual void
+ GetTypesWithQuery(TypeQuery &query,
+llvm::function_ref callback);
virtual void
GetFunctions(const Module::LookupInfo &lookup_info, SymbolFileDWARF &dwarf,
const CompilerDeclContext &parent_decl_ctx,
@@ -115,6 +122,11 @@ class DWARFIndex {
bool
GetFullyQualifiedTypeImpl(const DWARFDeclContext &context, DWARFDIE die,
llvm::function_ref callback);
+
+ /// Check if the type \a die can meet the requirements of \a query.
+ bool
+ ProcessTypeDIEMatchQuery(TypeQuery &query, DWARFDIE die,
+ llvm::function_ref callback);
};
} // namespace dwarf
} // namespace lldb_private::plugin
diff --git a/lldb/source/Plugins/SymbolFile/DWARF/Deb
[Lldb-commits] [lldb] c117222 - [LLDB][Minidump] Add Multiplatform test to ensure determinism (#108602)
Author: Jacob Lalonde
Date: 2024-09-26T14:33:12-07:00
New Revision: c1173bacf604e60414542743d021a9f13aee
URL:
https://github.com/llvm/llvm-project/commit/c1173bacf604e60414542743d021a9f13aee
DIFF:
https://github.com/llvm/llvm-project/commit/c1173bacf604e60414542743d021a9f13aee.diff
LOG: [LLDB][Minidump] Add Multiplatform test to ensure determinism (#108602)
Adds a test that ensures two minidumps produced from the same target are
the same bytes. Covers the three primary core flavors.
Added:
Modified:
lldb/test/API/functionalities/process_save_core_minidump/TestProcessSaveCoreMinidump.py
Removed:
diff --git
a/lldb/test/API/functionalities/process_save_core_minidump/TestProcessSaveCoreMinidump.py
b/lldb/test/API/functionalities/process_save_core_minidump/TestProcessSaveCoreMinidump.py
index ccdb6653cf16f8..03cc415924e0bb 100644
---
a/lldb/test/API/functionalities/process_save_core_minidump/TestProcessSaveCoreMinidump.py
+++
b/lldb/test/API/functionalities/process_save_core_minidump/TestProcessSaveCoreMinidump.py
@@ -522,3 +522,46 @@ def minidump_deleted_on_save_failure(self):
finally:
self.assertTrue(self.dbg.DeleteTarget(target))
+
+def minidump_deterministic_
diff erence(self):
+"""Test that verifies that two minidumps produced are identical."""
+
+self.build()
+exe = self.getBuildArtifact("a.out")
+try:
+target = self.dbg.CreateTarget(exe)
+process = target.LaunchSimple(
+None, None, self.get_process_working_directory()
+)
+self.assertState(process.GetState(), lldb.eStateStopped)
+
+core_styles = [
+lldb.eSaveCoreStackOnly,
+lldb.eSaveCoreDirtyOnly,
+lldb.eSaveCoreFull,
+]
+for style in core_styles:
+spec_one =
lldb.SBFileSpec(self.getBuildArtifact("core.one.dmp"))
+spec_two =
lldb.SBFileSpec(self.getBuildArtifact("core.two.dmp"))
+options = lldb.SBSaveCoreOptions()
+options.SetOutputFile(spec_one)
+options.SetPluginName("minidump")
+options.SetStyle(style)
+error = process.SaveCore(options)
+self.assertTrue(error.Success())
+options.SetOutputFile(spec_two)
+error = process.SaveCore(options)
+self.assertTrue(error.Success())
+
+file_one = None
+file_two = None
+with open(spec_one.GetFileName(), mode="rb") as file:
+file_one = file.read()
+with open(spec_two.GetFileName(), mode="rb") as file:
+file_two = file.read()
+self.assertEqual(file_one, file_two)
+self.assertTrue(os.unlink(spec_one.GetFileName()))
+self.assertTrue(os.unlink(spec_two.GetFileName()))
+
+finally:
+self.assertTrue(self.dbg.DeleteTarget(target))
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB][Minidump] Add Multiplatform test to ensure determinism (PR #108602)
https://github.com/Jlalond closed https://github.com/llvm/llvm-project/pull/108602 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Add docs describing how the thread plan stack affects stepping (PR #110167)
https://github.com/jimingham updated https://github.com/llvm/llvm-project/pull/110167 >From 0f79f9cf1820b46199fe587cafc67532136ed04b Mon Sep 17 00:00:00 2001 From: Jim Ingham Date: Thu, 26 Sep 2024 13:31:57 -0700 Subject: [PATCH 1/2] Add docs describing how the thread plan stack affects stepping --- lldb/docs/use/tutorial.rst | 27 +++ 1 file changed, 27 insertions(+) diff --git a/lldb/docs/use/tutorial.rst b/lldb/docs/use/tutorial.rst index 00e7befdd087a4..57bf6c4479801e 100644 --- a/lldb/docs/use/tutorial.rst +++ b/lldb/docs/use/tutorial.rst @@ -536,6 +536,33 @@ This command will run the thread in the current frame until it reaches line 100 in this frame or stops if it leaves the current frame. This is a pretty close equivalent to GDB's ``until`` command. +One other useful thing to note about the lldb stepping commands is that they +are implemented as a stack of interruptible operations. Until the operation - +e.g. step to the next line - is completed, the operation will remain on the +stack. If it is interrupted, new stepping commands will result in their +operations being pushed onto the stack, each of them retired as they are completed. + +Suppose, for instance, you ``step-over`` a source line, and hit a breakpoint +in a function called by the code of the line you are stepping over. Since the step-over +operation remains on the stack, you can examine the state at +the point of the breakpoint hit, step around in that frame, step in to other +frames, hit other breakpoints, etc. Then when you are done, a simple ``continue`` +will resume the original ``step-over`` operation, only ending when the desired line is reached. +This saves you from having to manually issue some number of ``step-out`` commands +to get back to the frame you were stepping over. + +Hand-called functions using the ``expr`` command are also implemented by +operations on this same stack. So if you are calling some code with the ``expr`` command, +and hit a breakpoint during the evaluation of that code, you can examine +the state where you stopped, step around at your convenience, and then issue a +``continue`` which will finish the expression evaluation operation and print the function +result. + +You can examine the state of the operations stack using the ``thread plan list`` +command, and if, for instance, you decide you don't actually want that outermost +next to continue running, you can remove it with the ``thread plan discard`` +command. + A process, by default, will share the LLDB terminal with the inferior process. When in this mode, much like when debugging with GDB, when the process is running anything you type will go to the ``STDIN`` of the inferior process. To >From 2d420a71cc945ad4c090e8ff56f2b505956845ea Mon Sep 17 00:00:00 2001 From: Jim Ingham Date: Thu, 26 Sep 2024 16:38:31 -0700 Subject: [PATCH 2/2] Address review comments. --- lldb/docs/use/tutorial.rst | 40 -- 1 file changed, 25 insertions(+), 15 deletions(-) diff --git a/lldb/docs/use/tutorial.rst b/lldb/docs/use/tutorial.rst index 57bf6c4479801e..76e8ac4aeab89c 100644 --- a/lldb/docs/use/tutorial.rst +++ b/lldb/docs/use/tutorial.rst @@ -538,30 +538,40 @@ equivalent to GDB's ``until`` command. One other useful thing to note about the lldb stepping commands is that they are implemented as a stack of interruptible operations. Until the operation - -e.g. step to the next line - is completed, the operation will remain on the -stack. If it is interrupted, new stepping commands will result in their -operations being pushed onto the stack, each of them retired as they are completed. - -Suppose, for instance, you ``step-over`` a source line, and hit a breakpoint -in a function called by the code of the line you are stepping over. Since the step-over -operation remains on the stack, you can examine the state at -the point of the breakpoint hit, step around in that frame, step in to other -frames, hit other breakpoints, etc. Then when you are done, a simple ``continue`` -will resume the original ``step-over`` operation, only ending when the desired line is reached. -This saves you from having to manually issue some number of ``step-out`` commands -to get back to the frame you were stepping over. +e.g. step to the next line - is completed, it will remain on the +stack. If the step over is interrupted and control returned to you, +any new stepping commands you issue won't replace the step-over, but instead +their operations will be pushed onto the stack after the original step over. +Then each of them will be retired as they are completed, finally returning to the +original step over operation. + +Suppose, for instance, you ``step-over`` a source line with a function call. +If there is a breakpoint in that function, hitting the breakpoint will interrupt +the step over. At that point, you will likely want to examine the state at +the breakpoint, maybe stepping around
[Lldb-commits] [lldb] Add docs describing how the thread plan stack affects stepping (PR #110167)
chelcassanova wrote: Adding myself as a reviewer here, I didn't know about either of these commands and the behaviour described here is something I've noticed without knowing exactly what was happening 😅 . The explanation for the docs looks good here so this LGTM. https://github.com/llvm/llvm-project/pull/110167 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB][Minidump] Add Multiplatform test to ensure determinism (PR #108602)
https://github.com/kusmour approved this pull request. 🚀 https://github.com/llvm/llvm-project/pull/108602 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Add docs describing how the thread plan stack affects stepping (PR #110167)
https://github.com/chelcassanova approved this pull request. https://github.com/llvm/llvm-project/pull/110167 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB][ProcessELFCore] Add Description to ProcessELFCore/ELFThread stop reasons (PR #110065)
Jlalond wrote: Looks like I got some failures due to the tests expecting an exact string match. Will fix https://github.com/llvm/llvm-project/pull/110065 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Inline expression evaluator error visualization (PR #106470)
https://github.com/adrian-prantl updated
https://github.com/llvm/llvm-project/pull/106470
>From 9f4ba3fdb8b144736e51134ced3019a2c57ca861 Mon Sep 17 00:00:00 2001
From: Adrian Prantl
Date: Wed, 28 Aug 2024 10:04:33 -0700
Subject: [PATCH 1/2] [lldb] Store expression evaluator diagnostics in an
llvm::Error (NFC)
This patch is a reworking of Pete Lawrence's (@PortalPete) proposal
for better expression evaluator error messages:
https://github.com/llvm/llvm-project/pull/80938
This patch is preparatory patch for improving the rendering of
expression evaluator diagnostics. Currently diagnostics are rendered
into a string and the command interpreter layer then textually parses
words like "error:" to (sometimes) color the output accordingly. In
order to enable user interfaces to do better with diagnostics, we need
to store them in a machine-readable fromat. This patch does this by
adding a new llvm::Error kind wrapping a DiagnosticDetail struct that
is used when the error type is eErrorTypeExpression. Multiple
diagnostics are modeled using llvm::ErrorList.
Right now the extra information is not used by the CommandInterpreter,
this will be added in a follow-up patch!
---
.../lldb/Expression/DiagnosticManager.h | 89 +++
lldb/include/lldb/Utility/Status.h| 23 ++--
lldb/source/Breakpoint/BreakpointLocation.cpp | 11 +-
lldb/source/Expression/DiagnosticManager.cpp | 103 +++---
lldb/source/Expression/ExpressionParser.cpp | 5 +-
lldb/source/Expression/UserExpression.cpp | 49 +
lldb/source/Expression/UtilityFunction.cpp| 18 +--
.../ExpressionParser/Clang/ClangDiagnostic.h | 5 +-
.../Clang/ClangExpressionParser.cpp | 69
.../Clang/ClangUserExpression.h | 2 +
.../Plugins/Platform/POSIX/PlatformPOSIX.cpp | 12 +-
.../Platform/Windows/PlatformWindows.cpp | 12 +-
lldb/source/Target/Target.cpp | 3 +-
lldb/source/Utility/Status.cpp| 29 +
.../TestModulesCompileError.py| 2 +-
.../Expression/DiagnosticManagerTest.cpp | 22 +++-
16 files changed, 292 insertions(+), 162 deletions(-)
diff --git a/lldb/include/lldb/Expression/DiagnosticManager.h
b/lldb/include/lldb/Expression/DiagnosticManager.h
index d49b7c99b114fb..3e363ee5c0139c 100644
--- a/lldb/include/lldb/Expression/DiagnosticManager.h
+++ b/lldb/include/lldb/Expression/DiagnosticManager.h
@@ -12,6 +12,9 @@
#include "lldb/lldb-defines.h"
#include "lldb/lldb-types.h"
+#include "lldb/Utility/FileSpec.h"
+#include "lldb/Utility/Status.h"
+
#include "llvm/ADT/STLExtras.h"
#include "llvm/ADT/StringRef.h"
@@ -20,6 +23,53 @@
namespace lldb_private {
+/// A compiler-independent representation of a Diagnostic. Expression
+/// evaluation failures often have more than one diagnostic that a UI
+/// layer might want to render differently, for example to colorize
+/// it.
+///
+/// Running example:
+/// (lldb) expr 1+foo
+/// error: :1:3: use of undeclared identifier 'foo'
+/// 1+foo
+/// ^
+struct DiagnosticDetail {
+ struct SourceLocation {
+FileSpec file;
+unsigned line = 0;
+uint16_t column = 0;
+uint16_t length = 0;
+bool in_user_input = false;
+ };
+ /// Contains {{}, 1, 3, 3, true} in the example above.
+ std::optional source_location;
+ /// Contains eSeverityError in the example above.
+ lldb::Severity severity = lldb::eSeverityInfo;
+ /// Contains "use of undeclared identifier 'x'" in the example above.
+ std::string message;
+ /// Contains the fully rendered error message.
+ std::string rendered;
+};
+
+/// An llvm::Error used to communicate diagnostics in Status. Multiple
+/// diagnostics may be chained in an llvm::ErrorList.
+class ExpressionError
+: public llvm::ErrorInfo {
+ std::string m_message;
+ std::vector m_details;
+
+public:
+ static char ID;
+ using llvm::ErrorInfo::ErrorInfo;
+ ExpressionError(lldb::ExpressionResults result, std::string msg,
+ std::vector details = {});
+ std::string message() const override;
+ llvm::ArrayRef GetDetail() const { return m_details; }
+ std::error_code convertToErrorCode() const override;
+ void log(llvm::raw_ostream &OS) const override;
+ std::unique_ptr Clone() const override;
+};
+
enum DiagnosticOrigin {
eDiagnosticOriginUnknown = 0,
eDiagnosticOriginLLDB,
@@ -49,37 +99,28 @@ class Diagnostic {
}
}
- Diagnostic(llvm::StringRef message, lldb::Severity severity,
- DiagnosticOrigin origin, uint32_t compiler_id)
- : m_message(message), m_severity(severity), m_origin(origin),
-m_compiler_id(compiler_id) {}
-
- Diagnostic(const Diagnostic &rhs)
- : m_message(rhs.m_message), m_severity(rhs.m_severity),
-m_origin(rhs.m_origin), m_compiler_id(rhs.m_compiler_id) {}
+ Diagnostic(DiagnosticOrigin origin, uint32_t compiler_id,
+ DiagnosticDetail detail)
+ : m_origin(origin), m_compiler_id(com
[Lldb-commits] [lldb] Add docs describing how the thread plan stack affects stepping (PR #110167)
https://github.com/adrian-prantl approved this pull request. https://github.com/llvm/llvm-project/pull/110167 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
