The original patchset has a minor flaw in building for UWP unrelated to the changes made in the original CL itself. $target_cpu is used in "host" toolset instead of $host_cpu and when building an arm target it causes issues as it can't build host tools.
Fixes an error introduced in crrev.com/c/923161
R=brucedawson@chromium.org, dpranke@chromium.org, phoglund@chromium.org
Bug: 812814
Change-Id: Ia6e7f1dc2b5494e212d67b99a119e023a1308c25
Reviewed-on: https://chromium-review.googlesource.com/1022493
Reviewed-by: Dirk Pranke <dpranke@chromium.org>
Reviewed-by: Bruce Dawson <brucedawson@chromium.org>
Commit-Queue: Patrik Höglund <phoglund@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#554707}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 86ac3fe7e3327a67ba131764738ed5cdb3685fff
This reverts commit 953fcf3fe08d99068f2a4b39081a2ab55dae178a.
Reason for revert: We want to set envvar directly.
Original change's description:
> Add disable_goma for args.gn on win
>
> Switching use_goma causes full rebuild due to command line update in build.ninja.
> I added disable_goma to set GOMA_DISABLED on environment.{x86,x64}.
>
> If we specify disable_goma=true, GOMA_DISABLED env is passed to gomacc.
> Then gomacc executes given argument instead of sending args to goma daemon.
>
> This will help toolchain maintainer to check difference of build behavior w/wo goma without rebuilding everything.
>
> Bug:
> Change-Id: Ie58958b5484d57be1c40fbbca363f1eef4b55c7e
> Reviewed-on: https://chromium-review.googlesource.com/768549
> Reviewed-by: Dirk Pranke <dpranke@chromium.org>
> Reviewed-by: Bruce Dawson <brucedawson@chromium.org>
> Commit-Queue: Takuto Ikuta <tikuta@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#518134}
TBR=dpranke@chromium.org,brucedawson@chromium.org,tikuta@chromium.org
Change-Id: Ia2d510f4149b30cff3f8dc6c0b89e37190c39368
Reviewed-on: https://chromium-review.googlesource.com/1015860
Reviewed-by: Nico Weber <thakis@chromium.org>
Commit-Queue: Takuto Ikuta <tikuta@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#551602}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: ee4c20c2074018c75d297647820d1d58f82fd7c9
This reverts crrev.com/c/952666. That commit was a workaround for a
bug which was fixed in Clang r327557, so the workaround is no longer
needed.
R=depranke,brucedawson
Bug: 818086
Change-Id: I98ba3cea051734da2eef81fe1986c9f9b5d9b617
Reviewed-on: https://chromium-review.googlesource.com/998513
Reviewed-by: Bruce Dawson <brucedawson@chromium.org>
Reviewed-by: Dirk Pranke <dpranke@chromium.org>
Commit-Queue: Bob Haarman <inglorion@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#548657}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 9ea7ffa8290370361c8d2bde8e13b5adac66acc7
LLD currently ignores /PROFILE, so it does not enable /OPT:ICF and
/OPT:REF for chrome_elf.dll. chrome_elf_import_unittests checks that the
linker strips dead dependencies on user32.dll and shell32.dll, so it
currently fails when chrome_elf.dll is linked with LLD.
I will fix this bug in upstream LLD, but in the meantime this will fix
the issue. This change also seens like it is more explicit and reduces
gn complexity, so maybe we should leave it like this after the LLD fix.
R=brucedawson@chromium.org, thakis@chromium.org
Bug: chromium:827075
Change-Id: Icd2a09aab031b7ff07738892c12a5de1ec9936b9
Reviewed-on: https://chromium-review.googlesource.com/986694
Commit-Queue: Reid Kleckner <rnk@chromium.org>
Reviewed-by: Nico Weber <thakis@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#547105}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: bf8b9821e804283aab1ee7a40c05d1a96eee0cf3
This removes the is_syzyasan build flag and related build configuration.
Everything under the SYZYASAN define is either removed, or moved under
ADDRESS_SANITIZER, as e.g. the previously SyzyASAN-only heap corruption
debug URLs.
The DCHECK debug URL is now enabled and the activity tracker grabs a
stack trace when DCHECK_IS_ON(), instead of only under SYZYASAN.
The metrics system sets the is_asan_build bit in the system profile now
under ADDRESS_SANITIZER, against the day when we ship Clang ASAN builds.
The SyzyProf profiling support is removed.
To support the upcoming official build with configurable DCHECKs, the
channel string visible in chrome://settings/help is adorned with "DCheck".
The DEPS to fetch the Syzygy binary archive is left in place, as the
zap_timestamps.exe utility is still in use. Once LLD replaces the MSVC
linker, that can be removed without penalty, at which time the DEPS will
be scrubbed.
Bug: 821764
Change-Id: I08202da8f032f2350a589cfcda9e9b2edd147b7d
Reviewed-on: https://chromium-review.googlesource.com/980912
Reviewed-by: Will Harris <wfh@chromium.org>
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Reviewed-by: Wez <wez@chromium.org>
Reviewed-by: Nico Weber <thakis@chromium.org>
Reviewed-by: Chris Hamilton <chrisha@chromium.org>
Reviewed-by: Sébastien Marchand <sebmarchand@chromium.org>
Commit-Queue: Sigurður Ásgeirsson <siggi@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#546966}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 69d0bcdd9729d123d9ba030d9506f763f0e2e56f
This is required to support building Microsoft's WinUWP store
application version of WebRTC.
vs_toolchain.py
- needed to perform environment variable expansion for "Program
Files(x86)" to correctly identify Visual Studio installation location
config/BUILD.gn
- remove delayimp.lib, kernel32.lib and ole32.lib from store
applications (instead requires dloadhelper.lib/WindowsApp.lib
must be used)
BUILDCONFIG.gn
- Do not use clang when compiling Windows UWP targets;
- Added declare_args for is_target_winuwp rather and stripped multi
defined variations of the host_os/current_os == "winrt_10", "winrt_81",
"winrt_81_phone" that heavily polluted the platform / target selections
(as the current targeting methodology is incorrect anyway). The
host_os/current_os is always be "win" and only the target should be
Windows UWP / store applications based on the target_os == "winuwp"
rather than all the flavors of UWP.
- Added filter for _winuwp source files (separate from just windows)
- Added default configs for desktop vs store applications to correctly set
the defines according to the desktop vs store targets
config/win/BUILD.gn
- The Windows UWP versioning assumes to be Windows 10 / store
app now although a updated GN allows for targeting older Windows UWP
versions/SDKs/device families. This allows the definitions for the
various application support versioning and application families required
for UWP to be set.
- The linker calls vsvarsall.bat to be executed via
toolchain/win/setup_toolchain.py in order to correctly identify the
correct linker library path information for Windows store SDK targets.
The hard coded and assumed library paths are fixed in all cases to be
discovered from the tooling for forward future platform support in all
cases.
- Added ARM linkage definitions for the Windows ARM CPU required for
properly targeting all three CPUs (x86, x64, arm) for universal store
binaries.
- Added the proper family C++/C defines required to target the various
Windows store application types currently offered for Windows UWP store
applications.
toolchain/win/BUILD.gn
- The name to support the storage of the environment variables now is
passed into the setup script to allow for easier extension of the
CPUs and target combinations (arm, x64, x86 in the desktop vs store
variations)
- "desktop" vs "store" is now specified the setup for the
correct toolchain targeting
- Sets true/false for is_target_winuwp is dependent on the toolchain
activated (so configurations will be set correctly when the toolchain is
specified for host tool targets required for build tools vs finalized
application targets)
- Cleaned up the Windows RT section to properly support Windows UWP
toolchains
toolchain/win/setup_toolchain.py
- the setup was missing the arm CPU for universal binaries required for
the UWP platform
- The calling of vcvarsall.bat was missing the "store" option for store
applications and all the CPU offered
- Added returning of linker paths by searching the library environments
for well-known library files expected in each of the 3 library paths
required "lib", "um" and "atlmfc"
R=phoglund@google.com
Bug: 812814
Change-Id: If1a6b1b1bc3ed940fc8e2ce726ac016e2491e61d
Reviewed-on: https://chromium-review.googlesource.com/923161
Commit-Queue: Patrik Höglund <phoglund@chromium.org>
Reviewed-by: Dirk Pranke <dpranke@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#545751}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: c5686578e8f519eeec50f574b284fbc12e6e15d8
lld doesn't support /debug:fastlink, and so we used to assert when
trying to use those two together.
However, as we're planning to switch over to lld by default, we don't
want to break the builds of those who have specified is_win_fastlink
manually. Instead, ignore the flag when linking with lld, and eventually
it will be phased out altogether.
Bug: 792131
Change-Id: I83ff749254d4dbc55aedbfc6e87702e8e8a06a23
Reviewed-on: https://chromium-review.googlesource.com/966225
Reviewed-by: Nico Weber <thakis@chromium.org>
Commit-Queue: Hans Wennborg <hans@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#543714}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 8299aa5141fb91909e13d0d91ee76779e5753285
crbug.com/818086 shows that using control flow guard, ThinLTO, and
RTTI together results in broken binaries. This change disables CFG
when ThinLTO and RTTI are enabled to allow builds to succeed while a
fix for the problem is developed.
R=dpranke,thakis
Bug: 818086
Change-Id: Ia926350dc4193f3a1c87a45b36a8d5dc1dd97c08
Reviewed-on: https://chromium-review.googlesource.com/952666
Reviewed-by: Nico Weber <thakis@chromium.org>
Commit-Queue: Nico Weber <thakis@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#541646}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 97d1b87c143adf416220c3bdf36650c8831cb6c2
`clang-cl /Brepro -flto=thin` causes:
warning: argument unused during compilation: '-mno-incremental-linker-compatible'
because /Brepro is a built-in assembler flag, which isn't used in LTO builds.
(We have an open bug on clang-cl somewhere to print the original spelling of
aliased flags.)
Bug: 330260
Change-Id: I72c6fb496107a7c937019293e6ad6f749a680a20
Reviewed-on: https://chromium-review.googlesource.com/944003
Reviewed-by: Hans Wennborg <hans@chromium.org>
Commit-Queue: Nico Weber <thakis@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#540285}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 7c231bfc077d2e23b7f1bcecdcb6fbd21fd0639f
The InputPane APIs first appeared in RS1 version. RS2 or later SDK
is required to build Chrome so changing the version shouldn't be a
problem.
BUG=817501
Change-Id: I1ed1f4a630ffe1d913dee47c03ad4fd45f3c6759
Reviewed-on: https://chromium-review.googlesource.com/941913
Commit-Queue: Dave Tapuska <dtapuska@chromium.org>
Reviewed-by: Dirk Pranke <dpranke@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#540172}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: e470357360010d7de465b33650a040a9471b93f6
With link.exe this isn't always safe (/incremental relies on the mtime
timestamp stored in the .obj file, and there's no easy way to query if
/incremental is used), but with lld it should be.
Looking at `dumpbin /headers test.obj | findstr "time date stamp"`,
cl.exe seems to write a hash of the output to the time date stamp,
while clang-cl always seems to write 0 with /Brepro.
Bug: 330260
Change-Id: I1fd64d0f0678468bc73c672cb84a5a2d878e2e82
Reviewed-on: https://chromium-review.googlesource.com/941905
Reviewed-by: Reid Kleckner <rnk@chromium.org>
Commit-Queue: Nico Weber <thakis@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#540026}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 87a74692c1f308697f351676fbbb2010fe80d248
is_win_fastlink and use_lld are incompatible because lld does not
support /debug:fastlink because it doesn't need it. In addition,
compiling with is_win_fastlink causes .obj files to be bigger, due to
the -fstandalone-debug option which fastlink requires.
This change explicitly prohibits this combination of options to avoid
confusing error messages such as:
lld-link.exe: error: ignoring '/INCREMENTAL' because REF is enabled;
use '/OPT:NOREF' to disable ninja: build stopped: subcommand failed.
Also add /OPT:NOREF for incremental link with lld to dismiss warning introduced in
https://reviews.llvm.org/D42716
Change-Id: I8bfd77edc423963e38cec7fd24a906084d40a81c
Reviewed-on: https://chromium-review.googlesource.com/923835
Commit-Queue: Takuto Ikuta <tikuta@chromium.org>
Reviewed-by: Bruce Dawson <brucedawson@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#538051}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 91adc431c5a8dc8f25b54258c0e20ce397f60949
There appears to be a bug in Microsoft's linker when using /guard:cf
with incremental linking. The table of functions occasionally gets
corrupted or not update which leads to a CFG violation when the OS
thinks that an invalid indirect branch is being taken. The stack shows:
ntdll.dll!RtlFailFast2()
ntdll.dll!RtlpHandleInvalidUserCallTarget()
The error code returned is 0xC0000409 which is
STATUS_STACK_BUFFER_OVERRUN which is quite non-obvious and confusing.
A bug in the linker with incremental linking and CFG seems quite
plausible, and that combination is quite worthless, so the fix is to not
use CFG in component builds.
Note that future occurrences of this bug, if any, will show an error
code of 0xC0000409 where they used to show -1073741819. This is due to
a separate change that alters how we print these error codes.
Bug: 812421
Change-Id: I8042d4363ea93084ca56e0634124799183c4153c
Reviewed-on: https://chromium-review.googlesource.com/920761
Reviewed-by: Nico Weber <thakis@chromium.org>
Commit-Queue: Bruce Dawson <brucedawson@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#537027}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: dd23fadffd3a979017c07fda50828edf9c5583ae
This CL changes the build behavior for debug builds to always pass the
/DYNAMICBASE flag which enables ASLR relocation of executables. The
removal of /DYNAMICBASE from debug builds interacts badly with the
sandbox and a new feature to add AppContainer support as the OS
enables an option to force ASLR regardless of whether an executable has
been built with /DYNAMICBASE or not. The rationale for disabling ASLR
was to simplify debugging in the WinDBG debugger due to the name
conflict between chrome.exe and chrome.dll. However due to changes
in the underlying debug engine as well as chrome_elf.dll loading
before chrome.dll this no longer makes it useful.
Bug: 807267
Change-Id: I651d2b1aa2eb970cc02e7063b5467144c69d23be
Reviewed-on: https://chromium-review.googlesource.com/897623
Reviewed-by: Scott Graham <scottmg@chromium.org>
Commit-Queue: James Forshaw <forshaw@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#533836}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 74b3d06052ba093cf7ca45afb4a5ede5d7b10e73
There are three pieces to this puzzle:
1) Passing the -finstrument-functions-after-inlining flag to all
compiler invocations.
2) Implementing the __cyg_profile_func_enter function.
3) Making all .exe and .dll targets link in the library that provides
that function.
This patch implements those three, losely modeled on how the Android
build works, and adds documentation on how to use this to update the
order files.
Bug: 728324
Change-Id: I778bc8c0c2800244b8f18037197d62223ef92203
Reviewed-on: https://chromium-review.googlesource.com/783830
Commit-Queue: Hans Wennborg <hans@chromium.org>
Reviewed-by: Brett Wilson <brettw@chromium.org>
Reviewed-by: Reid Kleckner <rnk@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#519429}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 3f073d71053f12f66f67e94ed8b397ca34652ada
This gives the ability for projects to enable or disable exceptions
in general manner. Previously this was limited to a GCC/Clang config.
This will allow ANGLE to build the dEQP tests with Clang, since they
require a specific config to enable exceptions. This only affects
Windows builds; other platforms were working correctly.
Bug: 727437
Cq-Include-Trybots: master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
Change-Id: I25f617e4046a868a10b15df56fceec872fb036dc
Reviewed-on: https://chromium-review.googlesource.com/773079
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Brett Wilson <brettw@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#518019}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: c9f5ee0fd4004ab992bdc9413b96680c207e577b
The Fall Creators Update SDK uses DEPRECATEDENUMERATOR to mark some
enums as being deprecated but in the __cplusplus >= 201402 case it
fails to define it! This change forcibly defines it to work around
this header-file bug. This change avoids dozens of errors in
Windows.ApplicationModel.Contacts.h.
VS bug is filed here:
https://developercommunity.visualstudio.com/content/problem/131391/154-fails-to-define-deprecatedenumerator-2.html
Bug: 773476
Change-Id: I604228cac02f676e2c79e9a8e533fd332221b0cd
Reviewed-on: https://chromium-review.googlesource.com/717190
Commit-Queue: Bruce Dawson <brucedawson@chromium.org>
Reviewed-by: Nico Weber <thakis@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#508862}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 00de4b5174c190b4d9f6120ef550a310ec740459
Now that Chromium has switched to using and requiring VC++ 2017 for
Windows builds it makes sense for clang-cl to simulate VC++ 2017
instead of VC++ 2015. This gets _MSC_VER to be set to 1911 and
_MSC_FULL_VER to 191100000.
Bug: 683729
Change-Id: Ie9ec7243eafe60a7579b7c55ab05716d5fe7e4ce
Reviewed-on: https://chromium-review.googlesource.com/706349
Reviewed-by: Nico Weber <thakis@chromium.org>
Commit-Queue: Bruce Dawson <brucedawson@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#507245}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 0febf3c866810f188fb4122f0d2e3b5cfa030b94
VS 2015 does not implement CFG checks for longjmp but VS 2017 does. This
means that the VS 2017 linker, by default, requires that all source
files that use setjmp must be compiled with /guard:cf. This has
implications for clang-cl and for binary size so this change disables
CFG checks for longjmp.
That is, this is a linker flag change that affects runtime behavior so
that VS 2017 generated binaries will behave the same way as VS 2015
generated binaries.
Bug: 766236
Change-Id: I1c959858bceead4ccb28f273bf24926244d38083
Reviewed-on: https://chromium-review.googlesource.com/678063
Reviewed-by: Dirk Pranke <dpranke@chromium.org>
Reviewed-by: Hans Wennborg <hans@chromium.org>
Commit-Queue: Bruce Dawson <brucedawson@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#503825}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 20cc6ec55cf1322cb1afe3e87728d16df8f63834
ilk files are large in 64-bit builds and in non-component builds.
It looks like the conditional here has been wrong since it was
added in https://codereview.chromium.org/1019353004
I linked browser_tests locally, and ilk size is "only" a bit over
1GB, a lot smaller than blink_core.ilk, which we can successfully
link incrementally in 32-bit component builds. (I also checked
that browser_tests links fine incrementally.)
Bug: 755863
Change-Id: If94c1d562d7e02b94a8cb899116479ff2d9ecd92
Reviewed-on: https://chromium-review.googlesource.com/617764
Commit-Queue: Nico Weber <thakis@chromium.org>
Reviewed-by: Brett Wilson <brettw@chromium.org>
Reviewed-by: Scott Graham <scottmg@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#494926}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 421a3c55c1173a59db3554920ccb39c9c145fb03
This has a bunch of minor advantages:
1. It's less code
2. It's a build step less per windows_manifest
3. rc.exe is no longer explicitly required in the build, which means
just distributing lld-link is enough on non-Windows hosts,
we don't need to distribute an mt-like program (assuming lld-link
internally doesn't need to shell out to mt).
No intended behavior change.
Bug: 495204,749768
Change-Id: Ie079b82bc6217bc85942827f2c2843bb893d7186
Reviewed-on: https://chromium-review.googlesource.com/588387
Commit-Queue: Nico Weber <thakis@chromium.org>
Reviewed-by: Scott Graham <scottmg@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#490255}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 9ad0916c64be00ef8ba7f7f6a9b3c78813e17f21
This has a bunch of minor advantages:
1. It's less code
2. It's a build step less per windows_manifest
3. /manifest:embed automatically sets 1 or 2 based on /dll, so
clients of windows_manifest() clients no longer need to set type
4. rc.exe is no longer required for every single binary, which
helps bootstrapping of cross-building some chrome/win binaries
on non-win
No intended behavior change.
TBR=sergeyu,grt
Bug: 495204
Cq-Include-Trybots: master.tryserver.chromium.win:win10_chromium_x64_rel_ng
Change-Id: I13cd9103829fa535997fa7a7e5ec009dbc1b8039
Reviewed-on: https://chromium-review.googlesource.com/585109
Commit-Queue: Nico Weber <thakis@chromium.org>
Reviewed-by: Scott Graham <scottmg@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#489729}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 132e149a98b37ee78eaf86434dbe37f22fa40d4c
Running yasm on highbd_sad4d_sse2.asm takes about ~33 seconds on debug
component builds on Windows - closer to 42 seconds when the system is
under load. This is partially because compiler optimizations are
disabled in debug builds (costs ~5 seconds) and partially because we
link with the debug CRT (costs ~15 seconds). This change makes it so
that we always enable optimizations and always link with the release
CRT, thus reducing the time to run yasm on highbd_sad4d_sse2.asm from
~33 seconds to ~13 seconds.
Further improvements could be obtained by only running yasm once on the
.asm files, but such a change is left for later.
The total CPU-time savings is tiny compared to the cost of a full build,
but on some goma builds this step ends up being the long pole which
serializes the build and costs an estimated 5% of elapsed build time.
BUG=722617
Review-Url: https://codereview.chromium.org/2885213002
Cr-Original-Commit-Position: refs/heads/master@{#473066}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 9c90eb122f3327c8c03bbf2171a97cb157f89459
Adjust GN configs to only link with Control Flow Guard for executables.
This will still support CFG compiled into Microsoft system DLLs, in all
Chromium processes (e.g. chrome.exe).
This should prevent sporadic official clang build problems in DLLs, related
to CFG. Further investigation/fixes to follow.
TEST=CFGSupportTests.MsIndirectFailure in sbox_integration_tests suite.
BUG=584575,708098
Review-Url: https://codereview.chromium.org/2813823006
Cr-Original-Commit-Position: refs/heads/master@{#464475}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 723503ec2956cc8b66e53a5ee97985ec262a599d
When doing x64 builds of Chrome with VC++ we compile some modules
(currently just libyuv) with clang, in order to get inline assembly
support. This causes problems on /analyze builds because clang-cl
doesn't understand the /analyze compiler switches. This change
disables /analyze for those files that are compiled with clang.
With this change I can do a /analyze build of libyuv without
hitting any errors, but warnings are emitted as appropriate.
R=brettw@chromium.org
BUG=427616
Review-Url: https://codereview.chromium.org/2786733005
Cr-Original-Commit-Position: refs/heads/master@{#460874}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: bb4bb0ebf2bfc2881100122e1513ee3f694744a0
If anyone still needs them, please tell me about your use case
(and feel free to revert).
Ran `git ls-files -- '*.isolate' | xargs git rm`
BUG=703799
NOTRY=true
TBR=jochen,davidben
Review-Url: https://codereview.chromium.org/2766673003
Cr-Original-Commit-Position: refs/heads/master@{#458595}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: f526c497b9eae3805d18f71c1cefdf88cfaf8ab5
This enables support for CFG that is already compiled into Microsoft
system DLLs - in any of our processes.
Also disabling compilation of CFG with MSVC compiler. Preparing for
clang CFI instead.
TEST=CFGSupportTests.MsIndirectFailure in sbox_integration_tests suite.
BUG=584575
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.win:win10_chromium_x64_rel_ng
TBR=thestig or jochen (chrome\BUILD.gn)
Review-Url: https://codereview.chromium.org/2693193005
Cr-Original-Commit-Position: refs/heads/master@{#451116}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: f160102d25fb949a3ed24478268b8835cc086477
Link steps with warnings typically lead to working binaries, but warnings can indicate dependency issues in the codebase, slow down builds, and otherwise just make it harder to find more relevant output in build logs.
This CL also adds exceptions to ignore certain linker warnings under specific configurations and targets.
BUG=659007, 676418, 676417, 654776
Review-Url: https://codereview.chromium.org/2581893002
Cr-Original-Commit-Position: refs/heads/master@{#440600}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: c868aae8f9b8d51461afff79064c75339e6ce30c
Reason for revert:
V8 is on 2015 now.
Original issue's description:
> Revert of win: Remove unneeded references to visual_studio_version now that it's always 2015. (patchset #4 id:60001 of https://codereview.chromium.org/2450933002/ )
>
> Reason for revert:
> V8 relies on this.
>
> Original issue's description:
> > win: Remove unneeded references to visual_studio_version now that it's always 2015.
> >
> > BUG=
> >
> > Committed: https://crrev.com/a628db5056deb88589224bd68dcd9ec029932c83
> > Cr-Commit-Position: refs/heads/master@{#427463}
>
> TBR=scottmg@chromium.org,thakis@chromium.org
> # Not skipping CQ checks because original CL landed more than 1 days ago.
> BUG=
>
> Committed: https://crrev.com/f89b499961b139f38e8e01282a82d4ba5d21506e
> Cr-Commit-Position: refs/heads/master@{#434945}
TBR=scottmg@chromium.org,thakis@chromium.org,brucedawson@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=603131
Review-Url: https://codereview.chromium.org/2540013006
Cr-Original-Commit-Position: refs/heads/master@{#435944}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: fd2c63b1b790d0c41a41b708271e3d0264cbdbee
Chromium normally builds with /PROFILE in static release builds, which
implies "/OPT:REF /OPT:ICF /INCREMENTAL:NO /FIXED:NO". We can't use
/PROFILE with Clang, so instead pass the list of implied flags to make
Clang builds more closely match MSVC builds. We already do this for
is_win_fastlink=true builds, presumably for the same reason.
It turns out that the chrome_elf_unittests relies on /OPT:REF because it
allows the linker to remove unused user32.dll dependencies brought in by
//base. These tests only run in release+static builds, and most clang
release+static bots do official builds. Official builds already use
/OPT:REF for unrelated reasons, so we only see these test failures on
ASan bots, which don't do official builds.
BUG=646414
R=thakis@chromium.org
Review-Url: https://codereview.chromium.org/2520373003
Cr-Original-Commit-Position: refs/heads/master@{#433929}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 7bff5aca5d8144576a46b3dc0a37086c7e1a8d25
The /DEBUG:FASTLINK flag is incompatible with /PROFILE, so we turn off
/PROFILE when using /DEBUG:FASTLINK. However /PROFILE turns on various
linker optimization, which means that /DEBUG:FASTLINK results in larger
binaries, for no good reason. This was causing some confusion when
working on size optimizations. This change ensures that when /PROFILE is
turned off due to /DEBUG:FASTLINK that the same linker optimization
flags are applied.
This has no effect on non-fastlink builds, it just ensures that
is_win_fastlink does not affect binary sizes. Link times (measured for
non-component 64-bit release chrome.dll and chrome_child.dll) are about
2.7 faster with fastlink than without with this change, which is inline
with before.
This change also avoids using /debug:fastlink on minimal_symbols builds.
On such builds (because there is no debug information in the .obj files
or shared .pdb files) fastlink has no value and actually makes the final
PDBs slightly *bigger*.
BUG=495670
Review-Url: https://codereview.chromium.org/2495643002
Cr-Original-Commit-Position: refs/heads/master@{#431985}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: b05140cde29b38d482e1201b77fcf68fd310daa7
CFG supported on x86 and x64 >= Windows 8.1 Update (KB3000850).
Initial support for Control Flow Guard. "Enable" on chrome.exe to take
advantage of MS system32 dll CFG. Also compile and link chrome_elf with CFG.
NOTE: As ASLR is disabled in debug builds, so too is CFG.
Using the dumpbin tool from the Visual Studio command prompt, run "dumpbin /headers /loadconfig" against chrome.exe or chrome_elf.dll. 1) "DLL characteristics" now includes "Control Flow Guard", and 2) if code was compiled with cfg there will be "load config" for "Guard CF" function table and flags.
BUG=584575
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.win:win10_chromium_x64_rel_ng
Review-Url: https://codereview.chromium.org/2412983006
Cr-Original-Commit-Position: refs/heads/master@{#425226}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: d46842301ebc1f41a92448026bf95e3194538213
variants: "dynamic_crt" passes "/MD" and "/MDd", whereas "static_crt"
passes "/MT" and "/MTd". BUILDCONFIG then depends on "default_crt",
which has some logic to choose whether to use either dynamic_crt or
static_crt.
The main reason behind this is to allow users to config -= the
"default_crt" config: in gyp, it was possible to configure what was
going to be passed to the compiler via the
"win_{release,debug}_RuntimeLibrary" variable, which was useful when
building code that needs to pass "/CLR", as it requires "/MD" and does
not work with "/MT".
R=brettw@chromium.org,dpranke@chromium.org,scottmg@chromium.org
Review-Url: https://codereview.chromium.org/2379573003
Cr-Original-Commit-Position: refs/heads/master@{#421596}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 964b1666ed2178c3f9242ef140ed16c94df24edd
Component builds are, by definition, not optimized for maximum
performance. So incremental linking - which trades a little bit of
performance for much faster build times - is appropriate in release
component builds, as well as in debug builds.
This change enables incremental linking in release component builds.
This also requires turning off /OPT:ICF and /PROFILE in component
builds because they are incompatible with /incremental, but they are
performance related flags so they are also not important for component
builds.
blink_core.dll cannot be incrementally linked in debug x64 component
builds, but it *can* be incrementally linked in release x64 component
builds (and debug/release x86 component builds), and this change
enables incremental linking of blink_core.dll in all supported
configurations.
This drops the chrome rebuild time after touching
third_party\WebKit\Source\core\html\AutoplayExperimentHelper.cpp from
~260 seconds to 9 seconds. The chrome rebuild time after touching
base\win\registry.cc drops from ~200 seconds to less than 2 seconds,
with 21 of 24 link steps skipped entirely.
This also fixes some /INCREMENTAL /OPT:ICF mismatch warnings.
BUG=608801,621236
Review-Url: https://codereview.chromium.org/2331373006
Cr-Original-Commit-Position: refs/heads/master@{#418660}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 7bf1119ce51d5e5b489c780bbacc332eabdd6f07
Incremental linking is enabled by default on debug component builds on
Windows but has long been disabled for blink_core because it didn't
work. VS 2015 Update 3 fixes some incremental linking bugs and at some
point the .ilk file limit was raised from 2 GiB to 4 GiB so incremental
linking now works. This takes the elapsed time for these commands:
> touch third_party\WebKit\Source\core\html\AutoplayExperimentHelper.cpp
> ninja -d keeprsp -C out\Debug_component chrome
from ~400 s to ~10 s. Which is faster.
Most of the speed up is because incremental linking is faster than
full linking. The rest comes because when blink_core.dll is
incrementally linked then its import lib (blink_core.dll.lib) is not
updated which means that the subsequent 21 build steps (including
linking chrome.dll) are completely skipped.
On 64-bit builds the .ilk file is still too large and enabling
incremental linking doesn't cause build failures but doesn't help,
and probably slows down the build (due to creating the huge .ilk
file).
This change also deletes the /maxilksize flag. Currently this is
artificially restricting us to an old/obsolete limit. The .ilk file
for blink_core.dll is dangerously close to the old limit, but nowhere
near the new limit.
BUG=560475
Review-Url: https://codereview.chromium.org/2326143002
Cr-Original-Commit-Position: refs/heads/master@{#417852}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: f786d3a73671671237e8ab61d0d97d85a8db7d3c
* win: Members of base classes now should show up in debugger.
* win: Debugger shouldn't show funny highlights anymore due to
debug info no longer including column information. (we still
force this on if sanitizers are used, mostly for clusterfuzz.
maybe we want to make this toggleable independent of sanitizers
at some point)
* win: -Wextern-initializer no longer warns on midl-generated code
* win: clang-cl now accepts /source-encoding:utf-8 and friends
(utf-8 was the source enconding in clang-cl before already, but
now we don't warn on an explicit flag requesting this)
* all platforms: Three plugin checks are now on-by-default,
remove flags for these (see
https://codereview.chromium.org/2267713003https://codereview.chromium.org/2268203002https://codereview.chromium.org/2265093002
)
* win: clang-cl's /Brepro now does what it's supposed to do
* win: clang-cl now emits absolute paths in diagnostics, by
popular request.
Ran `tools/clang/scripts/upload_revision.py 280106`.
BUG=640254,637456,636109,636091,636099
Review-Url: https://codereview.chromium.org/2292173002
Cr-Original-Commit-Position: refs/heads/master@{#415563}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: a033f395bf2547cf4764f77cc9c86d08f3e22c23
Renames it tool_wrapper.py but otherwise keeps it unchanged from the original
https://chromium.googlesource.com/external/gyp.git/+/master/pylib/gyp/win_tool.py
The copy step of the old tool is currently kept pending a fix to NaCl that references it.
I changed internal references to itself to tool_wrapper.py, and split the internal strings containing the word "Copyright" (which it uses to filter tool output) to avoid triggering the copyright presubmit check.
Changes the build to refer to the file in-place rather than copying it to the build directory which was confusing.
The tool runs itself in the link_manifest step. Since the file is no longer copied to what will be the current directory when linking, I believe this will be broken. But the GN build does not use the manifest linking command. To keep changes minimal, I kept this code in for now.
Reland of http://crrev.com/2287603003 with fixes (keep the tool pending NaCl roll).
BUG=642014
R=scottmg@chromium.org
Review URL: https://codereview.chromium.org/2286413002 .
Cr-Original-Commit-Position: refs/heads/master@{#415034}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 3826c51de883b9beedc92de5c17e9946a92dfe6d
Robin Raymond
Takuto Ikuta
inglorion
Oleh Prypin
Reid Kleckner
Sigurdur Asgeirsson
Hans Wennborg
Nico Weber
Dave Tapuska
Bruce Dawson
Peter Collingbourne
James Forshaw
Jamie Madill
Julien Brianceau
pennymac
scottmg
wez
machenbach
rnk
raphael.kubo.da.costa
Brett Wilson