| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
set` (#156067)
Someone came up with a clever idea for a new breakpoint type, but we
couldn't figure out how to add it in an ergonomic way because
`breakpoint set` has used up all the short-option characters. And even
if they did find a way to add it, the help for `break set` is so
confusing - because of the way it is implemented - that very few people
would detect the addition.
The basic problem is that `break set` distinguishes amongst the
fundamental breakpoint types it offers by which "required option" you
provide. If you pass a `-a` you are setting an address breakpoint, if
`-n`, `-F`, etc. a symbol name based breakpoint. And so forth. That is
however pretty hard to discern from the option grouping printing from
`help break set`. `break set` also suffers from the problem that it uses
common options in different ways depending on which "required" option is
present, which makes documenting the various behaviors difficult. And as
we run out of single letters it makes extending it difficult to
impossible.
This PR fixes that situation by adding a new command for adding
breakpoints - `break add`. The new command specifies the "breakpoint
types" as subcommands of `break add` rather than distinguishing them by
their being one of the "required" options the way `break set` does. That
both makes it much clearer what the breakpoint types actually are, and
means that the option set can be dedicated to that particular breakpoint
type, and so the help for each is less cluttered, and can be documented
properly for each usage.
Instead of trying to parse the meaning of:
```
(lldb) help break set
Sets a breakpoint or set of breakpoints in the executable.
Syntax: breakpoint set <cmd-options>
Command Options Usage:
breakpoint set [-DHd] -l <linenum> [-G <boolean>] [-C <command>] [-c <expr>] [-Y <source-language>] [-i <count>] [-o <boolean>] [-q <queue-name>] [-t <thread-id>] [-x <thread-index>] [-T <thread-name>] [-R <address>] [-N <breakpoint-name>] [-u <column>] [-f <filename>] [-m <boolean>] [-s <shlib-name>] [-K <boolean>]
breakpoint set [-DHd] -a <address-expression> [-G <boolean>] [-C <command>] [-c <expr>] [-Y <source-language>] [-i <count>] [-o <boolean>] [-q <queue-name>] [-t <thread-id>] [-x <thread-index>] [-T <thread-name>] [-N <breakpoint-name>] [-s <shlib-name>]
breakpoint set [-DHd] -n <function-name> [-G <boolean>] [-C <command>] [-c <expr>] [-Y <source-language>] [-i <count>] [-o <boolean>] [-q <queue-name>] [-t <thread-id>] [-x <thread-index>] [-T <thread-name>] [-R <address>] [-N <breakpoint-name>] [-f <filename>] [-L <source-language>] [-s <shlib-name>] [-K <boolean>]
breakpoint set [-DHd] -F <fullname> [-G <boolean>] [-C <command>] [-c <expr>] [-Y <source-language>] [-i <count>] [-o <boolean>] [-q <queue-name>] [-t <thread-id>] [-x <thread-index>] [-T <thread-name>] [-R <address>] [-N <breakpoint-name>] [-f <filename>] [-L <source-language>] [-s <shlib-name>] [-K <boolean>]
breakpoint set [-DHd] -S <selector> [-G <boolean>] [-C <command>] [-c <expr>] [-Y <source-language>] [-i <count>] [-o <boolean>] [-q <queue-name>] [-t <thread-id>] [-x <thread-index>] [-T <thread-name>] [-R <address>] [-N <breakpoint-name>] [-f <filename>] [-L <source-language>] [-s <shlib-name>] [-K <boolean>]
breakpoint set [-DHd] -M <method> [-G <boolean>] [-C <command>] [-c <expr>] [-Y <source-language>] [-i <count>] [-o <boolean>] [-q <queue-name>] [-t <thread-id>] [-x <thread-index>] [-T <thread-name>] [-R <address>] [-N <breakpoint-name>] [-f <filename>] [-L <source-language>] [-s <shlib-name>] [-K <boolean>]
breakpoint set [-DHd] -r <regular-expression> [-G <boolean>] [-C <command>] [-c <expr>] [-Y <source-language>] [-i <count>] [-o <boolean>] [-q <queue-name>] [-t <thread-id>] [-x <thread-index>] [-T <thread-name>] [-R <address>] [-N <breakpoint-name>] [-f <filename>] [-L <source-language>] [-s <shlib-name>] [-K <boolean>]
breakpoint set [-DHd] -b <function-name> [-G <boolean>] [-C <command>] [-c <expr>] [-Y <source-language>] [-i <count>] [-o <boolean>] [-q <queue-name>] [-t <thread-id>] [-x <thread-index>] [-T <thread-name>] [-R <address>] [-N <breakpoint-name>] [-f <filename>] [-L <source-language>] [-s <shlib-name>] [-K <boolean>]
breakpoint set [-ADHd] -p <regular-expression> [-G <boolean>] [-C <command>] [-c <expr>] [-Y <source-language>] [-i <count>] [-o <boolean>] [-q <queue-name>] [-t <thread-id>] [-x <thread-index>] [-T <thread-name>] [-N <breakpoint-name>] [-f <filename>] [-m <boolean>] [-s <shlib-name>] [-X <function-name>]
breakpoint set [-DHd] -E <source-language> [-G <boolean>] [-C <command>] [-c <expr>] [-Y <source-language>] [-i <count>] [-o <boolean>] [-q <queue-name>] [-t <thread-id>] [-x <thread-index>] [-T <thread-name>] [-N <breakpoint-name>] [-h <boolean>] [-w <boolean>]
breakpoint set [-DHd] -P <python-class> [-k <none>] [-v <none>] [-G <boolean>] [-C <command>] [-c <expr>] [-Y <source-language>] [-i <count>] [-o <boolean>] [-q <queue-name>] [-t <thread-id>] [-x <thread-index>] [-T <thread-name>] [-N <breakpoint-name>] [-f <filename>] [-s <shlib-name>]
breakpoint set [-DHd] -y <linespec> [-G <boolean>] [-C <command>] [-c <expr>] [-Y <source-language>] [-i <count>] [-o <boolean>] [-q <queue-name>] [-t <thread-id>] [-x <thread-index>] [-T <thread-name>] [-R <address>] [-N <breakpoint-name>] [-m <boolean>] [-s <shlib-name>] [-K <boolean>]
```
We instead offer:
```
(lldb) help break add
Commands to add breakpoints of various types
Syntax: breakpoint add
Access the breakpoint search kernels built into lldb. Along with specifying the
search kernel, each breakpoint add operation can specify a common set of
"reaction" options for each breakpoint. The reaction options can also be
modified after breakpoint creation using the "breakpoint modify" command.
The following subcommands are supported:
address -- Add breakpoints by raw address
exception -- Add breakpoints on language exceptions. If no language is specified, break on exceptions for all supported languages
file -- Add breakpoints on lines in specified source files
name -- Add breakpoints matching function or symbol names
pattern -- Add breakpoints matching patterns in the source text Expects 'raw' input (see 'help raw-input'.)
scripted -- Add breakpoints using a scripted breakpoint resolver.
For more help on any particular subcommand, type 'help <command> <subcommand>'.
```
The individual subcommand helps are also easier to read. They are still
a little too verbose because they all repeat the options for the
`reactions`. A general fix for our help system would be when a command
incorporates an OptionGroup whole into the command options, help would
show the option group name - which you could separately look up. But
even without that:
```
(lldb) help br a a
Add breakpoints by raw address
Syntax: breakpoint add address <cmd-options> <address> [<address> [...]]
Command Options Usage:
breakpoint add address [-DHde] [-G <boolean>] [-C <command>] [-c <expr>] [-Y <source-language>] [-i <count>] [-o <boolean>] [-q <queue-name>] [-t <thread-id>] [-x <thread-index>] [-T <thread-name>] [-N <breakpoint-name>] [-s <shlib-name>] <address> [<address> [...]]
-C <command> ( --command <command> )
A command to run when the breakpoint is hit, can be provided more than once, the commands will be run in left-to-right order.
-D ( --dummy-breakpoints )
Act on Dummy breakpoints - i.e. breakpoints set before a file is provided, which prime new targets.
-G <boolean> ( --auto-continue <boolean> )
The breakpoint will auto-continue after running its commands.
-H ( --hardware )
Require the breakpoint to use hardware breakpoints.
-N <breakpoint-name> ( --breakpoint-name <breakpoint-name> )
Adds this name to the list of names for this breakpoint. Can be specified more than once.
-T <thread-name> ( --thread-name <thread-name> )
The breakpoint stops only for the thread whose thread name matches this argument.
-Y <source-language> ( --condition-language <source-language> )
Specifies the Language to use when executing the breakpoint's condition expression.
-c <expr> ( --condition <expr> )
The breakpoint stops only if this condition expression evaluates to true.
-d ( --disable )
Disable the breakpoint.
-e ( --enable )
Enable the breakpoint.
-i <count> ( --ignore-count <count> )
Set the number of times this breakpoint is skipped before stopping.
-o <boolean> ( --one-shot <boolean> )
The breakpoint is deleted the first time it stop causes a stop.
-q <queue-name> ( --queue-name <queue-name> )
The breakpoint stops only for threads in the queue whose name is given by this argument.
-s <shlib-name> ( --shlib <shlib-name> )
Set the breakpoint at an address relative to sections in this shared library.
-t <thread-id> ( --thread-id <thread-id> )
The breakpoint stops only for the thread whose TID matches this argument. The token 'current' resolves to the current thread's ID.
-x <thread-index> ( --thread-index <thread-index> )
The breakpoint stops only for the thread whose index matches this argument.
This command takes options and free-form arguments. If your arguments resemble option specifiers (i.e., they start with a - or --), you must use ' --
' between the end of the command options and the beginning of the arguments.
```
is pretty readable.
|
|
This aligns with the DAP
[specification](https://microsoft.github.io/debug-adapter-protocol//specification.html#Base_Protocol_ProtocolMessage)
Force it to be an error in test cases.
|
|
Literal[T] (#170182)
Pyright automatically deduces these functions to return `Literal["foo"]`
since the implementation returns "foo". This causes any overload that
returns a different literal or a string to report that they're
overloaded in an incompatible way. By correctly annotating them as
returning str, the overloads can return different strings without this
error
I was encountering these a lot while writing tests for my downstream
target
|
|
|
|
This patch adds support for `dataBreakpointInfoBytes` capability from
DAP. You can test this feature in VSCode (`Add data breakpoint at
address` button in breakpoints tab).
|
|
While taking a look at the code of lldb test-suite packages, I have
noticed that in `get_triple_str` in `darwin.py` env is added inside a
`components` list, which is probably supposed to be `component` (defined
on the line 61).
Signed-off-by: Nikita B <n2h9z4@gmail.com>
|
|
## Summary:
This change introduces a `DAPSessionManager` to enable multiple DAP
sessions to share debugger instances when needed, for things like child
process debugging and some scripting hooks that create dynamically new
targets.
Changes include:
- Add `DAPSessionManager` singleton to track and coordinate all active DAP
sessions
- Support attaching to an existing target via its globally unique target
ID (targetId parameter)
- Share debugger instances across sessions when new targets are created
dynamically
- Refactor event thread management to allow sharing event threads
between sessions and move event thread and event thread handlers to `EventHelpers`
- Add `eBroadcastBitNewTargetCreated` event to notify when new targets are
created
- Extract session names from target creation events
- Defer debugger initialization from 'initialize' request to
'launch'/'attach' requests. The only time the debugger is used currently
in between its creation in `InitializeRequestHandler` and the `Launch`
or `Attach` requests is during the `TelemetryDispatcher` destruction
call at the end of the `DAP::HandleObject` call, so this is safe.
This enables scenarios when new targets are created dynamically so that
the debug adapter can automatically start a new debug session for the
spawned target while sharing the debugger instance.
## Tests:
The refactoring maintains backward compatibility. All existing DAP test
cases pass.
Also added a few basic unit tests for DAPSessionManager
```
>> ninja DAPTests
>> ./tools/lldb/unittests/DAP/DAPTests
>>./bin/llvm-lit -v ../llvm-project/lldb/test/API/tools/lldb-dap/
```
|
|
This patch adds support for format option in the `evaluate` request
according to
[DAP](https://microsoft.github.io/debug-adapter-protocol/specification#Requests_Evaluate)
specification. Also, fixed typo in `LLDB_DAP_INVALID_VARRERF` constant.
|
|
supports -fbounds-safety (#169112)
This patch makes it possible to detect in LLDB shell and API tests if
`-fbounds-safety` is supported by the compiler used for testing. The
motivation behind this is to allow upstreaming
https://github.com/swiftlang/llvm-project/pull/11835 but with the tests
disabled in upstream because the full implementation of -fbounds-safety
isn't available in Clang yet.
For shell tests when -fbounds-safety is available the
`clang-bounds-safety` feature is available which means tests can be
annotated with `# REQUIRES: clang-bounds-safety`.
API tests that need -fbounds-safety support in the compiler can use the
new `@skipUnlessBoundsSafety` decorator.
rdar://165225507
|
|
During the initialization sequence in our tests the first 'threads'
response sould only be kept if the process is actually stopped,
otherwise we will have stale data.
In VSCode, during the debug session startup sequence immediately after
'configurationDone' a 'threads' request is made. This initial request is
to retrieve the main threads name and id so the UI can be populated.
However, in our tests we do not want to cache this value unless the
process is actually stopped. We do need to make this initial request
because lldb-dap is caching the initial thread list during
configurationDone before the process is resumed. We need to make this
call to ensure the cached initial threads are purged.
I noticed this in a CI job for another review
(https://github.com/llvm/llvm-project/actions/runs/19348261989/job/55353961798)
where the tests incorrectly failed to fetch the threads prior to
validating the thread names.
|
|
https://green.lab.llvm.org/job/llvm.org/view/LLDB/job/lldb-cmake-sanitized/2744/consoleText
|
|
Adding structured types for the evaluate request handler.
This should be mostly a non-functional change. I did catch some spelling
mistakes in our tests ('variable' vs 'variables').
|
|
|
|
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.
|
|
(#165892)
… concurrency." (#165688)""
This reverts commit 17dbd8690e36f8e514fb47f4418f78420d0fc019.
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.
|
|
Fixes 17dbd8690e36f8e514fb47f4418f78420d0fc019 (again)
|
|
Fixes 17dbd8690e36f8e514fb47f4418f78420d0fc019.
|
|
(#165688)"
This reverts commit f205be095609aa61dfac3ae729406e0af2dcd15f.
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.
|
|
(#165688)
Reverts llvm/llvm-project#165496
Due to flaky failures on Arm 32-bit since this change. Detailed in
https://github.com/llvm/llvm-project/pull/165496#issuecomment-3467209089.
|
|
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.
|
|
stdlib (#164462)
On linux if you specify the an external libc++ and clang will still link
to the system's libc++. This patch fixes that.
Fixes https://github.com/llvm/llvm-project/issues/116040
|
|
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
|
|
When [1] landed, gdbremote server tests had to be updated to understand
the new packet field.
[1]: https://github.com/llvm/llvm-project/pull/163249
|
|
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
```
|
|
shlex.join is available in Python 3.8, which is the LLVM Project's
minimum version.
https://docs.python.org/3/library/shlex.html#shlex.join
|
|
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 1902ffd9a4914d4cd03e200ca9050bf3b1564c19 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.
|
|
inferior (#162064)
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.
|
|
Support for `qMemTags` packet in debugserver which allows usage of
LLDB's `memory tag read` on Darwin.
|
|
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:
a0a82ee19d6f2ff1013407ba4c973bfe5428423f
757bb36a58c7d7151a28c6a5fc7caa2e1f44de87
83b48b13f3a70bf56053e92593270c519859cfd7
b45f1fb377636a34c01e34b89341c97d19975554
d2e153981e62fb2ea781ef456ff744f9893e0733
e2d1bbebbb099c7010a31fad62a9128166ef14a0
71cae12442e7476e6397fd73db05e127bfe2d035
7dd879bdc01297a551196a60bb5a5a90ca4dd1ed
f3b542e3148cfc244f63cb7c987ccf8ebc71942b
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 adds support for the `memory` event from the
[DAP](https://microsoft.github.io/debug-adapter-protocol/specification#Events_Memory).
After this event is emitted, VS Code refetches the corresponding memory
range and re-renders the memory view. I think this patch and
[PR](https://github.com/llvm/llvm-project/pull/151884) can improve
experience for users who use `setVariable` request.
|
|
As far as I understand, lldb-dap does not currently support stdio
redirection. I have added support for this via a new field in the launch
configuration named `stdio`. It was inspired by the same named field in
[CodeLLDB](https://github.com/vadimcn/codelldb/blob/master/MANUAL.md#stdio-redirection).
|
|
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.
|
|
This patch replaces `list` with its `typing` implementation, i.e
`list[str]` becomes `List[str]`.
[Type hinting generic in the standard collection were introduced in
Python 3.9](https://peps.python.org/pep-0585/), however the minimum
supported Python version for lldb is 3.8. This patch will unblock the
[bots for Ubuntu
20.04](https://ci.swift.org/view/Swift%20rebranch/job/oss-swift-rebranch-package-ubuntu-20_04/2847/consoleText),
which run on Python 3.8.
|
|
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.
|
|
In an upcoming patch we'll start supporting a new compressed_pair
layout. This refactor will make it easier to add tests for that new
layout.
|
