DavidSpickett wrote:
Yes please.
https://github.com/llvm/llvm-project/pull/137515
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Author: David Spickett
Date: 2025-05-09T10:31:17Z
New Revision: fd8b84ea0fa1eb1da105257f419d926278dc0445
URL:
https://github.com/llvm/llvm-project/commit/fd8b84ea0fa1eb1da105257f419d926278dc0445
DIFF:
https://github.com/llvm/llvm-project/commit/fd8b84ea0fa1eb1da105257f419d926278dc0445.diff
LOG
https://github.com/DavidSpickett created
https://github.com/llvm/llvm-project/pull/139251
These are currently failing on Windows on Arm:
https://lab.llvm.org/buildbot/#/builders/141/builds/8556
Unresolved Tests (1):
lldb-api :: tools/lldb-dap/memory/TestDAP_memory.py
https://github.com/DavidSpickett edited
https://github.com/llvm/llvm-project/pull/139251
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
DavidSpickett wrote:
@JDevlieghere FYI.
I realise this is not the most helpful or informative action to take, but
Linaro folks will be busy with other things next week so I want this bot green
again soon.
If you need us to investigate locally I can do that but it'll be the week of
the 19th b
DavidSpickett wrote:
At this time there is no pre-merge CI for Arm. If you feel like hacking
something together, it is possible to use Github's Runners to test it on your
own fork. I hope to make that route more user friendly at some point, and
expand the automatic CI to Arm when we can.
Fix
DavidSpickett wrote:
That would be great if you can, there isn't one in that folder right now but
you can find another elsewhere, or add a new file. I didn't want to go changing
all the check lines myself in case I broke something.
https://github.com/llvm/llvm-project/pull/137515
_
DavidSpickett wrote:
Seems fine, my only question is does the source actually need to be doing this
much?
Or in other words: the example should be as complex as it needs to be to show
the bug. If that means just calling the same do-nothing function over and over
to create more lines, that wou
DavidSpickett wrote:
I've
[skipped](https://github.com/llvm/llvm-project/commit/fd8b84ea0fa1eb1da105257f419d926278dc0445)
the new tests on Windows because we don't have the headers the sigchld example
uses.
(no notification of the failure was sent because we were already failing some
lldb-da
@@ -0,0 +1,57 @@
+## Test that `list header.h:` works correctly when header is available.
+##
+# RUN: split-file %s %t
+
+# RUN: %clang_host -g %t/main_with_inlined.cc %t/foo.cc -o
%t/main_with_inlined.out
+# RUN: %clang_host -g %t/main_no_inlined.cc %t/foo.cc -o %t/main_no_inli
@@ -0,0 +1,57 @@
+## Test that `list header.h:` works correctly when header is available.
+##
+# RUN: split-file %s %t
+
+# RUN: %clang_host -g %t/main_with_inlined.cc %t/foo.cc -o
%t/main_with_inlined.out
+# RUN: %clang_host -g %t/main_no_inlined.cc %t/foo.cc -o %t/main_no_inli
@@ -735,14 +735,25 @@ size_t ValueObject::GetPointeeData(DataExtractor &data,
uint32_t item_idx,
case eAddressTypeLoad: {
ExecutionContext exe_ctx(GetExecutionContextRef());
Process *process = exe_ctx.GetProcessPtr();
- if (process) {
+ if (process &&
https://github.com/DavidSpickett commented:
Surprised no one found this sooner, thanks for contributing.
https://github.com/llvm/llvm-project/pull/139196
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/l
DavidSpickett wrote:
Could already checked in core files be used for this test? I assume not but
please confirm. We like to avoid checked in binaries if we can.
I think we need the core and the program file because the program file tells us
the address of `F`
https://github.com/DavidSpickett edited
https://github.com/llvm/llvm-project/pull/139196
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -735,14 +735,25 @@ size_t ValueObject::GetPointeeData(DataExtractor &data,
uint32_t item_idx,
case eAddressTypeLoad: {
ExecutionContext exe_ctx(GetExecutionContextRef());
Process *process = exe_ctx.GetProcessPtr();
- if (process) {
+ if (process &&
@@ -977,6 +977,33 @@ def test_get_core_file_api(self):
self.assertEqual(process.GetCoreFile().GetFilename(), core_file_name)
self.dbg.DeleteTarget(target)
+@skipIfLLVMTargetMissing("X86")
+def test_ro_cstring(self):
DavidSpickett wrote:
DavidSpickett wrote:
Also FYI this has CI failures,
https://buildkite.com/llvm-project/github-pull-requests/builds/177176#0196b180-e7c0-49e9-99ac-65dcc8a3c1a9,
not sure if you are aware.
LLDB isn't known for being super stable in pre-commit CI, but they are on the
same topic as this.
https:/
DavidSpickett wrote:
You can include your gist content in the PR summary, I've certainly seen longer
commit messages than that in llvm :)
The question I want to be able to answer from the final commit message is "what
is a dead process and how do I make one?". So that in future if I need to
i
DavidSpickett wrote:
And these were made using source code that's already checked in I assume?
https://github.com/llvm/llvm-project/pull/139196
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.l
@@ -0,0 +1,65 @@
+#!/usr/bin/env python3
+# Usage: convert-lldb-header-to-rpc-header.py
+# This scripts takes common LLDB headers (such as lldb-defines.h) and replaces
references to LLDB
+# with those for RPC. This happens for:
+# - namespace definitions
+# - namespace usage
+
https://github.com/DavidSpickett approved this pull request.
Sure, let's give this a go now.
(rather than end of week for a potential weekend of red)
https://github.com/llvm/llvm-project/pull/138791
___
lldb-commits mailing list
lldb-commits@lists.llv
https://github.com/DavidSpickett requested changes to this pull request.
Actually the launch sequence changes are breaking Windows tests. I need to see
that all green first.
https://github.com/llvm/llvm-project/pull/138791
___
lldb-commits mailing lis
DavidSpickett wrote:
We have failing tests on Windows after this. Latest result at this time is:
```
Unresolved Tests (2):
lldb-api :: tools/lldb-dap/completions/TestDAP_completions.py
lldb-api :: tools/lldb-dap/startDebugging/TestDAP_startDebugging.py
***
DavidSpickett wrote:
> I also needed to remove the brk #0xf000 instruction because lldb is not able
> to step over it -- it just ends up spinning forever. FWICS, it's not actually
> necessary now that you're stepping through the test. Nonetheless, this is a
> bug -- one that @DavidSpickett mig
DavidSpickett wrote:
I think there are kernel issues that need to be fixed before all the LLDB
features can work. So don't waste your own time on this right now, I will
coordinate with Arm's kernel team to get this working.
https://github.com/llvm/llvm-project/pull/135563
_
https://github.com/DavidSpickett edited
https://github.com/llvm/llvm-project/pull/141063
___
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/141063
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -93,13 +93,6 @@ function(add_lldb_library name)
set(libkind STATIC)
endif()
- #PIC not needed on Win
- # FIXME: Setting CMAKE_CXX_FLAGS here is a no-op, use target_compile_options
DavidSpickett wrote:
Do we in fact use target_compile_options? Or do
@@ -0,0 +1,57 @@
+// clang-format off
+
+// REQUIRES: target-windows
+// RUN: %build --compiler=clang-cl -o %t.exe --std c++20 -- %s
+// RUN: env LLDB_USE_NATIVE_PDB_READER=1 %lldb -f %t.exe -o "b main" -o "run"
-o "fr v" -o c | FileCheck %s
+
+#include
DavidSpi
@@ -93,13 +93,6 @@ function(add_lldb_library name)
set(libkind STATIC)
endif()
- #PIC not needed on Win
- # FIXME: Setting CMAKE_CXX_FLAGS here is a no-op, use target_compile_options
DavidSpickett wrote:
Sounds reasonable, I've been bitten by distro c
https://github.com/DavidSpickett approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/141063
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -100,29 +100,25 @@ function(add_lldb_library name)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fPIC")
DavidSpickett wrote:
Should you remove OBJECT from:
```
cmake_parse_arguments(PARAM
"MODULE;SHARED;STATIC;OBJECT;PLUGIN;FRAMEWORK;NO_INTERNAL_DEPENDE
@@ -100,29 +100,25 @@ function(add_lldb_library name)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fPIC")
DavidSpickett wrote:
> And even if they did, llvm_add_library should know how to handle that.
Oh is this why you left those bits in?
https://github.com/ll
@@ -100,29 +100,25 @@ function(add_lldb_library name)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fPIC")
DavidSpickett wrote:
Also the bit:
```
elseif (PARAM_OBJECT)
set(libkind OBJECT)
```
https://github.com/llvm/llvm-project/pull/141066
DavidSpickett wrote:
This is failing on Windows on Arm, started here:
https://lab.llvm.org/buildbot/#/builders/141/builds/8891
```
AssertionError: False is not true : breakpoint not hit,
stopped_events=[{'body': {'exitCode': 0}, 'event': 'exited', 'seq': 0, 'type':
'event'}]
Config=aarch64-C:
Author: David Spickett
Date: 2025-05-22T09:48:31Z
New Revision: c82b30c13463073b359695a83d1dc1b7fc1c8088
URL:
https://github.com/llvm/llvm-project/commit/c82b30c13463073b359695a83d1dc1b7fc1c8088
DIFF:
https://github.com/llvm/llvm-project/commit/c82b30c13463073b359695a83d1dc1b7fc1c8088.diff
LOG
DavidSpickett wrote:
Looks like a Windows/PDB/COFF vs. Linux/DWARF/ELF difference. We can't break on
a function when there's no debug information. It's not due to the architecture.
So if you feel like coming up with a hack to make it work, the failure should
reproduce on x64 Windows as well. P
DavidSpickett wrote:
Such a hack might be breaking on a place that does have debug information and
stepping into one that doesn't, then placing a breakpoint on subsequent
assembly lines. Might be. Didn't try it because it seemed like it might defeat
the point of the test as it wouldn't place t
@@ -0,0 +1,592 @@
+//===-- RPCServerSourceEmitter.cpp
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Ap
@@ -0,0 +1,241 @@
+# LLDB Maintainers
+
+This file is a list of the
[maintainers](https://llvm.org/docs/DeveloperPolicy.html#maintainers) for LLDB.
+
+## Current Maintainers
+
+The following people are the active maintainers for the project. Please reach
out to them for code rev
https://github.com/DavidSpickett approved this pull request.
LGTM.
I got us to a point where every file in llvm-project is `Maintainers.*` but
didn't have the appetite to make them all Markdown yet.
https://github.com/llvm/llvm-project/pull/140958
__
DavidSpickett wrote:
Let's see what I find first, sometimes these things are quite simple to fix.
https://github.com/llvm/llvm-project/pull/139969
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo
@@ -444,6 +461,88 @@ NativeProcessLinux::NativeProcessLinux(::pid_t pid, int
terminal_fd,
SetState(StateType::eStateStopped, false);
}
+llvm::Expected> NativeProcessLinux::Seize(::pid_t pid) {
+ Log *log = GetLog(POSIXLog::Process);
+
+ uint64_t options = GetDefaultPtrace
@@ -444,6 +461,88 @@ NativeProcessLinux::NativeProcessLinux(::pid_t pid, int
terminal_fd,
SetState(StateType::eStateStopped, false);
}
+llvm::Expected> NativeProcessLinux::Seize(::pid_t pid) {
+ Log *log = GetLog(POSIXLog::Process);
+
+ uint64_t options = GetDefaultPtrace
@@ -444,6 +461,88 @@ NativeProcessLinux::NativeProcessLinux(::pid_t pid, int
terminal_fd,
SetState(StateType::eStateStopped, false);
}
+llvm::Expected> NativeProcessLinux::Seize(::pid_t pid) {
+ Log *log = GetLog(POSIXLog::Process);
+
+ uint64_t options = GetDefaultPtrace
@@ -444,6 +461,88 @@ NativeProcessLinux::NativeProcessLinux(::pid_t pid, int
terminal_fd,
SetState(StateType::eStateStopped, false);
}
+llvm::Expected> NativeProcessLinux::Seize(::pid_t pid) {
+ Log *log = GetLog(POSIXLog::Process);
+
+ uint64_t options = GetDefaultPtrace
@@ -312,10 +312,27 @@ NativeProcessLinux::Manager::Attach(
Log *log = GetLog(POSIXLog::Process);
LLDB_LOG(log, "pid = {0:x}", pid);
- auto tids_or = NativeProcessLinux::Attach(pid);
- if (!tids_or)
-return tids_or.takeError();
- ArrayRef<::pid_t> tids = *tids_or;
+
https://github.com/DavidSpickett edited
https://github.com/llvm/llvm-project/pull/137041
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/DavidSpickett commented:
I leave the discussion of race conditions or lack of to @labath .
https://github.com/llvm/llvm-project/pull/137041
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mail
@@ -444,6 +461,88 @@ NativeProcessLinux::NativeProcessLinux(::pid_t pid, int
terminal_fd,
SetState(StateType::eStateStopped, false);
}
+llvm::Expected> NativeProcessLinux::Seize(::pid_t pid) {
+ Log *log = GetLog(POSIXLog::Process);
+
+ uint64_t options = GetDefaultPtrace
@@ -444,6 +461,88 @@ NativeProcessLinux::NativeProcessLinux(::pid_t pid, int
terminal_fd,
SetState(StateType::eStateStopped, false);
}
+llvm::Expected> NativeProcessLinux::Seize(::pid_t pid) {
+ Log *log = GetLog(POSIXLog::Process);
+
+ uint64_t options = GetDefaultPtrace
@@ -444,6 +461,88 @@ NativeProcessLinux::NativeProcessLinux(::pid_t pid, int
terminal_fd,
SetState(StateType::eStateStopped, false);
}
+llvm::Expected> NativeProcessLinux::Seize(::pid_t pid) {
+ Log *log = GetLog(POSIXLog::Process);
+
+ uint64_t options = GetDefaultPtrace
@@ -0,0 +1,592 @@
+//===-- RPCServerSourceEmitter.cpp
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Ap
@@ -0,0 +1,592 @@
+//===-- RPCServerSourceEmitter.cpp
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Ap
https://github.com/DavidSpickett commented:
A couple of comments to be addressed but otherwise I have no problems with this.
https://github.com/llvm/llvm-project/pull/138032
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.o
DavidSpickett wrote:
Sounds sensible. If docker has bundled the fixed kernel, then that's most of
the M4 users covered and anyone else can update their kernel.
https://github.com/llvm/llvm-project/pull/135563
___
lldb-commits mailing list
lldb-commits
DavidSpickett wrote:
So if you have code that wants to use SVE2 and may run on an SME only device
with this older kernel, I think you could make it check for HWCAP_SVE and
HWCAP2_SVE2. As the Architecture manual says:
```
FEAT_SVE2, Scalable Vector Extension version 2
<...>
If FEAT_SVE2 is impl
DavidSpickett wrote:
I checked cpuinfo and hwcaps for 6.5 (doesn't have the fix) and 6.15 (does, and
it was what I was using anyway). Same machine configuration, SME only.
```
$ uname -a
Linux e125016 6.5.0 #6 SMP PREEMPT Tue May 20 09:43:29 UTC 2025 aarch64 aarch64
aarch64 GNU/Linux
Features
https://github.com/DavidSpickett edited
https://github.com/llvm/llvm-project/pull/139916
___
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/139916
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
DavidSpickett wrote:
1. This went in without tests, intentional?
2. Seems like a release note worthy feature.
https://github.com/llvm/llvm-project/pull/115408
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mail
https://github.com/DavidSpickett created
https://github.com/llvm/llvm-project/pull/140875
Recently the Linux Kernel has fixed a bunch of issues in SME support and while
testing that, I found two tests failing: FAIL:
test_za_register_dynamic_config_main_disabled
(TestZAThreadedDynamic.AArch64Z
https://github.com/DavidSpickett edited
https://github.com/llvm/llvm-project/pull/140875
___
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/140875
___
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/140875
___
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/137041
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
DavidSpickett wrote:
Candidates for how it ever worked:
* Out of bounds write managing to break something else in just the right way.
Then adding new extension registers meant it was invalidating registers again,
probably guarded control stack registers.
* LLDB got less aggressive about re-read
DavidSpickett wrote:
> I added my gist to the description, let me know what you think
This part looks good, that'll be enough to test this / explain why it exists.
https://github.com/llvm/llvm-project/pull/137041
___
lldb-commits mailing list
lldb-com
DavidSpickett wrote:
The reasoning is fine but I'm pretty sure there's an existing way to write this
skipif, let me look for it.
https://github.com/llvm/llvm-project/pull/141407
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.l
https://github.com/DavidSpickett edited
https://github.com/llvm/llvm-project/pull/141122
___
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/141122
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Author: David Spickett
Date: 2025-05-27T11:39:50Z
New Revision: f30a85b7005cb332b88d91dfe9ef094ef6249bd9
URL:
https://github.com/llvm/llvm-project/commit/f30a85b7005cb332b88d91dfe9ef094ef6249bd9
DIFF:
https://github.com/llvm/llvm-project/commit/f30a85b7005cb332b88d91dfe9ef094ef6249bd9.diff
LOG
https://github.com/DavidSpickett closed
https://github.com/llvm/llvm-project/pull/141407
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -11,7 +11,7 @@ image show-unwind -n func0
# CHECK-NEXT: This UnwindPlan is sourced from the compiler: yes.
# CHECK-NEXT: This UnwindPlan is valid at all instruction locations: no.
# CHECK-NEXT: This UnwindPlan is for a trap handler function: no.
-# CHECK-NEXT: Address range
https://github.com/DavidSpickett approved this pull request.
LGTM.
https://github.com/llvm/llvm-project/pull/141062
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -16,12 +15,61 @@
namespace lldb_dap {
+static llvm::Expected
+HandleDataBreakpointBytes(DAP &dap,
+ const protocol::DataBreakpointInfoArguments &args) {
+ llvm::StringRef address = args.name;
+
+ unsigned long long load_addr = LLDB_INVALID_ADDRES
@@ -16,12 +15,61 @@
namespace lldb_dap {
+static llvm::Expected
+HandleDataBreakpointBytes(DAP &dap,
+ const protocol::DataBreakpointInfoArguments &args) {
+ llvm::StringRef address = args.name;
+
+ unsigned long long load_addr = LLDB_INVALID_ADDRES
DavidSpickett wrote:
I see the magic exit value listed in
https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-erref/596a1078-e883-4972-9bbc-49e60bebca55.
I wondered if we could say "exited with NTSTATUS ", but I'm not sure if
all exit codes in this scenario would be NTSATUS or onl
@@ -16,12 +15,61 @@
namespace lldb_dap {
+static llvm::Expected
+HandleDataBreakpointBytes(DAP &dap,
+ const protocol::DataBreakpointInfoArguments &args) {
+ llvm::StringRef address = args.name;
+
+ unsigned long long load_addr = LLDB_INVALID_ADDRES
@@ -0,0 +1,22 @@
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+
+class MissingDllTestCase(TestBase):
+@skipUnlessWindows
+def test(self):
DavidSpickett wrote:
Add a doc
DavidSpickett wrote:
I've pushed it directly to get the bot green:
https://github.com/llvm/llvm-project/commit/f30a85b7005cb332b88d91dfe9ef094ef6249bd9
Thanks for figuring out the reason for the failure.
https://github.com/llvm/llvm-project/pull/141407
__
https://github.com/DavidSpickett approved this pull request.
LGTM. This is a nice improvement thanks for working on it.
https://github.com/llvm/llvm-project/pull/141290
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cg
DavidSpickett wrote:
This looks like a good candidate for a [release
note](https://github.com/llvm/llvm-project/blob/main/llvm/docs/ReleaseNotes.md#changes-to-lldb).
You can add that here or in a follow up PR.
https://github.com/llvm/llvm-project/pull/140150
___
DavidSpickett wrote:
> That's the part where I'm not sure either
This PR is strictly better than before, so it's fine as it is.
https://github.com/llvm/llvm-project/pull/141290
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.ll
DavidSpickett wrote:
@asb might have a IRSC-V Linux system handy to generate a core file from.
`lldb/test/API/functionalities/postmortem/elf-core/main_fpr.c` would cover GPR
and FPR, I think that's all we need here. It can be added to
`lldb/test/API/functionalities/postmortem/elf-core/TestLinu
2801 - 2886 of 2886 matches
Mail list logo
