* 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>
sed -i '' -E -e 's/Copyright (.+) The Crashpad Authors\. All rights reserved\.$/Copyright \1 The Crashpad Authors/' $(git grep -El 'Copyright (.+) The Crashpad Authors\. All rights reserved\.$')
Bug: chromium:1098010
Change-Id: I8d6138469ddbe3d281a5d83f64cf918ec2491611
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3878262
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
Remove unneeded base/strings/stringprintf.h includes.
ARCH_CPU_X86_64 macro is used without including build/build_config.h
Missing base/check.h
Change-Id: Ib7864ab7b30ef8fc37649783f7b90b618d0d6a0b
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/2920552
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Justin Cohen <justincohen@chromium.org>
Previously, StartHandler() launched the handler process, then connected
over a pipe to register for crash handling. Instead, the initial client
can create and inherit handles to the handler and pass those handle
values and other data (addresses, etc.) on the command line.
This should improve startup time as there's no need to synchronize with
the process at startup, and allows avoiding a call to CreateProcess()
directly in StartHandler(), which is important for registration for
crash reporting from DllMain().
Incidentally adds new utility functions for string/number conversion and
string splitting.
Note: API change; UseHandler() is removed for all platforms.
BUG=chromium:567850,chromium:656800
Change-Id: I1602724183cb107f805f109674c53e95841b24fd
Reviewed-on: https://chromium-review.googlesource.com/400015
Reviewed-by: Mark Mentovai <mark@chromium.org>
