[libc++] Drop the legacy debug mode symbols by default

[ldionne]

Summary

Leave the escape hatch in place with a note, but don't include the
debug mode symbols by default since we don't support the debug mode
in the normal library anymore.

This is technically an ABI break for users who were depending on
those debug mode symbols in the dylib, however those users will
already be broken at compile-time because they must have been using
_LIBCPP_DEBUG=2, which is now an error.

[ldionne]

Vendors, heads up -- this is an ABI change.

[philnik]

I'm kind-of fearing that there are some applications out there that depend on the debug symbols in their release build somehow. I'm not sure if we want to break them, but that's not my call to make, so I'm fine with this.

[ldionne]

In D127360#3568495, @philnik wrote:

I'm kind-of fearing that there are some applications out there that depend on the debug symbols in their release build somehow. I'm not sure if we want to break them, but that's not my call to make, so I'm fine with this.

Right -- this is why this is an ABI-breaking change, actually. I know this isn't a problem for Apple because we've never shipped those debug mode symbols, however it could potentially be for other vendors. That's why I'm adding libc++ vendors to the review -- it would be great if they could take a look in their ecosystem and see if applications are depending on those symbols (I know not all vendors have the capability to do that, but some do have at least a partial view of their ecosystems).

The main reason for this patch goes beyond simple cleanup -- the implementation of the debug mode itself is going to change in ways that are ABI breaking as well, so if we keep this around, it would become stale and out-of-sync with the rest of the debug mode. I'm thinking that we can try making this change, and if vendors encounter significant issues (most likely during qualification of LLVM 15), we can easily flip the switch back to ON by default.

[ldionne]

@danalbert @dim I think this is worth your input. Can you confirm whether you folks have been shipping symbols like __ZNSt3__111__libcpp_db10__insert_iEPv (std::__1::__libcpp_db::__insert_i(void*)), and whether you are aware of applications using those symbols?

[emaste]

In D127360#3569979, @ldionne wrote:

@danalbert @dim I think this is worth your input. Can you confirm whether you folks have been shipping symbols like __ZNSt3__111__libcpp_db10__insert_iEPv (std::__1::__libcpp_db::__insert_i(void*)), and whether you are aware of applications using those symbols?

Looking on my laptop I see _ZNSt3__111__libcpp_db10__insert_iEPv in /usr/lib/libc++.so.1, but I suspect they've never been used.

Perhaps another thing that will just be solved with a library rename to libc++.so.2 (for the std::pair / ABIv2 issue).

[Mordante]

A few minor nits. I'm happy when our vendors are happy.

libcxx/CMakeLists.txt

218

Do we want to mention in which version it will be removed?

libcxx/docs/ReleaseNotes.rst

149

not your change: instead looks out of place.

150

Here too a version number?

[ldionne]

In D127360#3570599, @emaste wrote:

In D127360#3569979, @ldionne wrote:

@danalbert @dim I think this is worth your input. Can you confirm whether you folks have been shipping symbols like __ZNSt3__111__libcpp_db10__insert_iEPv (std::__1::__libcpp_db::__insert_i(void*)), and whether you are aware of applications using those symbols?

Looking on my laptop I see _ZNSt3__111__libcpp_db10__insert_iEPv in /usr/lib/libc++.so.1, but I suspect they've never been used.

Indeed, my thinking here is that nobody's using these symbols, and if they do, they're already at risk of non-benign ODR violations. In practice, we've seen serious failures trying to use the debug mode in the past, for example in std::string. Hence, I suspect nobody's been using them, but at worst vendors could chime in here if they try to deploy this change and encounter issues. That's why I'm leaving a escape hatch too -- to give vendors to quickly remediate to any issue they might find while deploying this and give them time to reach out here so we can figure out a path forward.

[ldionne]

Rebase and adjust ABI list tests. We don't check for debug mode symbols in the ABI list tests anymore
since there is an intent to leave the debug mode ABI unstable.

[ldionne]

Adjust more ABI lists

[Mordante]

I'm happy with the current version. It still would be great to get more vendor feedback,

[ldionne]

Update more ABI lists

[ldionne]

Rebase onto main.

libcxx/CMakeLists.txt

