[libcxx-commits] [PATCH] D68269: [libc++] Define new/delete in libc++abi only by default

[Louis Dionne via Phabricator via libcxx-commits]

ldionne added a comment.

In D68269#2322291 <https://reviews.llvm.org/D68269#2322291>, @dim wrote:

> In D68269#2322151 <https://reviews.llvm.org/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.

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.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D68269/new/

https://reviews.llvm.org/D68269