This patch refactors the way we check for the windows version in the
`@skipIfWindows` decorator.
The new logic reuses the `expectedCompilerVersion` method logic for the
parsing and comparison of the version.
When using --platform remote-* options, explicitly clear the libcxx
configuration variables instead of just warning and continuing with
potentially set values. This prevents the test suite from attempting to
use custom libcxx paths on remote platforms where they're not
applicable.
Also initialize libcxx variables to None when not specified, ensuring a
clean state regardless of how the arguments are parsed.
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
Flag changes reverted as those require the X86 target to be enabled.
Don't have time to test fixes as I need to go to sleep so will revert for now.
Reverts: 423919d31f4b55f22b09cd5066534f7c91e71d4b
Implementation files using the Intel syntax typically explicitly specify it.
Do the same for the few files using AT&T syntax.
This enables building LLVM with `-mllvm -x86-asm-syntax=intel` in one's Clang config files
(i.e. a global preference for Intel syntax).
When you run an expression and the result has a dynamic type that is
different from the expression's static result type, we print the result
variable using the dynamic type, but at present when you use the result
variable in an expression later on, we only give you access to the
static type. For instance:
```
(lldb) expr MakeADerivedReportABase()
(Derived *) $0 = 0x00000001007e93e0
(lldb) expr $0->method_from_derived()
^
error: no member named 'method_from_derived' in 'Base'
(lldb)
```
The static return type of that function is `Base *`, but we printed that
the result was a `Derived *` and then only used the `Base *` part of it
in subsequent expressions. That's not very helpful, and forces you to
guess and then cast the result types to their dynamic type in order to
be able to access the full type you were returned, which is
inconvenient.
This patch makes lldb retain the dynamic type of the result variable
(and ditto for persistent result variables).
It also adds more testing of expression result variables with various
types of dynamic values, to ensure we can access both the ivars and
methods of the type we print the result as.
This adjusts the behavior of running dap_server.py directly to better
support the current state of development. A few parts of the 'main' body
were stale and not functional.
These improvements include:
* Instead of the custom tracefile / replay file parsing logic, I
adjusted the replay helper to handle parsing lldb-dap log files created
with the `LLDBDAP_LOG` env variable, allowing you to more easily run a
failing test like: `python3
lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
--adapter lldb-dap -r
lldb-test-build.noindex/tools/lldb-dap/console/TestDAP_console.test_custom_escape_prefix/dap.txt`
* Migrated argument parsing to `argparse`, that is in all verisons of
py3+ and has a few improvements over `optparse`.
* Corrected the existing arguments and updated `run_vscode` >
`run_adapter`. You can use this for simple debugging like: `xcrun
python3 lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
--adapter=lldb-dap --adapter-arg='--pre-init-command' --adapter-arg
'help' --program a.out --init-command 'help'`
This patch converts the `jit-loader_rtdyld_elf.test` test from a Shell
test to an API test.
This test is timing out in CI on Windows and the hang cannot be
reproduced at desk. Converting it to an API test would allow us to
instrument it better in order to trace the failure.
DAP tests easily timeout when the computer is under-load.
This is easily noticeable if you run the test in a loop a compile llvm.
or running the test on slower CI/machines.
This affects mostly the `DAP_launch`, `DAP_attach`,
`DAP_restart_console` and occasionally `DAP_output` tests.
Would lead in the direction of enabling some of the test on windows.
```
File "/Volumes/workspace/Dev/llvm-project/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py", line 1140, in request_launch
return self._send_recv(command_dict)
File "/Volumes/workspace/Dev/llvm-project/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py", line 548, in _send_recv
raise ValueError(f"no response for {request!r}")
ValueError: no response for {'command': 'launch', 'type': 'request', 'arguments': {'program': '/Volumes/workspace/Dev/llvm-build/release/lldb-test-build.noindex/tools/lldb-dap/restart/TestDAP_restart_console.test_basic_functionality/a.out', 'initCommands': ['settings clear --all', 'settings set symbols.enable-external-lookup false', 'settings set target.inherit-tcc true', 'settings set target.disable-aslr false', 'settings set target.detach-on-error false', 'settings set target.auto-apply-fixits false', 'settings set plugin.process.gdb-remote.packet-timeout 60', 'settings set symbols.clang-modules-cache-path "/Volumes/workspace/Dev/llvm-build/release/lldb-test-build.noindex/module-cache-lldb"', 'settings set use-color false', 'settings set show-statusline false'], 'console': 'integratedTerminal', 'disableASLR': False, 'enableAutoVariableSummaries': False, 'enableSyntheticChildDebugging': False, 'displayExtendedBacktrace': False}, 'seq': 2}
Config=arm64-/Volumes/workspace/Dev/llvm-build/release/bin/clang
----------------------------------------------------------------------
Ran 2 tests in 28.579s
```
Increase the DEFAULT_TIMEOUT from 10 to 50
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.
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 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.
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.
… 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.
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.
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 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.
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:
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
