[Lldb-commits] [lldb] [lldb][Linux] Mark memory regions used for shadow stacks (PR #117861)
DavidSpickett wrote: GCS is not implemented in QEMU yet - https://linaro.atlassian.net/browse/QEMU-517. I used Arm's Foundation Model via shrinkwrap: ``` $ shrinkwrap build --overlay=arch/v9.5.yaml ns-edk2.yaml $ shrinkwrap run --rtvar=KERNEL=/home/davspi01/work/open_source/linux.build/arm64/arch/arm64/boot/Image --rtvar=ROOTFS=/home/davspi01/work/open_source/jammy-arm64-rootfs.img ns-edk2.yaml ``` For some reason it always mounts the file system read only on my machine, so you may need to remount it as writeable. I used our existing script to build the rootfs and kernel, didn't need to change anything for GCS to be detected. https://github.com/llvm/llvm-project/pull/117861 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][debugserver] Read/write SME registers on arm64 (PR #119171)
@@ -0,0 +1,111 @@
+/// BUILT with
+///xcrun -sdk macosx.internal clang -mcpu=apple-m4 -g sme.c -o sme
+
+#include
+#include
+#include
+
+void write_sve_regs() {
+ asm volatile("ptrue p0.b\n\t");
+ asm volatile("ptrue p1.h\n\t");
+ asm volatile("ptrue p2.s\n\t");
+ asm volatile("ptrue p3.d\n\t");
+ asm volatile("pfalse p4.b\n\t");
+ asm volatile("ptrue p5.b\n\t");
+ asm volatile("ptrue p6.h\n\t");
+ asm volatile("ptrue p7.s\n\t");
+ asm volatile("ptrue p8.d\n\t");
+ asm volatile("pfalse p9.b\n\t");
+ asm volatile("ptrue p10.b\n\t");
+ asm volatile("ptrue p11.h\n\t");
+ asm volatile("ptrue p12.s\n\t");
+ asm volatile("ptrue p13.d\n\t");
+ asm volatile("pfalse p14.b\n\t");
+ asm volatile("ptrue p15.b\n\t");
+
+ asm volatile("cpy z0.b, p0/z, #1\n\t");
+ asm volatile("cpy z1.b, p5/z, #2\n\t");
+ asm volatile("cpy z2.b, p10/z, #3\n\t");
+ asm volatile("cpy z3.b, p15/z, #4\n\t");
+ asm volatile("cpy z4.b, p0/z, #5\n\t");
+ asm volatile("cpy z5.b, p5/z, #6\n\t");
+ asm volatile("cpy z6.b, p10/z, #7\n\t");
+ asm volatile("cpy z7.b, p15/z, #8\n\t");
+ asm volatile("cpy z8.b, p0/z, #9\n\t");
+ asm volatile("cpy z9.b, p5/z, #10\n\t");
+ asm volatile("cpy z10.b, p10/z, #11\n\t");
+ asm volatile("cpy z11.b, p15/z, #12\n\t");
+ asm volatile("cpy z12.b, p0/z, #13\n\t");
+ asm volatile("cpy z13.b, p5/z, #14\n\t");
+ asm volatile("cpy z14.b, p10/z, #15\n\t");
+ asm volatile("cpy z15.b, p15/z, #16\n\t");
+ asm volatile("cpy z16.b, p0/z, #17\n\t");
+ asm volatile("cpy z17.b, p5/z, #18\n\t");
+ asm volatile("cpy z18.b, p10/z, #19\n\t");
+ asm volatile("cpy z19.b, p15/z, #20\n\t");
+ asm volatile("cpy z20.b, p0/z, #21\n\t");
+ asm volatile("cpy z21.b, p5/z, #22\n\t");
+ asm volatile("cpy z22.b, p10/z, #23\n\t");
+ asm volatile("cpy z23.b, p15/z, #24\n\t");
+ asm volatile("cpy z24.b, p0/z, #25\n\t");
+ asm volatile("cpy z25.b, p5/z, #26\n\t");
+ asm volatile("cpy z26.b, p10/z, #27\n\t");
+ asm volatile("cpy z27.b, p15/z, #28\n\t");
+ asm volatile("cpy z28.b, p0/z, #29\n\t");
+ asm volatile("cpy z29.b, p5/z, #30\n\t");
+ asm volatile("cpy z30.b, p10/z, #31\n\t");
+ asm volatile("cpy z31.b, p15/z, #32\n\t");
+}
+
+#define MAX_VL_BYTES 256
+void set_za_register(int svl, int value_offset) {
+ uint8_t data[MAX_VL_BYTES];
+
+ // ldr za will actually wrap the selected vector row, by the number of rows
+ // you have. So setting one that didn't exist would actually set one that
did.
+ // That's why we need the streaming vector length here.
+ for (int i = 0; i < svl; ++i) {
+// This may involve instructions that require the smefa64 extension.
+for (int j = 0; j < MAX_VL_BYTES; j++)
+ data[j] = i + value_offset;
+// Each one of these loads a VL sized row of ZA.
+asm volatile("mov w12, %w0\n\t"
+ "ldr za[w12, 0], [%1]\n\t" ::"r"(i),
+ "r"(&data)
+ : "w12");
+ }
+}
+
+static uint16_t arm_sme_svl_b(void) {
+ uint64_t ret = 0;
+ asm volatile("rdsvl %[ret], #1" : [ret] "=r"(ret));
+ return (uint16_t)ret;
+}
+
+void arm_sme2_set_zt0() {
+#define ZTO_LEN (512 / 8)
+ uint8_t data[ZTO_LEN];
+ for (unsigned i = 0; i < ZTO_LEN; ++i)
+data[i] = i + 0;
+
+ asm volatile("ldr zt0, [%0]" ::"r"(&data));
+#undef ZT0_LEN
+}
+
+int main() {
+ printf("Enable SME mode\n");
+
+ asm volatile("smstart");
+
+ write_sve_regs();
+
+ set_za_register(arm_sme_svl_b(), 4);
+
+ arm_sme2_set_zt0();
+
+ int c = 10; // break here
+ c += 5;
+ c += 5;
jasonmolenda wrote:
Yeah I think you can disable streaming SVE mode (PSTATE.SM) and leave SME
(PSTATE.ZA) enabled (so the ZA/ZT0 registers keep their current contents), to
call a function or use FPSIMD instructions (and assuming the function you call
doesn't do any SME things). With the caveat that changing PSTATE.SM zeros out
the Z/V and P registers.
https://github.com/llvm/llvm-project/pull/119171
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][debugserver] Read/write SME registers on arm64 (PR #119171)
@@ -0,0 +1,111 @@
+/// BUILT with
+///xcrun -sdk macosx.internal clang -mcpu=apple-m4 -g sme.c -o sme
+
+#include
+#include
+#include
+
+void write_sve_regs() {
+ asm volatile("ptrue p0.b\n\t");
+ asm volatile("ptrue p1.h\n\t");
+ asm volatile("ptrue p2.s\n\t");
+ asm volatile("ptrue p3.d\n\t");
+ asm volatile("pfalse p4.b\n\t");
+ asm volatile("ptrue p5.b\n\t");
+ asm volatile("ptrue p6.h\n\t");
+ asm volatile("ptrue p7.s\n\t");
+ asm volatile("ptrue p8.d\n\t");
+ asm volatile("pfalse p9.b\n\t");
+ asm volatile("ptrue p10.b\n\t");
+ asm volatile("ptrue p11.h\n\t");
+ asm volatile("ptrue p12.s\n\t");
+ asm volatile("ptrue p13.d\n\t");
+ asm volatile("pfalse p14.b\n\t");
+ asm volatile("ptrue p15.b\n\t");
+
+ asm volatile("cpy z0.b, p0/z, #1\n\t");
+ asm volatile("cpy z1.b, p5/z, #2\n\t");
+ asm volatile("cpy z2.b, p10/z, #3\n\t");
+ asm volatile("cpy z3.b, p15/z, #4\n\t");
+ asm volatile("cpy z4.b, p0/z, #5\n\t");
+ asm volatile("cpy z5.b, p5/z, #6\n\t");
+ asm volatile("cpy z6.b, p10/z, #7\n\t");
+ asm volatile("cpy z7.b, p15/z, #8\n\t");
+ asm volatile("cpy z8.b, p0/z, #9\n\t");
+ asm volatile("cpy z9.b, p5/z, #10\n\t");
+ asm volatile("cpy z10.b, p10/z, #11\n\t");
+ asm volatile("cpy z11.b, p15/z, #12\n\t");
+ asm volatile("cpy z12.b, p0/z, #13\n\t");
+ asm volatile("cpy z13.b, p5/z, #14\n\t");
+ asm volatile("cpy z14.b, p10/z, #15\n\t");
+ asm volatile("cpy z15.b, p15/z, #16\n\t");
+ asm volatile("cpy z16.b, p0/z, #17\n\t");
+ asm volatile("cpy z17.b, p5/z, #18\n\t");
+ asm volatile("cpy z18.b, p10/z, #19\n\t");
+ asm volatile("cpy z19.b, p15/z, #20\n\t");
+ asm volatile("cpy z20.b, p0/z, #21\n\t");
+ asm volatile("cpy z21.b, p5/z, #22\n\t");
+ asm volatile("cpy z22.b, p10/z, #23\n\t");
+ asm volatile("cpy z23.b, p15/z, #24\n\t");
+ asm volatile("cpy z24.b, p0/z, #25\n\t");
+ asm volatile("cpy z25.b, p5/z, #26\n\t");
+ asm volatile("cpy z26.b, p10/z, #27\n\t");
+ asm volatile("cpy z27.b, p15/z, #28\n\t");
+ asm volatile("cpy z28.b, p0/z, #29\n\t");
+ asm volatile("cpy z29.b, p5/z, #30\n\t");
+ asm volatile("cpy z30.b, p10/z, #31\n\t");
+ asm volatile("cpy z31.b, p15/z, #32\n\t");
+}
+
+#define MAX_VL_BYTES 256
+void set_za_register(int svl, int value_offset) {
+ uint8_t data[MAX_VL_BYTES];
+
+ // ldr za will actually wrap the selected vector row, by the number of rows
+ // you have. So setting one that didn't exist would actually set one that
did.
+ // That's why we need the streaming vector length here.
+ for (int i = 0; i < svl; ++i) {
+// This may involve instructions that require the smefa64 extension.
+for (int j = 0; j < MAX_VL_BYTES; j++)
+ data[j] = i + value_offset;
+// Each one of these loads a VL sized row of ZA.
+asm volatile("mov w12, %w0\n\t"
+ "ldr za[w12, 0], [%1]\n\t" ::"r"(i),
+ "r"(&data)
+ : "w12");
+ }
+}
+
+static uint16_t arm_sme_svl_b(void) {
+ uint64_t ret = 0;
+ asm volatile("rdsvl %[ret], #1" : [ret] "=r"(ret));
+ return (uint16_t)ret;
+}
+
+void arm_sme2_set_zt0() {
+#define ZTO_LEN (512 / 8)
+ uint8_t data[ZTO_LEN];
+ for (unsigned i = 0; i < ZTO_LEN; ++i)
+data[i] = i + 0;
+
+ asm volatile("ldr zt0, [%0]" ::"r"(&data));
+#undef ZT0_LEN
+}
+
+int main() {
+ printf("Enable SME mode\n");
+
+ asm volatile("smstart");
+
+ write_sve_regs();
+
+ set_za_register(arm_sme_svl_b(), 4);
+
+ arm_sme2_set_zt0();
+
+ int c = 10; // break here
+ c += 5;
+ c += 5;
jasonmolenda wrote:
Ah, I just found the optional feature that M4 doesn't implement -
FEAT_SME_FA64. This would allow the use of SIMD instructions while in
streaming SVE mode.
https://github.com/llvm/llvm-project/pull/119171
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Disallow left shifts of negative values in the interpreter (PR #119620)
https://github.com/adrian-prantl created
https://github.com/llvm/llvm-project/pull/119620
This trips UBSAN and probably isn't partiuclarly useful either.
>From 104f0d227f5642bf7a02311482fafb4edc667c67 Mon Sep 17 00:00:00 2001
From: Adrian Prantl
Date: Wed, 11 Dec 2024 13:57:43 -0800
Subject: [PATCH] [lldb] Disallow left shifts of negative values in the
interpreter
This trips UBSAN and probably isn't partiuclarly useful either.
---
lldb/source/DataFormatters/FormatterBytecode.cpp | 8 +---
lldb/unittests/DataFormatter/FormatterBytecodeTest.cpp | 7 +--
2 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/lldb/source/DataFormatters/FormatterBytecode.cpp
b/lldb/source/DataFormatters/FormatterBytecode.cpp
index f344fbaff6f02a..e49c7506781875 100644
--- a/lldb/source/DataFormatters/FormatterBytecode.cpp
+++ b/lldb/source/DataFormatters/FormatterBytecode.cpp
@@ -379,7 +379,7 @@ llvm::Error Interpret(std::vector
&control,
BINOP_CHECKZERO(%);
continue;
case op_shl:
-#define SHIFTOP(OP)
\
+#define SHIFTOP(OP, LEFT)
\
{
\
TYPE_CHECK(Any, UInt);
\
uint64_t y = data.Pop();
\
@@ -390,16 +390,18 @@ llvm::Error Interpret(std::vector
&control,
data.Push(x OP y);
\
} else if (std::holds_alternative(data.back())) {
\
int64_t x = data.Pop();
\
+ if (x < 0 && LEFT)
\
+return error("left shift of negative value");
\
if (y > 64)
\
return error("shift out of bounds");
\
data.Push(x OP y);
\
} else
\
return error("unsupported data types");
\
}
- SHIFTOP(<<);
+ SHIFTOP(<<, true);
continue;
case op_shr:
- SHIFTOP(<<);
+ SHIFTOP(>>, false);
continue;
case op_and:
BINOP(&);
diff --git a/lldb/unittests/DataFormatter/FormatterBytecodeTest.cpp
b/lldb/unittests/DataFormatter/FormatterBytecodeTest.cpp
index 15d9229de00332..7307db650c1629 100644
--- a/lldb/unittests/DataFormatter/FormatterBytecodeTest.cpp
+++ b/lldb/unittests/DataFormatter/FormatterBytecodeTest.cpp
@@ -147,9 +147,12 @@ TEST_F(FormatterBytecodeTest, ArithOps) {
{
DataStack data;
unsigned char minus_one = 127;
-ASSERT_TRUE(
+ASSERT_FALSE(
Interpret({op_lit_int, minus_one, op_lit_uint, 2, op_shl}, data));
-ASSERT_EQ(data.Pop(), -4);
+unsigned char minus_two = 126;
+ASSERT_TRUE(
+Interpret({op_lit_int, minus_two, op_lit_uint, 1, op_shr}, data));
+ASSERT_EQ(data.Pop(), -1);
}
{
DataStack data;
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Disallow left shifts of negative values in the interpreter (PR #119620)
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Adrian Prantl (adrian-prantl)
Changes
This trips UBSAN and probably isn't partiuclarly useful either.
---
Full diff: https://github.com/llvm/llvm-project/pull/119620.diff
2 Files Affected:
- (modified) lldb/source/DataFormatters/FormatterBytecode.cpp (+5-3)
- (modified) lldb/unittests/DataFormatter/FormatterBytecodeTest.cpp (+5-2)
``diff
diff --git a/lldb/source/DataFormatters/FormatterBytecode.cpp
b/lldb/source/DataFormatters/FormatterBytecode.cpp
index f344fbaff6f02a..e49c7506781875 100644
--- a/lldb/source/DataFormatters/FormatterBytecode.cpp
+++ b/lldb/source/DataFormatters/FormatterBytecode.cpp
@@ -379,7 +379,7 @@ llvm::Error Interpret(std::vector
&control,
BINOP_CHECKZERO(%);
continue;
case op_shl:
-#define SHIFTOP(OP)
\
+#define SHIFTOP(OP, LEFT)
\
{
\
TYPE_CHECK(Any, UInt);
\
uint64_t y = data.Pop();
\
@@ -390,16 +390,18 @@ llvm::Error Interpret(std::vector
&control,
data.Push(x OP y);
\
} else if (std::holds_alternative(data.back())) {
\
int64_t x = data.Pop();
\
+ if (x < 0 && LEFT)
\
+return error("left shift of negative value");
\
if (y > 64)
\
return error("shift out of bounds");
\
data.Push(x OP y);
\
} else
\
return error("unsupported data types");
\
}
- SHIFTOP(<<);
+ SHIFTOP(<<, true);
continue;
case op_shr:
- SHIFTOP(<<);
+ SHIFTOP(>>, false);
continue;
case op_and:
BINOP(&);
diff --git a/lldb/unittests/DataFormatter/FormatterBytecodeTest.cpp
b/lldb/unittests/DataFormatter/FormatterBytecodeTest.cpp
index 15d9229de00332..7307db650c1629 100644
--- a/lldb/unittests/DataFormatter/FormatterBytecodeTest.cpp
+++ b/lldb/unittests/DataFormatter/FormatterBytecodeTest.cpp
@@ -147,9 +147,12 @@ TEST_F(FormatterBytecodeTest, ArithOps) {
{
DataStack data;
unsigned char minus_one = 127;
-ASSERT_TRUE(
+ASSERT_FALSE(
Interpret({op_lit_int, minus_one, op_lit_uint, 2, op_shl}, data));
-ASSERT_EQ(data.Pop(), -4);
+unsigned char minus_two = 126;
+ASSERT_TRUE(
+Interpret({op_lit_int, minus_two, op_lit_uint, 1, op_shr}, data));
+ASSERT_EQ(data.Pop(), -1);
}
{
DataStack data;
``
https://github.com/llvm/llvm-project/pull/119620
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Convert the StackFrameList mutex to a shared mutex. (PR #117252)
https://github.com/jimingham updated
https://github.com/llvm/llvm-project/pull/117252
>From b0d2179cf01cdd0b07bc43cef2a8c14d282e7ee7 Mon Sep 17 00:00:00 2001
From: Jim Ingham
Date: Tue, 19 Nov 2024 17:38:02 -0800
Subject: [PATCH 1/9] Convert the recursive StackFrameList mutex to a
non-recursive one.
---
lldb/include/lldb/Target/StackFrameList.h | 19 +++-
lldb/source/Target/StackFrameList.cpp | 104 +-
2 files changed, 81 insertions(+), 42 deletions(-)
diff --git a/lldb/include/lldb/Target/StackFrameList.h
b/lldb/include/lldb/Target/StackFrameList.h
index 7d0e7a5b9a71b2..1c59d2e97937da 100644
--- a/lldb/include/lldb/Target/StackFrameList.h
+++ b/lldb/include/lldb/Target/StackFrameList.h
@@ -103,11 +103,15 @@ class StackFrameList {
/// Realizes frames up to (and including) end_idx (which can be greater than
/// the actual number of frames.)
/// Returns true if the function was interrupted, false otherwise.
+ /// Does not hold the StackFrameList mutex.
bool GetFramesUpTo(uint32_t end_idx,
InterruptionControl allow_interrupt = AllowInterruption);
+ /// Does not hold the StackFrameList mutex.
void GetOnlyConcreteFramesUpTo(uint32_t end_idx, Unwind &unwinder);
+ // This gets called without the StackFrameList lock held, callers should
+ // hold the lock.
void SynthesizeTailCallFrames(StackFrame &next_frame);
bool GetAllFramesFetched() { return m_concrete_frames_fetched == UINT32_MAX;
}
@@ -122,6 +126,9 @@ class StackFrameList {
void SetCurrentInlinedDepth(uint32_t new_depth);
+ /// Calls into the stack frame recognizers and stop info to set the most
+ /// relevant frame. This can call out to arbitrary user code so it can't
+ /// hold the StackFrameList mutex.
void SelectMostRelevantFrame();
typedef std::vector collection;
@@ -142,7 +149,14 @@ class StackFrameList {
// TODO: This mutex may not always be held when required. In particular, uses
// of the StackFrameList APIs in lldb_private::Thread look suspect. Consider
// passing around a lock_guard reference to enforce proper locking.
- mutable std::recursive_mutex m_mutex;
+ mutable std::mutex m_mutex;
+
+ // llvm::sys::RWMutex m_stack_list_mutex;
+
+ // Setting the inlined depth should be protected against other attempts to
+ // change it, but since it doesn't mutate the list itself, we can limit the
+ // critical regions it produces by having a separate mutex.
+ mutable std::mutex m_inlined_depth_mutex;
/// A cache of frames. This may need to be updated when the program counter
/// changes.
@@ -171,6 +185,9 @@ class StackFrameList {
const bool m_show_inlined_frames;
private:
+ uint32_t SetSelectedFrameNoLock(lldb_private::StackFrame *frame);
+ lldb::StackFrameSP GetFrameAtIndexNoLock(uint32_t idx);
+
StackFrameList(const StackFrameList &) = delete;
const StackFrameList &operator=(const StackFrameList &) = delete;
};
diff --git a/lldb/source/Target/StackFrameList.cpp
b/lldb/source/Target/StackFrameList.cpp
index 94a381edd5e202..8dc358e492 100644
--- a/lldb/source/Target/StackFrameList.cpp
+++ b/lldb/source/Target/StackFrameList.cpp
@@ -38,7 +38,7 @@ using namespace lldb_private;
StackFrameList::StackFrameList(Thread &thread,
const lldb::StackFrameListSP &prev_frames_sp,
bool show_inline_frames)
-: m_thread(thread), m_prev_frames_sp(prev_frames_sp), m_mutex(),
m_frames(),
+: m_thread(thread), m_prev_frames_sp(prev_frames_sp), m_frames(),
m_selected_frame_idx(), m_concrete_frames_fetched(0),
m_current_inlined_depth(UINT32_MAX),
m_current_inlined_pc(LLDB_INVALID_ADDRESS),
@@ -63,6 +63,7 @@ void StackFrameList::CalculateCurrentInlinedDepth() {
}
uint32_t StackFrameList::GetCurrentInlinedDepth() {
+ std::lock_guard guard(m_inlined_depth_mutex);
if (m_show_inlined_frames && m_current_inlined_pc != LLDB_INVALID_ADDRESS) {
lldb::addr_t cur_pc = m_thread.GetRegisterContext()->GetPC();
if (cur_pc != m_current_inlined_pc) {
@@ -84,11 +85,6 @@ void StackFrameList::ResetCurrentInlinedDepth() {
if (!m_show_inlined_frames)
return;
- std::lock_guard guard(m_mutex);
-
- m_current_inlined_pc = LLDB_INVALID_ADDRESS;
- m_current_inlined_depth = UINT32_MAX;
-
StopInfoSP stop_info_sp = m_thread.GetStopInfo();
if (!stop_info_sp)
return;
@@ -98,6 +94,7 @@ void StackFrameList::ResetCurrentInlinedDepth() {
// We're only adjusting the inlined stack here.
Log *log = GetLog(LLDBLog::Step);
if (inline_depth) {
+std::lock_guard guard(m_inlined_depth_mutex);
m_current_inlined_depth = *inline_depth;
m_current_inlined_pc = m_thread.GetRegisterContext()->GetPC();
@@ -107,6 +104,9 @@ void StackFrameList::ResetCurrentInlinedDepth() {
"depth: %d 0x%" PRIx64 ".\n",
m_current_inlined_depth, m_current_inlined_pc);
} else {
+std::lock_guard guard(m_inlined_de
[Lldb-commits] [lldb] Convert the StackFrameList mutex to a shared mutex. (PR #117252)
jimingham wrote: I pushed the last set of changes implementing some of your suggestions and adding the missing shared lock. https://github.com/llvm/llvm-project/pull/117252 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [clang] [lldb] [Serialization] Support loading template specializations lazily (PR #119333)
hahnjo wrote: I believe https://github.com/llvm/llvm-project/commit/30ea0f0ce476bf4c12684a9a514af2ca660bbe44 already addresses the cast. The bots are just slow... https://github.com/llvm/llvm-project/pull/119333 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [clang] [lldb] [Serialization] Support loading template specializations lazily (PR #119333)
vgvassilev wrote: @ChuanqiXu9, can we insert a fix for windows? https://github.com/llvm/llvm-project/pull/119333 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB][Minidump] Have Minidumps save off and properly read TLS data (PR #109477)
nico wrote: This broke minidumps in lldb: #119598 https://github.com/llvm/llvm-project/pull/109477 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [clang] [clang-tools-extra] [lld] [lldb] [llvm] Rework the `Option` library to reduce dynamic relocations (PR #119198)
@@ -53,10 +53,8 @@ class OptTable {
public:
/// Entry for a single option instance in the option data table.
struct Info {
-/// A null terminated array of prefix strings to apply to name while
-/// matching.
-ArrayRef Prefixes;
-StringLiteral PrefixedName;
+unsigned PrefixesOffset;
rnk wrote:
Thanks! I'm lean towards incremental development and progress, so let's proceed
and land this and refactor to align.
https://github.com/llvm/llvm-project/pull/119198
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [clang] [clang-tools-extra] [lld] [lldb] [llvm] Rework the `Option` library to reduce dynamic relocations (PR #119198)
@@ -845,13 +845,14 @@ MemoryBufferRef LinkerDriver::convertResToCOFF(ArrayRef mbs, // Create OptTable +#define OPTTABLE_STR_TABLE_CODE rnk wrote: I convinced myself this is not worth it. The changes to the `PrecomputedOptTable` are hard to abstract away. It would be easy to move the PREFIX macro definition here into the table generated file separately from the string table offset change, but we'd still have to touch all these files. https://github.com/llvm/llvm-project/pull/119198 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [clang] [clang-tools-extra] [lld] [lldb] [llvm] Rework the `Option` library to reduce dynamic relocations (PR #119198)
https://github.com/rnk approved this pull request. Thanks! I think this is ready to land. https://github.com/llvm/llvm-project/pull/119198 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][Docs] Add Guarded Control Stack to AArch64 Linux page (PR #117860)
https://github.com/DavidSpickett updated https://github.com/llvm/llvm-project/pull/117860 >From 4838ed0ef8a62041981e61a8d405251bb32c147d Mon Sep 17 00:00:00 2001 From: David Spickett Date: Tue, 27 Aug 2024 15:22:10 +0100 Subject: [PATCH 1/2] [lldb][Docs] Add Guarded Control Stack to AArch64 Linux page The meat of this is how we execute expressions and deal with the aftermath. For most users this will never be a concern, so it functions more as a design doc than anything else. --- lldb/docs/use/aarch64-linux.md | 51 ++ 1 file changed, 51 insertions(+) diff --git a/lldb/docs/use/aarch64-linux.md b/lldb/docs/use/aarch64-linux.md index 393838dc0bb4f5..425336ddd81e2f 100644 --- a/lldb/docs/use/aarch64-linux.md +++ b/lldb/docs/use/aarch64-linux.md @@ -229,3 +229,54 @@ bytes. `zt0`'s value and whether it is active or not will be saved prior to expression evaluation and restored afterwards. + +## Guarded Control Stack Extension (GCS) + +GCS support includes the following new registers: + +* `gcs_features_enabled` +* `gcs_features_locked` +* `gcspr_el0` + +These map to the registers ptrace provides. The first two have had a `gcs_` +prefix added as their names are too generic without it. + +When the GCS is enabled the kernel allocates a memory region for it. This region +has a special attribute that LLDB will detect and presents like this: +``` + (lldb) memory region --all + <...> + [0xf7a0-0xf7e0) rw- + shadow stack: yes + [0xf7e0-0xf7e1) --- +``` + +`shadow stack` is a generic term used in the kernel for secure stack +extensions like GCS. + +### Expression Evaluation + +To execute an expression, LLDB must push the return address of the expression +wrapper (usually the entry point of the program) to the Guarded Control Stack. +It does this by decrementing `gcspr_el0` and writing to the location that +`gcspr_el0` then points to (instead of using the GCS push instructions). + +After an expression finishes, LLDB will restore the contents of all 3 registers, +apart from the enable bit of `gcs_features_enabled`. + +This is because there are limits on how often and from where you can set this +value. We cannot enable GCS from ptrace at all and it is expected that a process +that has enabled GCS then disabled it, will not enable it again. The simplest +choice was to not restore the enable bit at all. It's up to the user or +program to manage that value. + +The return address that was pushed onto the Guarded Control Stack will be left +in place. As will any values that were pushed to the stack by functions run +during the expresison. + +When the process resumes, `gcspr_el0` will be pointing to the original entry +on the stack. So the other values will have no effect and likely be overwritten +by future function calls. + +LLDB does not track and restore changes to general memory during expressions, +so not restoring the GCS contents fits with the current behaviour. >From 4916c3c3aa74eb586d4b70792922fb12d4021dae Mon Sep 17 00:00:00 2001 From: David Spickett Date: Wed, 11 Dec 2024 13:57:16 + Subject: [PATCH 2/2] Address Omair's comments --- lldb/docs/use/aarch64-linux.md | 40 +- 1 file changed, 25 insertions(+), 15 deletions(-) diff --git a/lldb/docs/use/aarch64-linux.md b/lldb/docs/use/aarch64-linux.md index 425336ddd81e2f..7c6157ce9df2af 100644 --- a/lldb/docs/use/aarch64-linux.md +++ b/lldb/docs/use/aarch64-linux.md @@ -256,27 +256,37 @@ extensions like GCS. ### Expression Evaluation -To execute an expression, LLDB must push the return address of the expression -wrapper (usually the entry point of the program) to the Guarded Control Stack. -It does this by decrementing `gcspr_el0` and writing to the location that -`gcspr_el0` then points to (instead of using the GCS push instructions). - -After an expression finishes, LLDB will restore the contents of all 3 registers, -apart from the enable bit of `gcs_features_enabled`. - -This is because there are limits on how often and from where you can set this -value. We cannot enable GCS from ptrace at all and it is expected that a process +To execute an expression when GCS is enabled, LLDB must push the return +address of the expression wrapper (usually the entry point of the program) +to the Guarded Control Stack. It does this by decrementing `gcspr_el0` and +writing to the location now pointed to by `gcspr_el0` (instead of using the +GCS push instructions). + +After an expression finishes, LLDB will restore the contents of all 3 +GCS registers, apart from the enable bit of `gcs_features_enabled`. This is +because there are limits on how often and from where you can set this +bit. + +We cannot enable GCS from ptrace at all and it is expected that a process that has enabled GCS then disabled it, will not enable it again. The simplest -choice was to not restore the enable bit at all. It's up to the user or -program to manage that val
[Lldb-commits] [lldb] [lldb][Docs] Add Guarded Control Stack to AArch64 Linux page (PR #117860)
@@ -229,3 +229,54 @@ bytes. `zt0`'s value and whether it is active or not will be saved prior to expression evaluation and restored afterwards. + +## Guarded Control Stack Extension (GCS) + +GCS support includes the following new registers: + +* `gcs_features_enabled` +* `gcs_features_locked` +* `gcspr_el0` + +These map to the registers ptrace provides. The first two have had a `gcs_` +prefix added as their names are too generic without it. + +When the GCS is enabled the kernel allocates a memory region for it. This region +has a special attribute that LLDB will detect and presents like this: +``` + (lldb) memory region --all + <...> + [0xf7a0-0xf7e0) rw- + shadow stack: yes + [0xf7e0-0xf7e1) --- +``` + +`shadow stack` is a generic term used in the kernel for secure stack +extensions like GCS. + +### Expression Evaluation + +To execute an expression, LLDB must push the return address of the expression +wrapper (usually the entry point of the program) to the Guarded Control Stack. +It does this by decrementing `gcspr_el0` and writing to the location that +`gcspr_el0` then points to (instead of using the GCS push instructions). + +After an expression finishes, LLDB will restore the contents of all 3 registers, DavidSpickett wrote: Done. https://github.com/llvm/llvm-project/pull/117860 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][Docs] Add Guarded Control Stack to AArch64 Linux page (PR #117860)
@@ -229,3 +229,54 @@ bytes. `zt0`'s value and whether it is active or not will be saved prior to expression evaluation and restored afterwards. + +## Guarded Control Stack Extension (GCS) + +GCS support includes the following new registers: + +* `gcs_features_enabled` +* `gcs_features_locked` +* `gcspr_el0` + +These map to the registers ptrace provides. The first two have had a `gcs_` +prefix added as their names are too generic without it. + +When the GCS is enabled the kernel allocates a memory region for it. This region +has a special attribute that LLDB will detect and presents like this: +``` + (lldb) memory region --all + <...> + [0xf7a0-0xf7e0) rw- + shadow stack: yes + [0xf7e0-0xf7e1) --- +``` + +`shadow stack` is a generic term used in the kernel for secure stack +extensions like GCS. + +### Expression Evaluation + +To execute an expression, LLDB must push the return address of the expression +wrapper (usually the entry point of the program) to the Guarded Control Stack. +It does this by decrementing `gcspr_el0` and writing to the location that DavidSpickett wrote: Done. https://github.com/llvm/llvm-project/pull/117860 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][Docs] Add Guarded Control Stack to AArch64 Linux page (PR #117860)
@@ -229,3 +229,54 @@ bytes. `zt0`'s value and whether it is active or not will be saved prior to expression evaluation and restored afterwards. + +## Guarded Control Stack Extension (GCS) + +GCS support includes the following new registers: + +* `gcs_features_enabled` +* `gcs_features_locked` +* `gcspr_el0` + +These map to the registers ptrace provides. The first two have had a `gcs_` +prefix added as their names are too generic without it. + +When the GCS is enabled the kernel allocates a memory region for it. This region +has a special attribute that LLDB will detect and presents like this: +``` + (lldb) memory region --all + <...> + [0xf7a0-0xf7e0) rw- + shadow stack: yes + [0xf7e0-0xf7e1) --- +``` + +`shadow stack` is a generic term used in the kernel for secure stack +extensions like GCS. + +### Expression Evaluation + +To execute an expression, LLDB must push the return address of the expression +wrapper (usually the entry point of the program) to the Guarded Control Stack. +It does this by decrementing `gcspr_el0` and writing to the location that +`gcspr_el0` then points to (instead of using the GCS push instructions). + +After an expression finishes, LLDB will restore the contents of all 3 registers, +apart from the enable bit of `gcs_features_enabled`. + +This is because there are limits on how often and from where you can set this DavidSpickett wrote: Done. https://github.com/llvm/llvm-project/pull/117860 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][Docs] Add Guarded Control Stack to AArch64 Linux page (PR #117860)
@@ -229,3 +229,54 @@ bytes. `zt0`'s value and whether it is active or not will be saved prior to expression evaluation and restored afterwards. + +## Guarded Control Stack Extension (GCS) + +GCS support includes the following new registers: + +* `gcs_features_enabled` +* `gcs_features_locked` +* `gcspr_el0` + +These map to the registers ptrace provides. The first two have had a `gcs_` +prefix added as their names are too generic without it. + +When the GCS is enabled the kernel allocates a memory region for it. This region +has a special attribute that LLDB will detect and presents like this: +``` + (lldb) memory region --all + <...> + [0xf7a0-0xf7e0) rw- + shadow stack: yes + [0xf7e0-0xf7e1) --- +``` + +`shadow stack` is a generic term used in the kernel for secure stack +extensions like GCS. + +### Expression Evaluation + +To execute an expression, LLDB must push the return address of the expression DavidSpickett wrote: Clarified that this only happens if GCS is enabled, not generally on any GCS aware system (since there's no stack memory for us to write to when it's disabled). https://github.com/llvm/llvm-project/pull/117860 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][Docs] Add Guarded Control Stack to AArch64 Linux page (PR #117860)
@@ -229,3 +229,54 @@ bytes. `zt0`'s value and whether it is active or not will be saved prior to expression evaluation and restored afterwards. + +## Guarded Control Stack Extension (GCS) + +GCS support includes the following new registers: + +* `gcs_features_enabled` +* `gcs_features_locked` +* `gcspr_el0` + +These map to the registers ptrace provides. The first two have had a `gcs_` +prefix added as their names are too generic without it. + +When the GCS is enabled the kernel allocates a memory region for it. This region +has a special attribute that LLDB will detect and presents like this: +``` + (lldb) memory region --all + <...> + [0xf7a0-0xf7e0) rw- + shadow stack: yes + [0xf7e0-0xf7e1) --- +``` + +`shadow stack` is a generic term used in the kernel for secure stack +extensions like GCS. + +### Expression Evaluation + +To execute an expression, LLDB must push the return address of the expression +wrapper (usually the entry point of the program) to the Guarded Control Stack. +It does this by decrementing `gcspr_el0` and writing to the location that +`gcspr_el0` then points to (instead of using the GCS push instructions). + +After an expression finishes, LLDB will restore the contents of all 3 registers, +apart from the enable bit of `gcs_features_enabled`. + +This is because there are limits on how often and from where you can set this +value. We cannot enable GCS from ptrace at all and it is expected that a process +that has enabled GCS then disabled it, will not enable it again. The simplest +choice was to not restore the enable bit at all. It's up to the user or +program to manage that value. DavidSpickett wrote: Done. The only people to ever do this will be us in the test suite, but without a way to tell if an expression is going to mess with GCS, we just have to let folks do it and find out the hard way. At least when they continue the SIGSEGV fault type would clue them into a problem with the shadow stack. But 99.9% of people will never hit this scenario. https://github.com/llvm/llvm-project/pull/117860 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB][Process/Utility] Introduce NativeRegisterContextDBReg class (PR #118043)
https://github.com/DavidSpickett approved this pull request. Since you mentioned FreeBSD I tried this on AArch64 FreeBSD and it doesn't cause any test failures (beyond what was already failing on `main`). This all LGTM. https://github.com/llvm/llvm-project/pull/118043 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [llvm] [DebugInfo] Add explicit visibility macros to CodeView template functions (PR #113102)
vgvassilev wrote: @fsfod, can you address the comments? https://github.com/llvm/llvm-project/pull/113102 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [llvm] [DebugInfo] Add explicit visibility macros to CodeView template functions (PR #113102)
@@ -495,7 +495,8 @@ class ClassRecord : public TagRecord {
};
// LF_UNION
-struct UnionRecord : public TagRecord {
+class UnionRecord : public TagRecord {
+public:
fsfod wrote:
yes it wasn't usable in the XMACRO to forward declare classes used for the
function declarations it creates
https://github.com/llvm/llvm-project/pull/113102
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Require gmake on FreeBSD and NetBSD (PR #119573)
https://github.com/DavidSpickett created
https://github.com/llvm/llvm-project/pull/119573
gmake is GNU make where make is not GNU compatible. This leads to a lot of
tests failing to build
with errors like:
```
make: "<...>/Makefile.rules" line 569: Invalid line type
```
See https://cmake.org/cmake/help/latest/variable/CMAKE_SYSTEM_NAME.html for the
platform names.
Tested on Linux and FreeBSD. Not tested on NetBSD, but the logic was always "if
netbsd or freebsd use gmake" so I think I'm safe to assume NetBSD will be fine
with this.
>From 4bec90c17bde6b70eca304801989ec1dc2a48097 Mon Sep 17 00:00:00 2001
From: David Spickett
Date: Wed, 11 Dec 2024 15:16:46 +
Subject: [PATCH] [lldb] Require gmake on FreeBSD and NetBSD
gmake is GNU make where make is not GNU compatible.
This leads to a lot of tests failing to build
with errors like:
```
make: "<...>/Makefile.rules" line 569: Invalid line type
```
See https://cmake.org/cmake/help/latest/variable/CMAKE_SYSTEM_NAME.html
for the platform names.
Tested on Linux and FreeBSD. Not tested on NetBSD, but the logic
was always "if netbsd or freebsd use gmake" so I think I'm
safe to assume NetBSD will be fine with this.
---
lldb/test/API/CMakeLists.txt | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/lldb/test/API/CMakeLists.txt b/lldb/test/API/CMakeLists.txt
index 36f4973ad9a452..66eccff297a999 100644
--- a/lldb/test/API/CMakeLists.txt
+++ b/lldb/test/API/CMakeLists.txt
@@ -52,11 +52,18 @@ set(LLDB_DEFAULT_TEST_DSYMUTIL
"${LLVM_TOOLS_BINARY_DIR}/dsymutil${CMAKE_EXECUTA
if(LLDB_TEST_MAKE)
set(LLDB_DEFAULT_TEST_MAKE ${LLDB_TEST_MAKE})
else()
- find_program(LLDB_DEFAULT_TEST_MAKE make gmake)
+ set(MAKE_NAMES "gmake")
+
+ # "make" on FreeBSD and NetBSD is not GNU make compatible.
+ if(NOT CMAKE_SYSTEM_NAME STREQUAL "FreeBSD" AND NOT CMAKE_SYSTEM_NAME
STREQUAL "NetBSD")
+list(APPEND MAKE_NAMES "make")
+ endif()
+
+ find_program(LLDB_DEFAULT_TEST_MAKE NAMES ${MAKE_NAMES})
if(LLDB_DEFAULT_TEST_MAKE)
message(STATUS "Found make: ${LLDB_DEFAULT_TEST_MAKE}")
else()
-message(STATUS "Not found: make")
+message(STATUS "Did not find one of: ${MAKE_NAMES}")
message(WARNING
"Many LLDB API tests require 'make' tool. Please provide it in Path "
"or pass via LLDB_TEST_MAKE.")
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Require gmake on FreeBSD and NetBSD (PR #119573)
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: David Spickett (DavidSpickett)
Changes
gmake is GNU make where make is not GNU compatible. This leads to a lot of
tests failing to build
with errors like:
```
make: "<...>/Makefile.rules" line 569: Invalid line type
```
See https://cmake.org/cmake/help/latest/variable/CMAKE_SYSTEM_NAME.html for the
platform names.
Tested on Linux and FreeBSD. Not tested on NetBSD, but the logic was always "if
netbsd or freebsd use gmake" so I think I'm safe to assume NetBSD will be fine
with this.
---
Full diff: https://github.com/llvm/llvm-project/pull/119573.diff
1 Files Affected:
- (modified) lldb/test/API/CMakeLists.txt (+9-2)
``diff
diff --git a/lldb/test/API/CMakeLists.txt b/lldb/test/API/CMakeLists.txt
index 36f4973ad9a452..66eccff297a999 100644
--- a/lldb/test/API/CMakeLists.txt
+++ b/lldb/test/API/CMakeLists.txt
@@ -52,11 +52,18 @@ set(LLDB_DEFAULT_TEST_DSYMUTIL
"${LLVM_TOOLS_BINARY_DIR}/dsymutil${CMAKE_EXECUTA
if(LLDB_TEST_MAKE)
set(LLDB_DEFAULT_TEST_MAKE ${LLDB_TEST_MAKE})
else()
- find_program(LLDB_DEFAULT_TEST_MAKE make gmake)
+ set(MAKE_NAMES "gmake")
+
+ # "make" on FreeBSD and NetBSD is not GNU make compatible.
+ if(NOT CMAKE_SYSTEM_NAME STREQUAL "FreeBSD" AND NOT CMAKE_SYSTEM_NAME
STREQUAL "NetBSD")
+list(APPEND MAKE_NAMES "make")
+ endif()
+
+ find_program(LLDB_DEFAULT_TEST_MAKE NAMES ${MAKE_NAMES})
if(LLDB_DEFAULT_TEST_MAKE)
message(STATUS "Found make: ${LLDB_DEFAULT_TEST_MAKE}")
else()
-message(STATUS "Not found: make")
+message(STATUS "Did not find one of: ${MAKE_NAMES}")
message(WARNING
"Many LLDB API tests require 'make' tool. Please provide it in Path "
"or pass via LLDB_TEST_MAKE.")
``
https://github.com/llvm/llvm-project/pull/119573
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Require gmake on FreeBSD and NetBSD (PR #119573)
DavidSpickett wrote: We could say we require a "GNU compatible" make but I didn't want to get into the weeds of whether Mac's make is technically GNU compatible or just happens to have all the features we need. This change makes FreeBSD work out of the box, that's the key goal here. https://github.com/llvm/llvm-project/pull/119573 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][AIX] Header Parsing for XCOFF Object File in AIX (PR #116338)
https://github.com/DhruvSrivastavaX updated
https://github.com/llvm/llvm-project/pull/116338
>From 0c63800bdcbadcfceed4c9a81305eda7d5a15960 Mon Sep 17 00:00:00 2001
From: Dhruv-Srivastava
Date: Fri, 15 Nov 2024 02:16:31 -0600
Subject: [PATCH 1/7] Added XCOFF Header Parsing
---
.../ObjectFile/XCOFF/ObjectFileXCOFF.cpp | 126 +-
.../ObjectFile/XCOFF/ObjectFileXCOFF.h| 58
2 files changed, 181 insertions(+), 3 deletions(-)
diff --git a/lldb/source/Plugins/ObjectFile/XCOFF/ObjectFileXCOFF.cpp
b/lldb/source/Plugins/ObjectFile/XCOFF/ObjectFileXCOFF.cpp
index 3be900f9a4bc9f..c06ece4347822d 100644
--- a/lldb/source/Plugins/ObjectFile/XCOFF/ObjectFileXCOFF.cpp
+++ b/lldb/source/Plugins/ObjectFile/XCOFF/ObjectFileXCOFF.cpp
@@ -81,9 +81,44 @@ ObjectFile *ObjectFileXCOFF::CreateInstance(const
lldb::ModuleSP &module_sp,
if (!objfile_up)
return nullptr;
+ // Cache xcoff binary.
+ if (!objfile_up->CreateBinary())
+return nullptr;
+
+ if (!objfile_up->ParseHeader())
+return nullptr;
+
return objfile_up.release();
}
+bool ObjectFileXCOFF::CreateBinary() {
+ if (m_binary)
+return true;
+
+ Log *log = GetLog(LLDBLog::Object);
+
+ auto binary = llvm::object::XCOFFObjectFile::createObjectFile(
+ llvm::MemoryBufferRef(toStringRef(m_data.GetData()),
+m_file.GetFilename().GetStringRef()),
+ file_magic::xcoff_object_64);
+ if (!binary) {
+LLDB_LOG_ERROR(log, binary.takeError(),
+ "Failed to create binary for file ({1}): {0}", m_file);
+return false;
+ }
+
+ // Make sure we only handle XCOFF format.
+ m_binary =
+ llvm::unique_dyn_cast(std::move(*binary));
+ if (!m_binary)
+return false;
+
+ LLDB_LOG(log, "this = {0}, module = {1} ({2}), file = {3}, binary = {4}",
+ this, GetModule().get(), GetModule()->GetSpecificationDescription(),
+ m_file.GetPath(), m_binary.get());
+ return true;
+}
+
ObjectFile *ObjectFileXCOFF::CreateMemoryInstance(
const lldb::ModuleSP &module_sp, WritableDataBufferSP data_sp,
const lldb::ProcessSP &process_sp, lldb::addr_t header_addr) {
@@ -136,13 +171,92 @@ bool ObjectFileXCOFF::MagicBytesMatch(DataBufferSP
&data_sp,
return XCOFFHeaderSizeFromMagic(magic) != 0;
}
-bool ObjectFileXCOFF::ParseHeader() { return false; }
+bool ObjectFileXCOFF::ParseHeader() {
+ ModuleSP module_sp(GetModule());
+ if (module_sp) {
+std::lock_guard guard(module_sp->GetMutex());
+lldb::offset_t offset = 0;
+
+if (ParseXCOFFHeader(m_data, &offset, m_xcoff_header)) {
+ m_data.SetAddressByteSize(GetAddressByteSize());
+ if (m_xcoff_header.auxhdrsize > 0)
+ParseXCOFFOptionalHeader(m_data, &offset);
+}
+return true;
+ }
+
+ return false;
+}
+
+bool ObjectFileXCOFF::ParseXCOFFHeader(lldb_private::DataExtractor &data,
+ lldb::offset_t *offset_ptr,
+ xcoff_header_t &xcoff_header) {
+ // FIXME: data.ValidOffsetForDataOfSize
+ xcoff_header.magic = data.GetU16(offset_ptr);
+ xcoff_header.nsects = data.GetU16(offset_ptr);
+ xcoff_header.modtime = data.GetU32(offset_ptr);
+ xcoff_header.symoff = data.GetU64(offset_ptr);
+ xcoff_header.auxhdrsize = data.GetU16(offset_ptr);
+ xcoff_header.flags = data.GetU16(offset_ptr);
+ xcoff_header.nsyms = data.GetU32(offset_ptr);
+ return true;
+}
+
+bool ObjectFileXCOFF::ParseXCOFFOptionalHeader(
+lldb_private::DataExtractor &data, lldb::offset_t *offset_ptr) {
+ lldb::offset_t init_offset = *offset_ptr;
+ // FIXME: data.ValidOffsetForDataOfSize
+ m_xcoff_aux_header.AuxMagic = data.GetU16(offset_ptr);
+ m_xcoff_aux_header.Version = data.GetU16(offset_ptr);
+ m_xcoff_aux_header.ReservedForDebugger = data.GetU32(offset_ptr);
+ m_xcoff_aux_header.TextStartAddr = data.GetU64(offset_ptr);
+ m_xcoff_aux_header.DataStartAddr = data.GetU64(offset_ptr);
+ m_xcoff_aux_header.TOCAnchorAddr = data.GetU64(offset_ptr);
+ m_xcoff_aux_header.SecNumOfEntryPoint = data.GetU16(offset_ptr);
+ m_xcoff_aux_header.SecNumOfText = data.GetU16(offset_ptr);
+ m_xcoff_aux_header.SecNumOfData = data.GetU16(offset_ptr);
+ m_xcoff_aux_header.SecNumOfTOC = data.GetU16(offset_ptr);
+ m_xcoff_aux_header.SecNumOfLoader = data.GetU16(offset_ptr);
+ m_xcoff_aux_header.SecNumOfBSS = data.GetU16(offset_ptr);
+ m_xcoff_aux_header.MaxAlignOfText = data.GetU16(offset_ptr);
+ m_xcoff_aux_header.MaxAlignOfData = data.GetU16(offset_ptr);
+ m_xcoff_aux_header.ModuleType = data.GetU16(offset_ptr);
+ m_xcoff_aux_header.CpuFlag = data.GetU8(offset_ptr);
+ m_xcoff_aux_header.CpuType = data.GetU8(offset_ptr);
+ m_xcoff_aux_header.TextPageSize = data.GetU8(offset_ptr);
+ m_xcoff_aux_header.DataPageSize = data.GetU8(offset_ptr);
+ m_xcoff_aux_header.StackPageSize = data.GetU8(offset_ptr);
+ m_xcoff_aux_header.FlagAndTDataAlignment = data.GetU8(offset_ptr);
+ m_xcoff_aux_header.TextSize = data.GetU64(offset_p
[Lldb-commits] [lldb] [lldb][Docs] Add Guarded Control Stack to AArch64 Linux page (PR #117860)
https://github.com/omjavaid approved this pull request. Looks good. Thanks for making the changes. https://github.com/llvm/llvm-project/pull/117860 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][AIX] Header Parsing for XCOFF Object File in AIX (PR #116338)
https://github.com/DhruvSrivastavaX edited https://github.com/llvm/llvm-project/pull/116338 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][AIX] Header Parsing for XCOFF Object File in AIX (PR #116338)
https://github.com/DhruvSrivastavaX edited https://github.com/llvm/llvm-project/pull/116338 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Disallow left shifts of negative values in the interpreter (PR #119620)
https://github.com/JDevlieghere approved this pull request. https://github.com/llvm/llvm-project/pull/119620 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] 2470cfa - [lldb] Disallow left shifts of negative values in the interpreter (#119620)
Author: Adrian Prantl
Date: 2024-12-11T14:16:23-08:00
New Revision: 2470cfab63ac14df02dc6df686fcae7b1a4eb84f
URL:
https://github.com/llvm/llvm-project/commit/2470cfab63ac14df02dc6df686fcae7b1a4eb84f
DIFF:
https://github.com/llvm/llvm-project/commit/2470cfab63ac14df02dc6df686fcae7b1a4eb84f.diff
LOG: [lldb] Disallow left shifts of negative values in the interpreter (#119620)
This trips UBSAN and probably isn't partiuclarly useful either.
Added:
Modified:
lldb/source/DataFormatters/FormatterBytecode.cpp
lldb/unittests/DataFormatter/FormatterBytecodeTest.cpp
Removed:
diff --git a/lldb/source/DataFormatters/FormatterBytecode.cpp
b/lldb/source/DataFormatters/FormatterBytecode.cpp
index f344fbaff6f02a..e49c7506781875 100644
--- a/lldb/source/DataFormatters/FormatterBytecode.cpp
+++ b/lldb/source/DataFormatters/FormatterBytecode.cpp
@@ -379,7 +379,7 @@ llvm::Error Interpret(std::vector
&control,
BINOP_CHECKZERO(%);
continue;
case op_shl:
-#define SHIFTOP(OP)
\
+#define SHIFTOP(OP, LEFT)
\
{
\
TYPE_CHECK(Any, UInt);
\
uint64_t y = data.Pop();
\
@@ -390,16 +390,18 @@ llvm::Error Interpret(std::vector
&control,
data.Push(x OP y);
\
} else if (std::holds_alternative(data.back())) {
\
int64_t x = data.Pop();
\
+ if (x < 0 && LEFT)
\
+return error("left shift of negative value");
\
if (y > 64)
\
return error("shift out of bounds");
\
data.Push(x OP y);
\
} else
\
return error("unsupported data types");
\
}
- SHIFTOP(<<);
+ SHIFTOP(<<, true);
continue;
case op_shr:
- SHIFTOP(<<);
+ SHIFTOP(>>, false);
continue;
case op_and:
BINOP(&);
diff --git a/lldb/unittests/DataFormatter/FormatterBytecodeTest.cpp
b/lldb/unittests/DataFormatter/FormatterBytecodeTest.cpp
index 15d9229de00332..7307db650c1629 100644
--- a/lldb/unittests/DataFormatter/FormatterBytecodeTest.cpp
+++ b/lldb/unittests/DataFormatter/FormatterBytecodeTest.cpp
@@ -147,9 +147,12 @@ TEST_F(FormatterBytecodeTest, ArithOps) {
{
DataStack data;
unsigned char minus_one = 127;
-ASSERT_TRUE(
+ASSERT_FALSE(
Interpret({op_lit_int, minus_one, op_lit_uint, 2, op_shl}, data));
-ASSERT_EQ(data.Pop(), -4);
+unsigned char minus_two = 126;
+ASSERT_TRUE(
+Interpret({op_lit_int, minus_two, op_lit_uint, 1, op_shr}, data));
+ASSERT_EQ(data.Pop(), -1);
}
{
DataStack data;
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Disallow left shifts of negative values in the interpreter (PR #119620)
https://github.com/adrian-prantl closed https://github.com/llvm/llvm-project/pull/119620 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][Docs] Add Guarded Control Stack to AArch64 Linux page (PR #117860)
@@ -229,3 +229,54 @@ bytes. `zt0`'s value and whether it is active or not will be saved prior to expression evaluation and restored afterwards. + +## Guarded Control Stack Extension (GCS) + +GCS support includes the following new registers: + +* `gcs_features_enabled` +* `gcs_features_locked` +* `gcspr_el0` + +These map to the registers ptrace provides. The first two have had a `gcs_` +prefix added as their names are too generic without it. + +When the GCS is enabled the kernel allocates a memory region for it. This region +has a special attribute that LLDB will detect and presents like this: +``` + (lldb) memory region --all + <...> + [0xf7a0-0xf7e0) rw- + shadow stack: yes + [0xf7e0-0xf7e1) --- +``` + +`shadow stack` is a generic term used in the kernel for secure stack +extensions like GCS. + +### Expression Evaluation + +To execute an expression, LLDB must push the return address of the expression +wrapper (usually the entry point of the program) to the Guarded Control Stack. +It does this by decrementing `gcspr_el0` and writing to the location that +`gcspr_el0` then points to (instead of using the GCS push instructions). + +After an expression finishes, LLDB will restore the contents of all 3 registers, +apart from the enable bit of `gcs_features_enabled`. + +This is because there are limits on how often and from where you can set this +value. We cannot enable GCS from ptrace at all and it is expected that a process +that has enabled GCS then disabled it, will not enable it again. The simplest +choice was to not restore the enable bit at all. It's up to the user or +program to manage that value. omjavaid wrote: Is there a chance expression function might enable GCS while it was previously disabled and should we be guard against that making sure use is aware that GCSenabled state has changed after execution of the expression https://github.com/llvm/llvm-project/pull/117860 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][Linux] Mark memory regions used for shadow stacks (PR #117861)
omjavaid wrote: Can we test this with QEMU? https://github.com/llvm/llvm-project/pull/117861 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][Docs] Add Guarded Control Stack to AArch64 Linux page (PR #117860)
@@ -229,3 +229,54 @@ bytes. `zt0`'s value and whether it is active or not will be saved prior to expression evaluation and restored afterwards. + +## Guarded Control Stack Extension (GCS) + +GCS support includes the following new registers: + +* `gcs_features_enabled` +* `gcs_features_locked` +* `gcspr_el0` + +These map to the registers ptrace provides. The first two have had a `gcs_` +prefix added as their names are too generic without it. + +When the GCS is enabled the kernel allocates a memory region for it. This region +has a special attribute that LLDB will detect and presents like this: +``` + (lldb) memory region --all + <...> + [0xf7a0-0xf7e0) rw- + shadow stack: yes + [0xf7e0-0xf7e1) --- +``` + +`shadow stack` is a generic term used in the kernel for secure stack +extensions like GCS. + +### Expression Evaluation + +To execute an expression, LLDB must push the return address of the expression +wrapper (usually the entry point of the program) to the Guarded Control Stack. +It does this by decrementing `gcspr_el0` and writing to the location that +`gcspr_el0` then points to (instead of using the GCS push instructions). + +After an expression finishes, LLDB will restore the contents of all 3 registers, +apart from the enable bit of `gcs_features_enabled`. + +This is because there are limits on how often and from where you can set this omjavaid wrote: This line should be part of the previous paragraph. https://github.com/llvm/llvm-project/pull/117860 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][AIX] Header Parsing for XCOFF Object File in AIX (PR #116338)
@@ -136,13 +169,42 @@ bool ObjectFileXCOFF::MagicBytesMatch(DataBufferSP
&data_sp,
return XCOFFHeaderSizeFromMagic(magic) != 0;
}
-bool ObjectFileXCOFF::ParseHeader() { return false; }
+bool ObjectFileXCOFF::ParseHeader() {
+
+ bool retVal = false;
+ ModuleSP module_sp(GetModule());
+ if (module_sp) {
+std::lock_guard guard(module_sp->GetMutex());
DhruvSrivastavaX wrote:
Done
https://github.com/llvm/llvm-project/pull/116338
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][Docs] Add Guarded Control Stack to AArch64 Linux page (PR #117860)
@@ -229,3 +229,54 @@ bytes. `zt0`'s value and whether it is active or not will be saved prior to expression evaluation and restored afterwards. + +## Guarded Control Stack Extension (GCS) + +GCS support includes the following new registers: + +* `gcs_features_enabled` +* `gcs_features_locked` +* `gcspr_el0` + +These map to the registers ptrace provides. The first two have had a `gcs_` +prefix added as their names are too generic without it. + +When the GCS is enabled the kernel allocates a memory region for it. This region +has a special attribute that LLDB will detect and presents like this: +``` + (lldb) memory region --all + <...> + [0xf7a0-0xf7e0) rw- + shadow stack: yes + [0xf7e0-0xf7e1) --- +``` + +`shadow stack` is a generic term used in the kernel for secure stack +extensions like GCS. + +### Expression Evaluation + +To execute an expression, LLDB must push the return address of the expression +wrapper (usually the entry point of the program) to the Guarded Control Stack. +It does this by decrementing `gcspr_el0` and writing to the location that omjavaid wrote: "LLDB writes the return address to the memory location now pointed to by gcspr_el0" https://github.com/llvm/llvm-project/pull/117860 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][Docs] Add Guarded Control Stack to AArch64 Linux page (PR #117860)
@@ -229,3 +229,54 @@ bytes. `zt0`'s value and whether it is active or not will be saved prior to expression evaluation and restored afterwards. + +## Guarded Control Stack Extension (GCS) + +GCS support includes the following new registers: + +* `gcs_features_enabled` +* `gcs_features_locked` +* `gcspr_el0` + +These map to the registers ptrace provides. The first two have had a `gcs_` +prefix added as their names are too generic without it. + +When the GCS is enabled the kernel allocates a memory region for it. This region +has a special attribute that LLDB will detect and presents like this: +``` + (lldb) memory region --all + <...> + [0xf7a0-0xf7e0) rw- + shadow stack: yes + [0xf7e0-0xf7e1) --- +``` + +`shadow stack` is a generic term used in the kernel for secure stack +extensions like GCS. + +### Expression Evaluation + +To execute an expression, LLDB must push the return address of the expression +wrapper (usually the entry point of the program) to the Guarded Control Stack. +It does this by decrementing `gcspr_el0` and writing to the location that +`gcspr_el0` then points to (instead of using the GCS push instructions). + +After an expression finishes, LLDB will restore the contents of all 3 registers, omjavaid wrote: "contents of all 3 GCS registers" https://github.com/llvm/llvm-project/pull/117860 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][Docs] Add Guarded Control Stack to AArch64 Linux page (PR #117860)
@@ -229,3 +229,54 @@ bytes. `zt0`'s value and whether it is active or not will be saved prior to expression evaluation and restored afterwards. + +## Guarded Control Stack Extension (GCS) + +GCS support includes the following new registers: + +* `gcs_features_enabled` +* `gcs_features_locked` +* `gcspr_el0` + +These map to the registers ptrace provides. The first two have had a `gcs_` +prefix added as their names are too generic without it. + +When the GCS is enabled the kernel allocates a memory region for it. This region +has a special attribute that LLDB will detect and presents like this: +``` + (lldb) memory region --all + <...> + [0xf7a0-0xf7e0) rw- + shadow stack: yes + [0xf7e0-0xf7e1) --- +``` + +`shadow stack` is a generic term used in the kernel for secure stack +extensions like GCS. + +### Expression Evaluation + +To execute an expression, LLDB must push the return address of the expression omjavaid wrote: Does this happen on all GCS enabled targets even if GCS is not enabled? https://github.com/llvm/llvm-project/pull/117860 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][AIX] Header Parsing for XCOFF Object File in AIX (PR #116338)
https://github.com/DhruvSrivastavaX edited https://github.com/llvm/llvm-project/pull/116338 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][AIX] Header Parsing for XCOFF Object File in AIX (PR #116338)
https://github.com/DhruvSrivastavaX edited https://github.com/llvm/llvm-project/pull/116338 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][AIX] Header Parsing for XCOFF Object File in AIX (PR #116338)
https://github.com/DhruvSrivastavaX edited https://github.com/llvm/llvm-project/pull/116338 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][AIX] Header Parsing for XCOFF Object File in AIX (PR #116338)
https://github.com/DhruvSrivastavaX edited https://github.com/llvm/llvm-project/pull/116338 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][AIX] Header Parsing for XCOFF Object File in AIX (PR #116338)
https://github.com/DhruvSrivastavaX edited https://github.com/llvm/llvm-project/pull/116338 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [clang] [lldb] [Serialization] Support loading template specializations lazily (PR #119333)
llvm-ci wrote:
LLVM Buildbot has detected a new failure on builder `clang-arm64-windows-msvc`
running on `linaro-armv8-windows-msvc-04` while building `clang,lldb` at step 4
"build stage 1".
Full details are available at:
https://lab.llvm.org/buildbot/#/builders/161/builds/3610
Here is the relevant piece of the build log for the reference
```
Step 4 (build stage 1) failure: 'ninja' (failure)
...
[3247/9149] Building CXX object
lib\CodeGen\AsmPrinter\CMakeFiles\LLVMAsmPrinter.dir\DebugHandlerBase.cpp.obj
[3248/9149] Building CXX object
lib\CodeGen\AsmPrinter\CMakeFiles\LLVMAsmPrinter.dir\DebugLocStream.cpp.obj
[3249/9149] Building CXX object
lib\CodeGen\AsmPrinter\CMakeFiles\LLVMAsmPrinter.dir\DIE.cpp.obj
[3250/9149] Building CXX object
lib\CodeGen\AsmPrinter\CMakeFiles\LLVMAsmPrinter.dir\DIEHash.cpp.obj
[3251/9149] Building CXX object
lib\CodeGen\AsmPrinter\CMakeFiles\LLVMAsmPrinter.dir\DwarfCFIException.cpp.obj
[3252/9149] Building CXX object
lib\CodeGen\AsmPrinter\CMakeFiles\LLVMAsmPrinter.dir\DwarfCompileUnit.cpp.obj
[3253/9149] Building CXX object
lib\CodeGen\AsmPrinter\CMakeFiles\LLVMAsmPrinter.dir\DwarfDebug.cpp.obj
[3254/9149] Building CXX object
lib\CodeGen\AsmPrinter\CMakeFiles\LLVMAsmPrinter.dir\DwarfExpression.cpp.obj
[3255/9149] Building CXX object
lib\CodeGen\AsmPrinter\CMakeFiles\LLVMAsmPrinter.dir\DwarfFile.cpp.obj
[3256/9149] Building CXX object
tools\clang\lib\Serialization\CMakeFiles\obj.clangSerialization.dir\ASTWriter.cpp.obj
FAILED:
tools/clang/lib/Serialization/CMakeFiles/obj.clangSerialization.dir/ASTWriter.cpp.obj
ccache C:\Users\tcwg\scoop\apps\llvm\current\bin\clang-cl.exe /nologo -TP
-DCLANG_BUILD_STATIC -DGTEST_HAS_RTTI=0 -DUNICODE -D_CRT_NONSTDC_NO_DEPRECATE
-D_CRT_NONSTDC_NO_WARNINGS -D_CRT_SECURE_NO_DEPRECATE -D_CRT_SECURE_NO_WARNINGS
-D_GLIBCXX_ASSERTIONS -D_HAS_EXCEPTIONS=0 -D_SCL_SECURE_NO_DEPRECATE
-D_SCL_SECURE_NO_WARNINGS -D_UNICODE -D__STDC_CONSTANT_MACROS
-D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
-IC:\Users\tcwg\llvm-worker\clang-arm64-windows-msvc\stage1\tools\clang\lib\Serialization
-IC:\Users\tcwg\llvm-worker\clang-arm64-windows-msvc\llvm\clang\lib\Serialization
-IC:\Users\tcwg\llvm-worker\clang-arm64-windows-msvc\llvm\clang\include
-IC:\Users\tcwg\llvm-worker\clang-arm64-windows-msvc\stage1\tools\clang\include
-IC:\Users\tcwg\llvm-worker\clang-arm64-windows-msvc\stage1\include
-IC:\Users\tcwg\llvm-worker\clang-arm64-windows-msvc\llvm\llvm\include /DWIN32
/D_WINDOWS /Zc:inline /Zc:__cplusplus /Oi /Brepro /bigobj /permissive-
-Werror=unguarded-availability-new /W4 -Wextra -Wno-unused-parameter
-Wwrite-strings -Wcast-qual -Wmissing-field-initializers -Wimplicit-fallthrough
-Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor
-Wdelete-non-virtual-dtor -Wsuggest-override -Wstring-conversion
-Wmisleading-indentation -Wctad-maybe-unsupported /Gw /O2 /Ob2 -std:c++17 -MD
/EHs-c- /GR- -UNDEBUG /showIncludes
/Fotools\clang\lib\Serialization\CMakeFiles\obj.clangSerialization.dir\ASTWriter.cpp.obj
/Fdtools\clang\lib\Serialization\CMakeFiles\obj.clangSerialization.dir\ -c --
C:\Users\tcwg\llvm-worker\clang-arm64-windows-msvc\llvm\clang\lib\Serialization\ASTWriter.cpp
C:\Users\tcwg\llvm-worker\clang-arm64-windows-msvc\llvm\clang\lib\Serialization\ASTWriter.cpp(4331,38):
error: non-constant-expression cannot be narrowed from type
'clang::serialization::DeclCode' to 'RecordData::value_type' (aka 'unsigned
long long') in initializer list [-Wc++11-narrowing]
4331 | RecordData::value_type Record[] = {IsPartial ?
DECL_PARTIAL_SPECIALIZATIONS
|
^~~~
4332 |: DECL_SPECIALIZATIONS};
|~~
C:\Users\tcwg\llvm-worker\clang-arm64-windows-msvc\llvm\clang\lib\Serialization\ASTWriter.cpp(4331,38):
note: insert an explicit cast to silence this issue
4331 | RecordData::value_type Record[] = {IsPartial ?
DECL_PARTIAL_SPECIALIZATIONS
|
^~~~
| static_cast(
4332 |: DECL_SPECIALIZATIONS};
|~~
| )
C:\Users\tcwg\llvm-worker\clang-arm64-windows-msvc\llvm\clang\lib\Serialization\ASTWriter.cpp(6068,40):
error: non-constant-expression cannot be narrowed from type
'clang::serialization::ASTRecordTypes' to 'RecordData::value_type' (aka
'unsigned long long') in initializer list [-Wc++11-narrowing]
6068 | RecordData::value_type Record[] = {RecordType,
getDeclID(D).getRawValue()};
|^~
C:\Users\tcwg\llvm-worker\clang-arm64-windows-msvc\llvm\clang\lib\Serialization\AS
[Lldb-commits] [clang] [clang-tools-extra] [lld] [lldb] [llvm] Rework the `Option` library to reduce dynamic relocations (PR #119198)
https://github.com/chandlerc edited https://github.com/llvm/llvm-project/pull/119198 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [clang] [clang-tools-extra] [lld] [lldb] [llvm] Rework the `Option` library to reduce dynamic relocations (PR #119198)
chandlerc wrote: Thanks for the careful review, merging! (And starting on the follow-ups!) https://github.com/llvm/llvm-project/pull/119198 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Implement basic support for reverse-continue (PR #112079)
jimingham wrote: @labath if you have a moment I think you would do a much better job commenting on the test harness parts of this, as they overlap somewhat with the other gdbremote based tests and you're probably more familiar with those than me for sure (and likely anyone...) https://github.com/llvm/llvm-project/pull/112079 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] ae5836f - [LLDB][Process/Utility] Introduce NativeRegisterContextDBReg class
Author: wanglei
Date: 2024-12-12T10:04:24+08:00
New Revision: ae5836f6b6a8544e6226f5c1ba6b1beacfe01aef
URL:
https://github.com/llvm/llvm-project/commit/ae5836f6b6a8544e6226f5c1ba6b1beacfe01aef
DIFF:
https://github.com/llvm/llvm-project/commit/ae5836f6b6a8544e6226f5c1ba6b1beacfe01aef.diff
LOG: [LLDB][Process/Utility] Introduce NativeRegisterContextDBReg class
Since the setup of debug registers for AArch64 and LoongArch is similar,
we extracted the shared logic from Class:
`NativeRegisterContextDBReg_arm64`
into a new Class:
`NativeRegisterContextDBReg`.
This will simplify the subsequent implementation of hardware breakpoints
and watchpoints on LoongArch.
Reviewed By: DavidSpickett
Pull Request: https://github.com/llvm/llvm-project/pull/118043
Added:
lldb/source/Plugins/Process/Utility/NativeRegisterContextDBReg.cpp
lldb/source/Plugins/Process/Utility/NativeRegisterContextDBReg.h
Modified:
lldb/source/Plugins/Process/Utility/CMakeLists.txt
lldb/source/Plugins/Process/Utility/NativeRegisterContextDBReg_arm64.cpp
lldb/source/Plugins/Process/Utility/NativeRegisterContextDBReg_arm64.h
Removed:
diff --git a/lldb/source/Plugins/Process/Utility/CMakeLists.txt
b/lldb/source/Plugins/Process/Utility/CMakeLists.txt
index 308ea29e31ad77..0526c95503175e 100644
--- a/lldb/source/Plugins/Process/Utility/CMakeLists.txt
+++ b/lldb/source/Plugins/Process/Utility/CMakeLists.txt
@@ -9,6 +9,7 @@ add_lldb_library(lldbPluginProcessUtility
LinuxSignals.cpp
MemoryTagManagerAArch64MTE.cpp
NativeProcessSoftwareSingleStep.cpp
+ NativeRegisterContextDBReg.cpp
NativeRegisterContextDBReg_arm64.cpp
NativeRegisterContextDBReg_x86.cpp
NativeRegisterContextRegisterInfo.cpp
diff --git
a/lldb/source/Plugins/Process/Utility/NativeRegisterContextDBReg.cpp
b/lldb/source/Plugins/Process/Utility/NativeRegisterContextDBReg.cpp
new file mode 100644
index 00..1e0c1a5db09ca4
--- /dev/null
+++ b/lldb/source/Plugins/Process/Utility/NativeRegisterContextDBReg.cpp
@@ -0,0 +1,409 @@
+//===-- NativeRegisterContextDBReg.cpp
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "NativeRegisterContextDBReg.h"
+
+#include "lldb/Utility/LLDBLog.h"
+#include "lldb/Utility/Log.h"
+#include "lldb/Utility/RegisterValue.h"
+
+using namespace lldb_private;
+
+uint32_t NativeRegisterContextDBReg::NumSupportedHardwareBreakpoints() {
+ Log *log = GetLog(LLDBLog::Breakpoints);
+
+ // Read hardware breakpoint and watchpoint information.
+ llvm::Error error = ReadHardwareDebugInfo();
+
+ if (error) {
+LLDB_LOG_ERROR(log, std::move(error),
+ "failed to read debug registers: {0}");
+return 0;
+ }
+
+ LLDB_LOG(log, "{0}", m_max_hbp_supported);
+ return m_max_hbp_supported;
+}
+
+uint32_t NativeRegisterContextDBReg::SetHardwareBreakpoint(lldb::addr_t addr,
+ size_t size) {
+ Log *log = GetLog(LLDBLog::Breakpoints);
+ LLDB_LOG(log, "addr: {0:x}, size: {1:x}", addr, size);
+
+ // Read hardware breakpoint and watchpoint information.
+ llvm::Error error = ReadHardwareDebugInfo();
+ if (error) {
+LLDB_LOG_ERROR(
+log, std::move(error),
+"unable to set breakpoint: failed to read debug registers: {0}");
+return LLDB_INVALID_INDEX32;
+ }
+
+ uint32_t control_value = 0, bp_index = 0;
+
+ if (!ValidateBreakpoint(size, addr))
+return LLDB_INVALID_INDEX32;
+
+ control_value = MakeBreakControlValue(size);
+
+ // Iterate over stored breakpoints and find a free bp_index
+ bp_index = LLDB_INVALID_INDEX32;
+ for (uint32_t i = 0; i < m_max_hbp_supported; i++) {
+if (!BreakpointIsEnabled(i))
+ bp_index = i; // Mark last free slot
+else if (m_hbp_regs[i].address == addr)
+ return LLDB_INVALID_INDEX32; // We do not support duplicate breakpoints.
+ }
+
+ if (bp_index == LLDB_INVALID_INDEX32)
+return LLDB_INVALID_INDEX32;
+
+ // Update breakpoint in local cache
+ m_hbp_regs[bp_index].real_addr = addr;
+ m_hbp_regs[bp_index].address = addr;
+ m_hbp_regs[bp_index].control = control_value;
+
+ // PTRACE call to set corresponding hardware breakpoint register.
+ error = WriteHardwareDebugRegs(eDREGTypeBREAK);
+
+ if (error) {
+m_hbp_regs[bp_index].address = 0;
+m_hbp_regs[bp_index].control &= ~m_hw_dbg_enable_bit;
+
+LLDB_LOG_ERROR(
+log, std::move(error),
+"unable to set breakpoint: failed to write debug registers: {0}");
+return LLDB_INVALID_INDEX32;
+ }
+
+ return bp_index;
+}
+
+bool NativeRegisterContextDBReg::ClearHardwareBreakpoint(uint32_t hw_idx) {
+ Log *log
[Lldb-commits] [lldb] [LLDB][Process/Utility] Introduce NativeRegisterContextDBReg class (PR #118043)
https://github.com/wangleiat closed https://github.com/llvm/llvm-project/pull/118043 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [clang] [clang-tools-extra] [lld] [lldb] [llvm] Rework the `Option` library to reduce dynamic relocations (PR #119198)
https://github.com/chandlerc closed https://github.com/llvm/llvm-project/pull/119198 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
