[Bug 279443] LIBCPP assertions are enabled in optimized builds when -DNDEBUG is given to clang

From: <bugzilla-noreply_at_freebsd.org>
Date: Mon, 29 Jul 2024 15:23:27 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279443

Dimitry Andric <dim@FreeBSD.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |cperciva@FreeBSD.org

--- Comment #16 from Dimitry Andric <dim@FreeBSD.org> ---
At some point during libc++ 18 development, the old assertions-on/off mechanism
(using _LIBCPP_ENABLE_ASSERTIONS) was replaced with various "hardening modes".
(See https://discourse.llvm.org/t/rfc-hardening-in-libc/73925 and various other
places.)

With upstream's libc++ builds, the hardening mode with which libc++.so itself
is built is chosen at configuration time, via the CMake LIBCXX_HARDENING_MODE
variable. It can be set to "none", "fast", "extensive" and "debug". In the
CMakeLists.txt there is the following comment:

  "Specify the default hardening mode to use. This mode will be used inside the
   compiled library and will be the default when compiling user code. Note that
   users can override this setting in their own code. This does not affect the
   ABI. Supported values are ${LIBCXX_SUPPORTED_HARDENING_MODES}.")

In any case, libc++ never used NDEBUG for these internal checks.

In -CURRENT, the precompiled shared and static libraries installed in the base
system use the mode selected in lib/libc++/__config_site, which is generated by
a CMake build with hardening mode set to "extensive" (aka 16).

I think it may make sense to tune down the level of the shared and static
libraries to "fast" for release branches, or maybe even stable branches, as the
"extensive" setting is slightly more expensive.

For a particular port that wants to change libc++'s defaults, they should use
e.g.:

-D_LIBCPP_HARDENING_MODE=_LIBCPP_HARDENING_MODE_NONE

or one of the other non-default settings.

-- 
You are receiving this mail because:
You are the assignee for the bug.