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
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
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
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
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
https://github.com/DhruvSrivastavaX edited
https://github.com/llvm/llvm-project/pull/118160
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -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
@@ -337,4 +354,471 @@
NativeRegisterContextLinux_loongarch64::GetExpeditedRegisters(
return expedited_reg_nums;
}
+uint32_t
+NativeRegisterContextLinux_loongarch64::NumSupportedHardwareBreakpoints() {
+ Log *log = GetLog(LLDBLog::Breakpoints);
+
+ // Read hardware breakpo
https://github.com/DhruvSrivastavaX edited
https://github.com/llvm/llvm-project/pull/118160
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -337,4 +354,471 @@
NativeRegisterContextLinux_loongarch64::GetExpeditedRegisters(
return expedited_reg_nums;
}
+uint32_t
+NativeRegisterContextLinux_loongarch64::NumSupportedHardwareBreakpoints() {
+ Log *log = GetLog(LLDBLog::Breakpoints);
+
+ // Read hardware breakpo
https://github.com/wangleiat updated
https://github.com/llvm/llvm-project/pull/118043
>From a7cba7ef089a6f2004b1879d30675652729370e5 Mon Sep 17 00:00:00 2001
From: wanglei
Date: Fri, 29 Nov 2024 10:43:31 +0800
Subject: [PATCH 1/2] =?UTF-8?q?[=F0=9D=98=80=F0=9D=97=BD=F0=9D=97=BF]=20in?=
=?UTF-8
wangleiat 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
https://github.com/DhruvSrivastavaX edited
https://github.com/llvm/llvm-project/pull/118160
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -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 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
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
@@ -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
@@ -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
@@ -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
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/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/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
@@ -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:
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
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
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
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
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
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
@@ -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
@@ -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/
@@ -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
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
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
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
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
@@ -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
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
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
@@ -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
@@ -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 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
@@ -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:
@@ -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 -
@@ -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
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
@@ -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/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
@@ -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
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
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
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
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/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
@@ -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:
@@ -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
@@ -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
@@ -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;
@@ -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,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
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
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
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
@@ -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
@@ -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;
+
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
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
@@ -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
@@ -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/7] Convert the recursive StackFrameList mutex to a
non-recursiv
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
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)
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,
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
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
1 - 100 of 110 matches
Mail list logo
