This initial change adds the AIX configuration to run-buildbot, an AIX
CMake cache file, and appropriate compiler and linker flags for testing
AIX to the lit "from scratch" configuration files. Either of the 32-bit or 64-bit configurations
can be built by setting OBJECT_MODE in the build environment (as is
typical for AIX).
Details
- Reviewers
sfertile ldionne xingxue hubert.reinterpretcast - Group Reviewers
Restricted Project Restricted Project - Commits
- rG228b3b729d90: [libc++][AIX] Add scripts and config for building with the libcxx CI…
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Awesome! Thanks a lot for looking into adding AIX to the supported configurations. Once we have an entry in buildkite-pipeline.yml and bots running that configuration, we can even list the platform as being officially supported in the docs!
libcxx/cmake/caches/AIX.cmake | ||
---|---|---|
4–6 | 😭 Is that all necessary for libc++ to work on top of AIX? If so, does that mean users have to specify those when building their own programs too? It's none of my business, but perhaps it'd be awesome if the Clang driver (and the C library for __LIBC_NO_CPP_MATH_OVERLOADS__) handled a bit more automatically, from a user perspective. | |
libcxx/test/configs/llvm-libc++-shared.cfg.in | ||
13 ↗ | (On Diff #377585) | Can you duplicate this file for AIX instead? It'll seem backwards and a really bad solution, but after landing https://reviews.llvm.org/D111196, those shouldn't contain so much duplication. I need to write some documentation to explain the intent of those "from-scratch" config files, but essentially they should be as close as possible to containing a vanilla compiler invocation for building a Hello World program on a given platform. I find it really important to avoid adding logic to those files since that's what we did with the old config.py and that's how it became impossible to understand (and impossible to verify that we were running the test suite correctly). |
libcxx/utils/ci/run-buildbot | ||
579 | Nitpick, but let's line them up while we're at it! Also, we can now use relative paths (there were quite a few changes in that area lately, so you should rebase onto main). The name of the config is just a suggestion. | |
libcxxabi/test/lit.site.cfg.in | ||
1 ↗ | (On Diff #377585) | I'm going to suggest that you don't even modify this file at all. No need to support legacy testing configs, we're trying to move away from them. Instead, you could specify -DLIBCXXABI_TEST_CONFIG="ibm-libc++-shared.cfg.in" in run-buildbot above and you'd never use the legacy config! |
libcxx/cmake/caches/AIX.cmake | ||
---|---|---|
4–6 | The __LIBC_NO_CPP_MATH_OVERLOADS__ actually does get added by the clang driver automatically, but thanks to the implementation we (perhaps some what naively) did in https://reviews.llvm.org/D109078, it won't be applied with -nostdlib++. We could look at changing that situation, but that's the status quo in the build compiler for now. The linker flags are necessary due to particular semantics of the AIX linker: -G enables support for the runtime linker, which is necessary if we want to be able to rebind any references in the library. The priority value we pass in bcdtors is required to set the static init priority for the library relative to other modules. I believe this is necessary because AIX doesn't support SVR4 dependency ordering between dependent modules, so we have to assign a value sufficiently low enough to make sure we init before any other dependent libraries. (We could move some of this into the main CMakeLists if you think it's more appropriate though) | |
libcxxabi/test/lit.site.cfg.in | ||
1 ↗ | (On Diff #377585) | I've done this, but it requires creating and tweaking a separate bridge file so we point at the right things for the libcxxabi tests. Let me know if you'd like that split out to a separate PR. |
- Rebase on main to pickup simplified config
- Split out lit config to ibm config file
- Adjust lit config to use the same config file for both libcxx and libcxxabi
libcxx/utils/ci/run-buildbot | ||
---|---|---|
127–150 | Suggestion: Instead, don't touch check-runtimes and just do this below under aix): ${NINJA} -vC "${BUILD_DIR}" install-cxx install-cxxabi ${NINJA} -vC "${BUILD_DIR}" check-cxx check-cxxabi You can add a TODO comment to use check-runtimes instead when libunwind works cleanly on the platform. That localizes the workaround more IMO. | |
libcxxabi/test/configs/cmake-bridge.cfg.in | ||
1 ↗ | (On Diff #377996) | I'm trying to tackle this in D111279, actually. To make progress on this patch, would you be OK with re-applying your changes to the legacy config.py so that you run the libc++ tests on top of the new config, but the libc++abi tests on top of the old config? Then, once I manage to land D111279, we'll eventually remove the legacy config and you'll switch to running the libc++abi tests on the new config. Does that make sense? Trying to find a pragmatic approach here. |
libcxxabi/test/configs/cmake-bridge.cfg.in | ||
---|---|---|
1 ↗ | (On Diff #377996) | I'm ok with pragmatically reverting the c++abi piece to the old config if necessary, but it looks like you've just landed D111279 as of this writing 🙂. So I'm going to rebase this to follow that precedent and let's see if we can keep everything to the new config. |
- Localize check function changes
- Rebase and create ibm-libc++abi-shared.cfg.in
- Remove extraneous pthread flag
Awesome! If you're able to run the tests locally with this, then LGTM.
Next step would be to finish up https://reviews.llvm.org/D111359.
I'm quite happy with this patch because it showcases exactly how I think new vendors should integrate with libc++ testing wise. We basically define how to minimally run a hello-world program in the Lit testing configs and everything else mostly works. There's still some work to do to remove duplication between libc++ and libc++abi, but everything in that area is difficult because they're two different CMake projects.
😭
Is that all necessary for libc++ to work on top of AIX? If so, does that mean users have to specify those when building their own programs too? It's none of my business, but perhaps it'd be awesome if the Clang driver (and the C library for __LIBC_NO_CPP_MATH_OVERLOADS__) handled a bit more automatically, from a user perspective.