From: Jonas Devlieghere Date: Tue, 16 May 2023 05:47:12 +0000 (-0700) Subject: [lldb] Define lldbassert based on NDEBUG instead of LLDB_CONFIGURATION_DEBUG X-Git-Tag: upstream/17.0.6~8317 X-Git-Url: http://review.tizen.org/git/?a=commitdiff_plain;h=10a50762caa6ac17dd063b28863a2ec60576c6f7;p=platform%2Fupstream%2Fllvm.git [lldb] Define lldbassert based on NDEBUG instead of LLDB_CONFIGURATION_DEBUG Whether assertions are enabled or not is orthogonal to the build type which could lead to surprising behavior for lldbassert. Previously, when doing a debug build with assertions disabled, lldbassert would become a NOOP, rather than printing an error like it does in a release build. By definining lldbassert in terms of NDEBUG, it behaves like a regular assert when assertions are enabled, and like a soft assert. Differential revision: https://reviews.llvm.org/D150639 --- diff --git a/lldb/docs/resources/contributing.rst b/lldb/docs/resources/contributing.rst index 5f4b24a..26320f6 100644 --- a/lldb/docs/resources/contributing.rst +++ b/lldb/docs/resources/contributing.rst @@ -66,8 +66,8 @@ rules of thumb: * Soft assertions. LLDB provides ``lldbassert()`` as a soft alternative to cover the middle ground of situations that indicate a - recoverable bug in LLDB. In a Debug configuration ``lldbassert()`` - behaves like ``assert()``. In a Release configuration it will print a + recoverable bug in LLDB. When asserts are enabled ``lldbassert()`` + behaves like ``assert()``. When asserts are disabled, it will print a warning and encourage the user to file a bug report, similar to LLVM's crash handler, and then return execution. Use these sparingly and only if error handling is not otherwise feasible. Specifically, diff --git a/lldb/include/lldb/Utility/LLDBAssert.h b/lldb/include/lldb/Utility/LLDBAssert.h index 471a2f7..524f56f 100644 --- a/lldb/include/lldb/Utility/LLDBAssert.h +++ b/lldb/include/lldb/Utility/LLDBAssert.h @@ -9,13 +9,22 @@ #ifndef LLDB_UTILITY_LLDBASSERT_H #define LLDB_UTILITY_LLDBASSERT_H -#ifdef LLDB_CONFIGURATION_DEBUG +#ifndef NDEBUG #define lldbassert(x) assert(x) #else +#if defined(__clang__) +// __FILE_NAME__ is a Clang-specific extension that functions similar to +// __FILE__ but only renders the last path component (the filename) instead of +// an invocation dependent full path to that file. +#define lldbassert(x) \ + lldb_private::lldb_assert(static_cast(x), #x, __FUNCTION__, \ + __FILE_NAME__, __LINE__) +#else #define lldbassert(x) \ lldb_private::lldb_assert(static_cast(x), #x, __FUNCTION__, __FILE__, \ __LINE__) #endif +#endif namespace lldb_private { void lldb_assert(bool expression, const char *expr_text, const char *func, diff --git a/lldb/source/Utility/LLDBAssert.cpp b/lldb/source/Utility/LLDBAssert.cpp index a8d8ef6..1768958 100644 --- a/lldb/source/Utility/LLDBAssert.cpp +++ b/lldb/source/Utility/LLDBAssert.cpp @@ -25,9 +25,6 @@ void lldb_private::lldb_assert(bool expression, const char *expr_text, if (LLVM_LIKELY(expression)) return; - // If asserts are enabled abort here. - assert(false && "lldb_assert failed"); - #if LLVM_SUPPORT_XCODE_SIGNPOSTS if (__builtin_available(macos 10.12, iOS 10, tvOS 10, watchOS 3, *)) { os_log_fault(OS_LOG_DEFAULT, @@ -36,9 +33,8 @@ void lldb_private::lldb_assert(bool expression, const char *expr_text, } #endif - // In a release configuration it will print a warning and encourage the user - // to file a bug report, similar to LLVM’s crash handler, and then return - // execution. + // Print a warning and encourage the user to file a bug report, similar to + // LLVM’s crash handler, and then return execution. errs() << format("Assertion failed: (%s), function %s, file %s, line %u\n", expr_text, func, file, line); errs() << "backtrace leading to the failure:\n";