@@ -43,11 +43,13 @@ class Block : public UserID, public SymbolContextScope {
typedef RangeVector RangeList;
typedef RangeList::Entry Range;
- /// Construct with a User ID \a uid, \a depth.
- ///
- /// Initialize this block with the specified UID \a uid. The \a depth in
DavidSpickett wrote:
And I don't see that LoongArch is doing anything unusual, so I think this is
just a refactoring exercise. It is native code so if you don't have an AArch64
machine to build on, I can test the PR for you.
https://github.com/llvm/llvm-project/pull/118043
https://github.com/DavidSpickett commented:
I was looking at the Arm (32 bit) code and it's also very similar, so if I find
the time I'll migrate this to this base class too.
See if you can move the use of pac_bits, then I'll test this for you on AArch64.
https://github.com/llvm/llvm-project/p
https://github.com/DavidSpickett edited
https://github.com/llvm/llvm-project/pull/118043
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -234,9 +234,9 @@ class NativeRegisterContextLinux_arm64
size_t GetFPMRBufferSize() { return sizeof(m_fpmr_reg); }
- llvm::Error ReadHardwareDebugInfo() override;
+ Status ReadHardwareDebugInfo() override;
DavidSpickett wrote:
@labath I seem to remembe
@@ -274,7 +161,7 @@ uint32_t
NativeRegisterContextDBReg_arm64::SetHardwareWatchpoint(
}
// Setup control value
- control_value = g_enable_bit | g_pac_bits | GetSizeBits(size);
+ control_value = m_hw_dbg_enable_bit | g_pac_bits | GetSizeBits(size);
David
https://github.com/DavidSpickett edited
https://github.com/llvm/llvm-project/pull/118043
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/DavidSpickett edited
https://github.com/llvm/llvm-project/pull/118043
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/DavidSpickett commented:
Looking good, I will test this version today.
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-co
@@ -0,0 +1,90 @@
+//===-- NativeRegisterContextDBReg.h *- C++
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apa
DavidSpickett wrote:
And now I see that x86 has a `NativeRegisterContextDBReg_x86` class.
The way it stores registers is quite different though, so I don't think:
1. We can share that much code without changing how it reads the registers.
2. That it's a problem if we just leave `NativeRegisterCo
@@ -0,0 +1,400 @@
+//===-- 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: Ap
@@ -0,0 +1,400 @@
+//===-- 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: Ap
@@ -272,199 +57,27 @@ uint32_t
NativeRegisterContextDBReg_arm64::SetHardwareWatchpoint(
addr = addr & (~0x07);
}
-
- // Setup control value
- control_value = g_enable_bit | g_pac_bits | GetSizeBits(size);
- control_value |= watch_flags << 3;
-
- // Iterate over stor
@@ -0,0 +1,90 @@
+//===-- NativeRegisterContextDBReg.h *- C++
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apa
@@ -272,199 +57,27 @@ uint32_t
NativeRegisterContextDBReg_arm64::SetHardwareWatchpoint(
addr = addr & (~0x07);
}
-
- // Setup control value
- control_value = g_enable_bit | g_pac_bits | GetSizeBits(size);
- control_value |= watch_flags << 3;
-
- // Iterate over stor
@@ -9,79 +9,16 @@
#ifndef lldb_NativeRegisterContextDBReg_arm64_h
#define lldb_NativeRegisterContextDBReg_arm64_h
-#include "Plugins/Process/Utility/NativeRegisterContextRegisterInfo.h"
-
-#include
+#include "Plugins/Process/Utility/NativeRegisterContextDBReg.h"
namespace
@@ -272,199 +57,27 @@ uint32_t
NativeRegisterContextDBReg_arm64::SetHardwareWatchpoint(
addr = addr & (~0x07);
}
-
- // Setup control value
- control_value = g_enable_bit | g_pac_bits | GetSizeBits(size);
- control_value |= watch_flags << 3;
-
- // Iterate over stor
@@ -9,79 +9,16 @@
#ifndef lldb_NativeRegisterContextDBReg_arm64_h
#define lldb_NativeRegisterContextDBReg_arm64_h
-#include "Plugins/Process/Utility/NativeRegisterContextRegisterInfo.h"
-
-#include
+#include "Plugins/Process/Utility/NativeRegisterContextDBReg.h"
namespace
DavidSpickett wrote:
The test failures were caused by:
```
virtual bool ValidateWatchpoint(size_t size, lldb::addr_t &addr) = 0;
```
Which is actually trying to change size for AArch64, but it's passed by copy so
it wasn't being updated in the caller. See my comments on those lines.
With that f
@@ -9,79 +9,16 @@
#ifndef lldb_NativeRegisterContextDBReg_arm64_h
#define lldb_NativeRegisterContextDBReg_arm64_h
-#include "Plugins/Process/Utility/NativeRegisterContextRegisterInfo.h"
-
-#include
+#include "Plugins/Process/Utility/NativeRegisterContextDBReg.h"
namespace
@@ -9,79 +9,16 @@
#ifndef lldb_NativeRegisterContextDBReg_arm64_h
#define lldb_NativeRegisterContextDBReg_arm64_h
-#include "Plugins/Process/Utility/NativeRegisterContextRegisterInfo.h"
-
-#include
+#include "Plugins/Process/Utility/NativeRegisterContextDBReg.h"
namespace
DavidSpickett wrote:
Something is up with watchpoints:
```
Failed Tests (12):
lldb-api ::
commands/watchpoints/multi_watchpoint_slots/TestWatchpointMultipleSlots.py
lldb-api ::
commands/watchpoints/watchpoint_commands/command/TestWatchpointCommandLLDB.py
lldb-api ::
commands/watchpoints/
https://github.com/DavidSpickett closed
https://github.com/llvm/llvm-project/pull/118059
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
DavidSpickett wrote:
> The relevant binaries build, but check-lldb currently hits unrelated errors
> for me blocking any progress in checking those changes.
`ninja check-lldb` passes on AArch64 Linux, and given the changes, it's
unlikely to fail on other platforms.
https://github.com/llvm/llv
DavidSpickett wrote:
If you look for:
```
FAILED:
[0mtools/clang/tools/extra/clangd/CMakeFiles/obj.clangDaemon.dir/CompileCommands.cpp.o
```
In the build log that's the failure reason.
All of the tests that reported JSON passed, that's why you have green test
reports but failed builds. I wi
https://github.com/DavidSpickett edited
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
DavidSpickett wrote:
Thanks for not ignoring the formatter - but - please remove the formatting
changes in this case because it's obscuring the actual change. When changing
existing code like this, we often ignore the formatter for this reason.
Also, I'm not sure this is any better. I guess th
@@ -312,16 +312,21 @@ struct DNBRegisterValue {
uint64_t uint64;
float float32;
double float64;
-int8_t v_sint8[64];
-int16_t v_sint16[32];
-int32_t v_sint32[16];
-int64_t v_sint64[8];
-uint8_t v_uint8[64];
-uint16_t v_uint16[32];
-uint32
https://github.com/DavidSpickett edited
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
DavidSpickett wrote:
> But when we are asking for a single register (e.g. Z0) when not in SSVE/SME
> mode, this should return an error.
I assume you did what we did for Linux, where the inactive registers do not
dissapear from the register list but just fail to read.
Linux also returns all 0s
@@ -0,0 +1,163 @@
+import lldb
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test.decorators import *
+import lldbsuite.test.lldbutil as lldbutil
+import os
+
+
+class TestSMERegistersDarwin(TestBase):
+NO_DEBUG_INFO_TESTCASE = True
+mydir = TestBase.compute_mydir
@@ -2387,6 +2863,36 @@ bool DNBArchMachARM64::SetRegisterValue(uint32_t set,
uint32_t reg,
}
break;
+case e_regSetSVE:
+ if (reg >= sve_z0 && reg <= sve_z31) {
+uint16_t max_svl_bytes = GetSMEMaxSVL();
+memcpy(&m_state.context.sve.z[reg -
@@ -2387,6 +2863,36 @@ bool DNBArchMachARM64::SetRegisterValue(uint32_t set,
uint32_t reg,
}
break;
+case e_regSetSVE:
+ if (reg >= sve_z0 && reg <= sve_z31) {
+uint16_t max_svl_bytes = GetSMEMaxSVL();
+memcpy(&m_state.context.sve.z[reg -
@@ -0,0 +1,163 @@
+import lldb
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test.decorators import *
+import lldbsuite.test.lldbutil as lldbutil
+import os
+
+
+class TestSMERegistersDarwin(TestBase):
+NO_DEBUG_INFO_TESTCASE = True
+mydir = TestBase.compute_mydir
@@ -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
@@ -0,0 +1,163 @@
+import lldb
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test.decorators import *
+import lldbsuite.test.lldbutil as lldbutil
+import os
+
+
+class TestSMERegistersDarwin(TestBase):
+NO_DEBUG_INFO_TESTCASE = True
+mydir = TestBase.compute_mydir
@@ -2281,6 +2712,51 @@ bool DNBArchMachARM64::GetRegisterValue(uint32_t set,
uint32_t reg,
}
break;
+case e_regSetSVE:
+ if (GetRegisterState(e_regSetSVE, false) != KERN_SUCCESS)
+return false;
+
+ if (reg >= sve_z0 && reg <= sve_z31) {
+
@@ -93,6 +93,55 @@ DNBArchMachARM64::SoftwareBreakpointOpcode(nub_size_t
byte_size) {
uint32_t DNBArchMachARM64::GetCPUType() { return CPU_TYPE_ARM64; }
+static std::once_flag g_cpu_has_sme_once;
+bool DNBArchMachARM64::CPUHasSME() {
+ static bool g_has_sme = false;
+ std:
https://github.com/DavidSpickett commented:
Lightly skimmed the debugserver parts, I assume one of your colleagues will
help there.
https://github.com/llvm/llvm-project/pull/119171
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://list
@@ -0,0 +1,163 @@
+import lldb
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test.decorators import *
+import lldbsuite.test.lldbutil as lldbutil
+import os
+
+
+class TestSMERegistersDarwin(TestBase):
+NO_DEBUG_INFO_TESTCASE = True
+mydir = TestBase.compute_mydir
@@ -2106,29 +2345,220 @@ const DNBRegisterInfo
DNBArchMachARM64::g_exc_registers[] = {
// Number of registers in each register set
const size_t DNBArchMachARM64::k_num_gpr_registers =
sizeof(g_gpr_registers) / sizeof(DNBRegisterInfo);
-const size_t DNBArchMachARM64::k_num_
https://github.com/DavidSpickett closed
https://github.com/llvm/llvm-project/pull/120740
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/DavidSpickett commented:
I'm not clear what you're asking for feedback on here.
Starting with a copy of the Linux platform, I understand that. However the
final changes don't look that different so I assume you have:
* Copied the Linux platform.
* Updated it until it builds o
https://github.com/DavidSpickett commented:
I should have said this before you wrote out all these tests, so apologies for
this up front, but -
There's no reason these tests need to be native, host only, tests. Cross
compiling them is not a problem. So I'd like to see these as API tests inste
DavidSpickett wrote:
Making the tests remote compatible also makes the changes to lit cpu id
unnecessary.
https://github.com/llvm/llvm-project/pull/120664
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman
DavidSpickett wrote:
ping!
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
@@ -0,0 +1,154 @@
+//===-- HostInfoAIX.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: Apach
DavidSpickett wrote:
These changes get things building I assume. So in that context I'm OK with
this. I have a feeling HostInfoAIX might end up essentially blank eventually,
but just because of the way we handle the HostInfo type, I think some file has
to exist for it to build. So it's OK to a
https://github.com/DavidSpickett closed
https://github.com/llvm/llvm-project/pull/117906
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/DavidSpickett approved this pull request.
https://github.com/llvm/llvm-project/pull/117906
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/DavidSpickett closed
https://github.com/llvm/llvm-project/pull/121920
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/DavidSpickett closed
https://github.com/llvm/llvm-project/pull/121913
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/DavidSpickett created
https://github.com/llvm/llvm-project/pull/121913
You could remove unistd.h and it builds, but only because something else
included it. So I've left it in in the spirit of "include what you use".
Tested on Linux and FreeBSD.
>From 770bad587e02f5aa2851b2
https://github.com/DavidSpickett edited
https://github.com/llvm/llvm-project/pull/121913
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -11,7 +11,9 @@
// C includes
#include
#include
+#ifndef _AIX
#include
DavidSpickett wrote:
https://github.com/llvm/llvm-project/pull/121913
https://github.com/llvm/llvm-project/pull/120979
___
lldb-commits m
https://github.com/DavidSpickett created
https://github.com/llvm/llvm-project/pull/121920
None
>From 0b4048f40300d00659a7b6067e183bb1fcc9efe5 Mon Sep 17 00:00:00 2001
From: David Spickett
Date: Tue, 7 Jan 2025 11:46:02 +
Subject: [PATCH] [lldb][NetBSD] Remove unused include in FileSystemPo
@@ -11,7 +11,9 @@
// C includes
#include
#include
+#ifndef _AIX
#include
DavidSpickett wrote:
A lot of them aren't used, I'll see how many I can remove on Linux and FreeBSD.
https://github.com/llvm/llvm-project/pull/120979
@@ -715,7 +715,7 @@ ConnectionFileDescriptor::ConnectFD(llvm::StringRef s,
ConnectionStatus ConnectionFileDescriptor::ConnectFile(
llvm::StringRef s, socket_id_callback_type socket_id_callback,
Status *error_ptr) {
-#if LLDB_ENABLE_POSIX
+#if LLDB_ENABLE_POSIX && !defin
@@ -16,6 +16,9 @@
#include
#include
#include
+#ifdef _AIX
+#include
DavidSpickett wrote:
Please do a PR to switch this to memset. This is more standard and saves us
from changing these includes.
https://github.com/llvm/llvm-project/pull/120979
__
@@ -715,7 +715,7 @@ ConnectionFileDescriptor::ConnectFD(llvm::StringRef s,
ConnectionStatus ConnectionFileDescriptor::ConnectFile(
llvm::StringRef s, socket_id_callback_type socket_id_callback,
Status *error_ptr) {
-#if LLDB_ENABLE_POSIX
+#if LLDB_ENABLE_POSIX && !defin
@@ -1226,7 +1226,7 @@ bool lldb_private::formatters::ObjCSELSummaryProvider(
time_t lldb_private::formatters::GetOSXEpoch() {
static time_t epoch = 0;
if (!epoch) {
-#ifndef _WIN32
+#if !defined(_WIN32) && !defined(_AIX)
DavidSpickett wrote:
Yes this is fi
https://github.com/DavidSpickett closed
https://github.com/llvm/llvm-project/pull/121747
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
DavidSpickett wrote:
Thanks!
https://github.com/llvm/llvm-project/pull/121747
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/DavidSpickett approved this pull request.
LGTM.
https://github.com/llvm/llvm-project/pull/121747
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/DavidSpickett edited
https://github.com/llvm/llvm-project/pull/121747
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/DavidSpickett closed
https://github.com/llvm/llvm-project/pull/122694
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/DavidSpickett edited
https://github.com/llvm/llvm-project/pull/124931
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/DavidSpickett commented:
I've looked at this a couple of times and on a general level, it seems fine,
but all the address vs. file address stuff is confusing to me. I'm just
guessing what each one is really.
So I have added some questions about that, maybe I'll be able to ap
@@ -243,25 +243,15 @@ bool Block::GetRangeContainingAddress(const Address &addr,
AddressRange &range) {
Function *function = CalculateSymbolContextFunction();
if (function) {
-const AddressRange &func_range = function->GetAddressRan
@@ -6,15 +6,22 @@
# CHECK: Found 1 function(s).
# CHECK: foo: [input.o[0x0-0xe), input.o[0x14-0x1c)]
-# CHECK-NEXT: input.o[0x0]: cmpl $0x0, %edi
-# CHECK-NEXT: input.o[0x3]: je 0x14
-# CHECK-NEXT: input.o[0x5]: jmp0x7
-# CHECK-NEXT: input.o[0x7]: callq 0xe
-# CHECK
@@ -0,0 +1,38 @@
+# REQUIRES: native && target-riscv64
+# RUN: %clangxx_host -fomit-frame-pointer %p/Inputs/riscv64-gp-read.cpp -o %t
DavidSpickett wrote:
I'm guessing that `-fomit-frame-pointer` is to stop code after the inline asm
generating save/restore routi
@@ -278,19 +268,16 @@ bool Block::GetRangeContainingLoadAddress(lldb::addr_t
load_addr,
uint32_t Block::GetRangeIndexContainingAddress(const Address &addr) {
Function *function = CalculateSymbolContextFunction();
- if (function) {
-const AddressRange &func_range = func
DavidSpickett wrote:
> I have added a live process test. But I struggle to test it (it is currently
> wrong on purpose - so ignore a eventually green pipeline). First off, I
> struggle to build libc with RISCV (I am cross compiling from x86-64).
> Additionally, I will probably have problems ru
https://github.com/DavidSpickett closed
https://github.com/llvm/llvm-project/pull/124758
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
DavidSpickett wrote:
Please set a valid email address first -
https://llvm.org/docs/DeveloperPolicy.html#github-email-address
Then this can be merged.
https://github.com/llvm/llvm-project/pull/124758
___
lldb-commits mailing list
lldb-commits@lists.l
DavidSpickett wrote:
> I am not sure whether I will lose the approval if I rebase.
GitHub seems to let you do almost anything without losing existing approvals,
for better or worse :)
It would have been fine anyway, it's just doing the rebase onto main that
"squash and merge" will do anyway.
https://github.com/DavidSpickett closed
https://github.com/llvm/llvm-project/pull/125156
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/DavidSpickett approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/125156
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/DavidSpickett created
https://github.com/llvm/llvm-project/pull/125242
This reverts commit a774de807e56c1147d4630bfec3110c11d41776e.
This is the same changes as last time, plus:
* We load the binary into the target object so that on Windows, we can resolve
the locations of t
DavidSpickett wrote:
Pull request just in case we have to discuss this more, going to merge right
now.
https://github.com/llvm/llvm-project/pull/125242
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/li
https://github.com/DavidSpickett closed
https://github.com/llvm/llvm-project/pull/125242
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
DavidSpickett wrote:
Back in again after fixing Windows testing -
https://github.com/llvm/llvm-project/pull/125242.
https://github.com/llvm/llvm-project/pull/123945
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-b
https://github.com/DavidSpickett requested changes to this pull request.
I see that the basics of this were added 2 years ago -
https://github.com/torvalds/linux/commit/1a69f7a161a78aead07cd4b811d796950e892fa4.
So I assume the build error here is not that NT_LOONGARCH_HW_BREAK is not
defined,
https://github.com/DavidSpickett edited
https://github.com/llvm/llvm-project/pull/126020
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -36,9 +36,30 @@
0xa03 /* LoongArch Advanced SIMD eXtension registers */
#endif
+#ifndef NT_LOONGARCH_HW_BREAK
+#define NT_LOONGARCH_HW_BREAK 0xa05 /* LoongArch hardware breakpoint
registers */
+#endif
+
+#ifndef NT_LOONGARCH_HW_WATCH
+#define NT_LOONGARCH_HW_WATCH 0x
DavidSpickett wrote:
> So I assume the build error here is not that NT_LOONGARCH_HW_BREAK is not
> defined, it's that user_watch_state got redefined?
And if so, why are you adding a redefinition of it?
This would only help if you are building lldb against kernel headers from
before a time whe
https://github.com/DavidSpickett approved this pull request.
https://github.com/llvm/llvm-project/pull/126352
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
DavidSpickett wrote:
I also looked at this but got into a rabbit hole finding out whether you could
have channel specific invites. I think you can, but I don't think it actually
helps us. As the other problem we have had is invites expiring, so the fewer
unique invite links the better.
https:
@@ -82,20 +82,25 @@
# CHECK-NEXT: (lldb) disassemble --name case2
# CHECK-NEXT: command-disassemble.s.tmp`n1::case2:
# CHECK-NEXT: command-disassemble.s.tmp[0x2044] <+0>: int$0x32
-# CHECK-NEXT: warning: Not disassembling a range because it is very large
[0x204
@@ -262,9 +269,11 @@ CommandObjectDisassemble::GetContainingAddressRanges() {
addr, eSymbolContextEverything, sc, resolve_tail_call_address);
if (sc.function || sc.symbol) {
AddressRange range;
- sc.GetAddressRange(eSymbolContextFunction | eSymbolContextS
@@ -82,20 +82,25 @@
# CHECK-NEXT: (lldb) disassemble --name case2
# CHECK-NEXT: command-disassemble.s.tmp`n1::case2:
# CHECK-NEXT: command-disassemble.s.tmp[0x2044] <+0>: int$0x32
-# CHECK-NEXT: warning: Not disassembling a range because it is very large
[0x204
@@ -82,20 +82,25 @@
# CHECK-NEXT: (lldb) disassemble --name case2
# CHECK-NEXT: command-disassemble.s.tmp`n1::case2:
# CHECK-NEXT: command-disassemble.s.tmp[0x2044] <+0>: int$0x32
-# CHECK-NEXT: warning: Not disassembling a range because it is very large
[0x204
https://github.com/DavidSpickett commented:
Negative offset makes sense to me given that it's relative to the symbol of the
function. Will be interesting to see how users interpret it though.
https://github.com/llvm/llvm-project/pull/126505
___
lldb-c
https://github.com/DavidSpickett edited
https://github.com/llvm/llvm-project/pull/126505
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -262,9 +269,11 @@ CommandObjectDisassemble::GetContainingAddressRanges() {
addr, eSymbolContextEverything, sc, resolve_tail_call_address);
if (sc.function || sc.symbol) {
AddressRange range;
- sc.GetAddressRange(eSymbolContextFunction | eSymbolContextS
@@ -82,20 +82,25 @@
# CHECK-NEXT: (lldb) disassemble --name case2
# CHECK-NEXT: command-disassemble.s.tmp`n1::case2:
# CHECK-NEXT: command-disassemble.s.tmp[0x2044] <+0>: int$0x32
-# CHECK-NEXT: warning: Not disassembling a range because it is very large
[0x204
DavidSpickett wrote:
Thanks for the clear explanation. Part of my confusion before was that I
mistakenly thought that the v2 struct added a padding field but this is not
correct. The only thing that has changed is the number of debug regs.
We send one `user_watch_state` to the kernel, but in v
@@ -50,6 +50,19 @@
#define REG_CONTEXT_SIZE
\
(GetGPRSize() + GetFPRSize() + sizeof(m_lsx) + sizeof(m_lasx))
+// In order to avoid undefined or redefined error, just add a new struct
+// loongarch_user_watch_state in LLD
DavidSpickett wrote:
LGTM, but @SixWeining for the final approval as the arch expert.
https://github.com/llvm/llvm-project/pull/126204
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commit
2101 - 2200 of 2869 matches
Mail list logo
