[compiler-rt] [ubsan] Introduce weak handle_error_begin and end hooks (PR #198916)

[via llvm-commits]

================
@@ -211,9 +211,26 @@ struct ReportOptions {
 
 bool ignoreReport(SourceLocation SLoc, ReportOptions Opts, ErrorType ET);
 
-#define GET_REPORT_OPTIONS(unrecoverable_handler) \
-    GET_CALLER_PC_BP; \
-    ReportOptions Opts = {unrecoverable_handler, pc, bp}
+// Called when a UBSan handler begins processing an error.
+// Used internally for running sanitizers at the same time as ubsan
+extern "C" SANITIZER_INTERFACE_ATTRIBUTE void __ubsan_handle_error_begin(void);
+
+// Called when a UBSan handler finishes processing an error.
+extern "C" SANITIZER_INTERFACE_ATTRIBUTE void __ubsan_handle_error_end(void);
+
----------------
davidtrevelyan wrote:

Apologies, I misremembered the contents of https://github.com/llvm/llvm-project/pull/193585: I mistakenly thought it contained the patch shared by @cjappl earlier here: https://github.com/cjappl/llvm-project/compare/cjappl/rtsan_ubsan_combo_supported...cjappl:llvm-project:cjappl/ubsan_helper_method, and it's this latter patch that I was referring to in my linked comment with the nonblocking concern [here](https://github.com/llvm/llvm-project/pull/193585#issuecomment-4497507902).

To summarise, https://github.com/llvm/llvm-project/pull/193585 suffers from a nested report problem. We think solving the nested report problem needs entry/exit hooks in ubsan's error reporting - _somewhere_ - and I believe our choice is either:

1. hooks go in `ScopedReport` as `__ubsan_on_report_begin/end` (for which we need to consider how they live alongside, perhaps confusingly, the existing `__ubsan_on_report`), vs
2. hooks go in at a higher level (e.g. `GET_REPORT_OPTIONS`) as `__ubsan_handle_error_begin/end`.

Sorry for the confusion. I marginally prefer option 2. above, but don't have strong feelings and happy with 1. @cjappl does this match with your understanding? 



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