https://github.com/DavidSpickett edited
https://github.com/llvm/llvm-project/pull/130503
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -220,6 +220,8 @@ Changes to LLDB
information about the current state of the debugger at the bottom of the
terminal. This is on by default and can be configured using the
`show-statusline` and `statusline-format` settings.
+* LLDB now supports `process continue --revers
https://github.com/DavidSpickett approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/134204
___
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/132688
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
DavidSpickett wrote:
I think this https://github.com/llvm/llvm-project/issues/63468 is the same sort
of issue. Not sure if it's the same though.
As you can tell from me saying "I will get back to this" 2 years ago, the
knowledge of any of that has left my head by now, but thank you for looking
https://github.com/DavidSpickett approved this pull request.
LGTM
Could you append to the PR description a list of known issues e.g. the redraw
on tab complete?
It's discussed here in comments already but it's good to have a record of what
state we are at and what you have promised to address
@@ -0,0 +1,171 @@
+//===-- Statusline.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: Apac
DavidSpickett wrote:
> The tab complete issue is (should be?) fixed with the current state of this
> PR.
Cool! I did not check it again locally. If you're reasonably sure you've fixed
it then I trust you there :)
Go ahead and land this and I'll try my best to break it again at some point.
h
DavidSpickett wrote:
@JDevlieghere if I start lldb with no arguments:
```
david.spickett@tcwg-jade-03-dev:~/build-llvm-aarch64$ ./bin/lldb
<< cursor is here at the start of the line, but no (lldb) was printed
< the status bar>
```
Does not happen if I have a program file, but this is also strange
https://github.com/DavidSpickett edited
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
@@ -0,0 +1,100 @@
+## This test checks that lldb handles (corrupt?) debug info which has
improperly
+## nested blocks. The behavior here is not prescriptive. We only want to check
+## that we do something "reasonable".
+
+
+# RUN: llvm-mc -triple=x86_64-pc-linux -filetype=obj %s
@@ -0,0 +1,100 @@
+## This test checks that lldb handles (corrupt?) debug info which has
improperly
+## nested blocks. The behavior here is not prescriptive. We only want to check
DavidSpickett wrote:
Could you add comments somewhere in this file that note where
https://github.com/DavidSpickett commented:
The explanation of the previous handling makes my head spin, but the argument
that it never worked anyway is a good one. So I'm no expert, but I'm ok with
the intent based on that at least.
https://github.com/llvm/llvm-project/pull/117725
__
@@ -333,38 +333,11 @@ void Block::FinalizeRanges() {
void Block::AddRange(const Range &range) {
Block *parent_block = GetParent();
if (parent_block && !parent_block->Contains(range)) {
-Log *log = GetLog(LLDBLog::Symbols);
-if (log) {
- ModuleSP module_sp(m_par
@@ -333,38 +333,11 @@ void Block::FinalizeRanges() {
void Block::AddRange(const Range &range) {
Block *parent_block = GetParent();
if (parent_block && !parent_block->Contains(range)) {
-Log *log = GetLog(LLDBLog::Symbols);
-if (log) {
- ModuleSP module_sp(m_par
https://github.com/DavidSpickett edited
https://github.com/llvm/llvm-project/pull/133275
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
DavidSpickett wrote:
The above failure is legit, this is the relevant bit of the log:
```
FAIL: test_dwarf (lldbsuite.test.lldbtest.TestExternCSymbols.test_dwarf)
--
Traceback (most recent call last):
File
"C:\Users\tcwg\ll
https://github.com/DavidSpickett created
https://github.com/llvm/llvm-project/pull/134995
Reverts llvm/llvm-project#132274
Broke a test on LLDB Widows on Arm:
https://lab.llvm.org/buildbot/#/builders/141/builds/7726
```
FAIL: test_dwarf (lldbsuite.test.lldbtest.TestExternCSymbols.test_dwarf)
<.
https://github.com/DavidSpickett closed
https://github.com/llvm/llvm-project/pull/134995
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -185,6 +185,8 @@ def setUpServerLogging(self, is_llgs):
]
def get_next_port(self):
+if available_ports := self.getPlatformAvailablePorts():
+return int(random.choice(available_ports))
DavidSpickett wrote:
Once a test cho
DavidSpickett wrote:
This change is fine I just want to understand whether you'll still get test
cases competing for ports even with this option.
https://github.com/llvm/llvm-project/pull/112555
___
lldb-commits mailing list
lldb-commits@lists.llvm.or
@@ -292,6 +292,13 @@ def create_parser():
metavar="platform-working-dir",
help="The directory to use on the remote platform.",
)
+group.add_argument(
+"--platform-available-ports",
+dest="lldb_platform_available_ports",
+nargs="*"
@@ -292,6 +292,13 @@ def create_parser():
metavar="platform-working-dir",
help="The directory to use on the remote platform.",
)
+group.add_argument(
+"--platform-available-ports",
+dest="lldb_platform_available_ports",
+nargs="*"
Author: David Spickett
Date: 2025-04-08T12:17:07Z
New Revision: db7fb704f6d5337399172331b4ee46e846171061
URL:
https://github.com/llvm/llvm-project/commit/db7fb704f6d5337399172331b4ee46e846171061
DIFF:
https://github.com/llvm/llvm-project/commit/db7fb704f6d5337399172331b4ee46e846171061.diff
LOG
@@ -0,0 +1,39 @@
+"""
+Test SBTarget Read Instruction.
+"""
+
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+
+
+class TargetReadInstructionsFlavor(TestBase):
+@skipIf(archs=no_match(["x86_64", "x86", "i386"]), oslist=["windows"])
@@ -0,0 +1,39 @@
+"""
+Test SBTarget Read Instruction.
+"""
+
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+
+
+class TargetReadInstructionsFlavor(TestBase):
+@skipIf(archs=no_match(["x86_64", "x86", "i386"]), oslist=["windows"])
Author: David Spickett
Date: 2025-04-11T13:14:16Z
New Revision: 5b384c3015100ad815f4d994d7ef35cc947db711
URL:
https://github.com/llvm/llvm-project/commit/5b384c3015100ad815f4d994d7ef35cc947db711
DIFF:
https://github.com/llvm/llvm-project/commit/5b384c3015100ad815f4d994d7ef35cc947db711.diff
LOG
@@ -0,0 +1,39 @@
+"""
+Test SBTarget Read Instruction.
+"""
+
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+
+
+class TargetReadInstructionsFlavor(TestBase):
+@skipIf(archs=no_match(["x86_64", "x86", "i386"]), oslist=["windows"])
DavidSpickett wrote:
At this time no, it's a feature I'd like to have one day. My advice would have
been to land it and see what happens :)
Unless we had pre-commit Windows lldb, but I think right now it's only Linux
and it gets disabled some times due to instability.
It's fixed for AArch64 L
DavidSpickett wrote:
I think I can test this on Arm's Foundation Model, I will do that and get back
to you. I have not checked it before now.
https://github.com/llvm/llvm-project/pull/135563
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
ht
Author: David Spickett
Date: 2025-04-22T08:53:01Z
New Revision: 382263376fcfed967f5bc17400d9e4542b37801c
URL:
https://github.com/llvm/llvm-project/commit/382263376fcfed967f5bc17400d9e4542b37801c
DIFF:
https://github.com/llvm/llvm-project/commit/382263376fcfed967f5bc17400d9e4542b37801c.diff
LOG
DavidSpickett wrote:
I think this relates to:
> 2.17 Code Addresses, Ranges and Base Addresses
> <...>
> The base address of the scope for any of the debugging information entries
> listed
> above is given by either the DW_AT_low_pc attribute or the first address in
> the
> first range entry in
DavidSpickett wrote:
> In particular the dynamic loader in the next debian release (trixie) has
> functions like this which means that lldb spews a bunch warning when
> debugging pretty much any binary
If you add this to the PR description, anyone downstream of us seeing this
error will have
@@ -42,6 +27,21 @@ look_me_up:
.size foo.__part.1, .Lfoo.__part.1_end-foo.__part.1
+bar:
+nop
+.Lbar_end:
+.size bar, .Lbar_end-bar
+
+.type foo,@function
+foo:
DavidSpickett wrote:
Trying to understand the change here.
DavidSpickett wrote:
> which (according to the paragraph you quote) means that the function's entry
> point is 0x1cfb0, which is not the lowest address in the function.
I managed to nitpick the text but then go on to assume the ranges would be
sorted with start address increasing. Bad idea.
B
https://github.com/DavidSpickett approved this pull request.
LGTM.
https://github.com/llvm/llvm-project/pull/132395
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
DavidSpickett wrote:
Might be another case of us building with clang, producing DWARF, then linking
with link.exe which discards the DWARF. I've skipped a few tests for this
already.
(though I wonder if we should just be using lld anyway)
https://github.com/llvm/llvm-project/pull/136226
_
@@ -42,6 +27,21 @@ look_me_up:
.size foo.__part.1, .Lfoo.__part.1_end-foo.__part.1
+bar:
+nop
+.Lbar_end:
+.size bar, .Lbar_end-bar
+
+.type foo,@function
+foo:
DavidSpickett wrote:
Ok I understand now. `look_me_up` is u
DavidSpickett wrote:
I see. Thanks for explaining, I'll let the experts weigh in on that topic then
:)
https://github.com/llvm/llvm-project/pull/137512
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/li
DavidSpickett wrote:
@Michael137, in the second screenshot in the PR description,
``clang-21`clang-main`` has `clang-main` highlighted, but ``clang-21`main``
does not highlight `main`. dyld also doesn't highlight start but that could be
a lack of the debug information needed.
Is that expected
DavidSpickett wrote:
> I don't know how the prebuilt binaries are built, but I'd guess they will
> install and zip the install-directory. In that case, this should work.
@omjavaid would know this for Windows on Arm.
https://github.com/llvm/llvm-project/pull/137467
_
https://github.com/DavidSpickett approved this pull request.
LGTM, I know when configuring via llvm CMAKE_BUILD_TYPE is required now.
I'd have guessed it's required for a standalone build as well, but you're not
changing that, so it must not be?
https://github.com/llvm/llvm-project/pull/137383
Author: David Spickett
Date: 2025-04-28T09:10:12Z
New Revision: 5afe9c72e4bea2ea38beb1cb0d3a3edc9a958414
URL:
https://github.com/llvm/llvm-project/commit/5afe9c72e4bea2ea38beb1cb0d3a3edc9a958414
DIFF:
https://github.com/llvm/llvm-project/commit/5afe9c72e4bea2ea38beb1cb0d3a3edc9a958414.diff
LOG
DavidSpickett wrote:
Likely won't find the fix today, but I suspect that the Windows process class
just doesn't know that it doesn't support reverse execution:
```
(lldb) process continue --reverse
Process 3108 resuming
(lldb) process status
Process 5360 stopped
```
The process being stopped is
Author: David Spickett
Date: 2025-04-24T12:16:29Z
New Revision: bcdafc107e1fb68893036cfba14e761c7b37b0e9
URL:
https://github.com/llvm/llvm-project/commit/bcdafc107e1fb68893036cfba14e761c7b37b0e9
DIFF:
https://github.com/llvm/llvm-project/commit/bcdafc107e1fb68893036cfba14e761c7b37b0e9.diff
LOG
DavidSpickett wrote:
Sod's law that the supposedly simple test would be the problem.
I'll figure this out, I've disabled it on Windows for now.
https://github.com/llvm/llvm-project/pull/132783
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
DavidSpickett wrote:
Jonas is added as he's listed as the code owner for this area, but does not
necessarily review all PRs.
In general, you only need one approval -
https://llvm.org/docs/CodeReview.html#lgtm-how-a-patch-is-accepted
Unless you happen to know or suspect others would want to co
@@ -353,6 +353,8 @@ static const ArchDefinitionEntry g_macho_arch_entries[] = {
{ArchSpec::eCore_x86_64_x86_64, llvm::MachO::CPU_TYPE_X86_64,
llvm::MachO::CPU_SUBTYPE_X86_ARCH1, UINT32_MAX, SUBTYPE_MASK},
{ArchSpec::eCore_x86_64_x86_64h, llvm::MachO::CPU_TYPE
@@ -113,6 +113,14 @@ TEST(ArchSpecTest, TestSetTriple) {
.consume_front("powerpc-apple-darwin"));
EXPECT_EQ(ArchSpec::eCore_ppc_ppc970, AS.GetCore());
+ AS = ArchSpec();
+ EXPECT_TRUE(AS.SetTriple("24-0-apple-unknown"));
+ EXPECT_EQ(uint32_t(llvm::MachO:
@@ -353,6 +353,8 @@ static const ArchDefinitionEntry g_macho_arch_entries[] = {
{ArchSpec::eCore_x86_64_x86_64, llvm::MachO::CPU_TYPE_X86_64,
llvm::MachO::CPU_SUBTYPE_X86_ARCH1, UINT32_MAX, SUBTYPE_MASK},
{ArchSpec::eCore_x86_64_x86_64h, llvm::MachO::CPU_TYPE
@@ -113,6 +113,14 @@ TEST(ArchSpecTest, TestSetTriple) {
.consume_front("powerpc-apple-darwin"));
EXPECT_EQ(ArchSpec::eCore_ppc_ppc970, AS.GetCore());
+ AS = ArchSpec();
+ EXPECT_TRUE(AS.SetTriple("24-0-apple-unknown"));
+ EXPECT_EQ(uint32_t(llvm::MachO:
@@ -353,6 +353,8 @@ static const ArchDefinitionEntry g_macho_arch_entries[] = {
{ArchSpec::eCore_x86_64_x86_64, llvm::MachO::CPU_TYPE_X86_64,
llvm::MachO::CPU_SUBTYPE_X86_ARCH1, UINT32_MAX, SUBTYPE_MASK},
{ArchSpec::eCore_x86_64_x86_64h, llvm::MachO::CPU_TYPE
@@ -353,6 +353,8 @@ static const ArchDefinitionEntry g_macho_arch_entries[] = {
{ArchSpec::eCore_x86_64_x86_64, llvm::MachO::CPU_TYPE_X86_64,
llvm::MachO::CPU_SUBTYPE_X86_ARCH1, UINT32_MAX, SUBTYPE_MASK},
{ArchSpec::eCore_x86_64_x86_64h, llvm::MachO::CPU_TYPE
DavidSpickett wrote:
> i guess header includes would be an example
Headers like ADT and so on are included in installed copies of LLVM but testing
files are not.
So would this break testing a standalone LLDB build? Or do we expect
"standalone" to mean you configure from `lldb/` but you do hav
https://github.com/DavidSpickett closed
https://github.com/llvm/llvm-project/pull/138331
___
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/138331
___
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
https://github.com/llvm/llvm-project/pull/137955
___
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.
https://github.com/llvm/llvm-project/pull/126935
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -115,5 +115,8 @@ TEST_F(HostTest, GetProcessInfoSetsPriority) {
}
ASSERT_TRUE(Info.IsZombie().has_value());
ASSERT_FALSE(Info.IsZombie().value());
+
+ ASSERT_TRUE(Info.IsCoreDumping().has_value());
+ ASSERT_FALSE(Info.IsCoreDumping().value());
DavidS
@@ -213,6 +213,11 @@ static bool GetStatusInfo(::pid_t Pid, ProcessInstanceInfo
&ProcessInfo,
} else if (Line.consume_front("Tgid:")) {
Line = Line.ltrim();
Line.consumeInteger(10, Tgid);
+} else if (Line.consume_front("CoreDumping:")) {
+ uint32_t cor
https://github.com/DavidSpickett approved this pull request.
LGTM.
https://github.com/llvm/llvm-project/pull/138263
___
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-02T13:00:12Z
New Revision: 7d01b85c2a0aa8bc91f731cfeb2a7b6885b8d04a
URL:
https://github.com/llvm/llvm-project/commit/7d01b85c2a0aa8bc91f731cfeb2a7b6885b8d04a
DIFF:
https://github.com/llvm/llvm-project/commit/7d01b85c2a0aa8bc91f731cfeb2a7b6885b8d04a.diff
LOG
@@ -283,39 +283,42 @@ uint32_t Block::GetRangeIndexContainingAddress(const
Address &addr) {
return m_ranges.FindEntryIndexThatContains(file_addr - func_file_addr);
}
+static AddressRange ToAddressRange(const Address &func_addr,
+ const Bloc
DavidSpickett wrote:
> We had code which was waiting for an pipe EOF, but it never got that due to
> the FD ending up in an unsuspecting (and unrelated) process. Although that's
> possible to solve in a different way, I think it's still better to declare
> all of the FDs passed to a process ex
@@ -122,8 +123,14 @@ struct ForkLaunchInfo {
ExitWithError(error_fd, "close");
break;
case FileAction::eFileActionDuplicate:
- if (dup2(action.fd, action.arg) == -1)
-ExitWithError(error_fd, "dup2");
+ if (action.fd != action.arg) {
+
@@ -122,8 +123,14 @@ struct ForkLaunchInfo {
ExitWithError(error_fd, "close");
break;
case FileAction::eFileActionDuplicate:
- if (dup2(action.fd, action.arg) == -1)
-ExitWithError(error_fd, "dup2");
+ if (action.fd != action.arg) {
+
@@ -122,8 +123,14 @@ struct ForkLaunchInfo {
ExitWithError(error_fd, "close");
break;
case FileAction::eFileActionDuplicate:
- if (dup2(action.fd, action.arg) == -1)
-ExitWithError(error_fd, "dup2");
+ if (action.fd != action.arg) {
+
Author: David Spickett
Date: 2025-05-01T09:30:33Z
New Revision: 47424df2d5c6cc5a2b2d49a8cad438d8e75fec61
URL:
https://github.com/llvm/llvm-project/commit/47424df2d5c6cc5a2b2d49a8cad438d8e75fec61
DIFF:
https://github.com/llvm/llvm-project/commit/47424df2d5c6cc5a2b2d49a8cad438d8e75fec61.diff
LOG
Author: David Spickett
Date: 2025-05-01T10:01:14Z
New Revision: 2dbab4ca8ddb218af555d8d1fd86b72612387582
URL:
https://github.com/llvm/llvm-project/commit/2dbab4ca8ddb218af555d8d1fd86b72612387582
DIFF:
https://github.com/llvm/llvm-project/commit/2dbab4ca8ddb218af555d8d1fd86b72612387582.diff
LOG
@@ -283,39 +283,42 @@ uint32_t Block::GetRangeIndexContainingAddress(const
Address &addr) {
return m_ranges.FindEntryIndexThatContains(file_addr - func_file_addr);
}
+static AddressRange ToAddressRange(const Address &func_addr,
+ const Bloc
@@ -0,0 +1,102 @@
+# REQUIRES: x86, lld
+
+# RUN: split-file %s %t
+# RUN: llvm-mc -filetype=obj -triple x86_64-pc-linux %t/file.s -o %t/file.o
+# RUN: ld.lld %t/file.o -o %t/file.out -T %t/file.lds
+# RUN: %lldb %t/file.out -o "disassemble --name func1" -o exit | FileCheck %s
+
+
@@ -1304,6 +1304,9 @@ void GDBRemoteCommunicationServerCommon::
if (!abi.empty())
response.Printf("elf_abi:%s;", abi.c_str());
response.Printf("ptrsize:%d;", proc_arch.GetAddressByteSize());
+std::optional non_resumable = proc_info.IsNonResumable();
+if (n
https://github.com/DavidSpickett closed
https://github.com/llvm/llvm-project/pull/138111
___
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/138111
Something to do with control code handling in Windows terminals breaks the
statusline in various ways. It makes LLDB unusable and even if you set the
setting to disable statusline, it's too late, and the
DavidSpickett wrote:
Tests are pexpect so they're not running on Windows anyway.
https://github.com/llvm/llvm-project/pull/138111
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -122,8 +123,14 @@ struct ForkLaunchInfo {
ExitWithError(error_fd, "close");
break;
case FileAction::eFileActionDuplicate:
- if (dup2(action.fd, action.arg) == -1)
-ExitWithError(error_fd, "dup2");
+ if (action.fd != action.arg) {
-
https://github.com/DavidSpickett commented:
> Currently we're creating inheritable (~FD_CLOEXEC) file descriptors in the
> (few) cases where we need to pass an FD to a subprocess. The problem with
> these is that, in a multithreaded application such as lldb, there's
> essentially no way to pre
https://github.com/DavidSpickett edited
https://github.com/llvm/llvm-project/pull/126935
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -87,3 +89,41 @@ TEST(Host, LaunchProcessSetsArgv0) {
ASSERT_THAT_ERROR(Host::LaunchProcess(info).takeError(), Succeeded());
ASSERT_THAT(exit_status.get_future().get(), 0);
}
+
+#ifdef LLVM_ON_UNIX
+TEST(Host, LaunchProcessDuplicatesHandle) {
+ static constexpr llvm::Str
@@ -122,8 +123,14 @@ struct ForkLaunchInfo {
ExitWithError(error_fd, "close");
break;
case FileAction::eFileActionDuplicate:
- if (dup2(action.fd, action.arg) == -1)
-ExitWithError(error_fd, "dup2");
+ if (action.fd != action.arg) {
+
DavidSpickett wrote:
> This is pretty complicated to test because it requires integration with the
> Kernel
Can you make the same thing happen without using a coredumper? I feel like the
answer is a solid no but I'm not sure why.
Another way we can do it is to write a test that checks that if
@@ -1676,7 +1681,11 @@ GDBRemoteCommunication::PacketResult
GDBRemoteCommunicationServerLLGS::Handle_vCont_actions(
StringExtractorGDBRemote &packet) {
StreamString response;
- response.Printf("vCont;c;C;s;S;t");
+ if (m_current_process && m_current_process->CanResume()
@@ -1304,6 +1304,9 @@ void GDBRemoteCommunicationServerCommon::
if (!abi.empty())
response.Printf("elf_abi:%s;", abi.c_str());
response.Printf("ptrsize:%d;", proc_arch.GetAddressByteSize());
+std::optional non_resumable = proc_info.IsNonResumable();
+if (n
@@ -0,0 +1,13 @@
+// Generate a dummy SB API file using lldb-rpc-gen.
+# RUN: mkdir -p %t/server
+# RUN: mkdir -p %t/lib
DavidSpickett wrote:
CI failing with:
```
/var/lib/buildkite-agent/builds/linux-56-59b8f5d88-spx4x-1/llvm-project/github-pull-requests/build/t
https://github.com/DavidSpickett approved this pull request.
Once you've checked the return value, this LGTM.
https://github.com/llvm/llvm-project/pull/138580
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mail
@@ -0,0 +1,94 @@
+LLDB RPC Upstreaming Design Doc
+===
+
+This document aims to explain the general structure of the upstreaming patches
for adding LLDB RPC. The 2 primary concepts explained here will be:
+
+* How LLDB RPC is used
+* How the ``lldb-rpc
https://github.com/DavidSpickett edited
https://github.com/llvm/llvm-project/pull/138612
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/DavidSpickett commented:
Thanks for writing this up.
When we get to a point where PRs have landed you can just change "will be" /
"will do" language to "is" / "does" and it should be a good reference for the
future.
One thing that is missing right now is how to test it. Bas
@@ -0,0 +1,80 @@
+//===-- RPCServerSourceEmitter.h
--===//
+//
+// 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
@@ -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
@@ -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,73 @@
+//===-- RPCServerHeaderEmitter.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: Apa
https://github.com/DavidSpickett edited
https://github.com/llvm/llvm-project/pull/138032
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/DavidSpickett commented:
Looks OK in isolation, a bit like looking at a TableGen backend, easier to
judge the output than the emitters.
Please look over the FIXMEs and see if anything can be done right now, I
highlighted one that is potentially a problem but the rest don't s
@@ -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
@@ -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 edited
https://github.com/llvm/llvm-project/pull/138032
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
DavidSpickett wrote:
But there's no lldb-rpc client built into `lldb`, right? Because that would be
my first instinct to try.
https://github.com/llvm/llvm-project/pull/138612
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm
2501 - 2600 of 2869 matches
Mail list logo
