[lldb] Add early CMake check for 'make' tool (#111531)

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 `UNRESOLVE

[lldb] Add early CMake check for 'make' tool (#111531)

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.

show more ...

[lldb][test] Use tools from llvm instead of compiler tools (#109961)

In #102185, toolchain detection for API tests has been rewritten in
Python. Tools paths for tests there are determined from comp

[lldb][test] Use tools from llvm instead of compiler tools (#109961)

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.

show more ...

[lldb] fix(lldb/**.py): fix comparison to None (#94017)

from PEP8
(https://peps.python.org/pep-0008/#programming-recommendations):

> Comparisons to singletons like None should always be done wit

[lldb] fix(lldb/**.py): fix comparison to None (#94017)

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>

show more ...

[lldb][test] Add --make argument to dotest.py (#93883)

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 u

[lldb][test] Add --make argument to dotest.py (#93883)

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;..."
...
```

show more ...

[lldb][test] Add --sysroot argument to dotest.py

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

[lldb][test] Add --sysroot argument to dotest.py

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;..."
...
```

show more ...

[lldb-dap] Automatically skip lldb-dap tests for remote platforms (#93169)

The don't currently work (and they're also not particularly useful,
since all of the remote stuff happens inside lldb).

[lldb-dap] Automatically skip lldb-dap tests for remote platforms (#93169)

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.

show more ...

Add a new SBExpressionOptions::SetLanguage() API (NFCI) (#89981)

that separates out language and version. To avoid reinventing the wheel
and introducing subtle incompatibilities, this API uses the

Add a new SBExpressionOptions::SetLanguage() API (NFCI) (#89981)

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

show more ...

[lldb][test] Improve invalid compiler error message

I was debugging space separation issues when passing user arguments
and noticed this error is really hard to read in that scenario.

Put "" around

[lldb][test] Improve invalid compiler error message

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.

show more ...

[lldb][test] Add `pexpect` category for tests that `import pexpect` (#84860)

Instead of directly annotating pexpect-based tests with
`@skipIfWindows`, we can tag them with a new `pexpect` category.

[lldb][test] Add `pexpect` category for tests that `import pexpect` (#84860)

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.

show more ...

[lldb][test] Switch LLDB API tests from vendored unittest2 to unittest (#79945)

This removes the dependency LLDB API tests have on
lldb/third_party/Python/module/unittest2, and instead uses the sta

[lldb][test] Switch LLDB API tests from vendored unittest2 to unittest (#79945)

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.

show more ...

[lldb] Remove obsolete signBinary helper (#79656)

On Darwin, the Makefile already (ad-hoc) signs everything it builds.
There's also no need to use lldb_codesign for this.

[lldb] Rename lldb-vscode to lldb-dap (#69264)

Rename lldb-vscode to lldb-dap. This change is largely mechanical. The
following substitutions cover the majority of the changes in this
commit:

[lldb] Rename lldb-vscode to lldb-dap (#69264)

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/

show more ...

[lldb] Remove use of __future__ in python

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: http

[lldb] Remove use of __future__ in python

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

show more ...

[NFC][Py Reformat] Reformat python files in lldb

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 problem

[NFC][Py Reformat] Reformat python files in lldb

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

show more ...

[lldb/test] Use SBPlatform info for lldbplatformutil.getPlatform()

Previously, we just used the platform name. This worked mostly OK, but
it required adding special handling for any unusual (and pot

[lldb/test] Use SBPlatform info for lldbplatformutil.getPlatform()

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

show more ...

[test] Fix LLDB tests with just-built libcxx when using a target directory.

In certain configurations, libc++ headers all exist in the same directory, and libc++ binaries exist in the same directory

[test] Fix LLDB tests with just-built libcxx when using a target directory.

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

show more ...

[lldb] Improve formatting of skipped categories message (NFC)

[lldb] Support specifying a custom libcxx for the API tests

This patch combines D129166 (to always pick the just-built libc++) and
D132257 (to allow customizing the libc++ for testing). The common g

[lldb] Support specifying a custom libcxx for the API tests

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

show more ...

[lldb] Remove uses of six module (NFC)

With lldb (& llvm) requiring Python 3.6+, use of the `six` module can be removed.

Differential Revision: https://reviews.llvm.org/D131304

[lldb] Use the just-built libc++ for testing the LLDB data formatters

Make sure we use the libc++ from the build dir. Currently, by passing
-stdlib=libc++, we might pick up the system libc++. This c

[lldb] Use the just-built libc++ for testing the LLDB data formatters

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

show more ...

[lldb] Remove the global platform list

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

[lldb] Remove the global platform list

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

show more ...

[lldb] Add Python bindings to print stack traces on crashes.

As noticed in D87637, when LLDB crashes, we only print stack traces if
LLDB is directly executed, not when used via Python bindings. Enab

[lldb] Add Python bindings to print stack traces on crashes.

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

show more ...

Recommit [lldb/test] Make category-skipping logic "platform"-independent

This recommits dddf4ce03, which was reverted because of a couple of test
failures on macos. The reason behind the failures wa

Recommit [lldb/test] Make category-skipping logic "platform"-independent

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

show more ...

Revert "[lldb/test] Make category-skipping logic "platform"-independent"

This reverts commit dddf4ce034a8e06cc1351492dceece3fa2344c14. It breaks
a couple of tests on macos.

[lldb/test] Make category-skipping logic "platform"-independent

The decision which categories are relevant for a particular test run
happen very early in the test setup process. They use the SBPlatf

[lldb/test] Make category-skipping logic "platform"-independent

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

show more ...