Skip to content

[cherry-pick][swift/release/5.9] [lldb][cmake] Allow specifying custom libcxx for tests in standalone builds #6900

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 4 commits into from
May 22, 2023

Conversation

Michael137
Copy link

@Michael137 Michael137 commented May 20, 2023

Standalone builds currently do not set the LLDB_HAS_LIBCXX,
LIBCXX_LIBRARY_DIR, LIBCXX_GENERATED_INCLUDE_DIR.
These are necessary for API tests with USE_LIBCPP to run against
a custom built libcxx. Thus on all buildbots using standalone builds
(most notably the public swift-ci), the API tests always run against
the libcxx headers in the system SDK.

This patch introduces a new cmake variable LLDB_TEST_LIBCXX_ROOT_DIR
that allows us to point the tests in standalone builds to a custom
libcxx directory.

Since the user can control the libcxx location we can hard error if
no such custom libcxx build exists.

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

(cherry picked from commit 2901ce3ac24799dacda21be3903d6d8294b70ea0)

@Michael137
Copy link
Author

Please test with following PR:
swiftlang/swift#66026

@swift-ci test

@Michael137
Copy link
Author

@swift-ci Please test macOS platform

@Michael137
Copy link
Author

Please test with following PR:
swiftlang/swift#66026

@swift-ci Please test macOS platform

1 similar comment
@Michael137
Copy link
Author

Please test with following PR:
swiftlang/swift#66026

@swift-ci Please test macOS platform

@Michael137
Copy link
Author

Michael137 commented May 21, 2023

The failing test is due to the newest libcxx causing std::forward to get mangled in a way that's not supported by the demangler that LLDB uses:

   frame #0: 0x0000000100006c28 a.out`_ZNSt3__17forwardB7v160000IRK3BarEEOT_Ru20__remove_reference_tIS4_E(__t=0x000000016fdfe7c4) at forward.h:26:29
   23   template <class _Tp>
   24   _LIBCPP_NODISCARD_EXT inline _LIBCPP_INLINE_VISIBILITY _LIBCPP_CONSTEXPR _Tp&&
   25   forward(__libcpp_remove_reference_t<_Tp>& __t) _NOEXCEPT {
-> 26     return static_cast<_Tp&&>(__t);
   27   }

Probably a missing cherry-pick

@Michael137 Michael137 force-pushed the bugfix/test-presets branch from a9b4595 to ebe97b1 Compare May 22, 2023 13:27
@Michael137
Copy link
Author

Please test with following PR:
swiftlang/swift#66026

@swift-ci Please test

@Michael137
Copy link
Author

Please test with following PR:
swiftlang/swift#66026
swiftlang/swift#66018

@swift-ci Please test

@adrian-prantl
Copy link

test with swiftlang/swift#66026
@swift-ci test

@Michael137
Copy link
Author

Please test with following PR:
swiftlang/swift#66026

@swift-ci Please test

@Michael137
Copy link
Author

Please test with following PR:
swiftlang/swift#66026

@swift-ci Please test windows Platform

@Michael137 Michael137 changed the title WIP: [lldb][test] Re-enable TestDataFormatterLibcxxRangesRefView.py [cherry-pick][swift/release/5.9] [lldb][cmake] Allow specifying custom libcxx for tests in standalone builds May 22, 2023
rupprecht and others added 4 commits May 22, 2023 19:47
…ctory.

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

(cherry picked from commit cb0eb9d)
(cherry picked from commit a9b4595baca074fa8dd6c9f3a2cd6edd6c5e2ffc)
(cherry picked from commit 61cc334)
…builds

Standalone builds currently do not set the `LLDB_HAS_LIBCXX`,
`LIBCXX_LIBRARY_DIR`, `LIBCXX_GENERATED_INCLUDE_DIR`.
These are necessary for API tests with `USE_LIBCPP` to run against
a custom built libcxx. Thus on all buildbots using standalone builds
(most notably the public swift-ci), the API tests always run against
the libcxx headers in the system SDK.

This patch introduces a new cmake variable `LLDB_TEST_LIBCXX_ROOT_DIR`
that allows us to point the tests in standalone builds to a custom
libcxx directory.

Since the user can control the libcxx location we can hard error if
no such custom libcxx build exists.

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

(cherry picked from commit 2901ce3ac24799dacda21be3903d6d8294b70ea0)
Now that the standalone build-bots test against a newly
built libcxx, we can re-enable the test.
With swiftlang/swift#66018 we started to run standalone tests
(e.g., the ones on swift-ci) against newly built libcxx.
This caused the test to fail on the 5.9 branch. The first
step-in into a pointer to a data member didn't behave as expected.

Thus skip it for now.
@Michael137 Michael137 force-pushed the bugfix/test-presets branch from 3e246a1 to dbd0474 Compare May 22, 2023 18:48
@Michael137
Copy link
Author

Please test with following PR:
swiftlang/swift#66026

@swift-ci Please test

@Michael137
Copy link
Author

Please test with following PR:
swiftlang/swift#66026

@swift-ci Please test windows Platform

1 similar comment
@Michael137
Copy link
Author

Please test with following PR:
swiftlang/swift#66026

@swift-ci Please test windows Platform

@adrian-prantl adrian-prantl merged commit 116b307 into swift/release/5.9 May 22, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants