Adding a SegmentHeap entry to the chrome.exe manifest will tell
recent-enough versions of Windows (20-04 and beyond) to opt chrome.exe
into using the segment heap instead of the legacy heap. Details are in
the bug but it appears that the default Windows heap is tuned for server
workloads where throughput is what matters most, and Chromium
(especially due to its multi-process architecture) also has to care
about memory footprint. Experiments with per-machine opting-in to the
segment heap for chrome.exe suggests that this could save hundreds of MB
in the browser and Network Service utility processes, among others, on
some machines. Actual results will vary widely, with the greatest
savings coming on many-core machines.
In order to avoid build warnings this change depends on switching to
building with the Windows 10.0.19041.0 (20-04) SDK.
The initial investigation of this is in crbug.com/982452.
Bug: 1014701
Change-Id: I217d045ee0d365ac57f7a73b0f5ed456469214c6
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2163163
Commit-Queue: Bruce Dawson <brucedawson@chromium.org>
Reviewed-by: Ken Rockot <rockot@google.com>
Cr-Commit-Position: refs/heads/master@{#782134}
GitOrigin-RevId: 1a9f684dad2f2620c5b88b3cea41c87143cd3c28
This reverts commit ed0697fcf0f958c1bc6643d911d99b1d9b52ed9b.
Reason for revert: crrev.com/c/2255126 fixes the midl.py failures
on Windows 7 class OSes and crrev.com/c/2260933 rolls in a native_client
change that stops preprocessing .S files with cl.exe. With those
changes cl.exe is not used in the build on Windows 7 anymore and that
should let this toolchain land.
This change now locks the SDK version to 10.0.19041.0 for users who
don't use a packaged toolchain which ensures consistency and should
simplify future toolchain upgrades. This change was tested with the
lock as shown and with a lock to a previous SDK version.
Original change's description:
> Revert "Reland "New toolchain for Windows 10 19041 SDK""
>
> This reverts commit 424526a023397ebbe6555ea27b82f66c137e8022.
>
> Reason for revert: win64-chrome build succeeded (progress) but
> win32-chrome builder failed with a previously unseen error, shown
> here:
>
> [170/58214] ACTION //remoting/host/win:remoting_lib_idl_idl_action(//build/toolchain/win:win_clang_x86)
> FAILED: gen/remoting/host/win/chromoting_lib.h gen/remoting/host/win/chromoting_lib.dlldata.c gen/remoting/host/win/chromoting_lib_i.c gen/remoting/host/win/chromoting_lib_p.c gen/remoting/host/win/chromoting_lib.tlb
> c:\b\s\w\ir\cipd_bin_packages\cpython\bin\python.exe ../../build/toolchain/win/midl.py environment.x86 c:/b/s/w/ir/cache/builder/src/third_party/win_build_output/midl/remoting/host/win gen/remoting/host/win 7219b935-4873-533b-9ce1-20c9e9b12def chromoting_lib.tlb chromoting_lib.h chromoting_lib.dlldata.c chromoting_lib_i.c chromoting_lib_p.c gen/remoting/host/win/chromoting_lib.idl /char signed /env win32 /Oicf
> cl : Command line error D8027 : cannot execute 'c:\b\s\w\ir\cache\builder\src\third_party\depot_tools\win_toolchain\vs_files\a687d8e2e4114d9015eb550e1b156af21381faac\win_sdk\bin\..\..\VC\Tools\MSVC\14.26.28801\bin\HostX64\x86\c1.dll'
> midl : command line error MIDL1003 : error returned by the C preprocessor (2)
>
> Original change's description:
> > Reland "New toolchain for Windows 10 19041 SDK"
> >
> > This is a reland of 4a4f53a7f22f9058b2f171fc46bc5657bbe83e45
> >
> > The original patch would fail to build on the mksnapshot step on
> > Windows 7 (and server equivalents). This was due to two APISet DLLs
> > that are required for the new dbghelp.dll. This change copies the two
> > of them during gn gen. In order to have them as part of the isolates
> > for cdb and in order to avoid dangerous ambiguity they are now
> > required, which means that when this change lands the new SDK will be
> > required. This is slightly disruptive for developers who aren't using
> > our toolchain, but it seems unavoidable.
> >
> > Developers who don't have the latest SDK installed will hit this error
> > message during gn gen:
> >
> > Exception: api-ms-win-downlevel-kernel32-l2-1-0.dll not found in "..."
> > You must install the "Debugging Tools for Windows" feature from the
> > Windows 10 SDK, the 10.0.19041.0 version.
> >
> > Original change's description:
> > > New toolchain for Windows 10 19041 SDK
> > >
> > > This change updates the toolchain package used to build Chromium with
> > > the 10.0.19041.0 (2020-04) SDK and VS 16.6.1. The d3dcompiler_47.dll
> > > DLLs for x86 and x64 were swapped out for the 10.0.17134 versions (as
> > > usual).
> > >
> > > The Debuggers directory was not swapped out this time because the
> > > problem with loading dbghelp.dll on Windows 7
> > > (https://crbug.com/1021650) has been resolved.
> > >
> > > The output for the cdb copy step was updated because one additional UCRT
> > > DLL is now copied.
> > >
> > > Packaging was done on a Windows Server 2019 VM, cleanly created for this
> > > purpose.
> > >
> > > The package was created by downloading the VS Professional 2019
> > > installer from https://visualstudio.microsoft.com/downloads/
> > > (free trial, not preview) and then running the installer like this:
> > >
> > > $ PATH_TO_INSTALLER.EXE ^
> > > --add Microsoft.VisualStudio.Workload.NativeDesktop ^
> > > --add Microsoft.VisualStudio.Component.VC.ATLMFC ^
> > > --add Microsoft.VisualStudio.Component.VC.Tools.ARM64 ^
> > > --add Microsoft.VisualStudio.Component.VC.MFC.ARM64 ^
> > > --includeRecommended --passive
> > >
> > > Then the latest Windows 10 SDK was downloaded and installed from
> > > https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk/
> > >
> > > Then the packaging script was run like this:
> > >
> > > python3 depot_tools\win_toolchain\package_from_installed.py 2019 -w 10.0.19041.0
> > >
> > > Since the new d3dcompiler_47.dll uses the UCRT and we want to avoid
> > > shipping that (https://crbug.com/920704) the final packaging step was to
> > > unzip the package, copy over the two copies of that DLL from the
> > > previous toolchain's win_sdk\Redist, and then repackage the toolchain
> > > with:
> > > > python3 package_from_installed.py --repackage=<full-path-to-toolchain-dir>
> > >
> > > UWP and ARM64 support and Python 3 compatibility were previously added
> > > to package_from_installed.py.
> > >
> > > Future changes will require the new SDK, but for now the previous SDK
> > > can also be used to build Chromium.
> > >
> > > The failures on the win*msvc* bots are unrelated. This was proven by
> > > creating crrev.com/c/2245914 which is a NOP toolchain test. The existing
> > > toolchain was repackaged with a single text file added and that caused
> > > identical failures.
> > >
> > > Bug: 920704, 1014701, 1021650, 1089996
> > > Change-Id: Ie496354582458aa8c1292ed4ef63d949ee2eb15d
> > > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2225224
> > > Commit-Queue: Bruce Dawson <brucedawson@chromium.org>
> > > Reviewed-by: Henrik Andreasson <henrika@chromium.org>
> > > Reviewed-by: Jamie Madill <jmadill@chromium.org>
> > > Reviewed-by: Nico Weber <thakis@chromium.org>
> > > Cr-Commit-Position: refs/heads/master@{#778924}
> >
> > Bug: 920704, 1014701, 1021650, 1089996, 1095767
> > Change-Id: I75e7653d57964e2929106e41b3f50594d3969e5f
> > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2249394
> > Reviewed-by: Daniel Cheng <dcheng@chromium.org>
> > Reviewed-by: Jesse McKenna <jessemckenna@google.com>
> > Reviewed-by: Jamie Madill <jmadill@chromium.org>
> > Commit-Queue: Bruce Dawson <brucedawson@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#780431}
>
> TBR=dcheng@chromium.org,henrika@webrtc.org,thakis@chromium.org,brucedawson@chromium.org,henrika@chromium.org,jessemckenna@google.com,jmadill@chromium.org
>
> Change-Id: If00e3865e66d9071189b2aca28f7541ecbdc6486
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Bug: 920704, 1014701, 1021650, 1089996, 1095767
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2255558
> Reviewed-by: Bruce Dawson <brucedawson@chromium.org>
> Reviewed-by: Daniel Cheng <dcheng@chromium.org>
> Commit-Queue: Bruce Dawson <brucedawson@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#780467}
TBR=dcheng@chromium.org,henrika@webrtc.org,thakis@chromium.org,brucedawson@chromium.org,henrika@chromium.org,jessemckenna@google.com,jmadill@chromium.org
Bug: 920704, 1014701, 1021650, 1089996, 1095767
Change-Id: I68e4c246ee903ba48d59b3bdea913ea3975c49d6
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2255527
Reviewed-by: Nico Weber <thakis@chromium.org>
Reviewed-by: Bruce Dawson <brucedawson@chromium.org>
Reviewed-by: Henrik Andreasson <henrika@chromium.org>
Commit-Queue: Bruce Dawson <brucedawson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#781663}
GitOrigin-RevId: a90d6d8f4ed7c9302f9329d205d0dc585997ab8f
This reverts commit 424526a023397ebbe6555ea27b82f66c137e8022.
Reason for revert: win64-chrome build succeeded (progress) but
win32-chrome builder failed with a previously unseen error, shown
here:
[170/58214] ACTION //remoting/host/win:remoting_lib_idl_idl_action(//build/toolchain/win:win_clang_x86)
FAILED: gen/remoting/host/win/chromoting_lib.h gen/remoting/host/win/chromoting_lib.dlldata.c gen/remoting/host/win/chromoting_lib_i.c gen/remoting/host/win/chromoting_lib_p.c gen/remoting/host/win/chromoting_lib.tlb
c:\b\s\w\ir\cipd_bin_packages\cpython\bin\python.exe ../../build/toolchain/win/midl.py environment.x86 c:/b/s/w/ir/cache/builder/src/third_party/win_build_output/midl/remoting/host/win gen/remoting/host/win 7219b935-4873-533b-9ce1-20c9e9b12def chromoting_lib.tlb chromoting_lib.h chromoting_lib.dlldata.c chromoting_lib_i.c chromoting_lib_p.c gen/remoting/host/win/chromoting_lib.idl /char signed /env win32 /Oicf
cl : Command line error D8027 : cannot execute 'c:\b\s\w\ir\cache\builder\src\third_party\depot_tools\win_toolchain\vs_files\a687d8e2e4114d9015eb550e1b156af21381faac\win_sdk\bin\..\..\VC\Tools\MSVC\14.26.28801\bin\HostX64\x86\c1.dll'
midl : command line error MIDL1003 : error returned by the C preprocessor (2)
Original change's description:
> Reland "New toolchain for Windows 10 19041 SDK"
>
> This is a reland of 4a4f53a7f22f9058b2f171fc46bc5657bbe83e45
>
> The original patch would fail to build on the mksnapshot step on
> Windows 7 (and server equivalents). This was due to two APISet DLLs
> that are required for the new dbghelp.dll. This change copies the two
> of them during gn gen. In order to have them as part of the isolates
> for cdb and in order to avoid dangerous ambiguity they are now
> required, which means that when this change lands the new SDK will be
> required. This is slightly disruptive for developers who aren't using
> our toolchain, but it seems unavoidable.
>
> Developers who don't have the latest SDK installed will hit this error
> message during gn gen:
>
> Exception: api-ms-win-downlevel-kernel32-l2-1-0.dll not found in "..."
> You must install the "Debugging Tools for Windows" feature from the
> Windows 10 SDK, the 10.0.19041.0 version.
>
> Original change's description:
> > New toolchain for Windows 10 19041 SDK
> >
> > This change updates the toolchain package used to build Chromium with
> > the 10.0.19041.0 (2020-04) SDK and VS 16.6.1. The d3dcompiler_47.dll
> > DLLs for x86 and x64 were swapped out for the 10.0.17134 versions (as
> > usual).
> >
> > The Debuggers directory was not swapped out this time because the
> > problem with loading dbghelp.dll on Windows 7
> > (https://crbug.com/1021650) has been resolved.
> >
> > The output for the cdb copy step was updated because one additional UCRT
> > DLL is now copied.
> >
> > Packaging was done on a Windows Server 2019 VM, cleanly created for this
> > purpose.
> >
> > The package was created by downloading the VS Professional 2019
> > installer from https://visualstudio.microsoft.com/downloads/
> > (free trial, not preview) and then running the installer like this:
> >
> > $ PATH_TO_INSTALLER.EXE ^
> > --add Microsoft.VisualStudio.Workload.NativeDesktop ^
> > --add Microsoft.VisualStudio.Component.VC.ATLMFC ^
> > --add Microsoft.VisualStudio.Component.VC.Tools.ARM64 ^
> > --add Microsoft.VisualStudio.Component.VC.MFC.ARM64 ^
> > --includeRecommended --passive
> >
> > Then the latest Windows 10 SDK was downloaded and installed from
> > https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk/
> >
> > Then the packaging script was run like this:
> >
> > python3 depot_tools\win_toolchain\package_from_installed.py 2019 -w 10.0.19041.0
> >
> > Since the new d3dcompiler_47.dll uses the UCRT and we want to avoid
> > shipping that (https://crbug.com/920704) the final packaging step was to
> > unzip the package, copy over the two copies of that DLL from the
> > previous toolchain's win_sdk\Redist, and then repackage the toolchain
> > with:
> > > python3 package_from_installed.py --repackage=<full-path-to-toolchain-dir>
> >
> > UWP and ARM64 support and Python 3 compatibility were previously added
> > to package_from_installed.py.
> >
> > Future changes will require the new SDK, but for now the previous SDK
> > can also be used to build Chromium.
> >
> > The failures on the win*msvc* bots are unrelated. This was proven by
> > creating crrev.com/c/2245914 which is a NOP toolchain test. The existing
> > toolchain was repackaged with a single text file added and that caused
> > identical failures.
> >
> > Bug: 920704, 1014701, 1021650, 1089996
> > Change-Id: Ie496354582458aa8c1292ed4ef63d949ee2eb15d
> > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2225224
> > Commit-Queue: Bruce Dawson <brucedawson@chromium.org>
> > Reviewed-by: Henrik Andreasson <henrika@chromium.org>
> > Reviewed-by: Jamie Madill <jmadill@chromium.org>
> > Reviewed-by: Nico Weber <thakis@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#778924}
>
> Bug: 920704, 1014701, 1021650, 1089996, 1095767
> Change-Id: I75e7653d57964e2929106e41b3f50594d3969e5f
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2249394
> Reviewed-by: Daniel Cheng <dcheng@chromium.org>
> Reviewed-by: Jesse McKenna <jessemckenna@google.com>
> Reviewed-by: Jamie Madill <jmadill@chromium.org>
> Commit-Queue: Bruce Dawson <brucedawson@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#780431}
TBR=dcheng@chromium.org,henrika@webrtc.org,thakis@chromium.org,brucedawson@chromium.org,henrika@chromium.org,jessemckenna@google.com,jmadill@chromium.org
Change-Id: If00e3865e66d9071189b2aca28f7541ecbdc6486
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: 920704, 1014701, 1021650, 1089996, 1095767
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2255558
Reviewed-by: Bruce Dawson <brucedawson@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Commit-Queue: Bruce Dawson <brucedawson@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#780467}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: ed0697fcf0f958c1bc6643d911d99b1d9b52ed9b
This is a reland of 4a4f53a7f22f9058b2f171fc46bc5657bbe83e45
The original patch would fail to build on the mksnapshot step on
Windows 7 (and server equivalents). This was due to two APISet DLLs
that are required for the new dbghelp.dll. This change copies the two
of them during gn gen. In order to have them as part of the isolates
for cdb and in order to avoid dangerous ambiguity they are now
required, which means that when this change lands the new SDK will be
required. This is slightly disruptive for developers who aren't using
our toolchain, but it seems unavoidable.
Developers who don't have the latest SDK installed will hit this error
message during gn gen:
Exception: api-ms-win-downlevel-kernel32-l2-1-0.dll not found in "..."
You must install the "Debugging Tools for Windows" feature from the
Windows 10 SDK, the 10.0.19041.0 version.
Original change's description:
> New toolchain for Windows 10 19041 SDK
>
> This change updates the toolchain package used to build Chromium with
> the 10.0.19041.0 (2020-04) SDK and VS 16.6.1. The d3dcompiler_47.dll
> DLLs for x86 and x64 were swapped out for the 10.0.17134 versions (as
> usual).
>
> The Debuggers directory was not swapped out this time because the
> problem with loading dbghelp.dll on Windows 7
> (https://crbug.com/1021650) has been resolved.
>
> The output for the cdb copy step was updated because one additional UCRT
> DLL is now copied.
>
> Packaging was done on a Windows Server 2019 VM, cleanly created for this
> purpose.
>
> The package was created by downloading the VS Professional 2019
> installer from https://visualstudio.microsoft.com/downloads/
> (free trial, not preview) and then running the installer like this:
>
> $ PATH_TO_INSTALLER.EXE ^
> --add Microsoft.VisualStudio.Workload.NativeDesktop ^
> --add Microsoft.VisualStudio.Component.VC.ATLMFC ^
> --add Microsoft.VisualStudio.Component.VC.Tools.ARM64 ^
> --add Microsoft.VisualStudio.Component.VC.MFC.ARM64 ^
> --includeRecommended --passive
>
> Then the latest Windows 10 SDK was downloaded and installed from
> https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk/
>
> Then the packaging script was run like this:
>
> python3 depot_tools\win_toolchain\package_from_installed.py 2019 -w 10.0.19041.0
>
> Since the new d3dcompiler_47.dll uses the UCRT and we want to avoid
> shipping that (https://crbug.com/920704) the final packaging step was to
> unzip the package, copy over the two copies of that DLL from the
> previous toolchain's win_sdk\Redist, and then repackage the toolchain
> with:
> > python3 package_from_installed.py --repackage=<full-path-to-toolchain-dir>
>
> UWP and ARM64 support and Python 3 compatibility were previously added
> to package_from_installed.py.
>
> Future changes will require the new SDK, but for now the previous SDK
> can also be used to build Chromium.
>
> The failures on the win*msvc* bots are unrelated. This was proven by
> creating crrev.com/c/2245914 which is a NOP toolchain test. The existing
> toolchain was repackaged with a single text file added and that caused
> identical failures.
>
> Bug: 920704, 1014701, 1021650, 1089996
> Change-Id: Ie496354582458aa8c1292ed4ef63d949ee2eb15d
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2225224
> Commit-Queue: Bruce Dawson <brucedawson@chromium.org>
> Reviewed-by: Henrik Andreasson <henrika@chromium.org>
> Reviewed-by: Jamie Madill <jmadill@chromium.org>
> Reviewed-by: Nico Weber <thakis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#778924}
Bug: 920704, 1014701, 1021650, 1089996, 1095767
Change-Id: I75e7653d57964e2929106e41b3f50594d3969e5f
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2249394
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Jesse McKenna <jessemckenna@google.com>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Bruce Dawson <brucedawson@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#780431}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 424526a023397ebbe6555ea27b82f66c137e8022
This change updates the toolchain package used to build Chromium with
the 10.0.19041.0 (2020-04) SDK and VS 16.6.1. The d3dcompiler_47.dll
DLLs for x86 and x64 were swapped out for the 10.0.17134 versions (as
usual).
The Debuggers directory was not swapped out this time because the
problem with loading dbghelp.dll on Windows 7
(https://crbug.com/1021650) has been resolved.
The output for the cdb copy step was updated because one additional UCRT
DLL is now copied.
Packaging was done on a Windows Server 2019 VM, cleanly created for this
purpose.
The package was created by downloading the VS Professional 2019
installer from https://visualstudio.microsoft.com/downloads/
(free trial, not preview) and then running the installer like this:
$ PATH_TO_INSTALLER.EXE ^
--add Microsoft.VisualStudio.Workload.NativeDesktop ^
--add Microsoft.VisualStudio.Component.VC.ATLMFC ^
--add Microsoft.VisualStudio.Component.VC.Tools.ARM64 ^
--add Microsoft.VisualStudio.Component.VC.MFC.ARM64 ^
--includeRecommended --passive
Then the latest Windows 10 SDK was downloaded and installed from
https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk/
Then the packaging script was run like this:
python3 depot_tools\win_toolchain\package_from_installed.py 2019 -w 10.0.19041.0
Since the new d3dcompiler_47.dll uses the UCRT and we want to avoid
shipping that (https://crbug.com/920704) the final packaging step was to
unzip the package, copy over the two copies of that DLL from the
previous toolchain's win_sdk\Redist, and then repackage the toolchain
with:
> python3 package_from_installed.py --repackage=<full-path-to-toolchain-dir>
UWP and ARM64 support and Python 3 compatibility were previously added
to package_from_installed.py.
Future changes will require the new SDK, but for now the previous SDK
can also be used to build Chromium.
The failures on the win*msvc* bots are unrelated. This was proven by
creating crrev.com/c/2245914 which is a NOP toolchain test. The existing
toolchain was repackaged with a single text file added and that caused
identical failures.
Bug: 920704, 1014701, 1021650, 1089996
Change-Id: Ie496354582458aa8c1292ed4ef63d949ee2eb15d
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2225224
Commit-Queue: Bruce Dawson <brucedawson@chromium.org>
Reviewed-by: Henrik Andreasson <henrika@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Nico Weber <thakis@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#778924}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 4a4f53a7f22f9058b2f171fc46bc5657bbe83e45
In x64 builds there is an extra C runtime DLL called vcruntime140_1.dll
(and it's debug equivalent). This tiny DLL seems to be responsible for
some exception handling work. This DLL has existed for a while but with
the recent attempt to switch to a new toolchain it started being
required - its absence was causing 0xC0000135 failures when running
angle_deqp_egl_tests.exe in a release component build.
This change adds it to the list of CRT DLLs to copy, for x64 builds
only.
Bug: 1089996
Change-Id: I8c1a64864634f40007e5efeaff375bc88d86aefd
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2238348
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Bruce Dawson <brucedawson@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#776707}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 808ee241dccb66e79264d3b41354ebd5a92215d6
They were apparently used by some old code coverage system long ago.
https://chromium-review.googlesource.com/c/chromium/src/+/764949/
removed tools/code_coverage/croc.py well over 2 years ago, so we
probably don't need these files either.
Bug: 784464
Change-Id: I2cb1c7ee973c26b673a225659967516f5bf922d7
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2036804
Commit-Queue: Lei Zhang <thestig@chromium.org>
Reviewed-by: Lei Zhang <thestig@chromium.org>
Auto-Submit: Nico Weber <thakis@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#742809}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: cb3953490314bd66e12023f6bdef8610685b467a
`gn format` recently changed its formatting behavior
for deps, source, and a few other elements when they
are assigned (with =) single-element lists to be consistent
with the formatting of updates (with +=) with single-element.
Now that we've rolled in a GN binary with the change,
reformat all files so that people don't get presubmit
warnings due to this.
This CL was uploaded by git cl split.
R=tikuta@chromium.org
Bug: 1041419
Change-Id: I15bd43c6df0ba87f879e5226e4dbb1af7ba73f03
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1998745
Auto-Submit: Nico Weber <thakis@chromium.org>
Reviewed-by: Takuto Ikuta <tikuta@chromium.org>
Commit-Queue: Takuto Ikuta <tikuta@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#731078}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 4782d7368c37ae35cf0c44456ba8307079a4d24e
The Windows 10 19013 Preview SDK has an extra UCRT file in the debuggers
directory and this file (api-ms-win-downlevel-kernel32-l2-1-0.dll) is
needed when running cdb.exe on Windows 7.
This change allows the copy_cdb_to_output action to run with 18632 and
later SDKs. Once we require a later SDK we should add the new file to
the list of outputs for this action but this will smooth the otherwise
bumpy transition.
Bug: 1021650
Change-Id: I2304aea73dfcd25258697c37d05b05dc6adff55e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1904873
Reviewed-by: Thomas Anderson <thomasanderson@chromium.org>
Commit-Queue: Bruce Dawson <brucedawson@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#713912}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: ff51aa28b262422402784c62eb2787b03b012f36
From what I can tell, it's not intentional that we keyed this off
using_sanitizer instead of is_asan.
As far as I know, the only sanitizer we currently use on mac and ios is
asan, so this should be a no-op there.
On Windows, we also have experimental CFI bots, and this might help
the 32-bit CFI bots that now no longer build the asan runtime.
(But presumably CFI needs some other runtime that we also no longer
build -- but it'll hopefully move the error a bit further back,
and copying the asan runtimes is needless work.)
TBR=pcc
Bug: 968434
Change-Id: I56528f2e82852d8c3145d657db77833321a6602c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1637032
Reviewed-by: Nico Weber <thakis@chromium.org>
Commit-Queue: Nico Weber <thakis@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#664745}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: b0ef5b0ca4d46a34d8d7568fbb07c53f2f5564c2
These changes allow more of Chromium to be built using Python 3.
The scripts still work with Python 2.
There are no intended behaviour changes.
Bug: 941669
Change-Id: I6897d00ce00ec6aa5d7ca216b9f302e725a21897
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1527522
Reviewed-by: Dirk Pranke <dpranke@chromium.org>
Commit-Queue: Raul Tambre <raul@tambre.ee>
Cr-Original-Commit-Position: refs/heads/master@{#642401}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 79fbf3cf437660defd0eee56685c7a785812591d
The changes are to allow build files to be generated using Python 3 on Windows.
The scripts still work with Python 2.
There are no intended behaviour changes.
Bug: 941669
Change-Id: I52c912c624660c7a46c05f8f36871744abd7b8d4
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1521487
Reviewed-by: Dirk Pranke <dpranke@chromium.org>
Commit-Queue: Raul Tambre <raul@tambre.ee>
Cr-Original-Commit-Position: refs/heads/master@{#641870}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 4197d3af6e42aa72076d6051153a644f3df62dd5
This reverts commit d17a7e3cc86ff480e081854b0c9a358ddf3112ac.
Reason for revert: Increase in heap corruption (and other?) crashes
in the d3dcompiler code path, such as crbug.com/932359. We have run
out of time to investigate before branching.
Original change's description:
> Switch to full 17763 SDK, including new d3dcompiler_47.dll
>
> The new (10.0.17763.0) version of d3dcompiler_47.dll contains various
> bug fixes which we want to ship. We initially avoided upgrading it with
> the rest of the SDK because it depends on the universal Windows 10 CRT
> (UCRT) which some Windows 7 machines lack. This caused test failures on
> some bots and would cause failures on some customer machines.
>
> This change updates how we package isolates so that they always include
> the UCRT, to avoid test failures. It also ships api-ms-win-*.dll and
> ucrtbase*.dll in mini_installer.exe so that the UCRT will be shipped to
> customers. The size increase to mini_installer.exe for this is about
> 400,000 bytes.
>
> This change also deletes an unused function (_read_configuration_from_gn)
> from create_installer_archive.py that sent me down an incorrect path
> while investigating fixes.
>
> The toolchain package is the same as the one used when landing
> crrev.com/c/1401403 except that the 17763 version of d3dcompiler_47.dll
> was retained. See that CL for full instructions on creating the
> toolchain package.
>
> Bug: 920704
> Change-Id: I9cb7a7ed5cb75d04962fc64869d26b12617c0463
> Reviewed-on: https://chromium-review.googlesource.com/c/1450414
> Reviewed-by: Greg Thompson <grt@chromium.org>
> Commit-Queue: Bruce Dawson <brucedawson@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#629193}
TBR=brucedawson@chromium.org,grt@chromium.org
Bug: 920704
Change-Id: Ia986017541e5e80a3cc5f1d96494e0e12a841ed1
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1507040
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Bruce Dawson <brucedawson@chromium.org>
Commit-Queue: Bruce Dawson <brucedawson@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#638596}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 666e6630b5d3c15313ce5ff385eac85459c65623
On ARM64 Win32 builds the UCRT is not a redistributable and therefore
must be omitted from the list of outputs. Otherwise the
copy_cdb_to_output will never be clean.
This was tested before and after with this pair of commands:
ninja.exe -C out\arm64 copy_cdb_to_output
ninja.exe -d explain -C out\arm64 copy_cdb_to_output
Before the build step was always dirty. After it is always clean.
Bug: 937083
Change-Id: Ica53b1b172441925dcbb27f6033774d49b1df9af
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1497491
Auto-Submit: Bruce Dawson <brucedawson@chromium.org>
Commit-Queue: Justin DeWitt <dewittj@chromium.org>
Reviewed-by: Justin DeWitt <dewittj@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#637404}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: dd3e44cc62a0cb83a470f71749ac0f05f3c24838
In crrev.com/c/1450414 the logic for when the UCRT files were shipped
was updated to ensure that the files were shipped for all non-ARM64
builds, to support the latest d3dcompiler_47.dll. Except the Boolean
logic was backwards so we were trying to ship them on ARM64, which is
wrong. This means that component builds of the ARM64 mini_installer
fail because they try to copy the api-ms-win*.dll redist files and
those don't exist for ARM64.
That fixes the logic, including separating out the logic for the UCRT
and the rest of the CRT.
This was tested on ARM64 by building isolates for all four permutations
of is_debug and is_component_build and confirming that they all worked.
This may need updating if we change how we ship d3dcompiler_47.dll but
this is correct for now.
Bug: 931856, 920704
Change-Id: I45c418403e03d3ba19348ed98f273ee9c80a5003
Reviewed-on: https://chromium-review.googlesource.com/c/1476316
Reviewed-by: David Bienvenu <davidbienvenu@chromium.org>
Commit-Queue: Bruce Dawson <brucedawson@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#637003}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: e782c345fb9cfc5558a85fe3fe0ffe482d79a7b8
This reverts commit 6ddbac7f8b44ca9f4ef8adaf21229df9dec380a2.
Reason for revert: causing most ANGLE Windows tests to fail with:
[ RUN ] D3DTextureTest.GlColorspaceNotAllowedForTypedD3DTexture/ES2_D3D9
../../third_party/angle/src/tests/test_utils/ANGLETest.cpp(57): error: Failed
ensureInitialized(138): LoadLibrary(d3dcompiler_47.dll) failed. GetLastError=126
e.g. https://ci.chromium.org/p/chromium/builders/luci.chromium.try/win-angle-rel/872
Original change's description:
> Toolchain with d3dcompiler_old.dll included
>
> This switches Chromium for Windows to use a new toolchain package that
> is the same as the one landed in crrev.com/c/1450414 except that it
> includes both the new d3dcompiler_47.dll (from the 17763 SDK) and the
> old one (from the 17134 SDK). The two versions are so that most
> customers get the new version, with all of its bug fixes, while those
> who don't have proper UCRT installs will fall back to the old version.
> If there are enough of the latter then we can figure out a way to ship
> the UCRT beside chrome.exe so that they can get the fixes as well. If
> there are few enough of the latter then we can drop support for them.
>
> This change also removes the UCRT from installs, reverting a portion of
> crrev.com/c/1450414, and adds d3dcompiler_old.dll to installs.
>
> This toolchain package was created by copying d3dcompiler_47.dll from
> the win_sdk\Redist\D3D\{x64|x86} directories of the 17134 SDK to
> d3dcompiler_old.dll and repackaging the directory using the --repackage
> option of depot_tools\win_toolchain\package_from_installed.py.
>
> Note that the logic in build\win\BUILD.gn for when to package up the
> UCRT was incorrect (it would try to package it for ARM64 component
> builds) and that is corrected as well in this change.
>
> Angle can then use d3dcompiler_old.dll as a fallback, and record
> metrics about how often the fallback is used.
>
> Bug: 920704
> Change-Id: Ida96d8b9247789a429519c50b0663f183d72c800
> Reviewed-on: https://chromium-review.googlesource.com/c/1461679
> Commit-Queue: Bruce Dawson <brucedawson@chromium.org>
> Reviewed-by: Jamie Madill <jmadill@google.com>
> Reviewed-by: Greg Thompson <grt@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#634207}
TBR=jmadill@google.com,brucedawson@chromium.org,grt@chromium.org
Change-Id: I0fbd1f963fdd4c3180715ff9eec38b7bb2c2bf4e
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: 920704
Reviewed-on: https://chromium-review.googlesource.com/c/1481670
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#634255}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 6f84ed3b4c8c26dc30642a91bb195943d1632cf3
This switches Chromium for Windows to use a new toolchain package that
is the same as the one landed in crrev.com/c/1450414 except that it
includes both the new d3dcompiler_47.dll (from the 17763 SDK) and the
old one (from the 17134 SDK). The two versions are so that most
customers get the new version, with all of its bug fixes, while those
who don't have proper UCRT installs will fall back to the old version.
If there are enough of the latter then we can figure out a way to ship
the UCRT beside chrome.exe so that they can get the fixes as well. If
there are few enough of the latter then we can drop support for them.
This change also removes the UCRT from installs, reverting a portion of
crrev.com/c/1450414, and adds d3dcompiler_old.dll to installs.
This toolchain package was created by copying d3dcompiler_47.dll from
the win_sdk\Redist\D3D\{x64|x86} directories of the 17134 SDK to
d3dcompiler_old.dll and repackaging the directory using the --repackage
option of depot_tools\win_toolchain\package_from_installed.py.
Note that the logic in build\win\BUILD.gn for when to package up the
UCRT was incorrect (it would try to package it for ARM64 component
builds) and that is corrected as well in this change.
Angle can then use d3dcompiler_old.dll as a fallback, and record
metrics about how often the fallback is used.
Bug: 920704
Change-Id: Ida96d8b9247789a429519c50b0663f183d72c800
Reviewed-on: https://chromium-review.googlesource.com/c/1461679
Commit-Queue: Bruce Dawson <brucedawson@chromium.org>
Reviewed-by: Jamie Madill <jmadill@google.com>
Reviewed-by: Greg Thompson <grt@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#634207}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 6ddbac7f8b44ca9f4ef8adaf21229df9dec380a2
The 17763 version of d3dcompiler_47.dll requires ucrtbase.dll. Change
crrev.com/c/1450414 switched to this new version of d3dcompiler_47.dll
and adjusted the DLLs we ship in isolates but in the debug case it
only shipped ucrtbased.dll, not ucrtbase.dll. This fixes that.
Local testing shows that angle_end2end_tests.isolate now always contains
ucrtbase.dll.
Bug: 929295, 920704
Change-Id: I3bb64dde923407e94404073b8f8f9bfd57692eac
Reviewed-on: https://chromium-review.googlesource.com/c/1457018
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Commit-Queue: Bruce Dawson <brucedawson@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#629780}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: edd50d7b272da6b84fde414ad95802f119770510
The new (10.0.17763.0) version of d3dcompiler_47.dll contains various
bug fixes which we want to ship. We initially avoided upgrading it with
the rest of the SDK because it depends on the universal Windows 10 CRT
(UCRT) which some Windows 7 machines lack. This caused test failures on
some bots and would cause failures on some customer machines.
This change updates how we package isolates so that they always include
the UCRT, to avoid test failures. It also ships api-ms-win-*.dll and
ucrtbase*.dll in mini_installer.exe so that the UCRT will be shipped to
customers. The size increase to mini_installer.exe for this is about
400,000 bytes.
This change also deletes an unused function (_read_configuration_from_gn)
from create_installer_archive.py that sent me down an incorrect path
while investigating fixes.
The toolchain package is the same as the one used when landing
crrev.com/c/1401403 except that the 17763 version of d3dcompiler_47.dll
was retained. See that CL for full instructions on creating the
toolchain package.
Bug: 920704
Change-Id: I9cb7a7ed5cb75d04962fc64869d26b12617c0463
Reviewed-on: https://chromium-review.googlesource.com/c/1450414
Reviewed-by: Greg Thompson <grt@chromium.org>
Commit-Queue: Bruce Dawson <brucedawson@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#629193}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: d17a7e3cc86ff480e081854b0c9a358ddf3112ac
This change adds ARM64 support to the CDB.exe copy script. Also, since
ARM64 Windows is by definition Windows 10 1709+, the eventing-provider
and ucrtbase DLLs are shipped with the OS and do not need to be copied.
Bug: 893460
Change-Id: Ia278c4636bc1303c24f174df88f6232a2e403c82
Reviewed-on: https://chromium-review.googlesource.com/c/1399289
Reviewed-by: Bruce Dawson <brucedawson@chromium.org>
Commit-Queue: Bruce Dawson <brucedawson@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#620533}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: aa675251d9e1778e19ac77c5bef290c2e78c04b0
Recent Windows 10 SDKs store the UCRT redist files in a different
directory so a change was landed to scan for the right directory to
handle old and new. However the glob call used a backslash and therefore
fails on Linux. This fixes that by using os.path.join.
Bug: 915036
Change-Id: I7f71b0e9300ac33964a05881525a5eba52203859
Reviewed-on: https://chromium-review.googlesource.com/c/1377503
Commit-Queue: Bruce Dawson <brucedawson@chromium.org>
Reviewed-by: Dirk Pranke <dpranke@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#617227}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 0778ef57fb5d7b77897bb321e0fe1451ae742d62
Recent versions of the 10.0.17763 SDK have rearranged the redist
directory where we find the UCRT DLLs. This change updates the
copy_cdb_to_output.py script so that it looks in the new (versioned)
directory first, and falls back to the old unversioned directory if that
doesn't work.
Without this change we still soon start seeing build failures when
using the locally installed toolchain on clean installs.
See also http://crrev.com/c/1370609 for the depot tools packaging
version of this change, and http://crrev.com/c/1371017 for the
vs_toolchain.py version of this change. Ideally this change would have
been made together with the vs_toolchain.py, but the break was found to
late. The try bots have now done full builds with the new SDK layout so
this should be the last change needed of this type.
Change-Id: I4c965c66296d2f0b6adad672a71c295ffb021c66
Reviewed-on: https://chromium-review.googlesource.com/c/1372222
Reviewed-by: Dirk Pranke <dpranke@chromium.org>
Commit-Queue: Bruce Dawson <brucedawson@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#615737}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 33f80443a11c321a12cb5337eea8dd46ecb0fecd
This change mostly contains build script change under //chrome/build only.
It is targeting MSVC arm64 toolset, but enable clang-cl
could be based on this change.
Bug: 893460
Change-Id: Ia6f69f067a97fcaeb77021c1019bc594b0859eda
Reviewed-on: https://chromium-review.googlesource.com/c/1272076
Commit-Queue: Bruce Dawson <brucedawson@chromium.org>
Reviewed-by: Dirk Pranke <dpranke@chromium.org>
Reviewed-by: Steven Valdez <svaldez@chromium.org>
Reviewed-by: Bruce Dawson <brucedawson@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#600083}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: d5bf20624a99401dcb6c9e6aee9244334008222b
Ideally, copy_cdb_to_output should depend on the files it's copying. But
since those live outside Chromium that's not really practical. Depending
on vs_toolchain.py is probably good enough; the important part is this
will force copy_cdb_to_output to run whenever the VS version changes.
Bug: 846313
Change-Id: Ie0596fb820ba71c40b65325d663f95c2bffe30a4
Reviewed-on: https://chromium-review.googlesource.com/1073451
Commit-Queue: Scott Graham <scottmg@chromium.org>
Reviewed-by: Scott Graham <scottmg@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#561893}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: bec05e14e8ac760ca6182f8cad11e1e8507758f4
This reverts commit 864136ef9686128f4afbfe6146cd3e2d08182d52.
Reason for revert:
While it seems this did trigger the cdb failures in crbug.com/846313,
it was not the root cause and reverting it didn't actually help.
Original change's description:
> Revert "Fixed SDK lookup for non C:\ Windows installation."
>
> This reverts commit 57fd44c74e13be05a3091976f9bcee39ee8f703e.
>
> Reason for revert: suspect for messing up symbols on Win7 bot
> @ crbug.com/846313
>
> Original change's description:
> > Fixed SDK lookup for non C:\ Windows installation.
> >
> > Bug: None
> > Change-Id: Ia0aa186d1d39b1beac8ce0152683f774ad5d2eaf
> > Reviewed-on: https://chromium-review.googlesource.com/1066065
> > Reviewed-by: Jochen Eisinger <jochen@chromium.org>
> > Commit-Queue: Jochen Eisinger <jochen@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#561063}
>
> TBR=jochen@chromium.org,yura.yaroshevich@gmail.com
>
> # Not skipping CQ checks because original CL landed > 1 day ago.
>
> Bug: 846313
> Change-Id: Id93a965aea5555961c539d47e05e79410894eff8
> Reviewed-on: https://chromium-review.googlesource.com/1072307
> Commit-Queue: Gabriel Charette <gab@chromium.org>
> Reviewed-by: Gabriel Charette <gab@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#561609}
TBR=gab@chromium.org,jochen@chromium.org,yura.yaroshevich@gmail.com
Bug: 846313
Change-Id: I9955a47bbe8a81a0dcf7befebfc422560f8a1cc4
Reviewed-on: https://chromium-review.googlesource.com/1073314
Reviewed-by: Hans Wennborg <hans@chromium.org>
Commit-Queue: Hans Wennborg <hans@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#561873}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 2e7257da41fbc81029fae5f306ae8123ec975f0c
This will allow webrtc and v8 to share the configs.
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.win:win-msvc-dbg
Bug: 653569
Change-Id: I41a4d9025f47fd3a9d6837f88c2bece108c213a8
Reviewed-on: https://chromium-review.googlesource.com/997794
Reviewed-by: Bruce Dawson <brucedawson@chromium.org>
Reviewed-by: Nico Weber <thakis@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#548874}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 5a4f610ded51627273b1f05e83379b1ce8e3c6aa
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
Chrome cannot build with VS 2015 anymore. Having it listed as a
supported compiler can lead to confusion for new Chromium developers.
This change scrubs inappropriate '2015' references from the Chromium
repo.
Bug: 683729
Change-Id: I2e02bc31ae8fd57a31ac65f1bb8a45eb5a5cd433
Reviewed-on: https://chromium-review.googlesource.com/807526
Commit-Queue: Bruce Dawson <brucedawson@chromium.org>
Reviewed-by: Scott Graham <scottmg@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#521829}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: cea79358b2c6f2d0d7834f3d153072fbe0bcc1a5
message_compiler.py checks to make sure its results match those
generated by mc.exe, but these checks are only valid for a given version
of mc.exe, because the output changes with every new Windows 10 SDK
version. The checking is disabled for SDK versions other than 10.0.15063
but only for .man files. This change extends the disabling of checking
for .mc files also, due to observed failures.
Bug: 774669
Change-Id: I618f68d8926b73621192e7933aea5d264fedd214
Reviewed-on: https://chromium-review.googlesource.com/807205
Reviewed-by: Scott Graham <scottmg@chromium.org>
Commit-Queue: Bruce Dawson <brucedawson@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#521577}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: fb4046a4b0fd9651c74c7dcd4638688c53937048
mc.exe's output for .man files is changing significantly in the
Fall Creator's SDK update.
Checking in outputs for multiple outputs means we'll never be able
to check in new baselines if the .man input changes, so we have
to decide on just one version. So get mc.exe's version and only
compare if it's the version that belongs to the SDK hash that's
the default in vs_toolchain.py.
We'll have to manually remember to update the checked-in output and
to bump the version number here after we update to the Fall SDK,
else we'll silently lose output checking for .man files, but that
seems like the lesser evil.
Bug: 774669
Change-Id: I841d10c53f60ea645cca1640e2a7be204ac0f31f
Reviewed-on: https://chromium-review.googlesource.com/735073
Reviewed-by: Bruce Dawson <brucedawson@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#511280}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 02ba53c693281052d9b52d411f34d125f4bf40a3
This helper file is intended to be used with GN generation of
Visual Studio solutions. Because GN doesn't have the concept of
different architectures or configurations, it can only gen a single
solution. What the script does is take a bunch of different solutions
from different GN output directories and merges them into a single
"meta" solution.
This allows the user to have a single open instance of Visual
Studio which can manage different build configurations. A common
use case is to have 32-bit/64-bit and Debug Release in the same
IDE, switchable by using the drop down menus.
The solution is forced to use the "x64" platform due to limitations
in Visual Studio.
Based on skia's script: https://skia-review.googlesource.com/4158
BUG=angleproject:1569
Change-Id: I0882211ab8ca442623632764ee6bc135bde02307
Reviewed-on: https://chromium-review.googlesource.com/729133
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Dirk Pranke <dpranke@chromium.org>
Reviewed-by: Bruce Dawson <brucedawson@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#511003}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: fcc7dabd24569a756d462e434a1bd4485cb7534e
This attempts to port https://github.com/google/syzygy/blob/master/syzygy/swapimport/swapimport_app.cc#L143
The motivation is to be able to run this on non-Windows hosts. This is
the last thing that's required to be able to link chrome.exe (with some
other local changes).
Not relying on a checked-in binary also makes changing the script easier.
Bug: 761849
Change-Id: I9956ce5c0929dcb3fd1309a8f0b2acc80b7b92ce
Reviewed-on: https://chromium-review.googlesource.com/649810
Commit-Queue: Nico Weber <thakis@chromium.org>
Reviewed-by: Scott Graham <scottmg@chromium.org>
Reviewed-by: Chris Hamilton <chrisha@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#499824}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: cf357e4d70c3f537994bbbce771b678bc6ef2d3e
Some versions of mc.exe apparently don't do that, see chromium-dev
"message_compiler.py build failure due to innocent enum ordering changes"
Also print a slightly more detailed diff.
Bug: 756607
Change-Id: I100891d0d1d06256448e568b9fa0ed8938d5957b
Reviewed-on: https://chromium-review.googlesource.com/649768
Reviewed-by: Scott Graham <scottmg@chromium.org>
Commit-Queue: Nico Weber <thakis@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#499663}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 570a3b4c38a155a075e4370a37bf184c7d35bbd4
This reverts commit d000a95b5c7189076d3e6d61f243caef3edeaa48.
Reason for revert: Speculating that this CL has caused a tree closure - see https://build.chromium.org/p/chromium.chrome/builders/Google%20Chrome%20Win/builds/21668
Original change's description:
> mc: Copy over checked-in outputs on non-Windows hosts.
>
> On Windows hosts, verify that the checked-in outputs are identical to
> what mc.exe actually produces.
>
> Bug: 756607
> Change-Id: If827c2b5d64730a27cf409af25783794366c1843
> Reviewed-on: https://chromium-review.googlesource.com/646659
> Commit-Queue: Nico Weber <thakis@chromium.org>
> Reviewed-by: Scott Graham <scottmg@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#499221}
TBR=thakis@chromium.org,scottmg@chromium.org
Change-Id: I9d2dc77942bdba7198ed442cedb2f3d815510f9f
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: 756607
Reviewed-on: https://chromium-review.googlesource.com/648146
Reviewed-by: Łukasz Anforowicz <lukasza@chromium.org>
Commit-Queue: Łukasz Anforowicz <lukasza@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#499227}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: ea662297506102da12eb1ee04e40fad15b77a1d5
On Windows hosts, verify that the checked-in outputs are identical to
what mc.exe actually produces.
Bug: 756607
Change-Id: If827c2b5d64730a27cf409af25783794366c1843
Reviewed-on: https://chromium-review.googlesource.com/646659
Commit-Queue: Nico Weber <thakis@chromium.org>
Reviewed-by: Scott Graham <scottmg@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#499221}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: d000a95b5c7189076d3e6d61f243caef3edeaa48
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
pgomgr.exe sometime fails to merge too many files at the same time, with
what seems to be a memory issue (process peak at ~4GB before failing,
it's a 64-bit process so it's probably a size_t/uint32_t issue). I've a
local repro that I'll send to MS, but in the meantime this fix is
required to fix the official build (and the PGO ones in general).
Bug: 729894
Change-Id: I9c862c0179de50ee89b22a03789c9fb0a1071d48
Reviewed-on: https://chromium-review.googlesource.com/528354
Commit-Queue: Sébastien Marchand <sebmarchand@chromium.org>
Reviewed-by: Scott Graham <scottmg@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#478066}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 0c6adbef4d5f4722e2a224c90164f30ec9cf26dd
pgomgr.exe has been moved to a different location in VS2017 so the logic
that find it should be updated.
It can't just be copied to the build directory because we always run the
x64 bit version of this binary (and we don't want to mix x86 and x64
binaries in the same build dir)
BUG=719319
Review-Url: https://codereview.chromium.org/2884613003
Cr-Original-Commit-Position: refs/heads/master@{#473438}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: ab3a1821bb57a51d11be2b038b3a698236ccd5fc
Bruce Dawson
Nico Weber
Hans Wennborg
Raul Tambre
Jamie Madill
Jon Kunkee
Sebastien Marchand
Tom Tan
Gabriel Charette
Yura Yaroshevich
Michael Achenbach
Sigurdur Asgeirsson
Scott Graham
Łukasz Anforowicz