Allwo building a WebView APK which doesn't contain any code or assets,
and no resources other than the icon. This APK has a special manifest
tag which will direct the system to provide the missing files from
another "donor" package at runtime that has compatible code (this will
be Monochrome).
To enable this to work, a new APK variable is defined called
"generate_buildconfig_java" so that the BuildConfig.java file can be
omitted from this APK (leaving the generated classes.dex containing
nothing but the AAPT-generated R class for the single icon resource).
The runtime doesn't like having multiple APKs in the classpath which
define the same classes, so we need to omit this BuildConfig to avoid
clashing with Monochrome's.
BUG=664456
Review-Url: https://codereview.chromium.org/2634563002
Cr-Original-Commit-Position: refs/heads/master@{#453911}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: cbafd406aff624f7191f76d64e3c0fcb66b60653
MIPS64 requires IAS to be explicitly set.
Few important mips64 related changes were missing in Clang.
With Clang roll to r295762 they are included and
clang does not crash anymore.
Now that build is ok we can switch to IAS as well.
BUG=None.
TEST=gn gen out-gn/mips64-clang --args="is_debug=false target_os=\"android\" target_cpu=\"mips64el\" is_clang=true mips_use_msa=false"
ninja -C out-gn/mips64-clang system_webview_apk
Review-Url: https://codereview.chromium.org/2720833002
Cr-Original-Commit-Position: refs/heads/master@{#453252}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 55850d4e8fca1b77851f90956fe3dd995b01afc0
This patch enables the auto raw pointer deduction on linux. The plan
is to also enable this on all the remaining platforms shortly.
R=thakis@chromium.org, danakj@chromium.org
BUG=554600
CQ_INCLUDE_TRYBOTS=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
Review-Url: https://codereview.chromium.org/2697873004
Cr-Original-Commit-Position: refs/heads/master@{#452973}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: c2a957c63637a55bb157b2cb24d2f3b5fce206d9
Reason for revert:
Build failure as a result of the flag. I will fix up and reland.
Original issue's description:
> build: Enable auto raw pointer deduction check on linux.
>
> This patch enables the auto raw pointer deduction on linux. The plan
> is to also enable this on all the remaining platforms shortly.
>
> R=thakis@chromium.org, danakj@chromium.org
> BUG=554600
> CQ_INCLUDE_TRYBOTS=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
>
> Review-Url: https://codereview.chromium.org/2697873004
> Cr-Commit-Position: refs/heads/master@{#452880}
> Committed: 4075255b12TBR=jochen@chromium.org,dalecurtis@chromium.org,danakj@chromium.org,thakis@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=554600
Review-Url: https://codereview.chromium.org/2713993003
Cr-Original-Commit-Position: refs/heads/master@{#452892}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 5187e38a974a9346dd330efc5802888d9b0d1f21
This patch enables the auto raw pointer deduction on linux. The plan
is to also enable this on all the remaining platforms shortly.
R=thakis@chromium.org, danakj@chromium.org
BUG=554600
CQ_INCLUDE_TRYBOTS=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
Review-Url: https://codereview.chromium.org/2697873004
Cr-Original-Commit-Position: refs/heads/master@{#452880}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 4075255b128597153622d38d72286ff223d64f33
Release builds with the Jessie sysroot currently have a dependency on
libglib2.0-0 (>= 2.41.1). However, the version of libglib packaged
with Trusty is only 2.40. This means users won't be able to install a
debian package on Trusty compiled with the Jessie sysroot.
This CL sets GLIB_VERSION_MAX_ALLOWED to 2.32, because that is the
version that ships with Wheezy. We can't use a later minimum glib
version because we still build with the Wheezy sysroot, and macro
versions later than GLIB_VERSION_2_32 are not defined. Keeping it at
2.32 is not harmful.
R=dpranke@chromium.org,thestig@chromium.org
Review-Url: https://codereview.chromium.org/2707203007
Cr-Original-Commit-Position: refs/heads/master@{#452749}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: d92ddb31281a028252ed844d200fc58a0efec783
Reason for revert:
Looks like this CL is breaking Android Compile on chromium.perf.
https://bugs.chromium.org/p/chromium/issues/detail?id=695534
Original issue's description:
> Fix repeated "-Wunknown-pragmas -Wno-error=unknown-pragmas".
>
> As gn only deduplicate the configs but not the configs' flags, the
> flags "-Wunknown-pragmas -Wno-error=unknown-pragmas" where repeated
> for each dependent target using the "grit" template. Instead add a
> single config adding those flag and reference it from the "grit"
> template to avoid the duplicates.
>
> BUG=None
>
> Review-Url: https://codereview.chromium.org/2717493002
> Cr-Commit-Position: refs/heads/master@{#452543}
> Committed: f673f4c59cTBR=lizeb@chromium.org,scottmg@chromium.org,sdefresne@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=None
Review-Url: https://codereview.chromium.org/2708923007
Cr-Original-Commit-Position: refs/heads/master@{#452595}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: b6c06ef04f90d35dcbdd08c083befa94152c1320
As gn only deduplicate the configs but not the configs' flags, the
flags "-Wunknown-pragmas -Wno-error=unknown-pragmas" where repeated
for each dependent target using the "grit" template. Instead add a
single config adding those flag and reference it from the "grit"
template to avoid the duplicates.
BUG=None
Review-Url: https://codereview.chromium.org/2717493002
Cr-Original-Commit-Position: refs/heads/master@{#452543}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: f673f4c59c985aa8ddfab2b3821c42af25d915e4
When the ios_automatically_manage_certs variable is set to true,
restrict the number of different Bundle Identifiers are used by
the build (as they are currently limited to 10 free certs per day).
BUG=613543
Review-Url: https://codereview.chromium.org/2709223002
Cr-Original-Commit-Position: refs/heads/master@{#452529}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: eb7eea750b9604ca75254a775f9d381514966196
Relanding with fix for amd64-generic Trusty build failure. Previous
version was crrev.com/2661023010.
Traditionally goma for Chrome has been less useful on Windows than on
other platforms because it was incompatible with full debug information.
Building with goma requires using /Z7 instead of /Zi, and this causes
the linker's memory usage and runtime to blow up as all of the debug
information is merged.
However, /debug:fastlink makes this work. Because it doesn't merge all
of the debug information it makes goma and /Z7 practical. Full release
component builds can be done in less than fifteen minutes, with
incremental builds taking just a few seconds. Without goma a full
release component build of Chrome can easily take 40+ minutes, even on a
Z840.
Goma's speedup comes from massively parallelizing the compile phase,
however even with /debug:fastlink the linking phases are longer with the
/Z7 switch that is required by goma. A /debug:fastlink of chrome.dll in
a component build goes from ~32 seconds to ~110 seconds on a Z620 when
/Z7 (goma) is selected. This penalty will be reduced by VC++ 2017 which
claims 30% speed improvements on /debug:fastlink.
So, if you frequently need to do full relinks then goma may still be a
bad choice. However for most scenarios this change should make goma a
good choice for component builds of Chrome, even with full debug
information enabled. To make use of this ability you need to explicitly
specify the switches below - symbol_level will otherwise default to 1
when use_goma == true.
use_goma = true
is_win_fastlink = true
symbol_level = 2
In addition, these two settings are strongly recommended if you want the
fastest possible builds:
is_component_build = true
target_cpu="x86" - to ensure incremental linking always works
The fastlink PDBs work well for most scenarios but there are a few
scenarios where they do not work:
- Copying PDBs to another machine (fails due to references to the .obj
files)
- Reporting on all symbols/globals with SymbolSort or windbg's "x"
command or similar will report nothing
- ETW tracing fails
- VS heap profiling fails
Ideally mspdbcmf.exe would let us create "normal" PDBs when needed but
in practice this appears to be unusable with /Z7 created PDBs.
BUG=630074,688203
Review-Url: https://codereview.chromium.org/2702203004
Cr-Original-Commit-Position: refs/heads/master@{#452171}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 77bdd81b8517ef0166ba14549545fa1f27d9bfec
The plist templates can have different values for the same key.
If the value is a list (plist array), merge should be the concatenation.
Don't compute union as as list can contain dicts.
BUG=692552
Review-Url: https://codereview.chromium.org/2715543002
Cr-Original-Commit-Position: refs/heads/master@{#452083}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 0cf3dac55d77555df465f3809e8f8636efef303d
When a DLL is instrumented with ASAN, there is some thunks introduced
that dynamically resolved the function through the imports table and
redirect the call from the DLL to the main executable.
Unfortunately, unreferenced functions recently got removed by the
linker.
Without this fix this function is not part of the final executable:
__asan_locate_address
% dumpbin D:\src\chromium\src\out\ninja64\initialexe\chrome.exe /exports | grep asan_l
This is making chrome to crash on startup when loading chrome_elf.dll.
ASAN is failing to hook on a function and call abort, which is also
failing because ASAN is still in the "tls-initialisation" phase.
R=ochang@chromium.org, rnk@chromium.org, thakis@chromium.org, chrisha@chromium.org
BUG=
Review-Url: https://codereview.chromium.org/2710573003
Cr-Original-Commit-Position: refs/heads/master@{#451836}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 803397e04777bc734a9c028813351c2e5079faf1
This fixes most compile issues with android_webview. There is still an
issue with a missing R.java though (updated comment in code about this).
BUG=620034
Review-Url: https://codereview.chromium.org/2699963002
Cr-Original-Commit-Position: refs/heads/master@{#451217}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: a1c2f35132f2a07e14c64b633485195a705f848e
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
Remove GMS from upstream WebView (it's only needed downstream) and
create a google_play_services_package variable with the upstream GMS
location, so it can be overridden downstream.
BUG=662166
Review-Url: https://codereview.chromium.org/2697543004
Cr-Original-Commit-Position: refs/heads/master@{#450780}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 635a45202f8cdaef30cfa4c5d4b602660e81395e
The linker script is applied to all shared_library() targets by default,
just like the hide_jni one was (but not loadable_module() targets).
This reduces the size of libchrome.so by 220kb.
Reverted in:
https://codereview.chromium.org/2685933002/
Reason for reland:
Tested webkit_tests now pass locally. Issue was that libosmesa.so
had its symbols hidden.
BUG=448386
TBR=brettw
Review-Url: https://codereview.chromium.org/2699473002
Cr-Original-Commit-Position: refs/heads/master@{#450734}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: e61084f2f942e6203a98bb4f7e505f9d7b679604
Prior to this CL, all Malloc Zone functions were rerouted through a light-weight
shim that kills the process [in oom_killer_malloc] on failure. This CL instead
reroutes the functions to the allocator shim, which is cross-platform, and has
the same effect on failure. The allocator shim also provides the ability to
track all allocations.
BUG=677302
Review-Url: https://codereview.chromium.org/2673173002
Cr-Original-Commit-Position: refs/heads/master@{#450302}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: ab510e5f21028950cec63965e024a40bd1ccba66
This matches the default behaviour, even in Debug builds, of GCC & Clang.
AllocationContextTracker::PseudoStackFrame actually relies on string
pooling to allow it to compare trace event category and name strings by
address rather than strcmp().
BUG=686208
Review-Url: https://codereview.chromium.org/2689793003
Cr-Original-Commit-Position: refs/heads/master@{#449874}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 772ff4cd3df488b794fa66e8ed9d2951543a11ee
This warning has existed for a while but used to be off-by-default.
Upstream made it on-by-default recently, which breaks the compile step
of the iOS ToT bot.
BUG=691120
TBR=hans
Review-Url: https://codereview.chromium.org/2682943010
Cr-Original-Commit-Position: refs/heads/master@{#449837}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 48130024a853818d09b132c10dfca934a14e7da6
We're working on a class of changes in the Linux desktop UI
that won't work on Precise; they need newer Linux versions
that basically amount to needing to link against the Debian
Jessie sysroot instead of the Debian Wheezy sysroot. Previously
we were working around this by checking whether we were building
with ozone + use_kbdcommon, but that caused a dependency inversion
by making //build depend on //ui.
This changes adds a dedicated GN build arg, use_jessie_sysroot,
that we'll explicitly set instead, and that way we can avoid
the dependency inversion.
R=thomasanderson@chromium.org, tonikitoo@igalia.com
BUG=564904
Review-Url: https://codereview.chromium.org/2687203002
Cr-Original-Commit-Position: refs/heads/master@{#449505}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 657454d7091e2d6108703305a6ba1d4904df98a0
clang finally hit the same file size wall that gcc hit a while ago.
(Locally, building lib_android_webview_unittests__library.so goes
from 6.5min to 3.8min on my linux box and file size of the .so goes
from over 4.1GB to 320MB -- at the cost of no detailed debug info
of coarse. Feels like investigating fission or similar would probably
be beneficial for the android build.)
BUG=648948,685259
Review-Url: https://codereview.chromium.org/2685033002
Cr-Original-Commit-Position: refs/heads/master@{#449314}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 7be003ae95486a55fc2a9ef5fb34e26f702fc241
We recently hit a corner case on the component build from the following
dependency structure:
/chrome/crash_uploader ("//chromecast/crash:crash_uploader") ->
/chrome/lib/libcast_reboot_1.0.so ("//chromecast/system/reboot") ->
/chrome/libnet.so ("//net")
In libcast_reboot_1.0.so's RPATH, $ORIGIN resolves to /chrome/lib,
meaning that it never searches /chrome/ for libnet.so, causing it to
crash. Explicitly adding the location of component libs to the RPATH
solves this issue.
Note: The RPATH will not be changed in production builds, which do not
use the component build.
BUG=
Change-Id: I0646a063ad787d3fe846fd0755f7f84a4cb6033b
Review-Url: https://codereview.chromium.org/2686903002
Cr-Original-Commit-Position: refs/heads/master@{#449130}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 3301fc1e1974b51ccb59f24519de0dcde34b9333
Reason for revert:
This was the actual culprit, will re-land v8 rolls.
Original issue's description:
> Reland of Android: Use linker script to hide all non-JNI symbols (patchset #1 id:1 of https://codereview.chromium.org/2685933002/ )
>
> Reason for revert:
> Revert fixed WebKit Android (Nexus4) but... I also reverted https://codereview.chromium.org/2680943003 in parallel as EST sheriff... so now we don't know which one fixed it... tentatively relanding this one to see..!
>
> Original issue's description:
> > Revert of Android: Use linker script to hide all non-JNI symbols (patchset #4 id:60001 of https://codereview.chromium.org/2633593004/ )
> >
> > Reason for revert:
> > Speculative revert, potential culprit for webkit_tests crashing on "WebKit Android (Nexus4)".
> >
> > Stack traces show not much else than JNI managed->native transitions and syscalls.
> >
> > Original issue's description:
> > > Android: Use linker script to hide all non-JNI symbols
> > >
> > > The linker script is applied to all shared_library() targets by default,
> > > just like the hide_jni one was.
> > >
> > > This reduces the size of libchrome.so by 220kb.
> > >
> > > BUG=448386
> > > CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_cronet_tester
> > >
> > > Review-Url: https://codereview.chromium.org/2633593004
> > > Cr-Commit-Position: refs/heads/master@{#448988}
> > > Committed: 6888d5002b
> >
> > TBR=torne@chromium.org,digit@chromium.org,brettw@chromium.org,agrieve@chromium.org
> > # Skipping CQ checks because original CL landed less than 1 days ago.
> > NOPRESUBMIT=true
> > NOTREECHECKS=true
> > NOTRY=true
> > BUG=448386
> >
> > Review-Url: https://codereview.chromium.org/2685933002
> > Cr-Commit-Position: refs/heads/master@{#449028}
> > Committed: de69a7c823
>
> TBR=torne@chromium.org,digit@chromium.org,brettw@chromium.org,agrieve@chromium.org,engedy@chromium.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=448386
>
> Review-Url: https://codereview.chromium.org/2683013002
> Cr-Commit-Position: refs/heads/master@{#449057}
> Committed: 59e1841b41TBR=torne@chromium.org,digit@chromium.org,brettw@chromium.org,agrieve@chromium.org,engedy@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=448386
Review-Url: https://codereview.chromium.org/2684123002
Cr-Original-Commit-Position: refs/heads/master@{#449096}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: c41fe7af125cf8b4ff24fd4b6b292213da99eda7
Reason for revert:
Revert fixed WebKit Android (Nexus4) but... I also reverted https://codereview.chromium.org/2680943003 in parallel as EST sheriff... so now we don't know which one fixed it... tentatively relanding this one to see..!
Original issue's description:
> Revert of Android: Use linker script to hide all non-JNI symbols (patchset #4 id:60001 of https://codereview.chromium.org/2633593004/ )
>
> Reason for revert:
> Speculative revert, potential culprit for webkit_tests crashing on "WebKit Android (Nexus4)".
>
> Stack traces show not much else than JNI managed->native transitions and syscalls.
>
> Original issue's description:
> > Android: Use linker script to hide all non-JNI symbols
> >
> > The linker script is applied to all shared_library() targets by default,
> > just like the hide_jni one was.
> >
> > This reduces the size of libchrome.so by 220kb.
> >
> > BUG=448386
> > CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_cronet_tester
> >
> > Review-Url: https://codereview.chromium.org/2633593004
> > Cr-Commit-Position: refs/heads/master@{#448988}
> > Committed: 6888d5002b
>
> TBR=torne@chromium.org,digit@chromium.org,brettw@chromium.org,agrieve@chromium.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=448386
>
> Review-Url: https://codereview.chromium.org/2685933002
> Cr-Commit-Position: refs/heads/master@{#449028}
> Committed: de69a7c823TBR=torne@chromium.org,digit@chromium.org,brettw@chromium.org,agrieve@chromium.org,engedy@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=448386
Review-Url: https://codereview.chromium.org/2683013002
Cr-Original-Commit-Position: refs/heads/master@{#449057}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 59e1841b41f8902a0f300eb8cc412a73725013ed
Reason for revert:
Speculative revert, potential culprit for webkit_tests crashing on "WebKit Android (Nexus4)".
Stack traces show not much else than JNI managed->native transitions and syscalls.
Original issue's description:
> Android: Use linker script to hide all non-JNI symbols
>
> The linker script is applied to all shared_library() targets by default,
> just like the hide_jni one was.
>
> This reduces the size of libchrome.so by 220kb.
>
> BUG=448386
> CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_cronet_tester
>
> Review-Url: https://codereview.chromium.org/2633593004
> Cr-Commit-Position: refs/heads/master@{#448988}
> Committed: 6888d5002bTBR=torne@chromium.org,digit@chromium.org,brettw@chromium.org,agrieve@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=448386
Review-Url: https://codereview.chromium.org/2685933002
Cr-Original-Commit-Position: refs/heads/master@{#449028}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: de69a7c823b439d35e7ee716a1da25e05a871efe
The linker script is applied to all shared_library() targets by default,
just like the hide_jni one was.
This reduces the size of libchrome.so by 220kb.
BUG=448386
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_cronet_tester
Review-Url: https://codereview.chromium.org/2633593004
Cr-Original-Commit-Position: refs/heads/master@{#448988}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 6888d5002b2eabe4fac226f0e5124fbd62bdd215
clang_revision variable may has format, that represents arithmetical
expression. For example – 284979-2.
Althought it is stated that this define should not be used in code,
it is unsafe. It can be made as string, so it will perfectly do it's
job and be much more safe.
R=brettw@chromium.org, dpranke@chromium.org
BUG=
Review-Url: https://codereview.chromium.org/2674983002
Cr-Original-Commit-Position: refs/heads/master@{#448520}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 3331c473d65bc3331cf14e9797b102fdbbf013ea
Tie the debian/jessie usage to use_xkbcommon rather
than use_ozone for now.
This is more conservative and avoids problems for ozone/headless
and other bots.
BUG=687725
Review-Url: https://codereview.chromium.org/2676643004
Cr-Original-Commit-Position: refs/heads/master@{#448468}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: ef8c544029d9e7201b3d24e87af90a97702ed5b4
We're not working on this config at the moment, so having a red buildbot
testing it is just waste of cycles.
BUG=688123, 598772
Review-Url: https://codereview.chromium.org/2677593002
Cr-Original-Commit-Position: refs/heads/master@{#447910}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 3ba9c67e210df1f039f93548c1ad5bb2dfe3a945
Reason for revert:
It broke amd64-generic Trusty informational build at generate_build_files:
ERROR at //build/config/compiler/compiler.gni:115:3: Assertion failed.
assert(is_win_fastlink || !use_goma,
^-----
Goma builds that use symbol_level 2 must use is_win_fastlink.
See //BUILD.gn:11:1: whence it was imported.
import("//build/config/compiler/compiler.gni")
^--------------------------------------------
GN gen failed: 1
step returned non-zero exit code: 1
@@@STEP_FAILURE@@@
See crbug.com/688203 for more info.
Original issue's description:
> Allow using goma on Windows with symbol_level == 2
>
> Traditionally goma for Chrome has been less useful on Windows than on
> other platforms because it was incompatible with full debug information.
> Building with goma requires using /Z7 instead of /Zi, and this causes
> the linker's memory usage and runtime to blow up as all of the debug
> information is merged.
>
> However, /debug:fastlink makes this work. Because it doesn't merge all
> of the debug information it makes goma and /Z7 practical. Full release
> component builds can be done in less than fifteen minutes, with
> incremental builds taking just a few seconds. Without goma a full
> release component build of Chrome can easily take 40+ minutes, even on a
> Z840.
>
> Goma's speedup comes from massively parallelizing the compile phase,
> however even with /debug:fastlink the linking phases are longer with the
> /Z7 switch that is required by goma. A /debug:fastlink of chrome.dll in
> a component build goes from ~32 seconds to ~110 seconds on a Z620 when
> /Z7 (goma) is selected. This penalty will be reduced by VC++ 2017 which
> claims 30% speed improvements on /debug:fastlink.
>
> So, if you frequently need to do full relinks then goma may still be a
> bad choice. However for most scenarios this change should make goma a
> good choice for component builds of Chrome, even with full debug
> information enabled. To make use of this ability you need to explicitly
> specify the switches below - symbol_level will otherwise default to 1
> when use_goma == true.
>
> use_goma = true
> is_win_fastlink = true
> symbol_level = 2
>
> The fastlink PDBs work well for most scenarios but there are a few
> scenarios (rare for most people) where they do not work:
> - Copying PDBs to another machine (fails due to references to the .obj
> files)
> - Reporting on all symbols/globals with SymbolSort or similar fails
> - ETW tracing fails
> - VS heap profiling fails
> Ideally mspdbcmf.exe would let us create "normal" PDBs when needed but
> in practice this appears to be unusable with /Z7 created PDBs.
>
> R=scottmg@chromium.org
>
> Review-Url: https://codereview.chromium.org/2661023010
> Cr-Commit-Position: refs/heads/master@{#447892}
> Committed: 4a3cadb2d9TBR=scottmg@chromium.org,dpranke@chromium.org,brucedawson@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review-Url: https://codereview.chromium.org/2669373002
Cr-Original-Commit-Position: refs/heads/master@{#447895}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 169e1ad7aeb6cf86dda8912fbf7e2ef3e2321344
Traditionally goma for Chrome has been less useful on Windows than on
other platforms because it was incompatible with full debug information.
Building with goma requires using /Z7 instead of /Zi, and this causes
the linker's memory usage and runtime to blow up as all of the debug
information is merged.
However, /debug:fastlink makes this work. Because it doesn't merge all
of the debug information it makes goma and /Z7 practical. Full release
component builds can be done in less than fifteen minutes, with
incremental builds taking just a few seconds. Without goma a full
release component build of Chrome can easily take 40+ minutes, even on a
Z840.
Goma's speedup comes from massively parallelizing the compile phase,
however even with /debug:fastlink the linking phases are longer with the
/Z7 switch that is required by goma. A /debug:fastlink of chrome.dll in
a component build goes from ~32 seconds to ~110 seconds on a Z620 when
/Z7 (goma) is selected. This penalty will be reduced by VC++ 2017 which
claims 30% speed improvements on /debug:fastlink.
So, if you frequently need to do full relinks then goma may still be a
bad choice. However for most scenarios this change should make goma a
good choice for component builds of Chrome, even with full debug
information enabled. To make use of this ability you need to explicitly
specify the switches below - symbol_level will otherwise default to 1
when use_goma == true.
use_goma = true
is_win_fastlink = true
symbol_level = 2
The fastlink PDBs work well for most scenarios but there are a few
scenarios (rare for most people) where they do not work:
- Copying PDBs to another machine (fails due to references to the .obj
files)
- Reporting on all symbols/globals with SymbolSort or similar fails
- ETW tracing fails
- VS heap profiling fails
Ideally mspdbcmf.exe would let us create "normal" PDBs when needed but
in practice this appears to be unusable with /Z7 created PDBs.
R=scottmg@chromium.org
Review-Url: https://codereview.chromium.org/2661023010
Cr-Original-Commit-Position: refs/heads/master@{#447892}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 4a3cadb2d998fb8f477d0ebc7ff13619b123a805
If __DATE__, __TIME__ or __TIMESTAMP__ used in code, current date or
time will be filled. Such a value may change compile by compile, and
breaks deterministic build.
BUG=314403
Review-Url: https://codereview.chromium.org/2664743002
Cr-Original-Commit-Position: refs/heads/master@{#447769}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 5eded4b55c92335c96702d53aa319a360c86f556
This CL should have no behavioral effect, since the relevant code is not enabled
yet.
allocator_shim_override_mac_symbols.h intercepts heap allocations using the
newly introduced APIs in allocator_interception_mac.h and redirects them to the
allocator shim. This eventually forwards to AllocatorDispatch::default_dispatch,
which in turns calls the original malloc zone functions..
BUG=665567
Review-Url: https://codereview.chromium.org/2658723007
Cr-Original-Commit-Position: refs/heads/master@{#447705}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 0d0395aeb25b9ab1422ab547f976d049a14e192f
Adding ochang@ to the file.
sanitizer & libfuzzer build configuration is very interconnected
and often needs to change in sync.
BUG=
Review-Url: https://codereview.chromium.org/2664403005
Cr-Original-Commit-Position: refs/heads/master@{#447685}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 5b2d8899ed66b788a1811b15163dd37bc178f5ca
torne
aizatsky
Gordana.Cmiljanovic
vmpstr
thakis
mmoroz
thomasanderson
prasadv
sdefresne
treib
brucedawson
fgorski
olivierrobin
jochen
ymzhang
etienneb
agrieve
pennymac
paulmiller
danakj
erikchen
wez
dpranke
slan
gab
engedy
zienag
tonikitoo
ochang
hans
xdai
yyanagisawa