11 Commits

Author SHA1 Message Date
Jonas Devlieghere
2238dcc393
[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
2023-05-25 12:54:09 -07:00
Felipe de Azevedo Piovezan
67c73d88de Reland "[lldb] Use just-built libcxx for tests when available"
This commit improves upon cc0b5ebf7fc8, which added support for
specifying which libcxx to use when testing LLDB. That patch honored
requests by tests that had `USE_LIBCPP=1` defined in their makefiles.
Now, we also use a non-default libcxx if all conditions below are true:

1. The test is not explicitly requesting the use of libstdcpp
(USE_LIBSTDCPP=1).
2. The test is not explicitly requesting the use of the system's
library (USE_SYSTEM_STDLIB=1).
3. A path to libcxx was either provided by the user through CMake flags
or libcxx was built together with LLDB.

Condition (2) is new and introduced in this patch in order to support
tests that are either:

* Cross-platform (such as API/macosx/macCatalyst and
API/tools/lldb-server). The just-built libcxx is usually not built for
platforms other than the host's.
* Cross-language (such as API/lang/objc/exceptions). In this case, the
Objective C runtime throws an exceptions that always goes through the
system's libcxx, instead of the just built libcxx. Fixing this would
require either changing the install-name of the just built libcxx in Mac
systems, or tuning the DYLD_LIBRARY_PATH variable at runtime.

Some other tests exposes limitations of LLDB when running with a debug
standard library. TestDbgInfoContentForwardLists had an assertion
removed, as it was checking for buggy LLDB behavior (which now
crashes). TestFixIts had a variable renamed, as the old name clashes
with a standard library name when debug info is present. This is a known
issue: https://github.com/llvm/llvm-project/issues/34391.

For `TestSBModule`, the way the "main" module is found was changed to
look for the "a.out" module, instead of relying on the index being 0. In
some systems, the index 0 is dyld when a custom standard library is
used.

Differential Revision: https://reviews.llvm.org/D132940
2022-09-12 15:32:25 -04:00
Felipe de Azevedo Piovezan
9a41f6e708 Revert "[lldb] Use just-built libcxx for tests when available"
This reverts commit c38eeecbc7d929c9601f2189214a7a90d3982a47.
2022-09-08 14:38:08 -04:00
Felipe de Azevedo Piovezan
c38eeecbc7 [lldb] Use just-built libcxx for tests when available
This commit improves upon cc0b5ebf7fc8, which added support for
specifying which libcxx to use when testing LLDB. That patch honored
requests by tests that had `USE_LIBCPP=1` defined in their makefiles.
Now, we also use a non-default libcxx if all conditions below are true:

1. The test is not explicitly requesting the use of libstdcpp
(USE_LIBSTDCPP=1).
2. The test is not explicitly requesting the use of the system's
library (USE_SYSTEM_STDLIB=1).
3. A path to libcxx was either provided by the user through CMake flags
or libcxx was built together with LLDB.

Condition (2) is new and introduced in this patch in order to support
tests that are either:

* Cross-platform (such as API/macosx/macCatalyst and
API/tools/lldb-server). The just-built libcxx is usually not built for
platforms other than the host's.
* Cross-language (such as API/lang/objc/exceptions). In this case, the
Objective C runtime throws an exceptions that always goes through the
system's libcxx, instead of the just built libcxx. Fixing this would
require either changing the install-name of the just built libcxx in Mac
systems, or tuning the DYLD_LIBRARY_PATH variable at runtime.

Some other tests exposes limitations of LLDB when running with a debug
standard library. TestDbgInfoContentForwardLists had an assertion
removed, as it was checking for buggy LLDB behavior (which now
crashes). TestFixIts had a variable renamed, as the old name clashes
with a standard library name when debug info is present. This is a known
issue: https://github.com/llvm/llvm-project/issues/34391.

For `TestSBModule`, the way the "main" module is found was changed to
look for the "a.out" module, instead of relying on the index being 0. In
some systems, the index 0 is dyld when a custom standard library is
used.

Differential Revision: https://reviews.llvm.org/D132940
2022-09-08 13:42:56 -04:00
Dave Lee
4cc8f2a017 [lldb][tests] Automatically call compute_mydir (NFC)
Eliminate boilerplate of having each test manually assign to `mydir` by calling
`compute_mydir` in lldbtest.py.

Differential Revision: https://reviews.llvm.org/D128077
2022-06-17 14:34:49 -07:00
Jonas Devlieghere
66b829ac7b
[lldb] Skip a bunch of tests that shouldn't run remotely
Skip a bunch of tests that don't really make sense to run remotely.
2022-04-08 10:46:34 -07:00
Dave Lee
779bbbf27f [lldb] Replace asserts on .Success() with assertSuccess()
Replace forms of `assertTrue(err.Success())` with `assertSuccess(err)` (added in D82759).

* `assertSuccess` prints out the error's message
* `assertSuccess` expresses explicit higher level semantics, both to the reader and for test failure output
* `assertSuccess` seems not to be well known, using it where possible will help spread knowledge
* `assertSuccess` statements are more succinct

Differential Revision: https://reviews.llvm.org/D119616
2022-02-14 08:31:17 -08:00
Med Ismail Bennani
aae3c4f2b4
[lldb/test] Skip TestSBModule unless darwin
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
2022-01-27 01:05:12 +01:00
Med Ismail Bennani
a6b5624372 Revert "[lldb/test] Try to fix TestSBModule failure"
This reverts commit 326516448c839d8f9cc515b20a34d0f3a6ee2374.
2022-01-27 01:04:38 +01:00
Med Ismail Bennani
326516448c [lldb/test] Try to fix TestSBModule failure
This should fix https://lab.llvm.org/buildbot/#/builders/68/builds/25571

Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
2022-01-27 01:00:29 +01:00
Med Ismail Bennani
ff52ef334b
[lldb/API] Add ability to check if module is backed by a file on disk
This patch introduces a new SBAPI method: `SBModule::IsFileBacked`

As the name suggests, it tells the user if the module's object file is
on disk or in memory.

rdar://68538278

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

Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
2022-01-26 20:40:24 +01:00