@@ -0,0 +1,165 @@
+# A bytecode for (LLDB) data formatters
+
+## Background
+
+LLDB provides very rich customization options to display data types (see
https://lldb.llvm.org/use/variable.html ). To use custom data formatters,
developers typically need to edit the global `~/.lldb
@@ -0,0 +1,165 @@
+# A bytecode for (LLDB) data formatters
+
+## Background
+
+LLDB provides very rich customization options to display data types (see
https://lldb.llvm.org/use/variable.html ). To use custom data formatters,
developers typically need to edit the global `~/.lldb
@@ -0,0 +1,486 @@
+"""
+Specification, compiler, disassembler, and interpreter
+for LLDB dataformatter bytecode.
+
+See formatter-bytecode.md for more details.
+"""
+from __future__ import annotations
+
+# Types
+type_String = 1
+type_Int = 2
+type_UInt = 3
+type_Object = 4
+type_
DavidSpickett wrote:
> The non-native (DIA based) PDB symbol file implementation was unmaintained
> and known to have issues.
FWIW I have seen feedback from users who have no idea what this does or why
there would be two things when one is always worse in their experience.
Unfortunately I've
DavidSpickett wrote:
Compiling languages into this is intriguing.
MLIR noob thinking out loud: if MLIR could lower into this could you write your
formatter in Fortran? :rofl:
https://github.com/llvm/llvm-project/pull/113398
___
lldb-commits mailing
@@ -0,0 +1,486 @@
+"""
+Specification, compiler, disassembler, and interpreter
+for LLDB dataformatter bytecode.
+
+See formatter-bytecode.md for more details.
+"""
+from __future__ import annotations
+
+# Types
+type_String = 1
+type_Int = 2
+type_UInt = 3
+type_Object = 4
+type_
@@ -0,0 +1,165 @@
+# A bytecode for (LLDB) data formatters
+
+## Background
+
+LLDB provides very rich customization options to display data types (see
https://lldb.llvm.org/use/variable.html ). To use custom data formatters,
developers typically need to edit the global `~/.lldb
@@ -0,0 +1,165 @@
+# A bytecode for (LLDB) data formatters
+
+## Background
+
+LLDB provides very rich customization options to display data types (see
https://lldb.llvm.org/use/variable.html ). To use custom data formatters,
developers typically need to edit the global `~/.lldb
@@ -0,0 +1,165 @@
+# A bytecode for (LLDB) data formatters
+
+## Background
+
+LLDB provides very rich customization options to display data types (see
https://lldb.llvm.org/use/variable.html ). To use custom data formatters,
developers typically need to edit the global `~/.lldb
@@ -0,0 +1,165 @@
+# A bytecode for (LLDB) data formatters
+
+## Background
+
+LLDB provides very rich customization options to display data types (see
https://lldb.llvm.org/use/variable.html ). To use custom data formatters,
developers typically need to edit the global `~/.lldb
@@ -0,0 +1,165 @@
+# A bytecode for (LLDB) data formatters
+
+## Background
+
+LLDB provides very rich customization options to display data types (see
https://lldb.llvm.org/use/variable.html ). To use custom data formatters,
developers typically need to edit the global `~/.lldb
@@ -0,0 +1,486 @@
+"""
+Specification, compiler, disassembler, and interpreter
+for LLDB dataformatter bytecode.
+
+See formatter-bytecode.md for more details.
+"""
+from __future__ import annotations
+
+# Types
+type_String = 1
+type_Int = 2
+type_UInt = 3
+type_Object = 4
+type_
@@ -0,0 +1,165 @@
+# A bytecode for (LLDB) data formatters
+
+## Background
+
+LLDB provides very rich customization options to display data types (see
https://lldb.llvm.org/use/variable.html ). To use custom data formatters,
developers typically need to edit the global `~/.lldb
@@ -0,0 +1,486 @@
+"""
+Specification, compiler, disassembler, and interpreter
+for LLDB dataformatter bytecode.
+
+See formatter-bytecode.md for more details.
+"""
+from __future__ import annotations
+
+# Types
+type_String = 1
+type_Int = 2
+type_UInt = 3
+type_Object = 4
+type_
@@ -0,0 +1,165 @@
+# A bytecode for (LLDB) data formatters
+
+## Background
+
+LLDB provides very rich customization options to display data types (see
https://lldb.llvm.org/use/variable.html ). To use custom data formatters,
developers typically need to edit the global `~/.lldb
DavidSpickett wrote:
This is very cool overall. At first the idea of a whole new VM seems like way
too much, but I think I'm getting a better sense of the tradeoffs having read
through this.
https://github.com/llvm/llvm-project/pull/113398
___
lldb-c
@@ -0,0 +1,27 @@
+import os
DavidSpickett wrote:
A bit surprised we don't have a scripted commands test that this could be added
to instead of making a new file.
https://github.com/llvm/llvm-project/pull/113996
___
ll
@@ -0,0 +1,27 @@
+import os
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+
+
+class TestCase(TestBase):
+NO_DEBUG_INFO_TESTCASE = True
+
+def test(self):
+"""
+Check that a Python command, which raises an unha
@@ -117,15 +148,22 @@ struct InitializePythonRAII {
PyImport_AppendInittab("_lldb", LLDBSwigPyInit);
}
+#if (PY_MAJOR_VERSION == 3 && PY_MINOR_VERSION >= 8) || (PY_MAJOR_VERSION > 3)
+config.install_signal_handlers = 0;
+Py_InitializeFromConfig(&config);
+
DavidSpickett wrote:
`launch-working-dir` sounds like `working-dir` to me. Do we need the `launch`
prefix? Should this be `target.process` not `target`?
This issue could be re-stated as "a process launched with -w does not use the
same working dir if run again". Which I think is certainly unex
@@ -117,15 +148,22 @@ struct InitializePythonRAII {
PyImport_AppendInittab("_lldb", LLDBSwigPyInit);
}
+#if (PY_MAJOR_VERSION == 3 && PY_MINOR_VERSION >= 8) || (PY_MAJOR_VERSION > 3)
+config.install_signal_handlers = 0;
+Py_InitializeFromConfig(&config);
+
https://github.com/DavidSpickett edited
https://github.com/llvm/llvm-project/pull/113521
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -201,6 +201,12 @@ let Definition = "target" in {
def DebugUtilityExpression: Property<"debug-utility-expression", "Boolean">,
DefaultFalse,
Desc<"Enable debugging of LLDB-internal utility expressions.">;
+ def LaunchWorkingDir: Property<"launch-working-dir", "Stri
https://github.com/DavidSpickett commented:
We only have one request for this feature, but the logic of it is clear and GDB
as an equivalent in `set cwd`:
https://sourceware.org/gdb/current/onlinedocs/gdb.html/Working-Directory.html
So this looks good to me once the docs are updated.
https://
@@ -201,6 +201,12 @@ let Definition = "target" in {
def DebugUtilityExpression: Property<"debug-utility-expression", "Boolean">,
DefaultFalse,
Desc<"Enable debugging of LLDB-internal utility expressions.">;
+ def LaunchWorkingDir: Property<"launch-working-dir", "Stri
@@ -691,7 +691,10 @@ let Command = "process launch" in {
def process_launch_plugin : Option<"plugin", "P">, Arg<"Plugin">,
Desc<"Name of the process plugin you want to use.">;
def process_launch_working_dir : Option<"working-dir", "w">,
Arg<"DirectoryName">,
-Desc<
@@ -64,3 +64,10 @@ else()
Python3_EXECUTABLE
LLDB_ENABLE_SWIG)
endif()
+
+set(LLDB_RECOMMENDED_PYTHON "3.8")
+if(Python3_LIBRARIES AND Python3_INCLUDE_DIRS AND Python3_EXECUTABLE AND
LLDB_ENABLE_SWIG
-
https://github.com/DavidSpickett updated
https://github.com/llvm/llvm-project/pull/114807
>From 12672234d81cc12625d8832fed4937221d37546e Mon Sep 17 00:00:00 2001
From: David Spickett
Date: Mon, 4 Nov 2024 14:41:19 +
Subject: [PATCH 1/2] [lldb] Recommend Python 3.8 as the minimum Python vers
https://github.com/DavidSpickett created
https://github.com/llvm/llvm-project/pull/114807
See
https://discourse.llvm.org/t/rfc-lets-document-and-enforce-a-minimum-python-version-for-lldb/82731
for discussions.
This matches LLVM's requirement to run tests. For LLDB 20 there will be a CMake
wa
https://github.com/DavidSpickett ready_for_review
https://github.com/llvm/llvm-project/pull/114807
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
DavidSpickett wrote:
Intentionally or not, this also fixes TestInlineStepping.py
`test_with_python_api` on Arm 32 bit.
https://github.com/llvm/llvm-project/pull/114628
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cg
https://github.com/DavidSpickett approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/114112
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -92,7 +92,38 @@ namespace {
struct InitializePythonRAII {
public:
InitializePythonRAII() {
-InitializePythonHome();
+#if (PY_MAJOR_VERSION == 3 && PY_MINOR_VERSION >= 8) || (PY_MAJOR_VERSION > 3)
+PyConfig config;
+PyConfig_InitPythonConfig(&config);
+#endif
+
DavidSpickett wrote:
> That was just a symptom, but what we want is users not having to specify
> process launch -w at all. We want our users to simply do run and that things
> just work.
We have:
* process launch -w does not carry the working dir to subsequent launches.
* Please open an iss
DavidSpickett wrote:
> Internally we use bazel in a way in which
Even if this way of using it (I have no experience with Bazel myself) is
unusual, I think the pitch for the setting is ok anyway.
https://github.com/llvm/llvm-project/pull/113521
___
ll
@@ -201,6 +201,10 @@ let Definition = "target" in {
def DebugUtilityExpression: Property<"debug-utility-expression", "Boolean">,
DefaultFalse,
Desc<"Enable debugging of LLDB-internal utility expressions.">;
+ def LaunchWorkingDir: Property<"launch-working-dir", "Stri
@@ -206,3 +207,70 @@ def test_environment_with_special_char(self):
self.assertEqual(value, evil_var)
process.Continue()
self.assertState(process.GetState(), lldb.eStateExited, PROCESS_EXITED)
+
+def test_target_launch_working_dir_prop(self):
+
@@ -206,3 +207,70 @@ def test_environment_with_special_char(self):
self.assertEqual(value, evil_var)
process.Continue()
self.assertState(process.GetState(), lldb.eStateExited, PROCESS_EXITED)
+
+def test_target_launch_working_dir_prop(self):
+
@@ -4428,6 +4428,15 @@ void TargetProperties::SetDisableSTDIO(bool b) {
const uint32_t idx = ePropertyDisableSTDIO;
SetPropertyAtIndex(idx, b);
}
+std::optional
+TargetProperties::GetLaunchWorkingDirectory() const {
DavidSpickett wrote:
If it's not used wh
@@ -201,6 +201,13 @@ class CommandObjectProcessLaunch : public
CommandObjectProcessLaunchOrAttach {
if (target->GetDisableSTDIO())
m_options.launch_info.GetFlags().Set(eLaunchFlagDisableSTDIO);
+if (!m_options.launch_info.GetWorkingDirectory()) {
---
@@ -206,3 +207,70 @@ def test_environment_with_special_char(self):
self.assertEqual(value, evil_var)
process.Continue()
self.assertState(process.GetState(), lldb.eStateExited, PROCESS_EXITED)
+
+def test_target_launch_working_dir_prop(self):
+
https://github.com/DavidSpickett commented:
I think you already did what I asked for in my comment just now, just docs and
comments to update.
https://github.com/llvm/llvm-project/pull/113521
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
h
https://github.com/DavidSpickett edited
https://github.com/llvm/llvm-project/pull/113521
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
DavidSpickett wrote:
Also please add a release note to the LLDB section in the llvm release notes
doc. These sort of settings people don't know they could use, until they
realise they exist.
https://github.com/llvm/llvm-project/pull/113521
___
lldb-c
@@ -47,6 +47,10 @@ static llvm::Expected *g_fcxx_modules_workaround
[[maybe_unused]];
// Include python for non windows machines
#include
+
+// Provide a meaningful diagnostic error if someone tries to compile this file
+// with a version of Python we don't support.
+static_
https://github.com/DavidSpickett commented:
Pavel's request so he can approve but looks fine to me. The static assert is a
nice addition.
I see the set home change had to be reverted but I assume you're sorting all
that out yourself.
https://github.com/llvm/llvm-project/pull/114346
__
https://github.com/DavidSpickett edited
https://github.com/llvm/llvm-project/pull/114346
___
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/114295
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Author: David Spickett
Date: 2024-10-31T09:08:00Z
New Revision: 7557972884106e6bdaf00eabe1a8cafec861a7fe
URL:
https://github.com/llvm/llvm-project/commit/7557972884106e6bdaf00eabe1a8cafec861a7fe
DIFF:
https://github.com/llvm/llvm-project/commit/7557972884106e6bdaf00eabe1a8cafec861a7fe.diff
LOG
@@ -0,0 +1,165 @@
+# A bytecode for (LLDB) data formatters
+
+## Background
+
+LLDB provides very rich customization options to display data types (see
https://lldb.llvm.org/use/variable.html ). To use custom data formatters,
developers typically need to edit the global `~/.lldb
@@ -1537,6 +1538,76 @@ static void LoadScriptingResourceForModule(const
ModuleSP &module_sp,
feedback_stream.GetData());
}
+// Load type summaries embedded in the binary. These are type summaries
provided
+// by the authors o
@@ -0,0 +1,22 @@
+#include
+
+struct Player {
+ char *name;
+ int number;
+};
+
+__attribute__((used, section("__DATA_CONST,__lldbsummaries"))) unsigned char
+_Player_type_summary[] = "\x01" // version
+ "\x25" // record size
+
@@ -1537,6 +1538,76 @@ static void LoadScriptingResourceForModule(const
ModuleSP &module_sp,
feedback_stream.GetData());
}
+// Load type summaries embedded in the binary. These are type summaries
provided
+// by the authors o
@@ -1537,6 +1538,76 @@ static void LoadScriptingResourceForModule(const
ModuleSP &module_sp,
feedback_stream.GetData());
}
+// Load type summaries embedded in the binary. These are type summaries
provided
+// by the authors o
DavidSpickett wrote:
> This upstreams the embedded type summary feature from the swiftlang branch of
> LLDB, since it shares a lot of the same goals and design points with
> https://github.com/llvm/llvm-project/pull/113398
Just want to be extra clear here, this shares some of the same goals bu
@@ -0,0 +1,165 @@
+# A bytecode for (LLDB) data formatters
+
+## Background
+
+LLDB provides very rich customization options to display data types (see
https://lldb.llvm.org/use/variable.html ). To use custom data formatters,
developers typically need to edit the global `~/.lldb
@@ -0,0 +1,486 @@
+"""
+Specification, compiler, disassembler, and interpreter
+for LLDB dataformatter bytecode.
+
+See formatter-bytecode.md for more details.
+"""
+from __future__ import annotations
+
+# Types
+type_String = 1
+type_Int = 2
+type_UInt = 3
+type_Object = 4
+type_
@@ -0,0 +1,165 @@
+# A bytecode for (LLDB) data formatters
+
+## Background
+
+LLDB provides very rich customization options to display data types (see
https://lldb.llvm.org/use/variable.html ). To use custom data formatters,
developers typically need to edit the global `~/.lldb
@@ -0,0 +1,165 @@
+# A bytecode for (LLDB) data formatters
+
+## Background
+
+LLDB provides very rich customization options to display data types (see
https://lldb.llvm.org/use/variable.html ). To use custom data formatters,
developers typically need to edit the global `~/.lldb
@@ -0,0 +1,486 @@
+"""
+Specification, compiler, disassembler, and interpreter
+for LLDB dataformatter bytecode.
+
+See formatter-bytecode.md for more details.
+"""
+from __future__ import annotations
+
+# Types
+type_String = 1
+type_Int = 2
+type_UInt = 3
+type_Object = 4
+type_
@@ -0,0 +1,486 @@
+"""
+Specification, compiler, disassembler, and interpreter
+for LLDB dataformatter bytecode.
+
+See formatter-bytecode.md for more details.
+"""
+from __future__ import annotations
+
+# Types
+type_String = 1
+type_Int = 2
+type_UInt = 3
+type_Object = 4
+type_
@@ -0,0 +1,486 @@
+"""
+Specification, compiler, disassembler, and interpreter
+for LLDB dataformatter bytecode.
+
+See formatter-bytecode.md for more details.
+"""
+from __future__ import annotations
+
+# Types
+type_String = 1
+type_Int = 2
+type_UInt = 3
+type_Object = 4
+type_
@@ -0,0 +1,165 @@
+# A bytecode for (LLDB) data formatters
+
+## Background
+
+LLDB provides very rich customization options to display data types (see
https://lldb.llvm.org/use/variable.html ). To use custom data formatters,
developers typically need to edit the global `~/.lldb
DavidSpickett wrote:
> process launch -w does not carry the working dir to subsequent launches.
> * Please open an issue for that.
Actually this is not a bug. `process launch` and `run` are two separate (at
least from the user perpsective) ways to run a program.
I think if you should just add
DavidSpickett wrote:
There was one somewhere in the text, but of course I can't find it so it was
clearly of little use :)
Is now a good time to remind you @JDevlieghere that these two videos are no
longer available on the Apple site. More than a decade old so it's not that
surprising but may
https://github.com/DavidSpickett closed
https://github.com/llvm/llvm-project/pull/114295
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
DavidSpickett wrote:
I looked into this. Not sure what the stepping logic goes by but I do see there
is no line table entry for the function call we expect to stop at after the
first stop.
I have cut the cpp down to:
```
1 inline void inline_trivial_1 () __attribute__((always_inline));
2
DavidSpickett wrote:
dwarfdump:
[arm_dwarfdump.txt](https://github.com/user-attachments/files/17598949/arm_dwarfdump.txt)
(this doesn't seem different to what AArch64 produces)
objdump:
[arm_objdump.txt](https://github.com/user-attachments/files/17598953/arm_objdump.txt)
stepping log:
[arm_st
https://github.com/DavidSpickett closed
https://github.com/llvm/llvm-project/pull/114807
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -157,6 +157,12 @@ let Definition = "target" in {
DefaultEnumValue<"eX86DisFlavorDefault">,
EnumValues<"OptionEnumValues(g_x86_dis_flavor_value_types)">,
Desc<"The default disassembly flavor to use for x86 or x86-64 targets.">;
+ def DisassemblyCPU: Property<"dis
https://github.com/DavidSpickett approved this pull request.
I thought maybe the test passed accidentally with this change but the backtrace
must still match so LGTM.
https://github.com/llvm/llvm-project/pull/115722
___
lldb-commits mailing list
lldb-
DavidSpickett wrote:
If I understand correctly this is building the test on Linux and running it on
Windows.
And it seems that the output is in fact better this way? Can't complain about
that.
https://github.com/llvm/llvm-project/pull/115722
___
lld
https://github.com/DavidSpickett edited
https://github.com/llvm/llvm-project/pull/115722
___
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.
Thought that maybe you could just re-use the check for `system-windows`, but
that's something lit adds for us by asking Python what it's running on.
LGTM.
https://github.com/llvm/llvm-project/pull/115716
_
DavidSpickett wrote:
Abandoning in favour of your patch, thanks!
https://github.com/llvm/llvm-project/pull/115288
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/DavidSpickett updated
https://github.com/llvm/llvm-project/pull/114807
>From fb436219e527f4de3cc4ce35eb3b884b824924a3 Mon Sep 17 00:00:00 2001
From: David Spickett
Date: Mon, 4 Nov 2024 14:41:19 +
Subject: [PATCH 1/2] [lldb] Recommend Python 3.8 as the minimum Python vers
https://github.com/DavidSpickett closed
https://github.com/llvm/llvm-project/pull/115288
___
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/109643
___
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.
Caused by https://github.com/llvm/llvm-project/pull/108504.
Thanks for the fix.
https://github.com/llvm/llvm-project/pull/109643
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
htt
https://github.com/DavidSpickett closed
https://github.com/llvm/llvm-project/pull/108996
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/DavidSpickett updated
https://github.com/llvm/llvm-project/pull/109427
>From cc4032e58217a01ff414b8d03866a1631f492df8 Mon Sep 17 00:00:00 2001
From: David Spickett
Date: Fri, 20 Sep 2024 14:00:44 +0100
Subject: [PATCH 1/3] [lldb][docs] Resurrect the information on adding a ne
@@ -0,0 +1,94 @@
+# Adding Programming Language Support
+
+LLDB has been architected to make it straightforward to add support for a
+programming language. Only a small enum in core LLDB needs to be modified to
+make LLDB aware of a new programming language. Everything else can be
@@ -0,0 +1,94 @@
+# Adding Programming Language Support
+
+LLDB has been architected to make it straightforward to add support for a
+programming language. Only a small enum in core LLDB needs to be modified to
+make LLDB aware of a new programming language. Everything else can be
https://github.com/DavidSpickett updated
https://github.com/llvm/llvm-project/pull/109427
>From cc4032e58217a01ff414b8d03866a1631f492df8 Mon Sep 17 00:00:00 2001
From: David Spickett
Date: Fri, 20 Sep 2024 14:00:44 +0100
Subject: [PATCH 1/2] [lldb][docs] Resurrect the information on adding a ne
@@ -0,0 +1,95 @@
+# Adding Programming Language Support
+
+LLDB has been architected to make it straightforward to add support for a
+programming language. Only a small enum in core LLDB needs to be modified to
+make LLDB aware of a new programming language. Everything else can be
@@ -0,0 +1,95 @@
+# Adding Programming Language Support
+
+LLDB has been architected to make it straightforward to add support for a
+programming language. Only a small enum in core LLDB needs to be modified to
+make LLDB aware of a new programming language. Everything else can be
@@ -0,0 +1,95 @@
+# Adding Programming Language Support
+
+LLDB has been architected to make it straightforward to add support for a
+programming language. Only a small enum in core LLDB needs to be modified to
+make LLDB aware of a new programming language. Everything else can be
DavidSpickett wrote:
> I think this page leaves a lot to be desired but it's a good start.
Given that language support runs from:
* Pretend it's C++ and hope (Rust) to -
* Have an entire llvm fork (Swift).
The documentation is never going to be great, this is true. Next time a
language is adde
DavidSpickett wrote:
ping!
https://github.com/llvm/llvm-project/pull/106695
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
DavidSpickett wrote:
ping!
https://github.com/llvm/llvm-project/pull/108365
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
DavidSpickett wrote:
Yes working to the standard is good, but in the minority of cases where you do
get a strange errno, `GDB_EUNKNOWN` is zero help and then you're working out
the `lldb-server gdbserver --log-channels` etc. command to get it to print the
real number.
So far that hasn't been
https://github.com/DavidSpickett created
https://github.com/llvm/llvm-project/pull/110104
None
>From 58911927a59557aab167792f62f2c9ba9a86fa0d Mon Sep 17 00:00:00 2001
From: David Spickett
Date: Thu, 29 Aug 2024 16:18:56 +0100
Subject: [PATCH] [lldb][AArch64] Read fpmr register from core files
https://github.com/DavidSpickett edited
https://github.com/llvm/llvm-project/pull/110104
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -61,3 +65,19 @@ def test_fpmr_register(self):
# 0 means the program found the new value in the sysreg as expected.
self.expect("continue", substrs=["exited with status = 0"])
+
+@skipIfLLVMTargetMissing("AArch64")
+def test_fpmr_register_core(self):
https://github.com/DavidSpickett updated
https://github.com/llvm/llvm-project/pull/110104
>From 58911927a59557aab167792f62f2c9ba9a86fa0d Mon Sep 17 00:00:00 2001
From: David Spickett
Date: Thu, 29 Aug 2024 16:18:56 +0100
Subject: [PATCH 1/2] [lldb][AArch64] Read fpmr register from core files
-
DavidSpickett wrote:
Last one for FPMR. I'll push the release notes directly.
Thanks for reviewing!
https://github.com/llvm/llvm-project/pull/110104
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listi
https://github.com/DavidSpickett closed
https://github.com/llvm/llvm-project/pull/109934
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/DavidSpickett updated
https://github.com/llvm/llvm-project/pull/109427
>From cc4032e58217a01ff414b8d03866a1631f492df8 Mon Sep 17 00:00:00 2001
From: David Spickett
Date: Fri, 20 Sep 2024 14:00:44 +0100
Subject: [PATCH 1/4] [lldb][docs] Resurrect the information on adding a ne
https://github.com/DavidSpickett closed
https://github.com/llvm/llvm-project/pull/108365
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
DavidSpickett wrote:
Landing this, post commit comments welcome as usual.
https://github.com/llvm/llvm-project/pull/108365
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
1901 - 2000 of 2869 matches
Mail list logo
