Prepare for building with clang

* Switch to Chromium's clang package on Windows. Fuchsia's clang
  package uses symlinks, which don't Just Work. See comment 3
  on the linked bug for details.

* Also tweak the installed path of the clang package to use
  win-amd64 instead of windows-amd64 to match gn's host_os
  variable, which is needed by the mini_chromium change in the
  roll mentioned below.

* Add `__declspec(noinline)` to sources of some end-to-end test
  binaries where the test expects a certain stack layout that's
  perturbed by inlining

* self_destroying_test_program.cc failed with Access Violation
  instead of with Breakpoint. I'm not 100% sure what's happening
  there as I couldn't reproduce it on my machine. The test uses
  VirtualFree(..., MEM_DECOMMIT) to make parts of the stack unreadable
  to make sure crashpad can handle that. My theory is that clang
  optimized out the call to `_alloca()`, which results in not enough
  of the stack being around for VirtualFree() to be able to decommit.
  https://geidav.wordpress.com/tag/reserved-memory/#:~:text=How%20does%20Windows%20manage%20stack%20memory%3F
  and https://godbolt.org/z/YdbYdKeMh suggest that this theory is
  not completely off -- but the
  `[[maybe_unused]] volatile void* do_not_optimize_away` bit feels
  homeopathic. And yet, with it this seems to pass CQ (see try results
  at patch sets 12 and 20) and without it it doesn't (see patch set 19).
  Maybe this was just luck and the test still feels flakily!
  (The linker's `/STACK` defaults to 1MB stack reserved and 4K
  committed -- 4K kind of seems like it should be enough for that
  VirtualFree call to succeed if that really is the problem.)
  So this part is a bit experimental.

Anyways, nothing uses clang yet, so no behavior change at this point
(other than `gclient sync` downloading less stuff and not failing
by default on Windows).

Includes a one-rev mini_chromium roll:

12ef786772..08d490553b

$ git log 12ef78677..08d490553 --date=short --no-merges --format='%ad %ae %s'
2025-02-13 thakis Prepare mini_chromium for using clang on Windows

Bug: 384682775
Change-Id: I33b54acf18cb6eadfd2167c76c0b4a5824efa64d
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/6242577
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Nico Weber <thakis@chromium.org>

DEPS

@@ -47,7 +47,7 @@ deps = {
       '9719c1e1e676814c456b55f5f070eabad6709d31',
   'crashpad/third_party/mini_chromium/mini_chromium':
       Var('chromium_git') + '/chromium/mini_chromium@' +
-      '12ef786772d9a73751e2d0f3ef9c792b09c386b5',
+      '08d490553b0dcb1324efb59b13be839d7f9f3b62',
   'crashpad/third_party/libfuzzer/src':
       Var('chromium_git') + '/chromium/llvm-project/compiler-rt/lib/fuzzer.git@' +
       'fda403cf93ecb8792cb1d061564d89a6553ca020',
@@ -126,15 +126,18 @@ deps = {
     'condition': 'checkout_fuchsia and host_os == "linux"',
     'dep_type': 'cipd'
   },
-  'crashpad/third_party/windows/clang/windows-amd64': {
+  'crashpad/third_party/windows/clang/win-amd64': {
-    'packages': [
+    'bucket': 'chromium-browser-clang',
+    'objects': [
       {
-        'package': 'fuchsia/third_party/clang/windows-amd64',
+        'object_name': 'Win/clang-llvmorg-20-init-17108-g29ed6000-2.tar.xz',
-        'version': 'XiBHLTa8HHj9lYwC-ArymS75s792s0_ANNvLOfsILqMC',
+        'sha256sum': '1c71efd923a91480480d4f31c2fd5f1369e01e14f15776a9454abbce0bc13548',
+        'size_bytes': 46357580,
+        'generation': 1737590897363452,
       },
     ],
     'condition': 'checkout_win and host_os == "win"',
-    'dep_type': 'cipd'
+    'dep_type': 'gcs',
   },
   'crashpad/third_party/fuchsia-gn-sdk': {
     'packages': [

handler/win/crashy_test_program.cc

@@ -133,7 +133,7 @@ bool CreateThreadWithRegisterPointingToTestMemory() {
   return true;
 }
 
-void SomeCrashyFunction() {
+__declspec(noinline) void SomeCrashyFunction() {
   // SetLastError and NTSTATUS so that we have something to view in !gle in
   // windbg. RtlNtStatusToDosError() stores STATUS_NO_SUCH_FILE into the
   // LastStatusError of the TEB as a side-effect, and we'll be setting

handler/win/self_destroying_test_program.cc

@@ -24,11 +24,17 @@
 namespace crashpad {
 namespace {
 
+// Without this, clang optimizes away the _alloca below, which in turn
+// makes the VirtualFree() crash with an access violation.
+#if defined(__clang__)
+#pragma clang optimize off
+#endif
+
 // We VirtualFree a region in ourselves (the stack) to confirm that the
 // exception reporter captures as much as possible in the minidump and doesn't
 // abort. __debugbreak() immediately after doing so because the process is
 // clearly in a very broken state at this point.
-bool FreeOwnStackAndBreak() {
+__declspec(noinline) bool FreeOwnStackAndBreak() {
   ProcessReaderWin process_reader;
   if (!process_reader.Initialize(GetCurrentProcess(),
                                  ProcessSuspensionState::kRunning)) {
@@ -45,7 +51,7 @@ bool FreeOwnStackAndBreak() {
 
   // Push the stack up a bit so that hopefully the crash handler can succeed,
   // but won't be able to read the base of the stack.
-  _alloca(16384);
+  [[maybe_unused]] volatile void* do_not_optimize_away = _alloca(16384);
 
   // We can't succeed at MEM_RELEASEing this memory, but MEM_DECOMMIT is good
   // enough to make it inaccessible.
@@ -63,7 +69,7 @@ bool FreeOwnStackAndBreak() {
   return true;
 }
 
-int SelfDestroyingMain(int argc, wchar_t* argv[]) {
+__declspec(noinline) int SelfDestroyingMain(int argc, wchar_t* argv[]) {
   if (argc != 2) {
     fprintf(stderr, "Usage: %ls <server_pipe_name>\n", argv[0]);
     return EXIT_FAILURE;
@@ -83,6 +89,10 @@ int SelfDestroyingMain(int argc, wchar_t* argv[]) {
   return EXIT_SUCCESS;
 }
 
+#if defined(__clang__)
+#pragma clang optimize on
+#endif
+
 }  // namespace
 }  // namespace crashpad