-
Notifications
You must be signed in to change notification settings - Fork 678
bazel: use hardened libc++ in non-release builds #27696
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
base: dev
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
This PR enables hardened libc++ for non-release builds to improve safety and debugging capabilities while maintaining maximum performance in production releases.
- Adds extensive hardening mode for debug and fastbuild configurations
- Explicitly disables hardening for release builds to prioritize performance
- Applies hardening settings to both regular and host compilation flags
a3860e3
to
ff975a1
Compare
ff975a1
to
c49c92c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
Copilot reviewed 1 out of 1 changed files in this pull request and generated 2 comments.
.bazelrc
Outdated
# the fast mode in production as well. | ||
# | ||
# https://libcxx.llvm.org/Hardening.html | ||
build --cxxopt=-D_LIBCPP_ASSERTION_SEMANTIC=_LIBCPP_ASSERTION_SEMANTIC_ENFORCE |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This ASSERTION macro is only in LLVM 21...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh well we can go to clang 21 its at its second point release now :P
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Building LLVM 21, at least to test this CI run
CI test resultstest results on build#72801
test results on build#72865
|
that's cool. quite a few test failures to sort through |
happy to help if they look like valid failures |
They are certainly UB (like where front was called on an empty span), but I have just started going through them. I have a patch locally that gives better errors and stacktraces (by default they use sigill and by default seastar blocks that signal). I should just triage them and put them in jira. |
decimal_value{absl::int128{std::numeric_limits<long>::max()}}, | ||
decimal_type{21, 0}, | ||
R"("9223372036854775807.")", | ||
R"("9223372036854775807")", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
em? the test explicitly states it tests with trailing decimal
other tests too, they explicitly don't have integral parts
# https://libcxx.llvm.org/Hardening.html | ||
build --cxxopt=-D_LIBCPP_ASSERTION_SEMANTIC=_LIBCPP_ASSERTION_SEMANTIC_ENFORCE | ||
build --cxxopt=-D_LIBCPP_HARDENING_MODE=_LIBCPP_HARDENING_MODE_EXTENSIVE | ||
build --host_cxxopt=-D_LIBCPP_HARDENING_MODE=_LIBCPP_HARDENING_MODE_EXTENSIVE |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why not _LIBCPP_HARDENING_MODE_DEBUG?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Extensive mode, which contains all the checks from fast mode and some additional checks for undefined behavior that incur relatively little overhead but aren’t security-critical. Production builds requiring a broader set of checks than fast mode should consider enabling extensive mode. The additional rigour impacts performance more than fast mode: we recommend benchmarking to determine if that is acceptable for your program.
Debug mode, which enables all the available checks in the library, including heuristic checks that might have significant performance overhead as well as internal library assertions. This mode should be used in non-production environments (such as test suites, CI, or local development). We do not commit to a particular level of performance in this mode. In particular, this mode is not intended to be used in production.
Backports Required
Release Notes