[libcxx-commits] [PATCH] D121478: [libc++] Add a lightweight overridable assertion handler

Louis Dionne via Phabricator via libcxx-commits libcxx-commits at lists.llvm.org
Fri Mar 11 11:00:09 PST 2022


ldionne created this revision.
ldionne added a reviewer: Mordante.
Herald added subscribers: arichardson, mgorny.
Herald added a project: All.
ldionne requested review of this revision.
Herald added a project: libc++.
Herald added a subscriber: libcxx-commits.
Herald added a reviewer: libc++.

This patch adds a lightweight assertion handler mechanism that can be
overriden at link-time in a fashion similar to `operator new`.

This is a third take on https://llvm.org/D121123 (which allowed customizing
the assertion handler at compile-time), and https://llvm.org/D119969
(which allowed customizing the assertion handler at runtime only).

This approach is, I think, the best of all three explored approaches.
Indeed, replacing the assertion handler in user code is ergonomic,
yet we retain the ability to provide a custom assertion handler when
deploying to older platforms that don't have a default handler in
the dylib.

As-is, this patch provides some amount of backwards compatibility with
the previous debug mode:

- Code that used to set _LIBCPP_DEBUG=0 in order to get basic assertions in their code will still get basic assertions. If they deploy to a platform where the default assertion handler isn't available, they will need to override the default handler with their custom one.
- Code that was previously compiled with references to __libcpp_debug_function and friends will work out-of-the-box, no changes required. This is because we provide the same symbols in the dylib as we used to.
- Code that used to set a custom __libcpp_debug_function will stop compiling, because we don't provide that declaration anymore. Users will have to migrate to the new way of setting a custom assertion handler, which is extremely easy. I suspect that pool of users is very limited, so breaking them at compile-time is probably acceptable.

The main downside of this approach is that code that enables assertions
and deploys to an older platform without overriding the default handler
will get a load-time error when the dynamic linker fails to find a
default handler.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D121478

Files:
  libcxx/CMakeLists.txt
  libcxx/cmake/caches/Generic-assertions.cmake
  libcxx/docs/BuildingLibcxx.rst
  libcxx/docs/ReleaseNotes.rst
  libcxx/docs/UsingLibcxx.rst
  libcxx/include/__assert
  libcxx/include/__config_site.in
  libcxx/include/version
  libcxx/lib/abi/arm64-apple-darwin.libcxxabi.v1.stable.exceptions.nonew.debug.incomplete.abilist
  libcxx/lib/abi/arm64-apple-darwin.libcxxabi.v1.stable.exceptions.nonew.nodebug.noincomplete.abilist
  libcxx/lib/abi/x86_64-apple-darwin.libcxxabi.v1.stable.exceptions.nonew.debug.incomplete.abilist
  libcxx/lib/abi/x86_64-apple-darwin.libcxxabi.v1.stable.exceptions.nonew.nodebug.noincomplete.abilist
  libcxx/lib/abi/x86_64-unknown-linux-gnu.libcxxabi.v1.stable.exceptions.nonew.debug.incomplete.abilist
  libcxx/lib/abi/x86_64-unknown-linux-gnu.libcxxabi.v1.stable.exceptions.nonew.debug.noincomplete.abilist
  libcxx/lib/abi/x86_64-unknown-linux-gnu.libcxxabi.v1.stable.exceptions.nonew.nodebug.incomplete.abilist
  libcxx/lib/abi/x86_64-unknown-linux-gnu.libcxxabi.v1.stable.noexceptions.nonew.debug.incomplete.abilist
  libcxx/src/CMakeLists.txt
  libcxx/src/assert.cpp
  libcxx/src/legacy_debug_handler.cpp
  libcxx/test/libcxx/assertions/assertion_handler.abort.pass.cpp
  libcxx/test/libcxx/assertions/assertion_handler.pass.cpp
  libcxx/utils/generate_feature_test_macro_components.py
  libcxx/utils/libcxx/test/params.py

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D121478.414705.patch
Type: text/x-patch
Size: 27337 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/libcxx-commits/attachments/20220311/553693e0/attachment-0001.bin>


More information about the libcxx-commits mailing list