[libcxx-commits] [libcxx] [libcxx] add Android assertion handler (PR #198831)

[George Burgess IV via libcxx-commits]

================
@@ -0,0 +1,58 @@
+// -*- C++ -*-
+//===----------------------------------------------------------------------===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+
+#ifndef __LIBCPP_ANDROID_ASSERTION_HANDLER
+#define __LIBCPP_ANDROID_ASSERTION_HANDLER
+
+#include <__config>
+#include <__log_hardening_failure>
+#include <__verbose_abort>
+#include <__verbose_trap>
+
+#if !defined(_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER)
+#  pragma GCC system_header
+#endif
+
+#if _LIBCPP_ASSERTION_SEMANTIC == _LIBCPP_ASSERTION_SEMANTIC_IGNORE
+#  define _LIBCPP_ASSERTION_HANDLER(message) ((void)0)
+
+#elif _LIBCPP_ASSERTION_SEMANTIC == _LIBCPP_ASSERTION_SEMANTIC_OBSERVE
+#  define _LIBCPP_ASSERTION_HANDLER(message) _LIBCPP_LOG_HARDENING_FAILURE(message)
+
+#elif _LIBCPP_ASSERTION_SEMANTIC == _LIBCPP_ASSERTION_SEMANTIC_QUICK_ENFORCE
+
+// Require `nomerge` for better crash attribution.
+#  define _LIBCPP_ASSERTION_HANDLER(message) \
+  ({ [[clang::nomerge]] _LIBCPP_VERBOSE_TRAP(message); })
----------------
gburgessiv wrote:

For #200078, totally agree that that needs to be hashed out. I have numbers handy for this patch, but nothing readily available for that one.

For the headers in this PR, Android currently enables libcxx hardening in two narrow parts of its codebase - my measurement of the binary size overhead of _simultaneously_:

- Flipping the platform-wide default to `FAST`
- Adding the `nomerge` to the `verbose` hardener

...was a 0.11% average code size regression, as calculated by:

- Running `du -b` across stripped binaries, and
- Filtering out all binaries that no change in binary size (since we have e.g., Rust and pure C binaries that I didn't want to skew this unfairly)

The total code size regression for these changes was <1MB for a multi-GB OS. My attempts to measure RAM diffs from the extra code size were all in the noise, too.

For the initial implementation of the adjacent `noinline __libcpp_android_verbose_abort` function, the number was closer to 0.36%. If we end up preferring the removal of the wrapper, I expect that number will go up a nontrivial amount, but realistically it will only be built as part of instrumented-for-debug-friendliness images, so I'm not opposed to a few more fractions of a point of bloat if you all prefer less complexity. :) 

https://github.com/llvm/llvm-project/pull/198831