DavidSpickett wrote:
> In a very ideal world, I would love if we could not strip anything, ever. But
> this places some burden on codegen of the expression evaluator, for all
> languages and all ABIs. I don't think it's doable right now.
Yes we're getting into a pointers as capabilities sort o
https://github.com/DavidSpickett created
https://github.com/llvm/llvm-project/pull/157435
First added in #153585 for Darwin only. All Linux AArch64 systems also have Top
Byte Ignore enabled in userspace so the test "just works" there.
FreeBSD has very recently gained Top Byte Ignore support:
https://github.com/DavidSpickett closed
https://github.com/llvm/llvm-project/pull/159790
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
DavidSpickett wrote:
s390x is the other big endian target, I have no idea what its vectors do.
https://github.com/llvm/llvm-project/pull/155000
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/ll
https://github.com/DavidSpickett created
https://github.com/llvm/llvm-project/pull/159559
As is done for other procfile tests.
>From 959edbe1add44159d473602d4151cf533cac4050 Mon Sep 17 00:00:00 2001
From: David Spickett
Date: Thu, 18 Sep 2025 12:51:55 +0100
Subject: [PATCH] [lldb][test] Disabl
DavidSpickett wrote:
The tests are stable on 32-bit Arm with this applied.
https://github.com/llvm/llvm-project/pull/159444
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
DavidSpickett wrote:
I assume this is fallout from
https://discourse.llvm.org/t/rfc-should-we-omit-local-symbols-in-elf-files-from-the-lldb-symbol-table/87384.
Which I have no context for but I'll add some of those folks on review.
https://github.com/llvm/llvm-project/pull/158551
_
@@ -293,6 +293,9 @@ void RegisterContextUnwind::InitializeZerothFrame() {
return;
}
+ // Give the Architecture a chance to replace the UnwindPlan.
+ AdoptArchitectureUnwindPlan();
DavidSpickett wrote:
Thanks for explaining.
https://github.com/llvm/ll
https://github.com/DavidSpickett closed
https://github.com/llvm/llvm-project/pull/159542
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Author: David Spickett
Date: 2025-09-15T08:48:04Z
New Revision: 757bb36a58c7d7151a28c6a5fc7caa2e1f44de87
URL:
https://github.com/llvm/llvm-project/commit/757bb36a58c7d7151a28c6a5fc7caa2e1f44de87
DIFF:
https://github.com/llvm/llvm-project/commit/757bb36a58c7d7151a28c6a5fc7caa2e1f44de87.diff
LOG
DavidSpickett wrote:
Also you'd probably save a bunch of time by doing one giant test that checks
all the little MTE additions in one go, maybe that is in fact your plan.
https://github.com/llvm/llvm-project/pull/159117
___
lldb-commits mailing list
l
https://github.com/DavidSpickett edited
https://github.com/llvm/llvm-project/pull/147990
___
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/157432
>From c0f08a5823327e83f17e921e65d6234ce98fce6b Mon Sep 17 00:00:00 2001
From: David Spickett
Date: Mon, 8 Sep 2025 11:41:33 +
Subject: [PATCH 1/2] [lldb][test] Prevent TestqOffsets.py picking up host
DavidSpickett wrote:
I forgot all about https://github.com/llvm/llvm-project/pull/157435 so I just
merged it and you'll have conflicts from that.
You don't have to make the test work on Linux, `if Darwin` is fine and extend
it later.
In an ideal world, we would know that the target has memory
DavidSpickett wrote:
A more generic term might be "significant" bits, significant to what is what
people will wonder but at least it covers the bits significant to address
resolution, plus anything required to use the pointer in code.
Which could include the PAC code, if you had really particu
https://github.com/DavidSpickett created
https://github.com/llvm/llvm-project/pull/159790
Reverts llvm/llvm-project#158161
Due to reported failures on remote Linux and Swift buildbots.
>From 9907ef2d116b893e0c3cce2cbf228ce52a82a285 Mon Sep 17 00:00:00 2001
From: David Spickett
Date: Fri, 19 S
DavidSpickett wrote:
"PreservingAccess" - though not every bit will be about access,
"PreservingPermissions" - these aren't really permissions as such, this is not
CHERI after all.
https://github.com/llvm/llvm-project/pull/159785
___
lldb-commits mai
https://github.com/DavidSpickett closed
https://github.com/llvm/llvm-project/pull/157435
___
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/159452
___
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/159523
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
DavidSpickett wrote:
I agree with the ultimate goal of being able to control the handling of
non-address bits, but help me understand this part:
> However, the CFA inside StackIDs is also used in other contexts through the
> method StackID::GetCallFrameAddress. One notable case is DWARFExpressi
https://github.com/DavidSpickett approved this pull request.
If this is required for the parent PR and that PR is eventually approved, this
LGTM.
Please add System Z to the listed systems in the PR description. That detail
may come in handy one day.
https://github.com/llvm/llvm-project/pull/1
https://github.com/DavidSpickett created
https://github.com/llvm/llvm-project/pull/159523
uintptr_t is usually a good idea when handling pointers, but lldb has to handle
64-bit addresses that might be from a remote system, on a 32-bit system.
So I've changed a few instances here to use addr_t
DavidSpickett wrote:
https://github.com/llvm/llvm-project/pull/159588 already fixed this.
https://github.com/llvm/llvm-project/pull/159375
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-co
https://github.com/DavidSpickett closed
https://github.com/llvm/llvm-project/pull/159375
___
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/159559
>From 959edbe1add44159d473602d4151cf533cac4050 Mon Sep 17 00:00:00 2001
From: David Spickett
Date: Thu, 18 Sep 2025 12:51:55 +0100
Subject: [PATCH 1/2] [lldb][test] Disable a procfile test when threading i
https://github.com/DavidSpickett closed
https://github.com/llvm/llvm-project/pull/159559
___
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/159542
This reverts the following commits:
a0a82ee19d6f2ff1013407ba4c973bfe5428423f
757bb36a58c7d7151a28c6a5fc7caa2e1f44de87
83b48b13f3a70bf56053e92593270c519859cfd7
b45f1fb377636a34c01e34b89341c97d19975554
d2e153
DavidSpickett wrote:
Landing this to fix the build, but @JDevlieghere please do give it a look.
https://github.com/llvm/llvm-project/pull/159523
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/l
https://github.com/DavidSpickett edited
https://github.com/llvm/llvm-project/pull/159523
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/DavidSpickett commented:
`ArchSpecValidator` starts instantiating a chain
of `ArchSpecValidator` until it gets to
`ArchSpecValidator` which does not inherit from
anything so it stops there.
`arm_generic` being the first core value and `wasm32` being the last. At least
righ
https://github.com/DavidSpickett commented:
My understanding:
* The ELF describes which extensions it is using.
* As the LLDB being used may not be linked with an LLVM that understands them
all, we have an allowlist of features we will read from the ELF.
And now I'm wondering what happens when
Author: David Spickett
Date: 2025-09-08T12:12:15Z
New Revision: e2d1bbebbb099c7010a31fad62a9128166ef14a0
URL:
https://github.com/llvm/llvm-project/commit/e2d1bbebbb099c7010a31fad62a9128166ef14a0
DIFF:
https://github.com/llvm/llvm-project/commit/e2d1bbebbb099c7010a31fad62a9128166ef14a0.diff
LOG
https://github.com/DavidSpickett created
https://github.com/llvm/llvm-project/pull/157432
Due to a fallback in GDBRemoteCommunicationClient.cpp, on Linux we will assume
a PID of 1 if the remote does not respond in some way that tells us the real
PID.
So if PID 1 happened to be a process that
DavidSpickett wrote:
Also this needs an entry in the release notes (llvm/docs/ReleaseNotes.md) and
something in the PR description about how it works for the user. Mentioning -Y
and the feature setting assuming it also works (make it work if it does not).
https://github.com/llvm/llvm-project/p
DavidSpickett wrote:
Also if we added an entry to one of these enums, would the "switch doesn't
cover value" warning still happen? I think it would right?
https://github.com/llvm/llvm-project/pull/159327
___
lldb-commits mailing list
lldb-commits@list
https://github.com/DavidSpickett approved this pull request.
> the root cause here is that GCC assumes that an enum variable still
> technically can have any value outside of the enum
Ok, I forgot about this aspect.
LGTM.
https://github.com/llvm/llvm-project/pull/159327
__
https://github.com/DavidSpickett created
https://github.com/llvm/llvm-project/pull/159395
Since #157170 this test has been flakey on several LLDB buildbots. I suspect
it's to do with mutli-threading, there are more details in #159377.
Disable parallel loading for now so we are not spamming peo
DavidSpickett wrote:
To prevent any confusion working on fixing that issue, I will leave this PR
open until the issue is resolved.
https://github.com/llvm/llvm-project/pull/159375
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists
https://github.com/DavidSpickett closed
https://github.com/llvm/llvm-project/pull/159395
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
DavidSpickett wrote:
This is unrelated to that since this fixes a Linux specific code path. The
failing tests are all NetBSD cores and I confirmed we're not calling the Linux
code accidentally there.
https://github.com/llvm/llvm-project/pull/159375
_
https://github.com/DavidSpickett approved this pull request.
Great find! I had noticed that lldb was slow to quit but I always thought it
would be something inherent to how things work on Windows.
https://github.com/llvm/llvm-project/pull/159308
___
l
https://github.com/DavidSpickett approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/159345
___
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/159375
https://github.com/llvm/llvm-project/pull/157170 added code that assigned
pr_fname to another std::string member.
In the lines before, we copy pr_fname using assign with a max length set to
either the le
DavidSpickett wrote:
Taking one as an example:
```
enum class FunctionNameRepresentation {
eName,
eNameWithArgs,
eNameWithNoArgs
};
```
And we do have a return for each of the cases.
So it feels like a limitation in GCC's analysis, is that right or did they make
a decision to wa
DavidSpickett wrote:
> How will this be tested?
And I don't care about re-using the existing MTE tests so much. A lot of them
do tricks like assuming mmap calls will produce memory in a certain sequence
that are likely not portable or even stable to begin with :)
https://github.com/llvm/llvm-
@@ -77,6 +77,35 @@ static void DescribeAddressBriefly(Stream &strm, const
Address &addr,
strm.Printf(".\n");
}
+static constexpr uint8_t g_mte_tag_shift = 64 - 8;
+static constexpr uintptr_t g_mte_tag_mask = (uintptr_t)0x0f << g_mte_tag_shift;
+
+bool StopInfoMachException:
DavidSpickett wrote:
The Linux version for reference -
https://github.com/llvm/llvm-project/commit/d510b5f199d6e7a3062b5a6ea43181c4cc00a605
Which uses the tag manager to handle all the masking. Though it appears to be
lldb-server side, I'm not sure if this Mach bit is. What's the plan for
han
https://github.com/DavidSpickett closed
https://github.com/llvm/llvm-project/pull/158906
___
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/158906
Flakey on Windows on Arm:
https://lab.llvm.org/buildbot/#/builders/141/builds/11540
See #137660
>From 38b081dca6952783c1064527e227e3c6195fa552 Mon Sep 17 00:00:00 2001
From: David Spickett
Date: Tue, 16
https://github.com/DavidSpickett approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/158559
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -1284,6 +1285,54 @@
ObjectFileELF::RefineModuleDetailsFromNote(lldb_private::DataExtractor &data,
return error;
}
+void ObjectFileELF::ParseRISCVAttributes(DataExtractor &data, uint64_t length,
+ ArchSpec &arch_spec) {
+ lldb::off
DavidSpickett wrote:
Sounds likely:
https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/fopen-wfopen?view=msvc-170
> In text mode, carriage return-line feed (CRLF) combinations are translated
> into single line feed (LF) characters on input, and LF characters are
> translated t
@@ -34,6 +36,7 @@ config.have_lldb_server = @LLDB_TOOL_LLDB_SERVER_BUILD@
config.lldb_system_debugserver = @LLDB_USE_SYSTEM_DEBUGSERVER@
config.llvm_use_sanitizer = "@LLVM_USE_SANITIZER@"
config.lldb_has_lldbrpc = @LLDB_BUILD_LLDBRPC@
+config.have_dia_sdk = lit.util.pythonize_b
https://github.com/DavidSpickett approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/158284
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/DavidSpickett commented:
Agree with the idea, thanks for continuing to work on this topic.
https://github.com/llvm/llvm-project/pull/158284
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mail
Author: David Spickett
Date: 2025-09-12T10:21:04Z
New Revision: 83b48b13f3a70bf56053e92593270c519859cfd7
URL:
https://github.com/llvm/llvm-project/commit/83b48b13f3a70bf56053e92593270c519859cfd7
DIFF:
https://github.com/llvm/llvm-project/commit/83b48b13f3a70bf56053e92593270c519859cfd7.diff
LOG
https://github.com/DavidSpickett edited
https://github.com/llvm/llvm-project/pull/158284
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
DavidSpickett wrote:
> remote-gdb-server
That though, might skip dyld altogether.
https://github.com/llvm/llvm-project/pull/157432
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
DavidSpickett wrote:
Ultimately I won't be casting the deciding vote here as I don't work with
RISC-V systems. Someone from Apple or perhaps others like @dlav-sc who do use
them should have the final approvals.
https://github.com/llvm/llvm-project/pull/147990
__
@@ -0,0 +1,10 @@
+# REQUIRES: target=riscv32-{{.*}}
+
+# RUN: %lldb -b -o "disassemble -b -n main" %p/Inputs/riscv_xqci.out |
FileCheck %s
+
+# CHECK: 051f 0058 qc.e.li a0, 0x58
+# CHECK: 1516 qc.extu a0, a0, 0x6, 0x0
+
+# RUN: %lldb -b -o "disassemble -b -n ma
@@ -0,0 +1,51 @@
+"""
+Test that we can backtrace up an ARM Cortex-M Exception return stack
+"""
+
+import lldb
+import json
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+
+class TestCortexMExceptionUnwind(T
https://github.com/DavidSpickett closed
https://github.com/llvm/llvm-project/pull/157432
___
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, thanks.
https://github.com/llvm/llvm-project/pull/157566
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
DavidSpickett wrote:
> Python 3.8 is EOL since over a year, and python 3.9 will be EOL in a month.
> The better solution would be to not keep using python past its upstream
> lifecycle of 5 years, which should be plenty for tip-of-tree.
I don't have the time to propose an update myself right n
DavidSpickett wrote:
> The one significant choice that we haven't agreed on at this point is whether
> Architecture::GetArchitectureUnwindPlan should return an empty UnwindPlanSP
> to indicate no override, or if it should return the std::shared_ptr UnwindPlan> identical to its input if it indic
DavidSpickett wrote:
Might be fixed next build, I saw the Linux ones fail then go green right after.
https://github.com/llvm/llvm-project/pull/149827
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listi
https://github.com/DavidSpickett updated
https://github.com/llvm/llvm-project/pull/157435
>From 528fbe2b518b586283ffa6ce93674dbf346687d7 Mon Sep 17 00:00:00 2001
From: David Spickett
Date: Mon, 8 Sep 2025 12:03:58 +
Subject: [PATCH 1/2] [lldb][test] Enable non-address bit WritePointerToMemo
@@ -0,0 +1,10 @@
+# REQUIRES: target=riscv32-{{.*}}
+
+# RUN: %lldb -b -o "disassemble -b -n main" %p/Inputs/riscv_xqci.out |
FileCheck %s
+
+# CHECK: 051f 0058 qc.e.li a0, 0x58
+# CHECK: 1516 qc.extu a0, a0, 0x6, 0x0
DavidSpickett wrote:
Mayb
https://github.com/DavidSpickett edited
https://github.com/llvm/llvm-project/pull/157432
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Author: David Spickett
Date: 2025-09-08T15:20:15Z
New Revision: b45f1fb377636a34c01e34b89341c97d19975554
URL:
https://github.com/llvm/llvm-project/commit/b45f1fb377636a34c01e34b89341c97d19975554
DIFF:
https://github.com/llvm/llvm-project/commit/b45f1fb377636a34c01e34b89341c97d19975554.diff
LOG
https://github.com/DavidSpickett edited
https://github.com/llvm/llvm-project/pull/157432
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
DavidSpickett wrote:
I'll try it but I have a suspicion we have code that says "anything on
localhost must be the host machine".
https://github.com/llvm/llvm-project/pull/157432
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.l
DavidSpickett wrote:
> would runCmd("platform select remote-linux") have the same effect?
This does work.
@tstellar can you confirm that this PR fixes the test for you?
https://github.com/llvm/llvm-project/pull/157432
___
lldb-commits mailing list
ll
Author: David Spickett
Date: 2025-09-08T12:39:07Z
New Revision: bf51a4df728fb5386b0305ce05353cf7e3eb3f01
URL:
https://github.com/llvm/llvm-project/commit/bf51a4df728fb5386b0305ce05353cf7e3eb3f01
DIFF:
https://github.com/llvm/llvm-project/commit/bf51a4df728fb5386b0305ce05353cf7e3eb3f01.diff
LOG
Author: David Spickett
Date: 2025-09-08T13:58:40Z
New Revision: d2e153981e62fb2ea781ef456ff744f9893e0733
URL:
https://github.com/llvm/llvm-project/commit/d2e153981e62fb2ea781ef456ff744f9893e0733
DIFF:
https://github.com/llvm/llvm-project/commit/d2e153981e62fb2ea781ef456ff744f9893e0733.diff
LOG
@@ -1593,6 +1620,13 @@ DisassemblerLLVMC::DisassemblerLLVMC(const ArchSpec
&arch,
features_str += "+a,+m,";
}
+ llvm::StringRef additional_features = arch.GetDisassemblyFeatures();
+ // Prepend the additional_features if it's not already in the features_str to
+ // a
@@ -1284,6 +1285,54 @@
ObjectFileELF::RefineModuleDetailsFromNote(lldb_private::DataExtractor &data,
return error;
}
+void ObjectFileELF::ParseRISCVAttributes(DataExtractor &data, uint64_t length,
+ ArchSpec &arch_spec) {
+ lldb::off
@@ -617,6 +617,13 @@ void ArchSpec::SetFlags(const std::string &elf_abi) {
SetFlags(flag);
}
+void ArchSpec::SetDisassemblyFeatures(std::string additional_features) {
DavidSpickett wrote:
This name is misleading. Set implies overwrite.
`AddDisassemblyFeatu
@@ -1446,6 +1446,33 @@ bool
DisassemblerLLVMC::MCDisasmInstance::IsAuthenticated(
return InstrDesc.isAuthenticated() || IsBrkC47x;
}
+void DisassemblerLLVMC::UpdateFeatureString(llvm::StringRef
additional_features,
+std::string &
https://github.com/DavidSpickett edited
https://github.com/llvm/llvm-project/pull/147990
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -1446,6 +1446,33 @@ bool
DisassemblerLLVMC::MCDisasmInstance::IsAuthenticated(
return InstrDesc.isAuthenticated() || IsBrkC47x;
}
+void DisassemblerLLVMC::UpdateFeatureString(llvm::StringRef
additional_features,
DavidSpickett wrote:
If this is only cal
@@ -1446,6 +1446,33 @@ bool
DisassemblerLLVMC::MCDisasmInstance::IsAuthenticated(
return InstrDesc.isAuthenticated() || IsBrkC47x;
}
+void DisassemblerLLVMC::UpdateFeatureString(llvm::StringRef
additional_features,
+std::string &
@@ -0,0 +1,10 @@
+# REQUIRES: target=riscv32-{{.*}}
+
+# RUN: %lldb -b -o "disassemble -b -n main" %p/Inputs/riscv_xqci.out |
FileCheck %s
+
+# CHECK: 051f 0058 qc.e.li a0, 0x58
+# CHECK: 1516 qc.extu a0, a0, 0x6, 0x0
DavidSpickett wrote:
Also
DavidSpickett wrote:
As in:
obj2yaml the file you have
yaml2obj and make the test work
cut bits out of the yaml
repeat until it's as small as you can reasonably get it
https://github.com/llvm/llvm-project/pull/147990
@@ -1446,6 +1446,33 @@ bool
DisassemblerLLVMC::MCDisasmInstance::IsAuthenticated(
return InstrDesc.isAuthenticated() || IsBrkC47x;
}
+void DisassemblerLLVMC::UpdateFeatureString(llvm::StringRef
additional_features,
+std::string &
@@ -1284,6 +1285,54 @@
ObjectFileELF::RefineModuleDetailsFromNote(lldb_private::DataExtractor &data,
return error;
}
+void ObjectFileELF::ParseRISCVAttributes(DataExtractor &data, uint64_t length,
DavidSpickett wrote:
`const DataExtractor &data` if you can
@@ -1593,6 +1620,13 @@ DisassemblerLLVMC::DisassemblerLLVMC(const ArchSpec
&arch,
features_str += "+a,+m,";
}
+ llvm::StringRef additional_features = arch.GetDisassemblyFeatures();
+ // Prepend the additional_features if it's not already in the features_str to
+ // a
@@ -0,0 +1,10 @@
+# REQUIRES: target=riscv32-{{.*}}
+
+# RUN: %lldb -b -o "disassemble -b -n main" %p/Inputs/riscv_xqci.out |
FileCheck %s
+
+# CHECK: 051f 0058 qc.e.li a0, 0x58
+# CHECK: 1516 qc.extu a0, a0, 0x6, 0x0
+
+# RUN: %lldb -b -o "disassemble -b -n ma
@@ -0,0 +1,10 @@
+# REQUIRES: target=riscv32-{{.*}}
+
+# RUN: %lldb -b -o "disassemble -b -n main" %p/Inputs/riscv_xqci.out |
FileCheck %s
DavidSpickett wrote:
There is also a setting:
```
target.disassembly-features -- Specify additional CPU features for
dis
DavidSpickett wrote:
I can confirm that AArch64 Neon and SVE work as stated:
> B2.9.3.2 Endianness in SIMD operations
>
> ...The four elements appear in the register in array order, with the
> lowest indexed element fetched from the lowest address. The order of bytes in
> the elements depends
https://github.com/DavidSpickett approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/155956
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
DavidSpickett wrote:
> With all those neat sequential values across the GPR registers, it's clear
> that the file was created artificially.
Yeah, so I was expecting to find some inline asm for that.
> The values in some of these registers would differ with each regeneration of
> the core file
DavidSpickett wrote:
> I'm not sure we can. The problem arises from transferring LLVM-IR values
> to/from the targets memory. If we don't have the target consuming/producing
> that memory then our test could just be consistently-wrong and pass anyway.
We can simulate a gdb-remote that's one of
DavidSpickett wrote:
> For testing the endianess, I'm not sure we have PPC LLDB buildbots that would
> test this
Debian will build PPC little endian once in a while and somewhere in the depths
of IBM there might be a machine but I've never seen a bug report from one.
Also not sure what endian
DavidSpickett wrote:
Same on Windows on Arm:
https://lab.llvm.org/buildbot/#/builders/141/builds/11277
```
TEST 'lldb-shell :: Process/UnsupportedLanguage.test'
FAILED
Exit Code: 1
Command Output (stdout):
--
# RUN: at line 3
c:\users\tcwg\llvm-worker
https://github.com/DavidSpickett edited
https://github.com/llvm/llvm-project/pull/156774
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -418,7 +418,7 @@ other command as far as there is only one alias command
match.");
if ((pos != std::string::npos) && (pos > 0))
raw_command_string = raw_command_string.substr(pos);
} else {
- result.AppendError("Error parsing command string. No alias
https://github.com/DavidSpickett approved this pull request.
LGTM
Remove the `@` mention in the description before merging, so that they don't
get spammed when this gets merged into forks.
https://github.com/llvm/llvm-project/pull/15
___
lldb-com
DavidSpickett wrote:
> from typing import List
Is this something we install or something that's included with Python 3.8+?
https://github.com/llvm/llvm-project/pull/156868
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.or
1 - 100 of 2243 matches
Mail list logo
