Explicitly check whether we are building debugserver for arm64e. To
debug an arm64e binary, debugserver itself needs to be an arm64e
process.
This PR eliminates the possibility of configuring LLDB with Right now,
it's possible to configure CMake with
`LLDB_ENABLE_ARM64E_DEBUGSERVER=Off` and the decorator wouldn't account
for that.
the ubsan decorator previously assumes the platform is macOS.
macOS has an extra underscore in symbols names match two or more.
uses the llvm-nm that is built instead of the system's nm.
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>
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
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.
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
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
We emit a warning when running the test suite remotely that says the
libcxx arguments will be ignored, but because they're set outside the
conditional block, we're not actually do this. Fix the logic by moving
the configuration in the conditional else-block.
This PR adds type summaries for
`std::{string,wstring,u8string,u16string,u32string}` from the MSVC STL.
See https://github.com/llvm/llvm-project/issues/24834 for the MSVC STL
issue.
The following changes were made:
- `dotest.py` now detects if the MSVC STL is available. It does so by
looking at the target triple, which is an additional argument passed
from Lit. It specifically checks for `windows-msvc` to not match on
`windows-gnu` (i.e. MinGW/Cygwin).
- (The main part): Added support for summarizing `std::(w)string` from
MSVC's STL. Because the type names from the libstdc++ (pre C++ 11)
string types are the same as on MSVC's STL, `CXXCompositeSummaryFormat`
is used with two entries, one for MSVC's STL and one for libstdc++.
With MSVC's STL, `std::u{8,16,32}string` is also handled. These aren't
handled for libstdc++, so I put them in `LoadMsvcStlFormatters`.
In lldb-dap, we have existing tests that are known to be unstable when
lldb and lldb-dap are built in the Debug configuration.
This decorator lets us skip those tests in CI jobs that are to slow with
those configurations.
This was split out from #140777 to make the patches smaller.
This patch adds --platform-available-ports option to the dotest.py
script to avoid hardcoded gdb ports in lldb testsuite.
Currently, this option could be helpful in GdbRemoteTestCases (e.g.
TestLldbGdbServer, TestNonStop, TestGdbRemoteThreadsInStopReply,
TestGdbRemotePlatformFile, TestGdbRemote_vCont)
Many LLDB's dotest.py based tests require the `make` tool. If it's not found in Path, they fail with an obscure error and show up as `UNRESOLVED`. On Windows, llvm-lit takes care of MSYS based testing tools like cat, printf, etc., but `make` is not part of that. Let's catch the situation early and check for it at configuration time.
This error isn't fatal: It should fail the build, but not immediately stop the configuration process. There might be other issues further down the line that can be caught in the same buildbot run.
In #102185, toolchain detection for API tests has been rewritten in
Python. Tools paths for tests there are determined from compiler path.
Here tools are taken from `--llvm-tools-dir` dotest.py argument, which
by default refers to the LLVM build directory, unless they are
explicitly redefined in environment variables. It helps to minimize
external dependencies and to maximize the reproducibility of the build.
from PEP8
(https://peps.python.org/pep-0008/#programming-recommendations):
> Comparisons to singletons like None should always be done with is or
is not, never the equality operators.
Co-authored-by: Eisuke Kawashima <e-kwsm@users.noreply.github.com>
This argument allows to specify the path to make which is used by
LLDB API tests to compile test programs.
It might come in handy for setting up cross-platform remote runs of API tests on Windows host.
It can be used to override the make path of LLDB API tests using `LLDB_TEST_USER_ARGS` argument:
```
cmake ...
-DLLDB_TEST_USER_ARGS="...;--make;C:\\Path\\to\\make.exe;..."
...
```
This argument allows to set specific sysroot pass which will be used for
building LLDB API test programs.
It might come in handy for setting up cross-platform remote runs of API
tests on Windows host.
It can be useful for cross-compiling LLDB API tests. The argument can be
set using `LLDB_TEST_USER_ARGS` argument:
```
cmake ...
-DLLDB_TEST_USER_ARGS="...;--sysroot;C:\path\to\sysroot;..."
...
```
The don't currently work (and they're also not particularly useful,
since all of the remote stuff happens inside lldb).
This saves us from annotating tests one by one.
that separates out language and version. To avoid reinventing the wheel
and introducing subtle incompatibilities, this API uses the table of
languages and versiond defined by the upcoming DWARF 6 standard
(https://dwarfstd.org/languages-v6.html). While the DWARF 6 spec is not
finialized, the list of languages is broadly considered stable.
The primary motivation for this is to allow the Swift language plugin to
switch between language dialects between, e.g., Swift 5.9 and 6.0 with
out introducing a ton of new language codes. On the main branch this
change is considered NFC.
Depends on https://github.com/llvm/llvm-project/pull/89980
I was debugging space separation issues when passing user arguments
and noticed this error is really hard to read in that scenario.
Put "" around the invalid compiler name so you can tell whether
you have spaces around it that's causing the problem.
Instead of directly annotating pexpect-based tests with
`@skipIfWindows`, we can tag them with a new `pexpect` category. We
still automatically skip windows behavior by adding `pexpect` to the
skip category list if the platform is windows, but also allow
non-Windows users to skip them by configuring cmake with
`-DLLDB_TEST_USER_ARGS=--skip-category=pexpect`
As a prerequisite, remove the restriction that `@add_test_categories`
can only apply to test cases, and we make the test runner look for
categories on both the class and the test method.
This removes the dependency LLDB API tests have on
lldb/third_party/Python/module/unittest2, and instead uses the standard
one provided by Python.
This does not actually remove the vendored dep yet, nor update the docs.
I'll do both those once this sticks.
Non-trivial changes to call out:
- expected failures (i.e. "bugnumber") don't have a reason anymore, so
those params were removed
- `assertItemsEqual` is now called `assertCountEqual`
- When a test is marked xfail, our copy of unittest2 considers failures
during teardown to be OK, but modern unittest does not. See
TestThreadLocal.py. (Very likely could be a real bug/leak).
- Our copy of unittest2 was patched to print all test results, even ones
that don't happen, e.g. `(5 passes, 0 failures, 1 errors, 0 skipped,
...)`, but standard unittest prints a terser message that omits test
result types that didn't happen, e.g. `OK (skipped=1)`. Our lit
integration parses this stderr and needs to be updated w/ that
expectation.
I tested this w/ `ninja check-lldb-api` on Linux. There's a good chance
non-Linux tests have similar quirks, but I'm not able to uncover those.
Rename lldb-vscode to lldb-dap. This change is largely mechanical. The
following substitutions cover the majority of the changes in this
commit:
s/VSCODE/DAP/
s/VSCode/DAP/
s/vscode/dap/
s/g_vsc/g_dap/
Discourse RFC:
https://discourse.llvm.org/t/rfc-rename-lldb-vscode-to-lldb-dap/74075/
These were useful primarily for the Python 2 to 3 transition. Python 2
is no longer supported so these are no longer necessary.
Differential Revision: https://reviews.llvm.org/D157759
This is an ongoing series of commits that are reformatting our Python
code. Reformatting is done with `black` (23.1.0).
If you end up having problems merging this commit because you have made
changes to a python file, the best way to handle that is to run `git
checkout --ours <yourfile>` and then reformat it with black.
RFC: https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style
Differential revision: https://reviews.llvm.org/D151460
Previously, we just used the platform name. This worked mostly OK, but
it required adding special handling for any unusual (and potentially
downstream) platform plugins, as evidenced by the hardcoding of the
qemu-user platform.
The current implementation was added in
D121605/21c5bb0a636c23ec75b13681c0a6fdb03ecd9c0d, which this essentially
reverts and goes back to the previous method of retrieving the platform
name from the platform triple (the "OS" field).
The motivation for D121605 was the ability to retrieve the process
without constructing an SBDebugger object (which would be necessary in a
world where SBPlatforms are managed by SBDebuggers). However, this world
did not arrive (mainly due to other commitments on my part), and I now
think that if we do want to go in that direction, that we should just
create a dummy/empty SBDebugger object for holding the initial
SBPlatform.
One benefit of D121605 was the unification of getPlatform and
getHostPlatform code paths, and I preserve that benefit by unifying them
in the other direction -- using the host SBPlatform for getHostPlatform.
Differential Revision: https://reviews.llvm.org/D138430
In certain configurations, libc++ headers all exist in the same directory, and libc++ binaries exist in the same directory as lldb libs. When `LLVM_ENABLE_PER_TARGET_RUNTIME_DIR` is enabled (*and* the host is not Apple, which is why I assume this wasn't caught by others?), this is not the case: most headers will exist in the usual `include/c++/v1` directory, but `__config_site` exists in `include/$TRIPLE/c++/v1`. Likewise, the libc++.so binary exists in `lib/$TRIPLE/`, not `lib/` (where LLDB libraries reside).
This also adds the just-built-libcxx functionality to the lldb-dotest tool.
The `LIBCXX_` cmake config is borrowed from `libcxx/CMakeLists.txt`. I could not figure out a way to share the cmake config; ideally we would reuse the same config instead of copy/paste.
Reviewed By: JDevlieghere, fdeazeve
Differential Revision: https://reviews.llvm.org/D133973
This patch combines D129166 (to always pick the just-built libc++) and
D132257 (to allow customizing the libc++ for testing). The common goal
is to avoid picking up an unexpected libc++ for testing.
Differential revision: https://reviews.llvm.org/D132263
Make sure we use the libc++ from the build dir. Currently, by passing
-stdlib=libc++, we might pick up the system libc++. This change ensures
that if LLVM_LIBS_DIR is set, we try to use the libc++ from there.
Differential revision: https://reviews.llvm.org/D129166
This patch moves the platform creation and selection logic into the
per-debugger platform lists. I've tried to keep functional changes to a
minimum -- the main (only) observable difference in this change is that
APIs, which select a platform by name (e.g.,
Debugger::SetCurrentPlatform) will not automatically pick up a platform
associated with another debugger (or no debugger at all).
I've also added several tests for this functionality -- one of the
pleasant consequences of the debugger isolation is that it is now
possible to test the platform selection and creation logic.
This is a product of the discussion at
<https://discourse.llvm.org/t/multiple-platforms-with-the-same-name/59594>.
Differential Revision: https://reviews.llvm.org/D120810
As noticed in D87637, when LLDB crashes, we only print stack traces if
LLDB is directly executed, not when used via Python bindings. Enabling
this by default may be undesirable (libraries shouldn't be messing with
signal handlers), so make this an explicit opt-in.
I "commandeered" this patch from Jordan Rupprecht who put this up for
review originally.
Differential revision: https://reviews.llvm.org/D91835
This recommits dddf4ce03, which was reverted because of a couple of test
failures on macos. The reason behind the failures was that the patch
inadvertenly changed the value returned by the host platform from
"macosx" to "darwin". The new version fixes that.
Original commit message was:
The decision which categories are relevant for a particular test run
happen very early in the test setup process. They use the SBPlatform
object to determine which categories should be skipped. The platform
object created for this purpose transcends individual test runs.
This setup is not compatible with the direction discussed in
<https://discourse.llvm.org/t/multiple-platforms-with-the-same-name/59594>
-- when platform objects are tied to a specific (SB)Debugger, they need
to be created alongside it, which currently happens in the test setUp
method.
This patch is the first step in that direction -- it rewrites the
category skipping logic to avoid depending on a global SBPlatform
object. Fortunately, the skipping logic is fairly simple (and I believe
it outght to stay that way) and mainly consists of comparing the
platform name against some hardcoded lists. This patch bases this
comparison on the platform name instead of the os part of the triple (as
reported by the platform).
Differential Revision: https://reviews.llvm.org/D121605
The decision which categories are relevant for a particular test run
happen very early in the test setup process. They use the SBPlatform
object to determine which categories should be skipped. The platform
object created for this purpose transcends individual test runs.
This setup is not compatible with the direction discussed in
<https://discourse.llvm.org/t/multiple-platforms-with-the-same-name/59594>
-- when platform objects are tied to a specific (SB)Debugger, they need
to be created alongside it, which currently happens in the test setUp
method.
This patch is the first step in that direction -- it rewrites the
category skipping logic to avoid depending on a global SBPlatform
object. Fortunately, the skipping logic is fairly simple (and I believe
it outght to stay that way) and mainly consists of comparing the
platform name against some hardcoded lists. This patch bases this
comparison on the platform name instead of the os part of the triple (as
reported by the platform).
Differential Revision: https://reviews.llvm.org/D121605
This patch fixes a bug in dotest.py where lldb.selected_platform was
being set to host platform even after a successful connection to a
remote platform via platform url. This patch fixes this behavior and
sets selected_platform to remote_platform after a successful connection.
This patch also removes target_platform variable from run_suite.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D105060
This adds a basic SB API for creating and stopping traces.
Note: This doesn't add any APIs for inspecting individual instructions. That'd be a more complicated change and it might be better to enhande the dump functionality to output the data in binary format. I'll leave that for a later diff.
This also enhances the existing tests so that they test the same flow using both the command interface and the SB API.
I also did some cleanup of legacy code.
Differential Revision: https://reviews.llvm.org/D103500
This is just a dotest check to see if we can compile a simple program that uses
libc++. Right now we are parsing the rather big `algorithm` header in the test
program, but the test really just checks whether we can find *any* libc++
headers and link against some libc++ SO. Using the much smaller `cassert` header
for checking whether we can find libc++ headers speeds up this check by a bit.
After some incredibly unscientific performance testing this saves a few seconds
when running the test suite on Linux (on macOS we hardcoded that libc++ is
always there, so this check won't be used there and we don't save any time).
Reviewed By: jankratochvil
Differential Revision: https://reviews.llvm.org/D101056
Enable reporting fork/vfork events to the server when supported.
At this moment, this is used only to test the server code, as real
client does not report fork-events and vfork-events as supported.
Differential Revision: https://reviews.llvm.org/D100208
Introduce a NativeProcessProtocol API for indicating support for
protocol extensions and enabling them. LLGS calls
GetSupportedExtensions() method on the process factory to determine
which extensions are supported by the plugin. If the future is both
supported by the plugin and reported as supported by the client, LLGS
enables it and reports to the client as supported by the server.
The extension is enabled on the process instance by calling
SetEnabledExtensions() method. This is done after qSupported exchange
(if the debugger is attached to any process), as well as after launching
or attaching to a new inferior.
The patch adds 'fork' extension corresponding to 'fork-events+'
qSupported feature and 'vfork' extension for 'vfork-events+'. Both
features rely on 'multiprocess+' being supported as well.
Differential Revision: https://reviews.llvm.org/D100153
Print a single line listing all the categories that are being skipped,
rather than relying on the check.*Support() functions specifying why a
particular category will be skipped. If we know why a category got
skipped, still print that in verbose mode.
The motivation for this change is that sometimes engineers misidentify
the output of these messages as the cause for a test failure (e.g. not
being able to build libc++ or libstdc++).
Differential revision: https://reviews.llvm.org/D100508
