h-vetinari wrote:
I think the title of the commit ("Support load lazy specialization lazily") is
hard to parse and somewhat redundant. Perhaps the following would be better
(IIUC): "Support loading template specializations lazily"
Also "We should a specialization ` A` in `M.cppm` [...]" in
th
https://github.com/ChuanqiXu9 edited
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
https://github.com/ChuanqiXu9 updated
https://github.com/llvm/llvm-project/pull/119333
>From bccd73362a411ef6652100f987843aa18dfb8085 Mon Sep 17 00:00:00 2001
From: Chuanqi Xu
Date: Fri, 6 Dec 2024 10:31:37 +0800
Subject: [PATCH] [Serialization] Support load lazy specialization lazily
Currentl
llvmbot wrote:
@llvm/pr-subscribers-clang-modules
Author: Chuanqi Xu (ChuanqiXu9)
Changes
Reland https://github.com/llvm/llvm-project/pull/83237
---
Currently all the specializations of a template (including instantiation,
specialization and partial specializations) will be loaded at o
https://github.com/ChuanqiXu9 created
https://github.com/llvm/llvm-project/pull/119333
Reland https://github.com/llvm/llvm-project/pull/83237
---
Currently all the specializations of a template (including instantiation,
specialization and partial specializations) will be loaded at once if we
@@ -845,13 +845,14 @@ MemoryBufferRef
LinkerDriver::convertResToCOFF(ArrayRef mbs,
// Create OptTable
+#define OPTTABLE_STR_TABLE_CODE
chandlerc wrote:
I have no idea. It took a lot of work to get even this to work, figuring out
each of the different ways
@@ -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;
+
@@ -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;
+
@@ -80,15 +78,56 @@ class OptTable {
const char *AliasArgs;
const char *Values;
-StringRef getName() const {
- unsigned PrefixLength = Prefixes.empty() ? 0 : Prefixes[0].size();
- return PrefixedName.drop_front(PrefixLength);
+bool hasNoPrefix() const
clayborg wrote:
> @clayborg Thank you, Greg! Lots of that info is not described anywhere, no
> wonder I missed it. Let me try your fixes in my provider, and I will get back
> to you.
>
> By some reason my provider works in CLI lldb, but not in lldb-dap, but I will
> check if your suggestions
clayborg wrote:
I think the patch seems good as it is without needing to differentiate really.
What are we gaining by hiding something that is trying to report progress that
can take some time? Wouldn't we want to know this in a sys diagnose situation?
If a python command runs for a long time,
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/7] Convert the recursive StackFrameList mutex to a
non-recursiv
https://github.com/adrian-prantl updated
https://github.com/llvm/llvm-project/pull/114333
>From 1e51be85ed88857a0ef53cf1a0756b98f7c11a1b Mon Sep 17 00:00:00 2001
From: Dave Lee
Date: Wed, 24 Jan 2024 12:42:45 -0800
Subject: [PATCH 1/2] [lldb] Load embedded type summary section (#7859) (#8040)
github-actions[bot] wrote:
:warning: Python code formatter, darker found issues in your code. :warning:
You can test this locally with the following command:
``bash
darker --check --diff -r
337936a83bc9ffaba67658245a8c9bef159584a3...4e7eb4780a82e0896e6e8daaff741d3e62051f0a
lldb
https://github.com/JDevlieghere approved this pull request.
https://github.com/llvm/llvm-project/pull/114333
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/adrian-prantl updated
https://github.com/llvm/llvm-project/pull/114333
>From 1e51be85ed88857a0ef53cf1a0756b98f7c11a1b Mon Sep 17 00:00:00 2001
From: Dave Lee
Date: Wed, 24 Jan 2024 12:42:45 -0800
Subject: [PATCH 1/2] [lldb] Load embedded type summary section (#7859) (#8040)
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/6] Convert the recursive StackFrameList mutex to a
non-recursiv
@@ -845,13 +845,14 @@ MemoryBufferRef
LinkerDriver::convertResToCOFF(ArrayRef mbs,
// Create OptTable
+#define OPTTABLE_STR_TABLE_CODE
rnk wrote:
Is it feasible to split out all the tool driver updates, like refactor all
these PREFIX definitions into the t
@@ -1012,33 +1006,26 @@ bool SBFrame::GetDescription(SBStream &description) {
SBValue SBFrame::EvaluateExpression(const char *expr) {
LLDB_INSTRUMENT_VA(this, expr);
- SBValue result;
std::unique_lock lock;
ExecutionContext exe_ctx(m_opaque_sp.get(), lock);
Stack
JDevlieghere wrote:
@Jlalond If it were up to me I'd create another PR which adds the
internal/external property. All existing progress events would be internal so
that should be NFC. We have unit tests for the progress events so you could
create an external progress event and test that it's o
Jlalond wrote:
@JDevlieghere if I were to add a way to identify an 'internal' vs 'external'
progress, do you want me to make all consumers aware to this distinction or are
we cool with just exposing the property as a part of this patch?
https://github.com/llvm/llvm-project/pull/119052
@@ -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;
+
@@ -80,15 +78,56 @@ class OptTable {
const char *AliasArgs;
const char *Values;
-StringRef getName() const {
- unsigned PrefixLength = Prefixes.empty() ? 0 : Prefixes[0].size();
- return PrefixedName.drop_front(PrefixLength);
+bool hasNoPrefix() const
@@ -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;
+
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/5] Convert the recursive StackFrameList mutex to a
non-recursiv
@@ -1012,33 +1006,26 @@ bool SBFrame::GetDescription(SBStream &description) {
SBValue SBFrame::EvaluateExpression(const char *expr) {
LLDB_INSTRUMENT_VA(this, expr);
- SBValue result;
std::unique_lock lock;
ExecutionContext exe_ctx(m_opaque_sp.get(), lock);
Stack
@@ -257,8 +257,8 @@ enum StopReason {
};
/// Command Return Status Types.
-enum ReturnStatus {
- eReturnStatusInvalid,
+enum ReturnStatus : int {
oontvoo wrote:
This is needed to serialize the ReturnStatus from a command.
https://github.com/llvm/llvm-projec
https://github.com/jimingham edited
https://github.com/llvm/llvm-project/pull/117252
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -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/kastiglione closed
https://github.com/llvm/llvm-project/pull/118814
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/jimingham edited
https://github.com/llvm/llvm-project/pull/117252
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Author: Dave Lee
Date: 2024-12-09T10:48:28-08:00
New Revision: 53fd724b256e1ccfcb04c90f7740f54e1801986d
URL:
https://github.com/llvm/llvm-project/commit/53fd724b256e1ccfcb04c90f7740f54e1801986d
DIFF:
https://github.com/llvm/llvm-project/commit/53fd724b256e1ccfcb04c90f7740f54e1801986d.diff
LOG:
https://github.com/kastiglione edited
https://github.com/llvm/llvm-project/pull/118814
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -594,7 +643,7 @@ StackFrameSP StackFrameList::GetFrameAtIndex(uint32_t idx) {
// GetFramesUpTo will fill m_frames with as many frames as you asked for, if
// there are that many. If there weren't then you asked for too many frames.
// GetFramesUpTo returns true if int
Jlalond wrote:
> > Just to throw my opinion into the debate; I view Progress.h in the same way
> > as I view any printing to the terminal (or stdout). We already allow Python
> > commands, and I believe formatters, to print to the user's console. So
> > restricting progress because we don't wa
JDevlieghere wrote:
> Just to throw my opinion into the debate; I view Progress.h in the same way
> as I view any printing to the terminal (or stdout). We already allow Python
> commands, and I believe formatters, to print to the user's console. So
> restricting progress because we don't want
https://github.com/Jlalond updated
https://github.com/llvm/llvm-project/pull/119052
>From 2adc8124e9b423d7c195cc6b986b43dfa8c10fe4 Mon Sep 17 00:00:00 2001
From: Jacob Lalonde
Date: Fri, 6 Dec 2024 18:17:44 -0800
Subject: [PATCH 1/2] Add SBPRogress class to enable commands to async report
to l
https://github.com/Jlalond updated
https://github.com/llvm/llvm-project/pull/119052
>From 2adc8124e9b423d7c195cc6b986b43dfa8c10fe4 Mon Sep 17 00:00:00 2001
From: Jacob Lalonde
Date: Fri, 6 Dec 2024 18:17:44 -0800
Subject: [PATCH 1/2] Add SBPRogress class to enable commands to async report
to l
@@ -18,11 +17,8 @@
#include "lldb/Core/Address.h"
#include "lldb/Core/Debugger.h"
#include "lldb/Expression/ExpressionVariable.h"
-#include "lldb/Expression/UserExpression.h"
JDevlieghere wrote:
Please upstage the header changes too.
https://github.com/llvm/
@@ -1012,33 +1006,26 @@ bool SBFrame::GetDescription(SBStream &description) {
SBValue SBFrame::EvaluateExpression(const char *expr) {
LLDB_INSTRUMENT_VA(this, expr);
- SBValue result;
std::unique_lock lock;
ExecutionContext exe_ctx(m_opaque_sp.get(), lock);
Stack
@@ -0,0 +1,56 @@
+//===-- SBProgress.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
https://github.com/oltolm updated
https://github.com/llvm/llvm-project/pull/119103
>From 1ee5dcee29ed50d87981112d1a25bcf2035368af Mon Sep 17 00:00:00 2001
From: oltolm
Date: Sat, 7 Dec 2024 17:24:07 +0100
Subject: [PATCH] lldb: do not show misleading error when there is no frame
---
lldb/sour
https://github.com/oltolm updated
https://github.com/llvm/llvm-project/pull/119103
>From 128431de6ef396105507e5666cb0f2b50f8f69db Mon Sep 17 00:00:00 2001
From: oltolm
Date: Sat, 7 Dec 2024 17:24:07 +0100
Subject: [PATCH] lldb: do not show misleading error when there is no frame
---
lldb/sour
oltolm wrote:
> I imagine that your change does make sense, but it's really not strictly tied
> to lldb-dap. It's more generic and it's about what happens when the
> expression evaluator is invoked from SBFrame when the process is not stopped,
> right?
Yes the message "can't evaluate expressi
oltolm 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.
Done.
> Also, I'm not sure this is any better. I
github-actions[bot] wrote:
:warning: C/C++ code formatter, clang-format found issues in your code.
:warning:
You can test this locally with the following command:
``bash
git-clang-format --diff 66f9448b4b14a117141a3efd014e1240b30b741f
8e649d4a2a23a5d644761611c285c5b8d753b007 --e
Jlalond wrote:
> The patch itself looks good with some nits, but I'm (still) on the fence
> whether this a good idea.
>
> In the past, a similar question has come up in the context of logging and
> whether we want to add SB APIs to make use of LLDB's internals. The argument
> in favor is that
@@ -0,0 +1,34 @@
+//===-- SBProgress.cpp ---*- 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:
https://github.com/oltolm updated
https://github.com/llvm/llvm-project/pull/119103
>From 8e649d4a2a23a5d644761611c285c5b8d753b007 Mon Sep 17 00:00:00 2001
From: oltolm
Date: Sat, 7 Dec 2024 17:24:07 +0100
Subject: [PATCH] lldb: do not show misleading error when there is no frame
---
lldb/sour
@@ -389,7 +389,7 @@ ifeq (1,$(USE_LIBCPP))
ifneq "$(LIBCPP_INCLUDE_TARGET_DIR)" ""
CXXFLAGS += -cxx-isystem
$(LIBCPP_INCLUDE_TARGET_DIR)
endif
- LDFLAGS += -L$(LIBCPP_LIBRARY_DIR)
-Wl,-rpath,$(LIBCPP_L
@@ -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 -
@@ -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/labath updated
https://github.com/llvm/llvm-project/pull/117725
>From a4d07c4279f6f474b468a7499f1970be42e2791d Mon Sep 17 00:00:00 2001
From: Pavel Labath
Date: Tue, 26 Nov 2024 16:12:40 +0100
Subject: [PATCH] [lldb] Handle improperly nested blocks differently
In 6c7f56192fa
@@ -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
@@ -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,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
labath wrote:
Any thoughts on this, Greg?
https://github.com/llvm/llvm-project/pull/117725
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
walter-erquinigo wrote:
I imagine that your change does make sense, but it's really not strictly tied
to lldb-dap. It's more generic and it's about what happens when the expression
evaluator is invoked from SBFrame when the process is not stopped, right?
In any case, please reduce this PR to ju
@@ -0,0 +1,34 @@
+//===-- SBProgress.cpp ---*- C++
+//-*-===//
JDevlieghere wrote:
Broken ASCII art. Also new headers
[shouldn't](https://discourse.llvm.org/t/is-c-in-header-files-still-relevant/83124)
contain `- C++ ` an
@@ -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(Ge
@@ -0,0 +1,34 @@
+//===-- SBProgress.cpp ---*- 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:
@@ -0,0 +1,34 @@
+//===-- SBProgress.cpp ---*- 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:
https://github.com/JDevlieghere edited
https://github.com/llvm/llvm-project/pull/119052
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/JDevlieghere commented:
The patch itself looks good with some nits, but I'm (still) on the fence
whether this a good idea.
In the past, a similar question has come up in the context of logging and
whether we want to add SB APIs to make use of LLDB's internals. The argument
https://github.com/ashgti closed
https://github.com/llvm/llvm-project/pull/119148
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Author: John Harrison
Date: 2024-12-09T08:43:58-08:00
New Revision: 117cfa66ea6b1e307db0e8da43a6e9306cdaaca0
URL:
https://github.com/llvm/llvm-project/commit/117cfa66ea6b1e307db0e8da43a6e9306cdaaca0
DIFF:
https://github.com/llvm/llvm-project/commit/117cfa66ea6b1e307db0e8da43a6e9306cdaaca0.diff
labath wrote:
> Can we build this feature into the Progress class by calling an accessor?
> Something like:
>
> ```
> Progress progress("Manually indexing DWARF", module_desc.GetData(),
> total_progress);
> progress.SetMinimumNotificationTime(std::chrono::milliseconds(10));
> ```
>
> Then any
https://github.com/labath commented:
It's definitely better, but I'm still not particularly thrilled with this
approach. IIUC, you made this work by changing the buildbot configuration,
which is fine if you control all the buildbots that build this way, but it's
definitely not ideal. The linke
https://github.com/labath edited
https://github.com/llvm/llvm-project/pull/118986
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/JDevlieghere approved this pull request.
Neat
https://github.com/llvm/llvm-project/pull/119148
___
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/119171
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -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_
@@ -0,0 +1,248 @@
+//===-- NativeProcessAIX.cpp ===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apach
@@ -81,9 +79,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;
@@ -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(Ge
@@ -0,0 +1,130 @@
+//===-- NativeProcessAIX.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: Apach
@@ -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
https://github.com/labath approved this pull request.
Thanks.
https://github.com/llvm/llvm-project/pull/119148
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -98,9 +98,20 @@ class ObjectFileXCOFF : public lldb_private::ObjectFile {
const lldb::ProcessSP &process_sp, lldb::addr_t header_addr);
protected:
+ typedef struct llvm::object::XCOFFFileHeader64 xcoff_header_t;
+
+ typedef struct llvm::object::XCOFFAuxi
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
@@ -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:
@@ -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) {
+
@@ -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
@@ -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,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
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
https://github.com/labath approved this pull request.
I'm fine with this.
https://github.com/llvm/llvm-project/pull/118814
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -23,6 +23,13 @@ STRING_EXTENSION_OUTSIDE(SBValue)
if -count <= key < count:
key %= count
return self.sbvalue.GetChildAtIndex(key)
+elif isinstance(key, str):
+if child :=
https://github.com/labath edited
https://github.com/llvm/llvm-project/pull/117252
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -594,7 +643,7 @@ StackFrameSP StackFrameList::GetFrameAtIndex(uint32_t idx) {
// GetFramesUpTo will fill m_frames with as many frames as you asked for, if
// there are that many. If there weren't then you asked for too many frames.
// GetFramesUpTo returns true if int
https://github.com/labath commented:
It's somewhat better, but it doesn't address my main concern, which is this
mid-scope switching of lock types. It's an unusual setup, and that's usually
not good thing when it comes to locking and threads.
I don't think that the fact that these are all read
chandlerc 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.
NP, and thanks. Sorry I missed that set of tests. Pushed a fix that makes
`check-clang-too
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
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
llvmbot wrote:
@llvm/pr-subscribers-clang-driver
Author: Chandler Carruth (chandlerc)
Changes
Apologies for the large change, I looked for ways to break this up and all of
the ones I saw added real complexity. This change focuses on the option's
prefixed names and the array of prefixes.
llvmbot wrote:
@llvm/pr-subscribers-llvm-binary-utilities
@llvm/pr-subscribers-lld
@llvm/pr-subscribers-clang
Author: Chandler Carruth (chandlerc)
Changes
Apologies for the large change, I looked for ways to break this up and all of
the ones I saw added real complexity. This change focuse
1 - 100 of 110 matches
Mail list logo
