LIBCXX_HARDENING_MODE is the new macro, the previous one was removed in LLVM 18.
See https://libcxx.llvm.org/Hardening.html.
Required before https://github.com/google/oss-fuzz/pull/11725 will do anything (with the bump to 18.x).
Seems reasonable to do now that almost all our test infra is using LLVM 18.
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
For detailed information about the code coverage, see the test coverage report.
See the guideline for information on the review process.
| Type | Reviewers |
|---|---|
| ACK | theuni |
If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.
IIRC usage was turned into a compile error (maybe only intermittently, will check again).
I think I was thinking of something else here. Have changed this to just adding the new macro.
12@@ -13,7 +13,12 @@ linux_release_CXXFLAGS=$(linux_release_CFLAGS)
13 linux_debug_CFLAGS=-O1 -g
14 linux_debug_CXXFLAGS=$(linux_debug_CFLAGS)
15
16-linux_debug_CPPFLAGS=-D_GLIBCXX_DEBUG -D_GLIBCXX_DEBUG_PEDANTIC -D_LIBCPP_ENABLE_DEBUG_MODE=1
17+# https://gcc.gnu.org/onlinedocs/libstdc++/manual/debug_mode.html
18+linux_debug_CPPFLAGS=-D_GLIBCXX_DEBUG -D_GLIBCXX_DEBUG_PEDANTIC
19+
20+# https://libcxx.llvm.org/Hardening.html
21+# _LIBCPP_ENABLE_DEBUG_MODE is the legacy define, it was last used in LLVM 17.
I have a hard time following what llvm does each release here. Why is https://libcxx.llvm.org/Hardening.html not available as versioned URL per release?
https://discourse.llvm.org/t/rfc-hardening-in-libc/73925 claims there are no breaking changes in the 18 release. So I wonder if everything can be kept as-is for now, because I suspect no one will be compiling with 19 for now?
Why is https://libcxx.llvm.org/Hardening.html not available as versioned URL per release?
Looks like it’s here: https://releases.llvm.org/18.1.0/projects/libcxx/docs/Hardening.html
claims there are no breaking changes in the 18 release.
I’ve also had a hard time following, and I think some of the changes were landed, reverted, and finally re-landed. According too https://releases.llvm.org/18.1.0/projects/libcxx/docs/ReleaseNotes/18.html:
New hardened modes for the library have been added, replacing the legacy debug mode that was removed in the LLVM 17 release. Unlike the legacy debug mode, some of these hardening modes are also intended to be used in production. See Hardening Modes for more details.
Ah, I see. The page may have only been written for the 18 release, or not included in the 17 release for some reason.
According to commit 4a825039a509c43ba20b2cd7aab448b3be16bcc3, “From LLVM 17, _LIBCPP_ENABLE_DEBUG_MODE can be used instead.” C.f. https://web.archive.org/web/20230815180109/https://libcxx.llvm.org/Hardening.html
This makes me wonder if it is worth it to support clang 17 debug mode, if clang 14,15, and 16 isn’t supported either.
It seems fine to require clang 18, if someone want to use clang, depends, and D_LIBCPP_HARDENING_MODE.
Is there anyone other than OSS-Fuzz and a CI config interested in this?
It seems fine to require clang 18, if someone want to use clang, depends, and D_LIBCPP_HARDENING_MODE. Is there anyone other than OSS-Fuzz and a CI config interested in this?
Yea; my main interest is our CIs, fuzzing infra and other external test infra, which is all running LLVM 18 (oss-fuzz soon to be).
Trying to make sense of all of this, I found this RFC helpful:
- LLVM 18: first release that supports hardening modes and ways to enable them as described in the RFC.
- The safe mode (available since the LLVM 15 release) is still supported; the release notes will mention that projects using the safe mode have to transition to use the hardened mode or the debug-lite mode instead (debug-lite is the rough equivalent of the old safe mode).
- A few checks that used to be in the safe mode might become excluded (internally, safe will be mapped to debug-lite). In LLVM 17, the safe mode contains every check that isn’t explicitly marked as debug-only, but finer-grained categorization might allow trimming it down further.
- The safe mode will no longer use
__libcpp_verbose_abortwhen a check fails (__builtin_trapwill be used instead). Overriding__libcpp_verbose_abortwill no longer have an effect on the behavior of the safemode.- The meaning of the debug mode will change. The legacy debug mode has been removed in LLVM 17 1. The new debug mode that is part of hardening will be enabled using the mechanisms explained in the RFC and will function differently (e.g. it won’t require a global database).
- LLVM 19: the safe mode will be deprecated. The
LIBCXX_ENABLE_ASSERTIONSCMake variable and the_LIBCPP_ENABLE_ASSERTIONSmacro will be deprecated (with a warning) and users will be given a message to migrate to the hardened mode or the debug-lite mode instead.- LLVM 20: the safe mode will be removed along with the associated macros and the CMake variable.
Oh, heh, I missed that @maflcko had already linked that. See also here for an RFC about the deprecation.
I think I’m inclined to agree that it’s not worth supporting the old mode. It seems it’s old and janky and deprecated for good reason.
utACK. Should darwin get this too though since it also uses libc++ ?
Maybe we could look into this once we switch the Darwin cross builds to use LLVM 18 (currently 17)? At this point the newest Apple Clang is still also based on LLVM 16.
`LIBCPP_HARDENING_MODE` is the new macro, the previous one was removed in
LLVM 18.
See https://libcxx.llvm.org/Hardening.html.
My understanding is that the previous macro does not exist in llvm 18 (what this CI task is using). (git grep LIBCPP_ENABLE_DEBUG_MODE upstream_push/release/18.x is empty).
It could make sense to double check that this can still catch issues.
Looks like it worked in https://github.com/bitcoin/bitcoin/runs/24156835563
0/msan/cxx_build/include/c++/v1/string_view:399: assertion __pos < size() failed: string_view[] index out of bounds
Labels
Build system