DavidSpickett wrote:
Thanks! You've saved me some work here. We've been seeing this fail on the
Linuxes too since I disabled it for Windows.
https://github.com/llvm/llvm-project/pull/98237
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http
https://github.com/DavidSpickett approved this pull request.
https://github.com/llvm/llvm-project/pull/98237
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
DavidSpickett wrote:
cI failure is unrelated:
```
Timed Out Tests (1):
lldb-api :: api/multiple-debuggers/TestMultipleDebuggers.py
```
Which is the *other* flaky test on my list to look at...
https://github.com/llvm/llvm-project/pull/98237
___
lldb-c
DavidSpickett wrote:
In case we need them for future reference, some failures this aims to fix:
https://github.com/llvm/llvm-project/pull/98041#issuecomment-2216892858
https://lab.llvm.org/buildbot/#/builders/59/builds/1234
https://lab.llvm.org/buildbot/#/builders/162/builds/1570
https://github.
Author: David Spickett
Date: 2024-07-10T10:35:28Z
New Revision: 08ce14732d528ab70309f334446d39782f2f07c0
URL:
https://github.com/llvm/llvm-project/commit/08ce14732d528ab70309f334446d39782f2f07c0
DIFF:
https://github.com/llvm/llvm-project/commit/08ce14732d528ab70309f334446d39782f2f07c0.diff
LOG
Author: David Spickett
Date: 2024-07-10T11:22:07Z
New Revision: 3e06392c7db0eacfca94a176d430d9988b3ffbd6
URL:
https://github.com/llvm/llvm-project/commit/3e06392c7db0eacfca94a176d430d9988b3ffbd6
DIFF:
https://github.com/llvm/llvm-project/commit/3e06392c7db0eacfca94a176d430d9988b3ffbd6.diff
LOG
DavidSpickett wrote:
Clang's decision to emit DW_AT_type or not goes back to
https://reviews.llvm.org/D42734 and in particular this code:
```
void DwarfUnit::constructEnumTypeDIE(DIE &Buffer, const DICompositeType *CTy) {
const DIType *DTy = resolve(CTy->getBaseType());
bool IsUnsigned = DTy
@@ -195,10 +199,10 @@ enum Format {
///< character arrays that can contain non printable
///< characters
eFormatAddressInfo,///< Describe what an address points to (func + offset
- ///< with file/line,
@@ -89,9 +89,13 @@
# The suffix of source filenames.
source_suffix = {
".rst": "restructuredtext",
-".md": "markdown",
}
+# Man pages do not use markdown pages, so we don't need to register a markdown
+# parser.
+if not building_man_page:
+source_suffix[".md"] =
https://github.com/DavidSpickett commented:
Looks fine to me just a minor comment on placement.
https://github.com/llvm/llvm-project/pull/98420
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/ll
https://github.com/DavidSpickett updated
https://github.com/llvm/llvm-project/pull/97824
>From 7ebe4e487b763ff26fbab6d75aa7c8694d63e8b1 Mon Sep 17 00:00:00 2001
From: David Spickett
Date: Fri, 5 Jul 2024 08:42:22 +
Subject: [PATCH 1/9] [llvm][TargetParser] Return optional from
getHostCPUFe
@@ -20,16 +20,15 @@ using namespace llvm;
int main(int argc, char **argv) {
#if defined(__i386__) || defined(_M_IX86) || \
defined(__x86_64__) || defined(_M_X64)
- StringMap features;
-
- if (!sys::getHostCPUFeatures(features))
+ const StringMap features = sys::getHostCP
https://github.com/DavidSpickett closed
https://github.com/llvm/llvm-project/pull/97824
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -1,8 +1,25 @@
# Overlapping PT_LOAD and PT_TLS segments should be able to exist side by side.
DavidSpickett wrote:
Maybe clarify this by adding "in an object file." on the end. So it's clear
that lldb is not making use of them, just able to ignore them as th
@@ -1,8 +1,25 @@
# Overlapping PT_LOAD and PT_TLS segments should be able to exist side by side.
+# When an ELF file contains both PT_LOAD and PT_TLS segmentsq where the PT_TLS
+# segment has the same p_vaddr and p_paddr as a PT_LOAD segment, this
+# was causing LLDB, when load
@@ -1,8 +1,25 @@
# Overlapping PT_LOAD and PT_TLS segments should be able to exist side by side.
+# When an ELF file contains both PT_LOAD and PT_TLS segmentsq where the PT_TLS
DavidSpickett wrote:
"PT_TLS segments" remove the "q" typo.
https://github.com/llv
https://github.com/DavidSpickett created
https://github.com/llvm/llvm-project/pull/98464
This was found during testing of llvm snapshots for Fedora.
This test was looking for an exact string match of the path calculated by
starting with lib/liblldb and with bin/lldb. However when CLANG_RESOURC
https://github.com/DavidSpickett closed
https://github.com/llvm/llvm-project/pull/98464
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -195,10 +199,10 @@ enum Format {
///< character arrays that can contain non printable
///< characters
eFormatAddressInfo,///< Describe what an address points to (func + offset
- ///< with file/line,
@@ -195,10 +199,10 @@ enum Format {
///< character arrays that can contain non printable
///< characters
eFormatAddressInfo,///< Describe what an address points to (func + offset
- ///< with file/line,
https://github.com/DavidSpickett created
https://github.com/llvm/llvm-project/pull/98616
Sice #98335 clang adds DW_AT_type, unless strict DWARF is requested.
>From 6b21c9e4dc4735dbd1be8c1b125e35c3ee01bbf7 Mon Sep 17 00:00:00 2001
From: David Spickett
Date: Fri, 12 Jul 2024 10:29:31 +
Subje
https://github.com/DavidSpickett edited
https://github.com/llvm/llvm-project/pull/98616
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
DavidSpickett wrote:
> Without this fix, a frameless function that faults in a firmware environment
> (that's where we've seen this issue most commonly) hasn't spilled lr to
> stack, so we need to retrieve it from the fault handler's
> full-register-context to find the caller of the frameless
https://github.com/DavidSpickett closed
https://github.com/llvm/llvm-project/pull/98616
___
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/90075
___
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/98829
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Author: David Spickett
Date: 2024-07-16T09:46:40Z
New Revision: 078cb7a4a07582a39ecd2f2fba9e9b1add9ebff3
URL:
https://github.com/llvm/llvm-project/commit/078cb7a4a07582a39ecd2f2fba9e9b1add9ebff3
DIFF:
https://github.com/llvm/llvm-project/commit/078cb7a4a07582a39ecd2f2fba9e9b1add9ebff3.diff
LOG
DavidSpickett wrote:
Did you consider making `AllowPort(0)` do nothing?
My guess is that this port dance is complicated enough as it is, and
`AllowPort(0)` doing nothing would be more implicit behaviour we have to pick
apart later.
https://github.com/llvm/llvm-project/pull/98833
_
Author: David Spickett
Date: 2024-07-16T13:08:04+01:00
New Revision: d4a89af5a8c52191797bed5ff7ff40a85435d3a0
URL:
https://github.com/llvm/llvm-project/commit/d4a89af5a8c52191797bed5ff7ff40a85435d3a0
DIFF:
https://github.com/llvm/llvm-project/commit/d4a89af5a8c52191797bed5ff7ff40a85435d3a0.diff
DavidSpickett wrote:
Is this something specific to risc-v or simply uncovered by testing against a
certain risc-v target? Just wondering why we haven't had to do this before now.
https://github.com/llvm/llvm-project/pull/99045
___
lldb-commits mailing
https://github.com/DavidSpickett edited
https://github.com/llvm/llvm-project/pull/99043
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
DavidSpickett wrote:
The other ABI plugins use the dwarf indexes and I guess that has to be the case
because the unwind plan's type is dwarf. Adding @jasonmolenda just in case
there's anything more to it.
https://github.com/llvm/llvm-project/pull/99043
_
@@ -34,6 +34,8 @@ def check_first_register_readable(test_case):
test_case.expect("register read r0", substrs=["r0 = 0x"])
elif arch in ["powerpc64le"]:
test_case.expect("register read r0", substrs=["r0 = 0x"])
+elif arch in ["rv64gc"]:
D
@@ -34,6 +34,8 @@ def check_first_register_readable(test_case):
test_case.expect("register read r0", substrs=["r0 = 0x"])
elif arch in ["powerpc64le"]:
test_case.expect("register read r0", substrs=["r0 = 0x"])
+elif arch in ["rv64gc"]:
D
@@ -34,6 +34,8 @@ def check_first_register_readable(test_case):
test_case.expect("register read r0", substrs=["r0 = 0x"])
elif arch in ["powerpc64le"]:
test_case.expect("register read r0", substrs=["r0 = 0x"])
+elif arch in ["rv64gc"]:
D
@@ -34,6 +34,8 @@ def check_first_register_readable(test_case):
test_case.expect("register read r0", substrs=["r0 = 0x"])
elif arch in ["powerpc64le"]:
test_case.expect("register read r0", substrs=["r0 = 0x"])
+elif arch in ["rv64gc"]:
D
https://github.com/DavidSpickett closed
https://github.com/llvm/llvm-project/pull/99043
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
DavidSpickett wrote:
> So, this patch fixes that issue, right?
Yes I think so, give me some time to test it myself.
https://github.com/llvm/llvm-project/pull/98833
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bi
https://github.com/DavidSpickett approved this pull request.
Disabling this for now is fine with me.
```
# shell parser error on RUN: at line 1:
c:\users\tcwg\llvm-worker\lldb-aarch64-windows\build\bin\clang.exe
--target=specify-a-target-or-use-a-_host-substitution
--target=aarch64-pc-windows
https://github.com/DavidSpickett approved this pull request.
https://github.com/llvm/llvm-project/pull/99039
___
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/99039
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
DavidSpickett wrote:
I tested this with the port mapping I usually use for simulator development and
it works fine.
Thanks for the fix.
https://github.com/llvm/llvm-project/pull/98833
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://
https://github.com/DavidSpickett closed
https://github.com/llvm/llvm-project/pull/98833
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
DavidSpickett wrote:
> Thanks for the patches (if we end up going down this route you'll probably
> want to split out the LLVM JIT changes into a separate PR).
I know little about the JIT side but this is my first reaction too. I wonder if
that has its own tests that need adding, and it'll get
DavidSpickett wrote:
Please remove the formatting changes and limit this to just the specifier
change.
I know most of the time we'd want it formatted but for a fix as limited as
this, the formatting change just gets in the way, and not formatting it doesn't
block merging either.
Otherwise th
DavidSpickett wrote:
The bot will complain again but we will ignore it :)
https://github.com/llvm/llvm-project/pull/94783
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/DavidSpickett requested changes to this pull request.
> The field this is consuming is actually 17 bytes long, because the process
> name is in parenthesis.
Ok then I am confused how this ever worked, but it sounds like scanf was never
a great way to do this anyway?
https:/
https://github.com/DavidSpickett created
https://github.com/llvm/llvm-project/pull/100387
As reported in https://github.com/llvm/llvm-project/issues/89710, the %s code
used for `comm` could and probably does, overflow the buffer. Likely we haven't
seen it cause problems because the following d
https://github.com/DavidSpickett closed
https://github.com/llvm/llvm-project/pull/100387
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
DavidSpickett wrote:
I have merged https://github.com/llvm/llvm-project/pull/100387 to fix this
instead, because it needed some background knowledge to do correctly.
But never the less, thank you @xgupta for making the effort to do this PR, it
has uncovered some unsafe code that only recently
https://github.com/DavidSpickett closed
https://github.com/llvm/llvm-project/pull/94783
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -1,4 +1,5 @@
# UNSUPPORTED: system-windows
+# XFAIL: target=x86_64-{{.*}}-windows{{.*}}
DavidSpickett wrote:
And this test I'm pretty sure is only failing due to cmd line syntax issues,
but no confirmation yet.
https://github.com/llvm/llvm-project/pull/1004
https://github.com/DavidSpickett created
https://github.com/llvm/llvm-project/pull/100561
Reverts llvm/llvm-project#94779
Due to bot failures: https://lab.llvm.org/buildbot/#/builders/18/builds/1371
>From b85152008f41e8136f5e21db875a63b464f8c10f Mon Sep 17 00:00:00 2001
From: David Spickett
D
https://github.com/DavidSpickett closed
https://github.com/llvm/llvm-project/pull/100561
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
DavidSpickett wrote:
The code looks ok but as landed it turned `A && B && C` into `A || B || C`,
despite that looking logical.
@medismailben can you figure out the intent here, I'm assuming this was your
code originally.
https://github.com/llvm/llvm-project/pull/94779
https://github.com/DavidSpickett approved this pull request.
LGTM.
https://github.com/llvm/llvm-project/pull/100628
___
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/100660
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -266,16 +266,11 @@ def getCompiler():
return module.getCompiler()
-def getCompilerBinary():
-"""Returns the compiler binary the test suite is running with."""
-return getCompiler().split()[0]
-
-
def getCompilerVersion():
"""Returns a string that represen
DavidSpickett wrote:
Seems fine to me, but there is a use of it in
`lldb/packages/Python/lldbsuite/test/lldbtest.py` that should also be removed.
https://github.com/llvm/llvm-project/pull/100660
___
lldb-commits mailing list
lldb-commits@lists.llvm.or
DavidSpickett wrote:
And the CI failure is one of our old friends:
```
Timed Out Tests (1):
lldb-api :: functionalities/fork/concurrent_vfork/TestConcurrentVFork.py
```
That you can safely ignore.
https://github.com/llvm/llvm-project/pull/100660
___
DavidSpickett wrote:
> I'd show a full test log but for whatever reason, it's not being verbose
> despite being asked to, working on that.
I've fixed this, you can get a full test list by downloading the log file e.g.
https://lab.llvm.org/buildbot/#/builders/141/builds/1139/steps/6/logs/stdio.
@@ -52,6 +52,7 @@ def test_negative_indexing(self):
self.build()
self.validate_negative_indexing()
+@expectedFailureAll(oslist=["windows"], archs=["x86_64"])
DavidSpickett wrote:
I recently updated this for Windows on Arm
https://github.
DavidSpickett wrote:
> When you display registers bitfields do you have a ValueObject?
Yes:
https://github.com/llvm/llvm-project/blob/6808e6c78edf63d2c0c9bd6fce168fe7e0a7d49f/lldb/source/Core/DumpRegisterValue.cpp#L47
I'm just calling `dump`, there's no register specific code there, ideally I
DavidSpickett wrote:
This seems fine, but what happens currently? Does it try to use a tool that's
built for the remote not the host?
https://github.com/llvm/llvm-project/pull/100836
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://li
DavidSpickett wrote:
> So instead of using enum for the field why not a union of enum and unsigned.
The union idea sort of works, but it's clunky enough I'm not going to pursue
it. The most verbose version:
```
fpcr = 0x
= {
<...>
RMode = (meaning = RN, value =
https://github.com/DavidSpickett closed
https://github.com/llvm/llvm-project/pull/90059
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
DavidSpickett wrote:
Custom printing code for just enums for registers would be possible but it
means copying a lot of existing code. A callback reduces that to a copy of
`DumpEnumValue` only. Or you can iterate the value object yourself but then you
have to provide the surrounding format too
https://github.com/DavidSpickett closed
https://github.com/llvm/llvm-project/pull/101169
___
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'm not sure whether we need `LLDB_SHELL_TESTS_DISABLE_REMOTE`, can you explain
how that would be used?
Would I set up a build with all the other flags, do my remote testing, then set
`LLDB_SHELL_TESTS_DISABLE_REMOTE=OFF` and run the shell tests loca
https://github.com/DavidSpickett edited
https://github.com/llvm/llvm-project/pull/95986
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -22,6 +24,55 @@ def _disallow(config, execName):
config.substitutions.append((" {0} ".format(execName),
warning.format(execName)))
+def get_lldb_args(config, suffix=None):
+lldb_args = []
+if "remote-linux" in config.available_features:
+lldb_args += [
@@ -22,6 +24,55 @@ def _disallow(config, execName):
config.substitutions.append((" {0} ".format(execName),
warning.format(execName)))
+def get_lldb_args(config, suffix=None):
+lldb_args = []
+if "remote-linux" in config.available_features:
+lldb_args += [
@@ -22,6 +24,55 @@ def _disallow(config, execName):
config.substitutions.append((" {0} ".format(execName),
warning.format(execName)))
+def get_lldb_args(config, suffix=None):
+lldb_args = []
+if "remote-linux" in config.available_features:
+lldb_args += [
@@ -4,16 +4,16 @@
target create -l "ls" /bin/ls
target list
-# CHECK: * target #0 (ls): /bin/ls
+# CHECK: * target #0 (ls): [[LS_PATH:.*]]
DavidSpickett wrote:
Could make this supported on Windows too if we happen to have some basic C file
hanging around in
@@ -4,16 +4,16 @@
target create -l "ls" /bin/ls
target list
-# CHECK: * target #0 (ls): /bin/ls
+# CHECK: * target #0 (ls): [[LS_PATH:.*]]
DavidSpickett wrote:
Though `/bin/ls` surely isn't going to be compatible with the remote a large
percentage of the tim
@@ -138,7 +191,7 @@ def use_support_substitutions(config):
# Set up substitutions for support tools. These tools can be overridden
at the CMake
# level (by specifying -DLLDB_LIT_TOOLS_DIR), installed, or as a last
resort, we can use
# the just-built version.
-
@@ -4,16 +4,16 @@
target create -l "ls" /bin/ls
target list
-# CHECK: * target #0 (ls): /bin/ls
+# CHECK: * target #0 (ls): [[LS_PATH:.*]]
DavidSpickett wrote:
Do I understand correctly here that the path `/bin/ls` is given to target
create, that program is
https://github.com/DavidSpickett commented:
What, if any, are the changes to how you would run lldb-server on Windows? I
see a new argument here but not sure if that's only meant for lldb-server to
pass to itself when it starts a child process.
https://github.com/llvm/llvm-project/pull/101283
https://github.com/DavidSpickett edited
https://github.com/llvm/llvm-project/pull/101283
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -159,6 +159,40 @@
GDBRemoteCommunicationServerPlatform::GDBRemoteCommunicationServerPlatform(
GDBRemoteCommunicationServerPlatform::~GDBRemoteCommunicationServerPlatform() =
default;
+void GDBRemoteCommunicationServerPlatform::Proc(
+const lldb_private::Args &args)
@@ -283,54 +293,94 @@ Status PipeWindows::ReadWithTimeout(void *buf, size_t
size,
DWORD sys_bytes_read = size;
BOOL result = ::ReadFile(m_read, buf, sys_bytes_read, &sys_bytes_read,
&m_read_overlapped);
- if (!result && GetLastError() != ERROR_I
@@ -159,6 +159,40 @@
GDBRemoteCommunicationServerPlatform::GDBRemoteCommunicationServerPlatform(
GDBRemoteCommunicationServerPlatform::~GDBRemoteCommunicationServerPlatform() =
default;
+void GDBRemoteCommunicationServerPlatform::Proc(
+const lldb_private::Args &args)
@@ -27,11 +27,13 @@ class TestLogHandler : public LogHandler {
: m_stream_sp(stream_sp) {}
void Emit(llvm::StringRef message) override {
+std::lock_guard guard(m_mutex);
DavidSpickett wrote:
A mutex is now required because of the sharing of the so
@@ -283,54 +293,94 @@ Status PipeWindows::ReadWithTimeout(void *buf, size_t
size,
DWORD sys_bytes_read = size;
BOOL result = ::ReadFile(m_read, buf, sys_bytes_read, &sys_bytes_read,
&m_read_overlapped);
- if (!result && GetLastError() != ERROR_I
@@ -114,6 +120,218 @@ static Status save_socket_id_to_file(const std::string
&socket_id,
return status;
}
+static GDBRemoteCommunicationServerPlatform::PortMap gdbserver_portmap;
+static std::mutex gdbserver_portmap_mutex;
+
+#if defined(_WIN32)
+static void SpawnProcessRea
@@ -159,6 +159,40 @@
GDBRemoteCommunicationServerPlatform::GDBRemoteCommunicationServerPlatform(
GDBRemoteCommunicationServerPlatform::~GDBRemoteCommunicationServerPlatform() =
default;
+void GDBRemoteCommunicationServerPlatform::Proc(
DavidSpickett wrote
DavidSpickett wrote:
What exactly does `lldb-server --server` mean? Because at least on Linux I see:
```
$ ./bin/lldb-server
Usage:
./bin/lldb-server v[ersion]
./bin/lldb-server g[dbserver] [options]
./bin/lldb-server p[latform] [options]
Invoke subcommand for additional help
```
Maybe you
@@ -114,6 +120,218 @@ static Status save_socket_id_to_file(const std::string
&socket_id,
return status;
}
+static GDBRemoteCommunicationServerPlatform::PortMap gdbserver_portmap;
+static std::mutex gdbserver_portmap_mutex;
+
+#if defined(_WIN32)
DavidSpicke
DavidSpickett wrote:
Linaro does yes, I think @omjavaid is currently dealing with that bot.
https://github.com/llvm/llvm-project/pull/100710
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-
DavidSpickett wrote:
I thought I saw that fixed once already, but perhaps that was just a full
revert.
We (Linaro) can test a patch for you if it's fiddly to verify, we just need to
know the general idea of it.
https://github.com/llvm/llvm-project/pull/97273
__
DavidSpickett wrote:
Actually I'm looking at old results, the latest build makes it to tests
https://lab.llvm.org/buildbot/#/builders/141/builds/1285 (which fail for
reasons unrelated to this patch).
https://github.com/llvm/llvm-project/pull/97273
__
DavidSpickett wrote:
Thanks for your efforts @kendalharland. If you think any of these details are
worth documenting (https://lldb.llvm.org/index.html), please do so. The page
sources are in `lldb/docs`.
https://github.com/llvm/llvm-project/pull/100477
_
@@ -2,6 +2,8 @@
# RUN: %lldb -x -b -o 'settings set interpreter.echo-comment-commands false'
-s %S/Inputs/EchoCommandsTest.in | FileCheck
%S/Inputs/EchoCommandsNoComments.out
# RUN: %lldb -x -b -o 'settings set interpreter.echo-commands false'
-s %S/Inputs/EchoCommand
@@ -2,6 +2,8 @@
# RUN: %lldb -x -b -o 'settings set interpreter.echo-comment-commands false'
-s %S/Inputs/EchoCommandsTest.in | FileCheck
%S/Inputs/EchoCommandsNoComments.out
# RUN: %lldb -x -b -o 'settings set interpreter.echo-commands false'
-s %S/Inputs/EchoCommand
@@ -22,6 +25,60 @@ def _disallow(config, execName):
config.substitutions.append((" {0} ".format(execName),
warning.format(execName)))
+def get_lldb_args(config, suffix=""):
+lldb_args = []
+if "remote-linux" in config.available_features:
+lldb_args += [
+
@@ -22,6 +25,60 @@ def _disallow(config, execName):
config.substitutions.append((" {0} ".format(execName),
warning.format(execName)))
+def get_lldb_args(config, suffix=""):
+lldb_args = []
+if "remote-linux" in config.available_features:
+lldb_args += [
+
DavidSpickett wrote:
Ok I see what `LLDB_SHELL_TESTS_DISABLE_REMOTE` does but I don't get why.
Perhaps you can show how a developer would:
* Hit the problem that this option addresses
* Apply the option
* What problems it would solve and what that final build looks like
* What the value of the r
DavidSpickett wrote:
I'm going to look into this now.
https://github.com/llvm/llvm-project/pull/100710
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Author: David Spickett
Date: 2024-08-01T12:59:49Z
New Revision: 229a16590a3cd65da77bb868498d3eed63bf6263
URL:
https://github.com/llvm/llvm-project/commit/229a16590a3cd65da77bb868498d3eed63bf6263
DIFF:
https://github.com/llvm/llvm-project/commit/229a16590a3cd65da77bb868498d3eed63bf6263.diff
LOG
DavidSpickett wrote:
Yeah, won't work with link.exe, so I've just disabled it. Nothing more for you
to do here.
https://github.com/llvm/llvm-project/pull/100710
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/m
101 - 200 of 2681 matches
Mail list logo
