[libc++] Define new/delete in libc++abi only by default

[ldionne]

Summary

Previously, we would define new/delete in both libc++ and libc++abi. Not only does this cause code bloat, but also it's technically an ODR violation since we don't know which operator will be selected. Furthermore, since those are weak definitions, we should strive to have as few of them as possible (to improve load times).

My preferred choice would have been to put the operators in libc++ only by default, however that would create a circular dependency between libc++ and libc++abi, which GNU linkers don't handle.

Folks who want to ship new/delete in libc++ instead of libc++abi are free to do so by turning on LIBCXX_ENABLE_NEW_DELETE_DEFINITIONS at CMake configure time.

On Apple platforms, this shouldn't be an ABI break because we re-export the new/delete symbols from libc++abi. This change actually makes libc++ behave closer to the system libc++ shipped on Apple platforms.

On other platforms, this is an ABI break for people linking against libc++ but not libc++abi.

[ldionne]

So, it turns out that even with GCC 9, this will cause errors like this (on my Linux Docker vm):

<...>lib/libc++abi.so: undefined reference to `operator delete(void*)'
<...>lib/libc++abi.so: undefined reference to `operator new[](unsigned long)'
<...>lib/libc++abi.so: undefined reference to `operator delete[](void*)'
<...>lib/libc++abi.so: undefined reference to `operator delete(void*, unsigned long)'

I see three solutions:

1. By default, provide new/delete in libc++abi but not in libc++. I'm not sure I like that.
2. Require that libc++abi be built with -DLIBCXXABI_ENABLE_NEW_DELETE_DEFINITIONS=ON on GCC. This means we need to change the CI builders to add that option.
3. "Fix" GCC and wait multiple years for GCC 9 not to be supported anymore before we switch the default.

I don't care whether we do (1) or (2) -- at Apple we specify -DLIBCXXABI_ENABLE_NEW_DELETE_DEFINITIONS=ON explicitly when we build libc++abi anyway. However, we need to align libc++abi and libc++ regarding who provides new/delete in the default LLVM configuration.

[ldionne]

@EricWF My preference would be to do (2) for the short term, and (3) in the long term. Whoever builds libc++abi from source using GCC needs to know what they're doing anyway. WDYT?

[ldionne]

Fix linker error with GCC

[ldionne]

It turns out the GCC problem was only due to the linker not resolving the undefined new/delete references in libc++abi to libc++. Adding another -lc++ after -lc++abi fixes the issue.

I think this patch is good to go as it is now.

[ldionne]

Pinging vendors for awareness of the change: @phosek @danalbert @dim

This is going in soon and will require a change in how you build libc++abi if you need new/delete definitions to be provided in libc++abi.so, namely to use -DLIBCXXABI_ENABLE_NEW_DELETE_DEFINITIONS=ON when you configure CMake for libc++abi.

The upshot of this change is that by default, we won't get both definitions in libc++ and libc++abi, thus unbreaking the default configuration.

[dim]

In D68269#1691913, @ldionne wrote:

Pinging vendors for awareness of the change: @phosek @danalbert @dim

This is going in soon and will require a change in how you build libc++abi if you need new/delete definitions to be provided in libc++abi.so, namely to use -DLIBCXXABI_ENABLE_NEW_DELETE_DEFINITIONS=ON when you configure CMake for libc++abi.

The upshot of this change is that by default, we won't get both definitions in libc++ and libc++abi, thus unbreaking the default configuration.

Hm, we don't use libc++abi in FreeBSD (at least not by default), but libcxxrt, which has its own new/delete definitions. I never noticed a conflict with libc++ though, since when is it providing new/delete by itself?

[emaste]

For reference libcxxrt comes from here: https://github.com/libcxxrt/libcxxrt

[mclow.lists]

If the Android and FreeBSD folks are ok with this, I'm fine with it

[ldionne]

In D68269#1692076, @dim wrote:

Hm, we don't use libc++abi in FreeBSD (at least not by default), but libcxxrt, which has its own new/delete definitions. I never noticed a conflict with libc++ though, since when is it providing new/delete by itself?

libc++ always provides new/delete unless you provide -DLIBCXX_ENABLE_NEW_DELETE_DEFINITIONS=OFF at CMake configuration time. Those definitions might be weak, though, and that could be why the ones from libcxxrt are used instead? It would be worth double-checking. At the very least, I can say that the definitions of new/delete are weak in both libc++ and libc++abi, on Ubuntu (tested on a Docker container).

[EricWF]

libcxx/utils/libcxx/test/config.py

765 ↗

