Otherwise these tests are reliant on the compiler defaulting to having the extensions on.
Rest of LLVM's codebase doesn't seem to make such assumptions.
Tested by building with `-std=c2y` in Clang's C frotend's config file.
From
https://github.com/llvm/llvm-project/pull/148554#issuecomment-3083261858
- this adds an option for API tests to be run with the both PDB readers
on Windows. As there are a lot of failures with PDB, this is an opt-in
per test.
To get PDB, `-g -gcodeview` has to be used on Clang. `-gcodeview` alone
isn't enough, because it won't cause clang to pass `-debug` to the
linker.
#149498 tracks the (currently) failing tests.
In lldb-dap tests, we sometimes spawn subprocesses directly but do not
always correctly clean them up.
This can cause some tests, like the `TestDAP_disconnect.test_attach` to
hang and not properly respect timeouts.
To fix this, I am passing the `lldbtest.Base.spawnSubprocess` helper to
the adapter client so it can be used spawn subprocesses in a way that we
can ensure they're cleaned up.
Noticed this while looking into test stability that the 'entry' stop
reason is not triggering correctly. This should ensure we correctly
trigger the 'entry' stop reason when launching a process with
`"stopOnEntry": true`. I've also updated the tests to ensure we receive
the 'entry' stop reason to catch this regression.
… concurrency." (#165688)""
This reverts commit 17dbd8690e.
This was causing timeouts on the premerge runners. Reverting for now
until the timeouts trigger within lit and/or we have a better testing
strategy for this.
macOS forbids injecting the ASAN runtime into system processes when SIP
is enabled. That includes the just-built libLTO that the just-built
clang injects into the system linker. Since we don't test the compiler
here, just use the system (non-asanified) LTO library to make ASAN tests
work for most users, including the bots.
This reverts commit f205be0956.
This new select mechanism has exposed the fact that the resources
the Arm Linux bot has can vary a lot. We do limit it to a low number
of parallel tests but in this case, I think it's write performance
somewhere.
Reland the changes since they work elsewhere, and disable lldb-dap
tests on Arm Linux while I fix our buildbot.
We currently use a background thread to read the DAP output. This means
the test thread and the background thread can race at times and we may
have inconsistent timing due to these races.
To improve the consistency I've removed the reader thread and instead
switched to using the `selectors` module that wraps `select` in a
platform independent way.
We've been treating the `seq` attribute incorrectly in lldb-dap.
Previously, we always had `seq=0` for events and responses. We only
filled in the `seq` field on reverse requests.
However, looking at the spec and other DAP implementations, we are
supposed to fill in the `seq` field for each request we send to the DAP
client.
I've updated our usage to fill in `seq` in `DAP::Send` so that all
events/requests/responses have a properly filled `seq` value.
While debugging the tests for #155000 I found it helpful to have both
sides
of the simulated gdb-rsp traffic rather than just the responses so I've
extended
the packetLog in MockGDBServerResponder to record traffic in both
directions.
Tests have been updated accordingly
Various DAP tests are specifying their own timeouts, with values ranging
from "1" to "20". Most of them seem arbitrary, but some come with a
comment.
The performance characters of running these tests in CI are
unpredictable (they generally run much slower than developers expect)
and really not something we can make assumptions about. I suspect these
timeouts are a contributing factor to the flakiness of the DAP tests.
This PR unifies the timeouts around a central value in the DAP server.
Fixes#162523
Everything in this commit should be python 3.8 compatible which has
required using older styles of type hints (e.g. `Optional[T]` rather
than 3.10's `T | None` and `List[T]` rather than 3.9's `list[T]`. There
are some python 3.9 type hints in other files which have not been
changed by this commit.
Issues:
qEcho() is passed an argument by the callers that the function didn't
have Several functions in the base class would silently do nothing if
not overriden. These now use `@abstractmethod` to require overrides
sendall() had inconsistent return types between overrides
Compatibility was checked with:
```
uvx vermin -t 3.8 $(find lldb/packages/Python -name '*.py')
```
Compability of the type hints was checked with:
```
uvx vermin -t 3.8 --eval-annotations $(find lldb/packages/Python -name '*.py')
```
and type hint correctness was checked with
```
uvx pyright lldb/packages/Python/lldbsuite/test/gdbclientutils.py
```
API tests in the `libc++` category will try their best to build against
a locally built libc++. If none exists, the `Makefile.rules` currently
fall back to using the system libc++.
The issue with falling back to the system libc++ is that we are now
potentially not testing what we intended to. But we also can't rely on
certain libc++ features being available that the tests are trying to
use. On Apple platforms this is a configuration error (because libc++ is
the only stdlib supported), but we can't make it an error on Linux
because a user might want to run the API tests with libstdc++.
The Ubunutu 22.04 bots on the Apple fork are failing to run following
tests are failing:
* `TestLibcxxInternalsRecognizer.py`
* `TestDataFormatterStdRangesRefView.py` because the system stdlib
doesn't have `std::ranges` support yet. And the tests just fail to
build. Building libc++ on those bots is also not possible because the
system compiler is too old (and the Apple fork builds all the
subprojects standalone, so it requires the system compiler).
This patch marks tests in the `libc++` category as `UNSUPPORTED` if no
local libc++ is available.
The downside is that we will inevitably lose coverage on bots that were
running these tests without a local libc++. Arguably those weren't
really testing the right thing. But for vendors with LLDB forks it might
have been useful to at least know that the tests on the fork don't fail
against the system libc++.
Confirmed that the libc++ pre-merge CI still runs these tests (since it
uses the explicit `--category libc++` dotest flag). Also confirmed that
LLDB pre-merge CI runs the tests (because it builds `libcxx` locally).
**Workaround**
If you do need want to run libc++ tests against the system stdlib, you
can invoke `lldb-dotest` with the `--category libc++` flag:
```
./path/to/build/lldb-dotest --category libc++
OR
./path/to/build/bin/llvm-lit -sv --param dotest-args='--category libc++' "/path/to/monorepo/lldb/test/API
```
rdar://136231390
Added in 1902ffd9a4 but appears to be
leftover code from some older design.
I can't find any code that reads packetLog via the class itself, or
checks whether it is None.
No tests failed on AArch64 Linux after removing it.
Fixes#161510
Addresses the Linux parts of #138085
The situation we have to handle here is systems where Yama ptrace_scope
set to 1.
> 1 - restricted ptrace: a process must have a predefined relationship
> with the inferior it wants to call PTRACE_ATTACH on. By default,
> this relationship is that of only its descendants when the above
> classic criteria is also met. To change the relationship, an
> inferior can call prctl(PR_SET_PTRACER, debugger, ...) to declare
> an allowed debugger PID to call PTRACE_ATTACH on the inferior.
> Using PTRACE_TRACEME is unchanged.
(https://www.kernel.org/doc/Documentation/security/Yama.txt)
The inferior was addressing this by calling this at the start of main():
prctl(PR_SET_PTRACER, PR_SET_PTRACER_ANY, 0, 0, 0);
Which is ok if lldb-server tries to attach after that call has happened,
but there was nothing to synchronise this. So if the system was heavily
loaded, the inferior may be stalled, delaying the call, causing
lldb-server to fail to attach with EPERM (permission denied).
We were not using any mechanism to retry the attach or wait for some
signal from the inferior.
Except we do do this in other tests, even other lldb-server tests.
So I have adopted that mechanism to these tests:
* The inferior is launched with `syncfile:<path>` as its first argument.
* It creates this file at `<path>`, at a point where we know attaching
has been allowed.
* The test framework launches the inferior then waits for the file to
appear.
* This check is retried a few times, increasing the delay each time and
eventually giving up.
* Only once it has seen the file does it start lldb-server and tell it
to attach to the inferior.
I have tested this by insterting a `sleep()` call before the attach
enable call and running the test on a machine with ptrace_scope set to
1. I was able to increase the sleep to 6 seconds before tests failed
(when running just these tests, single threaded).
With OS scheduling, you could be stalled indefinitely, so we may have to
increase this timeout but this is easy to do with
wait_for_file_on_target.
The alternative is to have the test runner check ptrace_scope and only
enable these on systems where it's 0. Would be good to keep them running
if we can though.
The way I was setting the path to the yaml2macho-core tool for
API tests assumed that the llvm tool bin directory was the same
as the lldb tool bin directory. There are build configuration
styles where they are not. Set it the same way lldb-dap etc
are set to the lldb bin dir.
We were looking for any mention of the feature name in cpuinfo, which
could have hit anything including features with common prefixes like
sme, sme2, smefa64.
Luckily this was not a problem but I'm changing this to find the
features line and split the features into a list. Then we are only
looking for exact matches.
Here's the information for one core as an example:
```
processor : 7
BogoMIPS : 200.00
Features : fp asimd evtstrm crc32 atomics fphp asimdhp cpuid <...>
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x0
CPU part : 0xd0f
CPU revision : 0
```
(and to avoid any doubt, this is from a CPU simulated in Arm's FVP, it's
not real)
Note that the layout of the label, colon, values is sometimes aligned
but not always. So I trim whitespace a few times to normalise that.
This repeats once for each core so we only need to find one features
line.
This addresses limitations in our testing infrastructure for checking
CPU features. Before this
* `getCPUInfo()` was Linux-only, and the
* `@skipUnlessFeature` decorator was Darwin-only and did not consider
the remote (on device) testing use case.
Introduce `CPUFeature` class as an abstraction to hide the
platform-specific implementations to check for CPU features. Unify local
(on host) and remote (on device) test execution by always going through
`test.run_platform_command()` which uses LLDB's `platform shell <cmd>`
command.
Potential future cleanups: I think `@skipUnlessFeature` decorator could
be used in place of code like this:
```
if not self.isAArch64SME():
self.skipTest("SME must be present.")
if not self.isAArch64SME2():
self.skipTest("SME2 must be present.")
```
This reverts the following commits:
a0a82ee19d757bb36a5883b48b13f3b45f1fb377d2e153981ee2d1bbebbb71cae124427dd879bdc0f3b542e314
Where I had disabled specific tests due to them being flakey on our
Windows on Arm bot.
Clearly this strategy isn't working because
every day I see a new random test failing.
Until something can be done about this, disable
every lldb-dap test on Windows on Arm. The coverage we get is just not
worth spamming contributors
who have nothing to do with lldb-dap.
See #137660
This patch fixes the problem, when after a `setVariable` request
pointers and references to the variable are not updated. VSCode doesn't
send a `variables` request after a `setVariable` request, so we should
trigger it explicitly via`invalidated` event .Also, updated
`writeMemory` request in similar way.
# Usage
This is an optional new command line option to use with `--connection`.
```
--connection-timeout <timeout> When using --connection, the number of seconds to
wait for new connections after the server has started and after all clients
have disconnected. Each new connection will reset the timeout. When the
timeout is reached, the server will be closed and the process will exit.
Not specifying this argument or specifying non-positive values will cause
the server to wait for new connections indefinitely.
```
A corresponding extension setting `Connection Timeout` is added to the
`lldb-dap` VS Code extension.
# Benefits
Automatic release of resources when lldb-dap is no longer being used
(e.g. release memory used by module cache).
# Test
See PR.
I've wanted a utility to create a corefile for test purposes given a bit
of memory and regsters, for a while. I've written a few API tests over
the years that needed exactly this capability -- we have several one-off
Mach-O corefile creator utility in the API testsuite to do this. But
it's a lot of boilerplate when you only want to specify some register
contents and memory contents, to create an API test.
This adds yaml2mach-core, a tool that should build on any system, takes
a yaml description of register values for one or more threads,
optionally memory values for one or more memory regions, and can take a
list of UUIDs that will be added as LC_NOTE "load binary" metadata to
the corefile so binaries can be loaded into virtual address space in a
test scenario.
The format of the yaml file looks like
```
cpu: armv7m
# optionally specify the number of bits used for addressing
# (this line is from a different, 64-bit, yaml file)
addressable-bits:
num-bits: 39
# optionally specify one or more binary UUID and slide/virtual address to be added as an LC_NOTE
# (this line is from a different, 64-bit, yaml file)
binaries:
- name: debug-binary.development
uuid: 67942352-5857-3D3D-90CB-A3F80BA67B04
virtual-address: 0xfffffff01840c000
threads:
- regsets:
- flavor: gpr
registers: [{name: sp, value: 0x2000fe70}, {name: r7, value: 0x2000fe80},
{name: pc, value: 0x0020392c}, {name: lr, value: 0x0020392d}]
memory-regions:
# stack memory
- addr: 0x2000fe70
UInt32: [ 0x0000002a, 0x20010e58, 0x00203923,
0x00000001, 0x2000fe88, 0x00203911,
0x2000ffdc, 0xfffffff9 ]
# instructions of a function
- addr: 0x203910
UInt8: [ 0xf8, 0xb5, 0x04, 0xaf, 0x06, 0x4c, 0x07, 0x49,
0x74, 0xf0, 0x2e, 0xf8, 0x01, 0xac, 0x74, 0xf0 ]
```
and that's all that is needed to specify a corefile where four register
values are specified (the others will be set to 0), and two memory
regions will be emitted.
The memory can be specified as an array of UInt8, UInt32, or UInt64, I
anticipate that some of these corefiles may have stack values
constructed manually and it may be simpler for a human to write them in
a particular grouping of values.
I needed this utility for an upcoming patch for ARM Cortex-M processors,
to create a test for the change. I took the opportunity to remove two of
the "trivial mach-o corefile" creator utilities I've written in the
past, which also restricted the tests to only run on Darwin systems
because I was using the system headers for Mach-O constant values.
rdar://110663219
TLDR
----------
This PR adds `--no-lldbinit` as a new CLI flag to the `lldb-dap`
Motivation
-----------
Rcently Users reported being unable to control `.lldbinit` file sourcing
when debugging through VS Code.
https://github.com/llvm/llvm-project/issues/155802.
VS Code extensions cannot easily inject custom parameters into the DAP
initialize request. Adding `--no-lldbinit` as a CLI flag solves this
problem by allowing the decision to skip `.lldbinit` files to be made at
debugger startup, before any initialization requests are processed.
VS Code extensions can control this behavior by specifying the flag
through `debugAdapterArgs` or similar mechanisms in launch
configurations.
```
{
"type": <extension-type>,
"request": "launch",
"name": "Debug with --no-lldbinit",
"program": "${workspaceFolder}/your-program",
"debugAdapterArgs": ["--no-lldbinit"]
}
```
Summary
----------
This PR introduces a new command-line flag `--no-lldbinit` (with alias
`-x`) to `lldb-dap`. The flag prevents automatic parsing of `.lldbinit`
files during debugger initialization, giving users control over whether
their LLDB initialization scripts are loaded.
### Key Changes:
1. **CLI Option Definition** (`Options.td`): Added the `--no-lldbinit`
flag with `-x` alias
2. **Core Implementation** (`DAP.cpp`): Added support for storing and
using the no-lldbinit flag
3. **Initialization Handler** (`InitializeRequestHandler.cpp`): Modified
to respect the flag during debugger initialization
4. **Main Tool** (`lldb-dap.cpp`): Added argument parsing for the new
flag
5. **Test Infrastructure** (`dap_server.py & lldbdap_testcase.py`):
Enhanced test framework to support additional arguments
Test Plan
---------
### New Test Coverage (`TestDAP_launch.py`)
**Test Method:** `test_no_lldbinit_flag()`
**Test Strategy:**
1. **Setup**: Creates a temporary `.lldbinit` file with specific
settings that would normally be loaded
2. **Execution**: Launches lldb-dap with the `--no-lldbinit` flag
3. **Verification**: Confirms that the settings from `.lldbinit` are NOT
applied, proving the flag works correctly
**Test Environment:**
* Uses a temporary home directory with a custom `.lldbinit` file
* Sets specific LLDB settings (`stop-disassembly-display never`,
`target.x86-disassembly-flavor intel`)
* Launches debug adapter with `--no-lldbinit` flag via `additional_args`
parameter
**Validation Approach:**
* Executes `settings show stop-disassembly-display` command during
initialization
* Verifies the output does NOT contain "never" (which would indicate
`.lldbinit` was sourced)
* Confirms that initialization commands are still executed properly
### Testing Infrastructure Enhancements
**File Modifications:**
* `dap_server.py`: Enhanced to accept `additional_args` parameter for
passing extra CLI flags
* `lldbdap_testcase.py`: Updated `build_and_create_debug_adapter()`
method to support additional arguments and environment variables
### Unit Test Integration
**Unit Test Updates** (`DAPTest.cpp`):
* Added initialization of the new flag in test setup to ensure
consistent test behavior
**Test Run**
<img width="1759" height="1373" alt="Screenshot 2025-08-29 at 5 56
18 PM"
src="https://github.com/user-attachments/assets/769b319a-5009-4ade-aff8-c5f548b38123"
/>
---------
Co-authored-by: Piyush Jaiswal <piyushjais@meta.com>
Improved response Message handling in lldbdap_testcase.py to handle
various formats. Allows for more descriptive error messaging (Provides
useful info even when error details are malformed)
---------
Co-authored-by: Piyush Jaiswal <piyushjais@meta.com>
Starting with https://github.com/llvm/llvm-project/pull/154686 the
compressed_pair children are now wrapped in an anonymous structure.
This patch adjusts the LLDB data-formatters to support that.
Outstanding questions:
1. Should GetChildMemberWithName look through anonymous structures? That
will break users most likely. But maybe introducing a new API is worth
it? Then we wouldnt have to do this awkward passing around of
`anon_struct_index`
2. Do we support the layout without the anonymous structure? It's not
too much added complexity. And we did release that version of libc++, so
there is code out there compiled against it. But there is no great way
of testing it (some of our macOS matrix bots do test it i suppose, but
not in a targeted way). We have the layout "simulator" tests for some of
the STL types which I will adjust.
Re-land the symbol table feature in lldb-dap after it was
[reverted](2b8e806942)
because of a crash in the `aarch64` tests, which was caused by
dereferencing `SBSymbol::GetName` which might return `nullptr` for an
invalid symbol.
This patch reapplies the original commits and adds the missing null
check.
Also adding `skipIfWindows` for the module symbols tests, since LLDB
doesn't recognize the symbols from a.out there.
Originally commited in 362b9d78b4 and then
reverted in cb63b75e32.
This re-lands a subset of the changes to
dap_server.py/DebugCommunication and addresses the python3.10
compatibility issue.
This includes less type annotations since those were the reason for the
failures on that specific version of python.
I've done additional testing on python3.8, python3.10 and python3.13 to
further validate these changes.
Resolves#141955
- Adds data to breakpoints `Source` object, in order for assembly
breakpoints, which rely on a temporary `sourceReference` value, to be
able to resolve in future sessions like normal path+line breakpoints
- Adds optional `instructions_offset` parameter to `BreakpointResolver`
You cannot use a NamedTempFile with an external process because it may
not be flushed to disk. The safest and most portable approach is to
close the file, call the other process and then unlink the file
manually.
Presumably this works fine on Linux, but it fails on Darwin when
targeting remote-linux.
See https://bugs.python.org/issue29573
Fix cross-compilation of test inferiors on Darwin, targeting remote
Linux. This requires specifying the target triple and using LLD for
linking.
Fixes#150806
When debug info categories were set for a test method with the
`@add_test_categories` decorator, they were all added to its
"categories" attribute. If some of these categories were not supported,
`LLDBTestResult.startTest()` skipped all variants of the test method.
For example, the tests in `TestWithLimitDebugInfo.py` use the categories
`dwarf` and `dwo`. However, since `dwo` is not supported on Windows, all
the tests in this file were skipped, even though the tests for `dwarf`
could be run.
Pick the builder for the target platform, not the host platform. This is
necessary when running the test suite remotely on a different platform.
Unlike for Darwin, both Windows and Linux us the default builder, which
is why this went unnoticed on the remote-linux bots.