message(FATAL_ERROR "Value '${LIBCXX_TYPEINFO_COMPARISON_IMPLEMENTATION}' is not a valid value for
                        LIBCXX_TYPEINFO_COMPARISON_IMPLEMENTATION")
 endif()
 
 option(LIBCXX_HIDE_FROM_ABI_PER_TU_BY_DEFAULT "Enable per TU ABI insulation by default. To be used by vendors." OFF)
 set(LIBCXX_ABI_DEFINES "" CACHE STRING "A semicolon separated list of ABI macros to define in the site config header.")
 option(LIBCXX_EXTRA_SITE_DEFINES "Extra defines to add into __config_site")
 option(LIBCXX_USE_COMPILER_RT "Use compiler-rt instead of libgcc" OFF)
 
-cmake_dependent_option(LIBCXX_ENABLE_BACKWARDS_COMPATIBILITY_DEBUG_MODE_SYMBOLS
+option(LIBCXX_ENABLE_BACKWARDS_COMPATIBILITY_DEBUG_MODE_SYMBOLS
   "Whether to include the old Debug mode symbols in the compiled library. This
    is provided for backwards compatibility since the compiled library used to
    always contain those symbols, regardless of whether the library was built
-   with the debug mode enabled." ON
-   "LIBCXX_ABI_VERSION EQUAL 1" OFF) # Always OFF in ABI version != 1
+   with the debug mode enabled. This is OFF by default, please contact the libc++
+   developers if you need to turn this on, as this will be removed in the future." OFF)
 
 # ABI Library options ---------------------------------------------------------
 if (LIBCXX_TARGETING_MSVC)
   set(LIBCXX_DEFAULT_ABI_LIBRARY "vcruntime")
 elseif (${CMAKE_SYSTEM_NAME} MATCHES "FreeBSD")
   set(LIBCXX_DEFAULT_ABI_LIBRARY "libcxxrt")
 else()
   set(LIBCXX_DEFAULT_ABI_LIBRARY "libcxxabi")

libcxx/cmake/caches/Apple.cmake

 set(CMAKE_BUILD_TYPE MinSizeRel CACHE STRING "")
 set(CMAKE_POSITION_INDEPENDENT_CODE OFF CACHE BOOL "")
 
 set(LIBCXX_USE_COMPILER_RT ON CACHE BOOL "")
 set(LIBCXX_ENABLE_ASSERTIONS OFF CACHE BOOL "")
 set(LIBCXX_ABI_VERSION "1" CACHE STRING "")
 set(LIBCXX_ENABLE_EXPERIMENTAL_LIBRARY OFF CACHE BOOL "")
 set(LIBCXX_ENABLE_STATIC ON CACHE BOOL "")
 set(LIBCXX_ENABLE_SHARED ON CACHE BOOL "")
 set(LIBCXX_CXX_ABI libcxxabi CACHE STRING "")
 set(LIBCXX_HIDE_FROM_ABI_PER_TU_BY_DEFAULT ON CACHE BOOL "")
-set(LIBCXX_ENABLE_BACKWARDS_COMPATIBILITY_DEBUG_MODE_SYMBOLS OFF CACHE BOOL "")
 set(LIBCXX_ENABLE_VENDOR_AVAILABILITY_ANNOTATIONS ON CACHE BOOL "")
 set(LIBCXX_ENABLE_INCOMPLETE_FEATURES OFF CACHE BOOL "")
 
 set(LIBCXX_HERMETIC_STATIC_LIBRARY ON CACHE BOOL "")
 set(LIBCXXABI_HERMETIC_STATIC_LIBRARY ON CACHE BOOL "")
 
 set(LIBCXXABI_ENABLE_ASSERTIONS OFF CACHE BOOL "")
 set(LIBCXXABI_ENABLE_FORGIVING_DYNAMIC_CAST ON CACHE BOOL "")
 
 set(LIBCXX_TEST_CONFIG "apple-libc++-shared.cfg.in" CACHE STRING "")
 set(LIBCXXABI_TEST_CONFIG "apple-libc++abi-shared.cfg.in" CACHE STRING "")
 set(LIBCXX_TEST_PARAMS "stdlib=apple-libc++" CACHE STRING "")
 set(LIBCXXABI_TEST_PARAMS "${LIBCXX_TEST_PARAMS}" CACHE STRING "")

libcxx/docs/ReleaseNotes.rst

- ``std::valarray``'s unary operators ``!``, ``+``, ``~`` and ``-`` now return an expression
   reference. This is a potential ABI break for code that exposes ``std::valarray`` on an ABI
   boundary, specifically if the return type of an ABI-boundary function is ``auto``-deduced
   from an expression involving unary operators on ``valarray``. If you are concerned by this,
   you can audit whether your executable or library exports any function that returns a
   ``valarray``, and if so ensure that any such function uses ``std::valarray`` directly
   as a return type instead of relying on the type of ``valarray``-expressions, which is
   not guaranteed by the Standard anyway.
 
+- By default, the legacy debug mode symbols are not provided with the library anymore. If
+  you are a vendor and need to re-enable them, please use the ``LIBCXX_ENABLE_BACKWARDS_COMPATIBILITY_DEBUG_MODE_SYMBOLS``
+  CMake flag instead, and contact the libc++ developers as this will be removed in
+  the future. Furthermore, please note that ``LIBCXX_ENABLE_DEBUG_MODE_SUPPORT`` is
+  not honored anymore.
+
 Build System Changes
 --------------------
 
 - Support for standalone builds have been entirely removed from libc++, libc++abi and
   libunwind. Please use :ref:`these instructions <build instructions>` for building
   libc++, libc++abi and/or libunwind.
 
 - The ``{LIBCXX,LIBCXXABI,LIBUNWIND}_TARGET_TRIPLE``, ``{LIBCXX,LIBCXXABI,LIBUNWIND}_SYSROOT`` and
- Previously, the C++ ABI library headers would be installed inside ``<prefix>/include/c++/v1``
   its own headers.
 
 - The legacy testing configuration is now deprecated and will be removed in the next release. For
   most users, this should not have any impact. However, if you are testing libc++, libc++abi or
   libunwind in a configuration or on a platform that used to be supported by the legacy testing
   configuration and isn't supported by one of the configurations in ``libcxx/test/configs``,
   ``libcxxabi/test/configs`` or ``libunwind/test/configs``, please move to one of those
   configurations or define your own.
-
-- The ``LIBCXX_ENABLE_DEBUG_MODE_SUPPORT`` CMake configuration is not supported anymore. If you
-  were disabling support for the debug mode with that flag, please use ``LIBCXX_ENABLE_BACKWARDS_COMPATIBILITY_DEBUG_MODE_SYMBOLS=OFF``
-  instead.