(On Diff #222629)

We want the link line we generate to match exactly what Clang spits out. Otherwise we're potentially hiding bugs.

In this case, Clang will fail to link programs with the installed version of libc++.

[danalbert]

If the Android and FreeBSD folks are ok with this, I'm fine with it

Fine for Android for at least the platform and the NDK (we don't actually build with CMake in those cases). +srhines just in case there's another case I don't know about.

[ldionne]

So, the problem with this patch as it stands is that it introduces a link-time dependency from libc++abi back to libc++, because libc++abi needs the definition of new and delete (which would be in libc++ only with this patch). This is what I'm working around in the tests by re-adding -lc++ after -lc++abi on the compiler command line. This isn't a problem on Apple platforms IIUC since the order of command-line -l<xxx> arguments doesn't matter, but it does for linkers on most other platforms.

The alternative would be to only provide new/delete inside libc++abi, not in libc++ (by default). So, vendors (@phosek @srhines @danalbert @dim @emaste), are you OK with the default becoming that libc++abi provides new/delete, and libc++ DOES NOT (by default). If you want to keep shipping new/delete as part of libc++, you'll need to specify -DLIBCXX_ENABLE_NEW_DELETE_DEFINITIONS=ON at CMake configure time.

Side note: I don't care which way we go, because at Apple we specify both LIBCXX_ENABLE_NEW_DELETE_DEFINITIONS=OFF and LIBCXXABI_ENABLE_NEW_DELETE_DEFINITIONS=ON explicitly anyway. What I care about is that by default, we provide the symbols in exactly one place, because that will allow me to do interesting simplifications without breaking the default configuration in upstream LLVM.

[thakis]

In D68269#1695143, @ldionne wrote:

So, the problem with this patch as it stands is that it introduces a link-time dependency from libc++abi back to libc++, because libc++abi needs the definition of new and delete (which would be in libc++ only with this patch). This is what I'm working around in the tests by re-adding -lc++ after -lc++abi on the compiler command line. This isn't a problem on Apple platforms IIUC since the order of command-line -l<xxx> arguments doesn't matter, but it does for linkers on most other platforms.

We (Chromium) currently statically link libc++ on all platforms, but use the platform default abi library. If I read the thread here right, this means we currently get operator new from libc++ but going forward we'd get it from the platform abi libraries -- but at the moment none (except darwin) have it yet. So that'd likely be an issue for us.

[ldionne]

In D68269#1695159, @thakis wrote:

In D68269#1695143, @ldionne wrote:

So, the problem with this patch as it stands is that it introduces a link-time dependency from libc++abi back to libc++, because libc++abi needs the definition of new and delete (which would be in libc++ only with this patch). This is what I'm working around in the tests by re-adding -lc++ after -lc++abi on the compiler command line. This isn't a problem on Apple platforms IIUC since the order of command-line -l<xxx> arguments doesn't matter, but it does for linkers on most other platforms.

We (Chromium) currently statically link libc++ on all platforms, but use the platform default abi library. If I read the thread here right, this means we currently get operator new from libc++ but going forward we'd get it from the platform abi libraries -- but at the moment none (except darwin) have it yet. So that'd likely be an issue for us.

This means that you folks need to keep shipping new/delete in libc++.a, which entails that you'd configure it with -DLIBCXX_ENABLE_NEW_DELETE_DEFINITIONS=ON at CMake-configure time. If you don't use CMake to build libc++, none of this matters to you.

[srhines]

In D68269#1693496, @danalbert wrote:

If the Android and FreeBSD folks are ok with this, I'm fine with it

Fine for Android for at least the platform and the NDK (we don't actually build with CMake in those cases). +srhines just in case there's another case I don't know about.

I don't think there are any other problems for us. When we build libc++ as part of the toolchain build, it is primarily to be used for the Linux host, because external/libcxx handles our on-device cases. I looked at our build rules briefly to make sure that everything should be fine, and agree with Dan.

[danalbert]

The alternative would be to only provide new/delete inside libc++abi, not in libc++ (by default). So, vendors (@phosek @srhines @danalbert @dim @emaste), are you OK with the default becoming that libc++abi provides new/delete, and libc++ DOES NOT (by default). If you want to keep shipping new/delete as part of libc++, you'll need to specify -DLIBCXX_ENABLE_NEW_DELETE_DEFINITIONS=ON at CMake configure time.

Also fine for Android. libc++abi and libc++ aren't separate (shared) libraries on Android, so it wouldn't make a difference for us.

[ldionne]

Rebase on top of master.

[phosek]

This is fine with Fuchsia, thanks for checking!

[ldionne]

Move new/delete to libc++abi instead of libc++.

This is the suggestion that had been informally approved in the review but
not implemented yet.

[ldionne]

I just updated the review to match the behavior we had agreed on informally. Because this constitutes a tricky change, I'm going to re-iterate what the change does and what the potential implications of it are, and ask that vendors acknowledge the change again.

Currently, in the vanilla LLVM build, both libc++ and libc++abi define and export the various new/delete operators. This is both wrong (ODR violation) and also bad from a code size perspective. It's also just plain confusing. This change moves the operators to libc++abi only, and removes them from libc++. This means:

• On Linux: libc++.so will NOT be exporting new/delete operators. You'll have to link against libc++abi to get those (which should already be the case in most cases). This is an ABI break if you're shipping libc++.so and it links against another ABI library that doesn't provide new/delete.
• On Apple: libc++.dylib re-exports the new/delete operators from libc++abi.dylib, so there should be no functional change here.

For vendors who want to keep the new/delete operators in libc++.dylib, they can define -DLIBCXX_ENABLE_NEW_DELETE_DEFINITIONS=ON (and -DLIBCXXABI_ENABLE_NEW_DELETE_DEFINITIONS=OFF) to get that behavior.

Ping @thakis @srhines @emaste @dim @danalbert @phosek @mgorny @christof @EricWF . Sorry for pinging such a large number of people, but I'd rather have a large audience for a change of this nature.

[ldionne]

Ping. Please take a look. I'll ship this in a week if nobody cares.

[dim]

In D68269#2322151, @ldionne wrote:

Ping. Please take a look. I'll ship this in a week if nobody cares.

On FreeBSD we replaced (quite a while ago now) libsupc++ with libcxxrt. Currently this also provides new and delete operators, but not all that are provided by libc++ (as of ~11.0.0 rc5):

libcxxrt:

% nm -D /lib/libcxxrt.so.1|c++filt|grep -Ew 'new|delete' 
0000000000017d10 W operator delete[](void*)
0000000000017d30 W operator delete[](void*, unsigned long)
0000000000017cc0 W operator delete(void*)
0000000000017d20 W operator delete(void*, unsigned long)
0000000000017cd0 W operator new[](unsigned long)
0000000000017c20 W operator new(unsigned long)
0000000000017c90 W operator new(unsigned long, std::nothrow_t const&)

libc++:

00000000000b5c80 W operator delete[](void*)
00000000000b5c90 W operator delete[](void*, std::nothrow_t const&)
00000000000b5e10 W operator delete[](void*, std::align_val_t)
00000000000b5e20 W operator delete[](void*, std::align_val_t, std::nothrow_t const&)
00000000000b5ca0 W operator delete[](void*, unsigned long)
00000000000b5e30 W operator delete[](void*, unsigned long, std::align_val_t)
00000000000b5c50 W operator delete(void*)
00000000000b5c60 W operator delete(void*, std::nothrow_t const&)
00000000000b5de0 W operator delete(void*, std::align_val_t)
00000000000b5df0 W operator delete(void*, std::align_val_t, std::nothrow_t const&)
00000000000b5c70 W operator delete(void*, unsigned long)
00000000000b5e00 W operator delete(void*, unsigned long, std::align_val_t)
00000000000b5c10 W operator new[](unsigned long)
00000000000b5c20 W operator new[](unsigned long, std::nothrow_t const&)
00000000000b5da0 W operator new[](unsigned long, std::align_val_t)
00000000000b5db0 W operator new[](unsigned long, std::align_val_t, std::nothrow_t const&)
00000000000b5b70 W operator new(unsigned long)
00000000000b5be0 W operator new(unsigned long, std::nothrow_t const&)
00000000000b5cb0 W operator new(unsigned long, std::align_val_t)
00000000000b5d70 W operator new(unsigned long, std::align_val_t, std::nothrow_t const&)

The libcxxrt implementations basically call malloc and free, and it has a comment:

* These definitions are intended to be used for testing and are weak symbols
 * to allow them to be replaced by definitions from a STL implementation.
 * These versions simply wrap malloc() and free(), they do not provide a
 * C++-specific allocator.

but it seems that libc++ doesn't really have a substantially different implementation. (Not sure how you would generally implement a C++ specific allocator, but there will probably be cases where you can do things more efficiently if you know that you're not just allocating flat blobs.)

That said, both libcxxrt and libc++ mark their implementations as weak, so it's good guess which one wins... I'm actually not completely sure, except for the variants that libcxxrt doesn't implement. :)

In any case, we'd at least have to add the variants with align_val_t and with the const nothrow_t to libcxxrt, to make it backwards compatible. Another option would be to switch to libc++abi, but that is quite a lot more work.

[ldionne]

In D68269#2322291, @dim wrote:

In D68269#2322151, @ldionne wrote:

Ping. Please take a look. I'll ship this in a week if nobody cares.

On FreeBSD we replaced (quite a while ago now) libsupc++ with libcxxrt. Currently this also provides new and delete operators, but not all that are provided by libc++ (as of ~11.0.0 rc5):

[...]

That said, both libcxxrt and libc++ mark their implementations as weak, so it's good guess which one wins... I'm actually not completely sure, except for the variants that libcxxrt doesn't implement. :)

In any case, we'd at least have to add the variants with align_val_t and with the const nothrow_t to libcxxrt, to make it backwards compatible. Another option would be to switch to libc++abi, but that is quite a lot more work.

The other option, which I would argue is the least amount of work, is for you to configure CMake with -DLIBCXX_ENABLE_NEW_DELETE_DEFINITIONS=ON. The libc++ produced with that option should match what you have today.

[dim]

In D68269#2322295, @ldionne wrote:

In D68269#2322291, @dim wrote:

In D68269#2322151, @ldionne wrote:

Ping. Please take a look. I'll ship this in a week if nobody cares.

On FreeBSD we replaced (quite a while ago now) libsupc++ with libcxxrt. Currently this also provides new and delete operators, but not all that are provided by libc++ (as of ~11.0.0 rc5):

[...]

That said, both libcxxrt and libc++ mark their implementations as weak, so it's good guess which one wins... I'm actually not completely sure, except for the variants that libcxxrt doesn't implement. :)

In any case, we'd at least have to add the variants with align_val_t and with the const nothrow_t to libcxxrt, to make it backwards compatible. Another option would be to switch to libc++abi, but that is quite a lot more work.

The other option, which I would argue is the least amount of work, is for you to configure CMake with -DLIBCXX_ENABLE_NEW_DELETE_DEFINITIONS=ON. The libc++ produced with that option should match what you have today.

Ah of course, silly me! I was under the impression that you were going to throw out all the operators, but you added a configure-time option instead. That would indeed be just fine for FreeBSD, at least for the time being. (Still it's probably better to update libcxxrt or switch to libc++abi at some point.)

[phosek]

LGTM for Fuchsia.

[danalbert]

LGTM for Android.

[ldionne]

Thank you folks! I'm going to ship this on Friday Oct 16th if nobody objects before then.

[rsmith]

Quite a few buildbots have been broken since this landed. For example: http://lab.llvm.org:8011/#/builders/60/builds/161

Do the bot configurations need to be updated? If so, is someone working on that?

[mstorsjo]

Just FWIW, this broke my setup marginally, but it's trivial for me to fix it. (I just hadn't noticed this thread before.) As both libcxxabi and libcxx used to enable it by default, I had resorted to disabling the one in libcxxabi, but keeping the one in libcxx enabled implicitly - as that was the default (I hadn't actually noticed that there were cmake options for controlling it in both, I only knew about the one in libcxxabi). But it's trivial to fix it by explicitly setting the desired state for both of them so that it behaves the same regardless if building the latest release or the latest master version. And I can also switch to enable it in libcxxabi and disable the one in libcxx, to match the new default config.

[ldionne]

In D68269#2340961, @rsmith wrote:

Quite a few buildbots have been broken since this landed. For example: http://lab.llvm.org:8011/#/builders/60/builds/161

Do the bot configurations need to be updated? If so, is someone working on that?

I'm looking at this.

[ldionne]

@rsmith The only two bots I'm seeing fail because of this issue seem to be:

http://lab.llvm.org:8011/#/builders/119/builds/187
http://lab.llvm.org:8011/#/builders/60/builds/147

Are you seeing others?

libcxx/CMakeLists.txt

if (LLVM_HAVE_LINK_VERSION_SCRIPT AND NOT LIBCXX_STATICALLY_LINK_ABI_IN_SHARED_LIBRARY
     set(ENABLE_LINKER_SCRIPT_DEFAULT_VALUE ON)
 endif()
 
 option(LIBCXX_ENABLE_ABI_LINKER_SCRIPT
       "Use and install a linker script for the given ABI library"
       ${ENABLE_LINKER_SCRIPT_DEFAULT_VALUE})
 
 option(LIBCXX_ENABLE_NEW_DELETE_DEFINITIONS
-    "Build libc++ with definitions for operator new/delete. This option can
-     be used to disable the definitions when libc++abi is expected to provide
-     them" ON)
-
+  "Build libc++ with definitions for operator new/delete. These are normally
+   defined in libc++abi, but this option can be used to define them in libc++
+   instead. If you define them in libc++, make sure they are NOT defined in
+   libc++abi. Doing otherwise is an ODR violation." OFF)
 # Build libc++abi with libunwind. We need this option to determine whether to
 # link with libunwind or libgcc_s while running the test cases.
 option(LIBCXXABI_USE_LLVM_UNWINDER "Build and use the LLVM unwinder." OFF)
 
 # Target options --------------------------------------------------------------
 option(LIBCXX_BUILD_32_BITS "Build 32 bit libc++." ${LLVM_BUILD_32_BITS})
 set(LIBCXX_TARGET_TRIPLE "" CACHE STRING "Use alternate target triple.")
 set(LIBCXX_SYSROOT "" CACHE STRING "Use alternate sysroot.")

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 OFF CACHE BOOL "")
 set(LIBCXX_ENABLE_SHARED ON CACHE BOOL "")
 set(LIBCXX_TYPEINFO_COMPARISON_IMPLEMENTATION "1" CACHE STRING "")
 set(LIBCXX_CXX_ABI libcxxabi CACHE STRING "")
-set(LIBCXX_ENABLE_NEW_DELETE_DEFINITIONS OFF CACHE BOOL "")
 set(LIBCXX_HIDE_FROM_ABI_PER_TU_BY_DEFAULT ON CACHE BOOL "")
 set(LIBCXX_ENABLE_DEBUG_MODE_SUPPORT OFF CACHE BOOL "")
 
-set(LIBCXXABI_ENABLE_NEW_DELETE_DEFINITIONS ON CACHE BOOL "")
 set(LIBCXXABI_ENABLE_PIC OFF CACHE BOOL "")
 set(LIBCXXABI_ENABLE_ASSERTIONS OFF CACHE BOOL "")
 set(LIBCXXABI_ENABLE_FORGIVING_DYNAMIC_CAST ON CACHE BOOL "")

libcxx/docs/ReleaseNotes.rst

 
 New Features
 ------------
 
 - ...
 
 API Changes
 -----------
-- ...
+- By default, libc++ will _not_ include the definition for new and delete,
+  since those are provided in libc++abi. Vendors wishing to provide new and
+  delete in libc++ can build the library with ``-DLIBCXX_ENABLE_NEW_DELETE_DEFINITIONS=ON``
+  to get back the old behavior. This was done to avoid providing new and delete
+  in both libc++ and libc++abi, which is technically an ODR violation. Also
+  note that we couldn't decide to put the operators in libc++ only, because
+  they are needed from libc++abi (which would create a circular dependency).

libcxx/lib/abi/CHANGELOG.TXT

 Afterwards the ABI list should be updated to include the new changes.
 
 New entries should be added directly below the "Version" header.
 
 ------------
 Version 12.0
 ------------
 
+* XXXXXXX - [libc++] Define new/delete in libc++abi only by default
+
+  By default, libc++ does not include the definition for new and delete anymore.
+  Those were previously defined in both libc++ and libc++abi, which was an
+  ODR violation.
+
+  x86_64-apple-apple-darwin
+  -------------------------
+  The following symbols are now re-exported from libc++abi instead of exported
+  by libc++ directly (this should not be an ABI break):
+
+  Symbol moved: __ZdaPv
+  Symbol moved: __ZdaPvm
+  Symbol moved: __ZdaPvmSt11align_val_t
+  Symbol moved: __ZdaPvRKSt9nothrow_t
+  Symbol moved: __ZdaPvSt11align_val_t
+  Symbol moved: __ZdaPvSt11align_val_tRKSt9nothrow_t
+  Symbol moved: __ZdlPv
+  Symbol moved: __ZdlPvm
+  Symbol moved: __ZdlPvmSt11align_val_t
+  Symbol moved: __ZdlPvRKSt9nothrow_t
+  Symbol moved: __ZdlPvSt11align_val_t
+  Symbol moved: __ZdlPvSt11align_val_tRKSt9nothrow_t
+  Symbol moved: __Znam
+  Symbol moved: __ZnamRKSt9nothrow_t
+  Symbol moved: __ZnamSt11align_val_t
+  Symbol moved: __ZnamSt11align_val_tRKSt9nothrow_t
+  Symbol moved: __Znwm
+  Symbol moved: __ZnwmRKSt9nothrow_t
+  Symbol moved: __ZnwmSt11align_val_t
+  Symbol moved: __ZnwmSt11align_val_tRKSt9nothrow_t
+
+  x86_64-unknown-linux-gnu
+  ------------------------
+  The following symbols were moved to libc++abi, but are NOT being re-exported
+  by libc++. This constitutes an ABI break if one links against libc++ but
+  not libc++abi.
+
+  Symbol moved: _ZdaPv
+  Symbol moved: _ZdaPvm
+  Symbol moved: _ZdaPvmSt11align_val_t
+  Symbol moved: _ZdaPvRKSt9nothrow_t
+  Symbol moved: _ZdaPvSt11align_val_t
+  Symbol moved: _ZdaPvSt11align_val_tRKSt9nothrow_t
+  Symbol moved: _ZdlPv
+  Symbol moved: _ZdlPvm
+  Symbol moved: _ZdlPvmSt11align_val_t
+  Symbol moved: _ZdlPvRKSt9nothrow_t
+  Symbol moved: _ZdlPvSt11align_val_t
+  Symbol moved: _ZdlPvSt11align_val_tRKSt9nothrow_t
+  Symbol moved: _Znam
+  Symbol moved: _ZnamRKSt9nothrow_t
+  Symbol moved: _ZnamSt11align_val_t
+  Symbol moved: _ZnamSt11align_val_tRKSt9nothrow_t
+  Symbol moved: _Znwm
+  Symbol moved: _ZnwmRKSt9nothrow_t
+  Symbol moved: _ZnwmSt11align_val_t
+  Symbol moved: _ZnwmSt11align_val_tRKSt9nothrow_t
+
 * 4f13b9992971 - [libc++] Simplify how we re-export symbols from libc++abi
 
   We re-export some symbols that were exported from libc++abi but not from
   libc++. Exporting new symbols is not an ABI break.
 
   x86_64-apple-apple-darwin
   -------------------------
   Symbol added: ___cxa_allocate_dependent_exception

libcxx/lib/abi/CMakeLists.txt

 set(ABILIST_FILE "${CMAKE_CURRENT_LIST_DIR}/${GENERIC_TARGET_TRIPLE}.v${LIBCXX_ABI_VERSION}.abilist")
 set(SYMDIFF_EXE "${LIBCXX_SOURCE_DIR}/utils/sym_diff.py")
 if (EXISTS "${ABILIST_FILE}"
     AND TARGET cxx_shared
     AND ("${LIBCXX_CXX_ABI_LIBNAME}" STREQUAL "libcxxabi" OR
          (APPLE AND "${LIBCXX_CXX_ABI_LIBNAME}" STREQUAL "default"))
     AND NOT LIBCXX_ABI_UNSTABLE
     AND LIBCXX_ENABLE_EXCEPTIONS
-    AND LIBCXX_ENABLE_NEW_DELETE_DEFINITIONS)
+    AND NOT LIBCXX_ENABLE_NEW_DELETE_DEFINITIONS)
     add_custom_target(check-cxx-abilist
             ${SYMDIFF_EXE} --only-stdlib-symbols --strict ${ABILIST_FILE}
             $<TARGET_SONAME_FILE:cxx_shared>
             DEPENDS cxx_shared
             COMMENT "Testing ABI compatibility...")
 else()
     message(STATUS "there is no pre-generated ABI list for the requested libc++ configuration. "
             "check-cxx-abilist target is not supported")
 endif()

libcxx/lib/abi/x86_64-apple-darwin.v1.abilist

 {'is_defined': True, 'name': '__ZTv0_n24_NSt3__113basic_ostreamIcNS_11char_traitsIcEEED0Ev', 'type': 'FUNC'}
 {'is_defined': True, 'name': '__ZTv0_n24_NSt3__113basic_ostreamIcNS_11char_traitsIcEEED1Ev', 'type': 'FUNC'}
 {'is_defined': True, 'name': '__ZTv0_n24_NSt3__113basic_ostreamIwNS_11char_traitsIwEEED0Ev', 'type': 'FUNC'}
 {'is_defined': True, 'name': '__ZTv0_n24_NSt3__113basic_ostreamIwNS_11char_traitsIwEEED1Ev', 'type': 'FUNC'}
 {'is_defined': True, 'name': '__ZTv0_n24_NSt3__114basic_iostreamIcNS_11char_traitsIcEEED0Ev', 'type': 'FUNC'}
 {'is_defined': True, 'name': '__ZTv0_n24_NSt3__114basic_iostreamIcNS_11char_traitsIcEEED1Ev', 'type': 'FUNC'}
 {'is_defined': True, 'name': '__ZTv0_n24_NSt3__19strstreamD0Ev', 'type': 'FUNC'}
 {'is_defined': True, 'name': '__ZTv0_n24_NSt3__19strstreamD1Ev', 'type': 'FUNC'}
-{'is_defined': True, 'name': '__ZdaPv', 'type': 'FUNC'}
-{'is_defined': True, 'name': '__ZdaPvRKSt9nothrow_t', 'type': 'FUNC'}
-{'is_defined': True, 'name': '__ZdaPvSt11align_val_t', 'type': 'FUNC'}
-{'is_defined': True, 'name': '__ZdaPvSt11align_val_tRKSt9nothrow_t', 'type': 'FUNC'}
-{'is_defined': True, 'name': '__ZdaPvm', 'type': 'FUNC'}
-{'is_defined': True, 'name': '__ZdaPvmSt11align_val_t', 'type': 'FUNC'}
-{'is_defined': True, 'name': '__ZdlPv', 'type': 'FUNC'}
-{'is_defined': True, 'name': '__ZdlPvRKSt9nothrow_t', 'type': 'FUNC'}
-{'is_defined': True, 'name': '__ZdlPvSt11align_val_t', 'type': 'FUNC'}
-{'is_defined': True, 'name': '__ZdlPvSt11align_val_tRKSt9nothrow_t', 'type': 'FUNC'}
-{'is_defined': True, 'name': '__ZdlPvm', 'type': 'FUNC'}
-{'is_defined': True, 'name': '__ZdlPvmSt11align_val_t', 'type': 'FUNC'}
-{'is_defined': True, 'name': '__Znam', 'type': 'FUNC'}
-{'is_defined': True, 'name': '__ZnamRKSt9nothrow_t', 'type': 'FUNC'}
-{'is_defined': True, 'name': '__ZnamSt11align_val_t', 'type': 'FUNC'}
-{'is_defined': True, 'name': '__ZnamSt11align_val_tRKSt9nothrow_t', 'type': 'FUNC'}
-{'is_defined': True, 'name': '__Znwm', 'type': 'FUNC'}
-{'is_defined': True, 'name': '__ZnwmRKSt9nothrow_t', 'type': 'FUNC'}
-{'is_defined': True, 'name': '__ZnwmSt11align_val_t', 'type': 'FUNC'}
-{'is_defined': True, 'name': '__ZnwmSt11align_val_tRKSt9nothrow_t', 'type': 'FUNC'}
+{'is_defined': False, 'name': '__ZdaPv', 'type': 'U'}
+{'is_defined': True, 'name': '__ZdaPv', 'type': 'I'}
+{'is_defined': False, 'name': '__ZdaPvRKSt9nothrow_t', 'type': 'U'}
+{'is_defined': True, 'name': '__ZdaPvRKSt9nothrow_t', 'type': 'I'}
+{'is_defined': False, 'name': '__ZdaPvSt11align_val_t', 'type': 'U'}
+{'is_defined': True, 'name': '__ZdaPvSt11align_val_t', 'type': 'I'}
+{'is_defined': False, 'name': '__ZdaPvSt11align_val_tRKSt9nothrow_t', 'type': 'U'}
+{'is_defined': True, 'name': '__ZdaPvSt11align_val_tRKSt9nothrow_t', 'type': 'I'}
+{'is_defined': False, 'name': '__ZdaPvm', 'type': 'U'}
+{'is_defined': True, 'name': '__ZdaPvm', 'type': 'I'}
+{'is_defined': False, 'name': '__ZdaPvmSt11align_val_t', 'type': 'U'}
+{'is_defined': True, 'name': '__ZdaPvmSt11align_val_t', 'type': 'I'}
+{'is_defined': False, 'name': '__ZdlPv', 'type': 'U'}
+{'is_defined': True, 'name': '__ZdlPv', 'type': 'I'}
+{'is_defined': False, 'name': '__ZdlPvRKSt9nothrow_t', 'type': 'U'}
+{'is_defined': True, 'name': '__ZdlPvRKSt9nothrow_t', 'type': 'I'}
+{'is_defined': False, 'name': '__ZdlPvSt11align_val_t', 'type': 'U'}
+{'is_defined': True, 'name': '__ZdlPvSt11align_val_t', 'type': 'I'}
+{'is_defined': False, 'name': '__ZdlPvSt11align_val_tRKSt9nothrow_t', 'type': 'U'}
+{'is_defined': True, 'name': '__ZdlPvSt11align_val_tRKSt9nothrow_t', 'type': 'I'}
+{'is_defined': False, 'name': '__ZdlPvm', 'type': 'U'}
+{'is_defined': True, 'name': '__ZdlPvm', 'type': 'I'}
+{'is_defined': False, 'name': '__ZdlPvmSt11align_val_t', 'type': 'U'}
+{'is_defined': True, 'name': '__ZdlPvmSt11align_val_t', 'type': 'I'}
+{'is_defined': False, 'name': '__Znam', 'type': 'U'}
+{'is_defined': True, 'name': '__Znam', 'type': 'I'}
+{'is_defined': False, 'name': '__ZnamRKSt9nothrow_t', 'type': 'U'}
+{'is_defined': True, 'name': '__ZnamRKSt9nothrow_t', 'type': 'I'}
+{'is_defined': False, 'name': '__ZnamSt11align_val_t', 'type': 'U'}
+{'is_defined': True, 'name': '__ZnamSt11align_val_t', 'type': 'I'}
+{'is_defined': False, 'name': '__ZnamSt11align_val_tRKSt9nothrow_t', 'type': 'U'}
+{'is_defined': True, 'name': '__ZnamSt11align_val_tRKSt9nothrow_t', 'type': 'I'}
+{'is_defined': False, 'name': '__Znwm', 'type': 'U'}
+{'is_defined': True, 'name': '__Znwm', 'type': 'I'}
+{'is_defined': False, 'name': '__ZnwmRKSt9nothrow_t', 'type': 'U'}
+{'is_defined': True, 'name': '__ZnwmRKSt9nothrow_t', 'type': 'I'}
+{'is_defined': False, 'name': '__ZnwmSt11align_val_t', 'type': 'U'}
+{'is_defined': True, 'name': '__ZnwmSt11align_val_t', 'type': 'I'}
+{'is_defined': False, 'name': '__ZnwmSt11align_val_tRKSt9nothrow_t', 'type': 'U'}
+{'is_defined': True, 'name': '__ZnwmSt11align_val_tRKSt9nothrow_t', 'type': 'I'}
 {'is_defined': False, 'name': '___cxa_allocate_exception', 'type': 'U'}
 {'is_defined': True, 'name': '___cxa_allocate_exception', 'type': 'I'}
 {'is_defined': False, 'name': '___cxa_atexit', 'type': 'U'}
 {'is_defined': False, 'name': '___cxa_bad_cast', 'type': 'U'}
 {'is_defined': True, 'name': '___cxa_bad_cast', 'type': 'I'}
 {'is_defined': False, 'name': '___cxa_bad_typeid', 'type': 'U'}
 {'is_defined': True, 'name': '___cxa_bad_typeid', 'type': 'I'}
 {'is_defined': False, 'name': '___cxa_begin_catch', 'type': 'U'}

libcxx/lib/abi/x86_64-unknown-linux-gnu.v1.abilist

 {'is_defined': True, 'name': '_ZNSt3__19to_stringEy', 'type': 'FUNC'}
 {'is_defined': True, 'name': '_ZNSt3__1plIcNS_11char_traitsIcEENS_9allocatorIcEEEENS_12basic_stringIT_T0_T1_EEPKS6_RKS9_', 'type': 'FUNC'}
 {'is_defined': False, 'name': '_ZNSt8bad_castC1Ev', 'type': 'FUNC'}
 {'is_defined': False, 'name': '_ZNSt8bad_castD1Ev', 'type': 'FUNC'}
 {'is_defined': False, 'name': '_ZNSt8bad_castD2Ev', 'type': 'FUNC'}
 {'is_defined': False, 'name': '_ZNSt9bad_allocC1Ev', 'type': 'FUNC'}
 {'is_defined': False, 'name': '_ZNSt9bad_allocD1Ev', 'type': 'FUNC'}
 {'is_defined': False, 'name': '_ZNSt9exceptionD2Ev', 'type': 'FUNC'}
-{'is_defined': False, 'name': '_ZSt15get_new_handlerv', 'type': 'FUNC'}
 {'is_defined': True, 'name': '_ZSt17__throw_bad_allocv', 'type': 'FUNC'}
 {'is_defined': True, 'name': '_ZSt17current_exceptionv', 'type': 'FUNC'}
 {'is_defined': True, 'name': '_ZSt17rethrow_exceptionSt13exception_ptr', 'type': 'FUNC'}
 {'is_defined': True, 'name': '_ZSt18uncaught_exceptionv', 'type': 'FUNC'}
 {'is_defined': True, 'name': '_ZSt19uncaught_exceptionsv', 'type': 'FUNC'}
 {'is_defined': True, 'name': '_ZSt7nothrow', 'size': 1, 'type': 'OBJECT'}
 {'is_defined': False, 'name': '_ZSt9terminatev', 'type': 'FUNC'}
 {'is_defined': True, 'name': '_ZTCNSt3__110istrstreamE0_NS_13basic_istreamIcNS_11char_traitsIcEEEE', 'size': 80, 'type': 'OBJECT'}

 {'is_defined': True, 'name': '_ZTv0_n24_NSt3__113basic_ostreamIcNS_11char_traitsIcEEED0Ev', 'type': 'FUNC'}
 {'is_defined': True, 'name': '_ZTv0_n24_NSt3__113basic_ostreamIcNS_11char_traitsIcEEED1Ev', 'type': 'FUNC'}
 {'is_defined': True, 'name': '_ZTv0_n24_NSt3__113basic_ostreamIwNS_11char_traitsIwEEED0Ev', 'type': 'FUNC'}
 {'is_defined': True, 'name': '_ZTv0_n24_NSt3__113basic_ostreamIwNS_11char_traitsIwEEED1Ev', 'type': 'FUNC'}
 {'is_defined': True, 'name': '_ZTv0_n24_NSt3__114basic_iostreamIcNS_11char_traitsIcEEED0Ev', 'type': 'FUNC'}
 {'is_defined': True, 'name': '_ZTv0_n24_NSt3__114basic_iostreamIcNS_11char_traitsIcEEED1Ev', 'type': 'FUNC'}
 {'is_defined': True, 'name': '_ZTv0_n24_NSt3__19strstreamD0Ev', 'type': 'FUNC'}
 {'is_defined': True, 'name': '_ZTv0_n24_NSt3__19strstreamD1Ev', 'type': 'FUNC'}
-{'is_defined': True, 'name': '_ZdaPv', 'type': 'FUNC'}
-{'is_defined': True, 'name': '_ZdaPvRKSt9nothrow_t', 'type': 'FUNC'}
-{'is_defined': True, 'name': '_ZdaPvSt11align_val_t', 'type': 'FUNC'}
-{'is_defined': True, 'name': '_ZdaPvSt11align_val_tRKSt9nothrow_t', 'type': 'FUNC'}
-{'is_defined': True, 'name': '_ZdaPvm', 'type': 'FUNC'}
-{'is_defined': True, 'name': '_ZdaPvmSt11align_val_t', 'type': 'FUNC'}
-{'is_defined': True, 'name': '_ZdlPv', 'type': 'FUNC'}
-{'is_defined': True, 'name': '_ZdlPvRKSt9nothrow_t', 'type': 'FUNC'}
-{'is_defined': True, 'name': '_ZdlPvSt11align_val_t', 'type': 'FUNC'}
-{'is_defined': True, 'name': '_ZdlPvSt11align_val_tRKSt9nothrow_t', 'type': 'FUNC'}
-{'is_defined': True, 'name': '_ZdlPvm', 'type': 'FUNC'}
-{'is_defined': True, 'name': '_ZdlPvmSt11align_val_t', 'type': 'FUNC'}
-{'is_defined': True, 'name': '_Znam', 'type': 'FUNC'}
-{'is_defined': True, 'name': '_ZnamRKSt9nothrow_t', 'type': 'FUNC'}
-{'is_defined': True, 'name': '_ZnamSt11align_val_t', 'type': 'FUNC'}
-{'is_defined': True, 'name': '_ZnamSt11align_val_tRKSt9nothrow_t', 'type': 'FUNC'}
-{'is_defined': True, 'name': '_Znwm', 'type': 'FUNC'}
-{'is_defined': True, 'name': '_ZnwmRKSt9nothrow_t', 'type': 'FUNC'}
-{'is_defined': True, 'name': '_ZnwmSt11align_val_t', 'type': 'FUNC'}
-{'is_defined': True, 'name': '_ZnwmSt11align_val_tRKSt9nothrow_t', 'type': 'FUNC'}
+{'is_defined': False, 'name': '_ZdaPv', 'type': 'FUNC'}
+{'is_defined': False, 'name': '_ZdaPvSt11align_val_t', 'type': 'FUNC'}
+{'is_defined': False, 'name': '_ZdlPv', 'type': 'FUNC'}
+{'is_defined': False, 'name': '_Znam', 'type': 'FUNC'}
+{'is_defined': False, 'name': '_ZnamSt11align_val_t', 'type': 'FUNC'}
+{'is_defined': False, 'name': '_Znwm', 'type': 'FUNC'}
 {'is_defined': False, 'name': '__cxa_allocate_exception', 'type': 'FUNC'}
 {'is_defined': False, 'name': '__cxa_begin_catch', 'type': 'FUNC'}
 {'is_defined': False, 'name': '__cxa_current_primary_exception', 'type': 'FUNC'}
 {'is_defined': False, 'name': '__cxa_decrement_exception_refcount', 'type': 'FUNC'}
 {'is_defined': False, 'name': '__cxa_end_catch', 'type': 'FUNC'}
 {'is_defined': False, 'name': '__cxa_free_exception', 'type': 'FUNC'}
 {'is_defined': False, 'name': '__cxa_guard_abort', 'type': 'FUNC'}
 {'is_defined': False, 'name': '__cxa_guard_acquire', 'type': 'FUNC'}

libcxx/src/CMakeLists.txt

if (LIBCXX_ENABLE_SHARED)
   endif()
 
   if (LIBCXX_OSX_REEXPORT_LIBCXXABI_SYMBOLS)
     target_link_libraries(cxx_shared PRIVATE
       "-Wl,-unexported_symbols_list,${CMAKE_CURRENT_SOURCE_DIR}/../lib/libc++unexp.exp"
       "-Wl,-reexported_symbols_list,${CMAKE_CURRENT_SOURCE_DIR}/../lib/libc++abi.v${LIBCXX_LIBCPPABI_VERSION}.exp"
       "-Wl,-force_symbols_not_weak_list,${CMAKE_CURRENT_SOURCE_DIR}/../lib/notweak.exp"
       "-Wl,-force_symbols_weak_list,${CMAKE_CURRENT_SOURCE_DIR}/../lib/weak.exp")
-
-    if (NOT LIBCXX_ENABLE_NEW_DELETE_DEFINITIONS)
-      target_link_libraries(cxx_shared PRIVATE
-        "-Wl,-reexported_symbols_list,${CMAKE_CURRENT_SOURCE_DIR}/../../libcxxabi/lib/new-delete.exp")
-    endif()
   endif()
 
   # Generate a linker script in place of a libc++.so symlink.
   if (LIBCXX_ENABLE_ABI_LINKER_SCRIPT)
       include(DefineLinkerScript)
       define_linker_script(cxx_shared)
   endif()
 

libcxxabi/CMakeLists.txt

option(LIBCXXABI_BUILD_EXTERNAL_THREAD_LIBRARY
    This option may only be set to ON when LIBCXXABI_ENABLE_THREADS=ON" OFF)
 option(LIBCXXABI_ENABLE_FORGIVING_DYNAMIC_CAST
 "Make dynamic_cast more forgiving when type_info's mistakenly have hidden \
 visibility, and thus multiple type_infos can exist for a single type. \
 When the dynamic_cast would normally fail, this option will cause the \
 library to try comparing the type_info names to see if they are equal \
 instead." OFF)
 
-# FIXME: This option should default to off. Unfortunatly GCC 4.9 fails to link
-# programs to due undefined references to new/delete in libc++abi. Once this
-# has been fixed or worked around the default value should be changed.
-# See https://reviews.llvm.org/D68269 for more details.
 option(LIBCXXABI_ENABLE_NEW_DELETE_DEFINITIONS
-    "Build libc++abi with definitions for operator new/delete. Normally libc++
-    provides these definitions" ON)
+  "Build libc++abi with definitions for operator new/delete. These are normally
+   defined in libc++abi, but it is also possible to define them in libc++, in
+   which case the definition in libc++abi should be turned off." ON)
 option(LIBCXXABI_BUILD_32_BITS "Build 32 bit libc++abi." ${LLVM_BUILD_32_BITS})
 option(LIBCXXABI_INCLUDE_TESTS "Generate build targets for the libc++abi unit tests." ${LLVM_INCLUDE_TESTS})
 set(LIBCXXABI_LIBDIR_SUFFIX "${LLVM_LIBDIR_SUFFIX}" CACHE STRING
     "Define suffix of library directory name (32/64)")
 option(LIBCXXABI_INSTALL_LIBRARY "Install the libc++abi library." ON)
 set(LIBCXXABI_TARGET_TRIPLE "" CACHE STRING "Target triple for cross compiling.")
 set(LIBCXXABI_GCC_TOOLCHAIN "" CACHE PATH "GCC toolchain for cross compiling.")
 set(LIBCXXABI_SYSROOT "" CACHE PATH "Sysroot for cross compiling.")

libcxxabi/src/CMakeLists.txt

if (APPLE)
     function(reexport_symbols file)
       export_symbols("${file}")
       target_link_libraries(cxxabi_shared INTERFACE "-Wl,-reexported_symbols_list,${file}")
     endfunction()
 
     export_symbols("${CMAKE_CURRENT_SOURCE_DIR}/../lib/itanium-base.exp")
 
     if (LIBCXXABI_ENABLE_NEW_DELETE_DEFINITIONS)
-      export_symbols("${CMAKE_CURRENT_SOURCE_DIR}/../lib/new-delete.exp")
+      reexport_symbols("${CMAKE_CURRENT_SOURCE_DIR}/../lib/new-delete.exp")
     endif()
 
     if (LIBCXXABI_ENABLE_EXCEPTIONS)
       reexport_symbols("${CMAKE_CURRENT_SOURCE_DIR}/../lib/exceptions.exp")
 
       if ("${CMAKE_OSX_ARCHITECTURES}" MATCHES "^(armv6|armv7|armv7s)$")
         reexport_symbols("${CMAKE_CURRENT_SOURCE_DIR}/../lib/personality-sjlj.exp")
       else()