[compiler-rt] [asan][win][msvc] override new and delete and seperate TUs (PR #68754)

[Amy Wishnousky via llvm-commits]

================
@@ -0,0 +1,51 @@
+//===-- asan_win_thunk_common.h  --------------------------------*- 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
+//
+//===----------------------------------------------------------------------===//
+//
+// This file is a part of AddressSanitizer, an address sanity checker.
+//
+// Windows-specific common utilities to communicate between static and DLL
+// portions of the ASAN runtime.
+//
+// This file must not include any core components of the ASAN runtime as it must
+// be able to be included in the portions statically linked with the user
+// program.
+//
+//===----------------------------------------------------------------------===//
+
+#pragma once
+#include <sanitizer_common/sanitizer_internal_defs.h>
+namespace __sanitizer {
+
+__declspec(noinline) inline __sanitizer::uptr __asan_GetCurrentPc() {
+  return GET_CALLER_PC();
+}
+
+struct __asan_win_stack_data {
----------------
amyw-msft wrote:

If I understand correctly, the question is "why not just call `GET_STACK_TRACE_MALLOC` where you are constructing an `__asan_win_stack_data`"?

The reason is to reduce the file size and complexity of the ASan .lib. The operator new/delete overrides need to be outside the ASan DLL and are included statically. `GET_STACK_TRACE_MALLOC` calls internal functions that would bloat the otherwise lightweight static library that is only new/delete overrides. We construct `__asan_win_stack_data` outside the DLL here to collect the stack trace and then pass that into the relevant ASan export where we have all the internals available. Potentially there is a better way to do this by collecting the stack trace inside the DLL and filtering to where we want to show, but at the time we went with this to avoid any "tweaking the numbers" games with respect to how optimization or internal changes affect how our stack traces are displayed.

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