mirror of
https://github.com/llvm/llvm-project.git
synced 2025-05-05 19:56:05 +00:00
c38eeecbc7
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