[libcxx-commits] [libcxx] [libc++][hardening] Introduce a dylib function to log hardening errors. (PR #148266)

[Konstantin Varlamov via libcxx-commits]

================
@@ -0,0 +1,50 @@
+// -*- 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___LOG_ERROR
+#define _LIBCPP___LOG_ERROR
+
+#include <__config>
+
+#if !defined(_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER)
+#  pragma GCC system_header
+#endif
+
+_LIBCPP_BEGIN_NAMESPACE_STD
+
+enum class _LogErrorReason {
+  // Where possible, it logs in a way that indicates a fatal error (which might include capturing the stack trace).
+  _HardeningFailure
+};
+
+// This function should never be called directly from the code -- it should only be called through the
+// `_LIBCPP_LOG_ERROR` macro.
+_LIBCPP_AVAILABILITY_LOG_ERROR _LIBCPP_EXPORTED_FROM_ABI void
+__log_error(_LogErrorReason __reason, const char* __message) _NOEXCEPT;
----------------
var-const wrote:

I'm a bit wary of doing it from a layering perspective. This is a low-level function used by hardening, and having its implementation use hardened classes that might theoretically try to call it again seems a bit off. While we could make sure that we don't use any parts of `string_view` that are hardened, I'd still prefer the logging function to operate on a level "below" hardening, so to speak.

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