lldb-server tests are a very special subclass of "api" tests. As they
communicate with lldb-server directly, they don't actually need most of
facilities provided by our TestBase class. In particular, they don't
need the ability to fork debug info flavours of tests (but they could
use debug server flavours).
This makes them inherit from "Base" instead. This avoids the need to
explicitly mark these tests as NO_DEBUG_INFO_TEST_CASE. Two additional
necessary tweaks were:
- move run_platform_command to the base (Base) class. This is used in
one test, and can be generally useful when running tests remotely.
- add a "build" method, forwarding to buildDefault. This is to avoid
updating each test case to use buildDefault (also, "build" sounds
better). It might be interesting to refactor the (Test)Base classes so
that all debug info flavour handling happens in TestBase, and the Base
class provides a simple build method automatically.
Kill (rather than detach) form the inferior if debugserver loses its
connection to lldb to prevent zombie processes.
Differential revision: https://reviews.llvm.org/D92908
TestLldbGdbServer.py testcases are timing out on LLDB/AArch64 Linux
buildbot since recent changes. I am temporarily increasing
DEFAULT_TIMEOUT to 20 seconds to see impact.
Now that the class does not use a thread, the name is no longer
appropriate. Rename the class to "Server" and make it a long-lived
object (instead of recreating it for every expect_gdbremote_sequence
call). The idea is to make this class a wrapper for all communication
with debug/lldb-server. This will enable some additional cleanups as we
had some duplication between socket_pump non-pump code paths.
Also squeeze in some small improvements:
- use python-level timeouts on sockets instead of the manual select
calls
- use byte arrays instead of strings when working with raw packets
Test runs log some of their output to files inside the LLDB session dir. This
session dir is shared between all tests, so all the tests have to make sure they
choose a unique file name inside that directory. We currently choose by default
`<test-class-name>-<test-method-name>` as the log file name. However, that means
that if not every test class in the test suite has a unique class name, then we
end up with a race condition as two tests will try to write to the same log
file.
I already tried in D83767 changing the format to use the test file basename
instead (which we already require to be unique for some other functionality),
but it seems the code for getting the basename didn't work on Windows.
This patch instead just changes that dotest stores the log files in the build
directory for the current test. We know that directory is unique for this test,
so no need to generate some unique file name now. Also removes all the
environment vars and parameters related to the now unused session dir.
The new log paths now look like this for a failure in 'TestCppOperators`:
```
./lldb-test-build.noindex/lang/cpp/operators/TestCppOperators.test_dwarf/Failure.log
./lldb-test-build.noindex/lang/cpp/operators/TestCppOperators.test_dsym/Failure.log
./lldb-test-build.noindex/lang/cpp/operators/TestCppOperators.test_gmodules/Failure.log
```
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D92498
This patch carries forward our aim to remove offset field from qRegisterInfo
packets and XML register description. I have created a new function which
returns if offset fields are dynamic meaning client can calculate offset on
its own based on register number sequence and register size. For now this
function only returns true for NativeRegisterContextLinux_arm64 but we can
test this for other architectures and make it standard later.
As a consequence we do not send offset field from lldb-server (arm64 for now)
while other stubs dont have an offset field so it wont effect them for now.
On the client side we have replaced previous offset calculation algorithm
with a new scheme, where we sort all primary registers in increasing
order of remote regnum and then calculate offset incrementally.
This committ also includes a test to verify all of above functionality
on Arm64.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D91241
This patch ovverides GetExpeditedRegisterSet for
NativeRegisterContextLinux_arm64 to send vector granule register in
expedited register set if SVE mode is selected.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D82855
A separate thread is not necessary, as we can do its work on the main
thread, while waiting for the packet to arrive. This makes the code
easier to understand and debug (other simplifications are possible too,
but I'll leave that for separate patches). The new implementation also
avoids busy waiting.
This extends the "memory region" command to
show tagged regions on AArch64 Linux when the MTE
extension is enabled.
(lldb) memory region the_page
[0x0000fffff7ff8000-0x0000fffff7ff9000) rw-
memory tagging: enabled
This is done by adding an optional "flags" field to
the qMemoryRegion packet. The only supported flag is
"mt" but this can be extended.
This "mt" flag is read from /proc/{pid}/smaps on Linux,
other platforms will leave out the "flags" field.
Where this "mt" flag is received "memory region" will
show that it is enabled. If it is not or the target
doesn't support memory tagging, the line is not shown.
(since majority of the time tagging will not be enabled)
Testing is added for the existing /proc/{pid}/maps
parsing and the new smaps parsing.
Minidump parsing has been updated where needed,
though it only uses maps not smaps.
Target specific tests can be run with QEMU and I have
added MTE flags to the existing helper scripts.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D87442
This adds `expect_var_path` to test variable paths so we no longer have to
use `frame var` and find substrs in the command output. The behaviour
is identical with `expect_expr` (and it also uses the same checking backend),
but it instead calls `GetValueForVariablePath` to evaluate the string as a variable
path.
Also rewrites a few of the tests that previously used `frame variable` to use
`expect_var_path`.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D90450
Those two decorators have identical behaviour. This removes
`not_remote_testsuite_ready` as `skipIfRemote` seems more consistent with the
other decorator names we have
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D89376
Make category-specifying files visible. There is really no good reason
to keep them hidden, and having them visible increases the chances
that someone will actually spot them.
Differential Revision: https://reviews.llvm.org/D91065
Replace the plethora of ObjC-implied 'skipUnlessDarwin' decorators
with marking tests as 'objc' category (whenever missing), and skip all
ObjC tests on non-Darwin platforms. I have used '.categories' file
wherever it was present already or all (>1) tests were relying on ObjC,
and explicit add_test_categories() where there was only one test.
Differential Revision: https://reviews.llvm.org/D91056
Use positive logic (i.e. llgs_platform/debugserver_platform) for
indicating which platforms use the particular server variant.
Deduplicate the lists — it is rather expected that none of the platforms
using LLGS would use debugserver.
Differential Revision: https://reviews.llvm.org/D90875
Depends on D89408.
This diff finally implements trace decoding!
The current interface is
$ trace load /path/to/trace/session/file.json
$ thread trace dump instructions
thread #1: tid = 3842849, total instructions = 22
[ 0] 0x40052d
[ 1] 0x40052d
...
[19] 0x400521
$ # simply enter, which is a repeat command
[20] 0x40052d
[21] 0x400529
...
This doesn't do any disassembly, which will be done in the next diff.
Changes:
- Added an IntelPTDecoder class, that is a wrapper for libipt, which is the actual library that performs the decoding.
- Added TraceThreadDecoder class that decodes traces and memoizes the result to avoid repeating the decoding step.
- Added a DecodedThread class, which represents the output from decoding and that for the time being only stores the list of reconstructed instructions. Later it'll contain the function call hierarchy, which will enable reconstructing backtraces.
- Added basic APIs for accessing the trace in Trace.h:
- GetInstructionCount, which counts the number of instructions traced for a given thread
- IsTraceFailed, which returns an Error if decoding a thread failed
- ForEachInstruction, which iterates on the instructions traced for a given thread, concealing the internal storage of threads, as plug-ins can decide to generate the instructions on the fly or to store them all in a vector, like I do.
- DumpTraceInstructions was updated to print the instructions or show an error message if decoding was impossible.
- Tests included
Differential Revision: https://reviews.llvm.org/D89283
The new FreeBSDRemote plugin has reached feature parity on i386
and amd64 targets. Use it by default on these architectures, while
allowing the use of the legacy plugin via FREEBSD_LEGACY_PLUGIN envvar.
Revisit the method of switching plugins. Apparently, the return value
of PlatformFreeBSD::CanDebugProcess() is what really decides whether
the legacy or the new plugin is used.
Update the test status. Reenable the tests that were previously
disabled on FreeBSD and do not cause hangs or are irrelevant to FreeBSD.
Mark all tests that fail reliably as expectedFailure. For now, tests
that are flaky (i.e. produce unstable results) are left enabled
and cause unpredictable test failures.
Differential Revision: https://reviews.llvm.org/D90757
In D89056 the default value for architecture was moved to `build` so that
all called functions see the same architecture value. It seems there are a
few functions that call buildDefault directly (and not via build), so
on some test configurations that set a custom arch value the architecture
value is no longer available.
This just adds the architecture code from build to buildDefault to get
the bots green again while I'm looking for a better solution.
This just adds the simulator platforms to the lldbplatform enumerations
and the respective test decorator.
The platform names for the simulator are just the SDK names since D85537, so
that's why we are not using LLDB's usual platform names here (e.g., SDK =
"iphonesimulator" vs LLDB platform ="ios-simulator").
Also removes the duplicate platform enumaration in lldbplatformutil.py.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D89694
This originally broke the TestQuoting which explicitly called buildDefault
instead of calling build() and marking the test as no_debug_info_test.
TestQuoting has been rewritten by now and is using `build`, so this should now
pass on all platforms.
Original summary:
The Darwin builder currently assumes in `getArchCFlags` that the passed `arch`
value is an actual string it can string.join with vendor/os/version/env strings:
```
triple = '-'.join([arch, vendor, os, version, env])
```
However this is not true for most tests as we just pass down the `arch=None`
default value from `TestBase.build`. This causes that if we actually end up in
this function we just error out when concatenating `None` with the other actual
strings of vendor/os/version/env. What we should do instead is check that if
there is no test-specific architecture that we fall back to the configuration's
architecture value.
It seems we already worked around this in `builder.getArchSpec` by explicitly
falling back to the architecture specified in the configuration.
This patch just moves this fallback logic to the top `build` function so that it
affects all functions called from `TestBase.build`.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D89056
This is a follow up to D88792 which found an issue in a call to PExpectTest's
expect function that allows passing a string to the `substrs` parameter. However
this issue was found by just grepping and TestPExpect's expect function is still
accepting a single string as a value to `substrs`.
This patch adds the same sanity check that D88792 added to the PExpectTest's
implementation of `expect` and also adds a small test for it.
Reviewed By: kastiglione, JDevlieghere
Differential Revision: https://reviews.llvm.org/D89302
The intention is not to allow stop-hook commands to query the
user, so this is correct. It also works around a deadlock in
switching to the Python Session to execute python based commands
in the stop hook when the Debugger stdin is backed by a FILE *.
Differential Revision: https://reviews.llvm.org/D90332
This fixes an flakyness is all gdb-remote tests. These tests have been
(mildly) flaky since we started using "localhost" instead of 127.0.0.1
in the test suite. The reason is that lldb-server needs to create two
sockets (v4 and v6) to listen for localhost connections. The algorithm
it uses first tries to select a random port (bind(localhost:0)) for the
first address, and then bind the same port for the second one.
The creating of the second socket can fail as there's no guarantee that
port will be available -- it seems that the (linux) kernel tries to
choose an unused port for the first socket (I've had to create thousands
of sockets to reproduce this reliably), but this can apparantly fail
when the system is under load (and our test suite creates a _lot_ of
sockets).
The socket creationg operation is considered successful if it creates at
least one socket is created, but the test harness has no way of knowing
which one it is, so it can end up connecting to the wrong address.
I'm not aware of a way to atomically create two sockets bound to the
same port. One way to fix this would be to make lldb-server report the
address is it listening on instead of just the port. However, this would
be a breaking change and it's not clear to me that's worth it (the
algorithm works pretty well under normal circumstances).
Instead, this patch sidesteps that problem by using "reverse"
connections. This way, the test harness is responsible for creating the
listening socket so it can pass the address that it has managed to open.
It also results in much simpler code overall.
To preserve test coverage for the named pipe method, I've moved the
relevant code to a dedicated test. To avoid original problem, this test
passes raw addresses (as obtained by getaddrinfo(localhost)) instead of
"localhost".
Differential Revision: https://reviews.llvm.org/D90313
The Darwin builder currently assumes in `getArchCFlags` that the passed `arch`
value is an actual string it can string.join with vendor/os/version/env strings:
```
triple = '-'.join([arch, vendor, os, version, env])
```
However this is not true for most tests as we just pass down the `arch=None`
default value from `TestBase.build`. This causes that if we actually end up in
this function we just error out when concatenating `None` with the other actual
strings of vendor/os/version/env. What we should do instead is check that if
there is no test-specific architecture that we fall back to the configuration's
architecture value.
It seems we already worked around this in `builder.getArchSpec` by explicitly
falling back to the architecture specified in the configuration.
This patch just moves this fallback logic to the top `build` function so that it
affects all functions called from `TestBase.build`.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D89056
It seems that if codesigning the test executables with the
`com.apple.private.security.no-sandbox` entitlement then the simulator refuses
to launch them and every test fails with `Process launch failed: process exited
with status -1 (no such process.)`.
This patch checks if we're trying to run the test suite on the simulator and
then avoids signing the executable with `no-sandbox`.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D89052
If the SDK name passed to dotest can't be found by `xcrun` we silently fall back
to the default SDK. This leads to rather cryptic errors being reported later on
when linking the actual test executables.
Instead just directly log and abort when this situation is encountered and
inform the user about the invalid argument.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D89053
This patch fixes a few issues seen when running `ninja check-lldb` in a Release build with VS2017:
- Some binaries couldn't be found (such as lldb-vscode.exe), because .exe wasn't appended to the file name.
- Many tests used to fail since our installed locale is in French - the OS error messages are not emitted in English.
- Our codepage being Windows-1252, python failed to decode some error messages with accentuations.
Differential Revision: https://reviews.llvm.org/D88975
Simplify the logic of parsing the lldb -P output to find the python
path. This removes the special handling for the LLDB.framework case and
instead of pattern matching known errors focus on finding a directory
path that contains an __init__.py.
Differential revision: https://reviews.llvm.org/D88840
Add preconditions to `TestBase.expect()` that catch semantically invalid calls
that happen to succeed anyway. This also fixes the broken callsites caught by
these checks.
This prevents the following incorrect calls:
1. `self.expect("lldb command", "some substr")`
2. `self.expect("lldb command", "assert message", "some substr")`
Differential Revision: https://reviews.llvm.org/D88792
Per the DAP spec for SetBreakpoints [1], the way to clear breakpoints is: `To clear all breakpoint for a source, specify an empty array.`
However, leaving the breakpoints field unset is also a well formed request (note the `breakpoints?:` in the `SetBreakpointsArguments` definition). If it's unset, we have a couple choices:
1. Crash (current behavior)
2. Clear breakpoints
3. Return an error response that the breakpoints field is missing.
I propose we do (2) instead of (1), and treat an unset breakpoints field the same as an empty breakpoints field.
[1] https://microsoft.github.io/debug-adapter-protocol/specification#Requests_SetBreakpoints
Reviewed By: wallace, labath
Differential Revision: https://reviews.llvm.org/D88513
When running in an ipv6-only environment where `AF_INET` sockets are not available, many lldb tests (mostly gdb remote tests) fail because things like `127.0.0.1` don't work there.
Use `localhost` instead of `127.0.0.1` whenever possible, or include a fallback of creating `AF_INET6` sockets when `AF_INET` fails.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D87333
A few fixes while trying to figure out why tests are being skipped for arsenm:
- We check `$compiler -v`, but `-v` is `--verbose`, not `--version`. Use the long flag name.
- We check all lines matching `version ...`, but we should exit early for the first version string we see (which should be the main one). I'm not sure if this is the issue, but perhaps this is causing some users to skip some tests if another "version ..." is showing up later.
- Having `\.` in a python string is triggering pylint warnings, because it should be escaped as a regex string, e.g. `r'\.' However, `.` in a character class does not need to be escaped, as it matches only a literal `.` in that context.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D88051
Register the `faulthandler` module so we can see what lldb tests are doing when they misbehave (e.g. run under a test runner that sets a timeout). This will print a stack trace for the following signals:
- `SIGSEGV`, `SIGFPE`, `SIGABRT`, `SIGBUS`, and `SIGILL` (via `faulthandler.enable()`)
- `SIGTERM` (via `faulthandler.register(SIGTERM)`) [This is what our test runners sends when it times out].
The only signal we currently handle is `SIGINT` (via `unittest2.signals.installHandler()`) so there should be no overlap added by this patch.
Because this import is not available until python3, and the `register()` method is not available on Windows, this is enabled defensively.
This should have absolutely no effect when tests are passing (or even normally failing), but can be observed by running this while ninja is running:
```
kill -s SIGTERM $(ps aux | grep dotest.py | head -1 | awk '{print $2}')
```
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D87637
targetHasSVE helper function was added to test for availability of SVE support
by connected platform. We now intend to use this function in other testcases
and I am moving it to a generic location in lldbtest.py to allow usage by
other upcoming testcases.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D86872
This updates the errors reported by expect()
to something like:
```
Ran command:
"help"
Got output:
Debugger commands:
<...>
Expecting start string: "Debugger commands:" (was found)
Expecting end string: "foo" (was not found)
```
(see added tests for more examples)
This shows the user exactly what was run,
what checks passed and which failed. Along with
whether that check was supposed to pass.
(including what regex patterns matched)
These lines are also output to the test
trace file, whether the test passes or not.
Note that expect() will still fail at the first failed
check, in line with previous behaviour.
Also I have flipped the wording of the assert
message functions (.*_MSG) to describe failures
not successes. This makes more sense as they are
only shown on assert failures.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D86792
Pavel Labath