Adds new frame-level service with one initial method to handle host zoom
level.
This moves zoom level supply from async_resource_handler.cc to being a
request made when render_frame_impl handles a willSendRequest.
The goal of this change is to remove the dependency of
content/browser/loader on the rest of content/browser in particular
here, removing the use of c/b/host_zoom_map_impl.h in
content/browser/loader/async_resource_handler.cc.
BUG=598073,609607
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_site_isolation
Review-Url: https://codereview.chromium.org/1964273002
Cr-Original-Commit-Position: refs/heads/master@{#394547}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 68c6f2ce16d9807b5cb82679099c82c40f39e911
This CL reworks the way ChromiumOS toolchains work in GN, in such a way
that they might actually have all the flags they need for the
ChromiumOS ebuild files to be able to set all of the flags it needs
(though there are still some missing GN build_args).
Specifically, the ebuild will now need to set the following in args.gn:
host_toolchain = "//build/toolchain/cros:host"
v8_snapshot_toolchain = "//build/toolchain/cros:v8_snapshot"
in order to support boards other than the amd64-generic build. The
ebuild should actually set these variables all the time; it just
happens that the amd64-generic build will work at the moment without
the variables, but that will not be guaranteed to remain true in the future.
This CL also adds the following optional build args that do pretty
much what you'd expect them to do:
cros_target_ld, cros_target_extra_cflags, cros_target_extra_cppflags,
cros_target_extra_cxx_flags, cros_target_extra_ldflags,
cros_host_ar, cros_host_cc, cros_host_cxx, cros_host_ld,
cros_host_is_clang, cros_host_extra_cflags, cros_host_extra_cppflags,
cros_host_extra_cxx_flags, cros_host_extra_ldflags,
cros_v8_snapshot_ar, cros_v8_snapshot_cc, cros_v8_snapshot_cxx,
cros_v8_snapshot_ld, cros_v8_snapshot_extra_cflags,
cros_v8_snapshot_extra_cppflags, cros_v8_snapshot_extra_cxx_flags,
cros_v8_snapshot_extra_ldflags
This CL should be backwards-compatible with the existing linux desktop
ChromiumOS builds and the amd64-generic simplechrome/ebuild (i.e., it
can be landed and reverted w/o requiring any other changes to be made).
It is a big hammer intended to un-block the ChromiumOS GN migration
while we continue thinking about how to best support ChromiumOS.
R=stevenjb@chromium.org, brettw@chromium.org
BUG=608596, 595653
Review-Url: https://codereview.chromium.org/1983613002
Cr-Original-Commit-Position: refs/heads/master@{#394534}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 8ad2f49335feaddddbd3f318fc6f4d13eb52760b
Use "xcrun" instead of "xcodebuild" as it is much faster and available
on all version of OS X supported for building Chrome.
Reduce running time of "gn gen" from 2.5 to 2.2s on MacBook Pro
laptop.
BUG=609541
Review-Url: https://codereview.chromium.org/1993653002
Cr-Original-Commit-Position: refs/heads/master@{#394505}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 268142df3c289fcd2605cd68f41e04ebade1067b
Tried to set arm_fpu to "cortex-a57+simd+crypto+fp+crc" for clang
These lines also affect GCC which is used to ship official chrome,
All ARMv8 implementations would support SIMD and FP by default, but
crypto is optional, so the code generated might fail on devices which
do not support crypto also adding cortex-a57 and using on cortex-a53
or vice versa might generate code that is going to be slower.
So we decided to revert this patch.
BUG : http://crbug.com/539781
BUG=539781
R=thakis@chromium.org
TEST=download apk to ARMv8 board and launch
Review-Url: https://codereview.chromium.org/1987733002
Cr-Original-Commit-Position: refs/heads/master@{#394334}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 5d3069f38c1bbacbfc9d1ef672ea8c8dc9d12b3f
This is modeled after what is done for the official Chrome linux build.
As it stands right now, the breakpad symbol file is roughly 300MB and
takes a couple of minutes to run, so the action should only be triggered
if this is an official release.
BUG=597454
Review-Url: https://codereview.chromium.org/1979773002
Cr-Original-Commit-Position: refs/heads/master@{#394191}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 060ef497fef78501475548ec61dbc8c290f02a9b
Remove workaround in build/config/ios/rules.gni now that gn has
been rolled to include support for product_type property.
BUG=597975
Review-Url: https://codereview.chromium.org/1948753002
Cr-Original-Commit-Position: refs/heads/master@{#394116}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 27e8737ee5fbc9cf0b8a2d4a2076cd07030f7096
Add toolchain hash for Update 3 pre-release and fix declarations of
delay-load hooks for VS 2015 Update 3. The new toolchain is not used
unless you go "set DEPOT_TOOLS_WIN_TOOLCHAIN_PRERELEASE=1", run
"gclient runhooks", and then regenerate ninja files (if using gn).
Therefore this change is a NOP for the build machines and the code
we ship.
VS 2015 Update 3 changes the delay hook function pointers to be const
because this is important for security. This matches that change.
The new compiler is discussed here:
https://blogs.msdn.microsoft.com/vcblog/2016/05/04/new-code-optimizer/
The version packaged up for this change was installed May 16th.
BUG=440500
Review-Url: https://codereview.chromium.org/1959413002
Cr-Original-Commit-Position: refs/heads/master@{#394031}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: a80d80c3e4c086a791b93a07ee089413fa60630d
Currently, Java exceptions hit while running native tests -- e.g. on JNI link
failure -- are lost to the logcat. This surfaces them to the test runner's
stdout.
BUG=
Review-Url: https://codereview.chromium.org/1982493002
Cr-Original-Commit-Position: refs/heads/master@{#393921}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 6cdb933c8d2c4cadbf842fbb3ceb9cecd0f70920
The revert of the Android gold change in r393738 also partially
reverted the change to using gold on x86 linux in r393645.
This CL re-lands the x86 linux part.
TBR=mlliu@chromium.org
BUG=590004, 611618,606749
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_compile_dbg_32_ng,linux_chromium_dbg_32_ng
Review-Url: https://codereview.chromium.org/1985503002
Cr-Original-Commit-Position: refs/heads/master@{#393759}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 665f2abb04029e72a8852a2ecb0959031272ff25
The only reason we were not using gold by default on x86
is that using icf was buggy. However, we think we've updated
to a working version of gold, and so we should now use it.
R=mcgrathr@chromium.org, thakis@chromium.org
BUG=590004
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_compile_dbg_32_ng,linux_chromium_dbg_32_ng
Review-Url: https://codereview.chromium.org/1951133002
Cr-Original-Commit-Position: refs/heads/master@{#393645}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 11668d5556912ae81fa645cea8a5b7bb381407c7
Heap profiler relies on frame pointers to do stack unwinding. ARM builds
are using thumb mode by default, but since frame pointers are broken in thumb
mode for both GCC and LLVM (https://llvm.org/bugs/show_bug.cgi?id=18505), we
need a way to build in arm mode.
This change exposes arm_use_thumb GN variable so that it can be set to false.
BUG=602701
Review-Url: https://codereview.chromium.org/1977533002
Cr-Original-Commit-Position: refs/heads/master@{#393615}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 2a91d261e9858e3914153f0fc3d0f57a4b126558
This is another attempt to fix which flags we use by default when
linking w/ gold. The interaction of gold + gcc on intel platforms
appears buggy, so we only use icf=safe there; gold + gcc on non-intel
platforms, and gold + clang on intel can use icf=all, as long
as we have the latest binutils.
This change is GN-only, since linux GYP builds are on their last
breaths and it's not worth worrying about x86 flags there.
R=mcgrathr@chromium.org, thakis@chromium.org
BUG=576197
Review-Url: https://codereview.chromium.org/1952353004
Cr-Original-Commit-Position: refs/heads/master@{#393563}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: a403dd9d7c3b7d3619da3ef989f4666e1e11cf95
The TODO about a system yasm is not longer necessary. We don't need to support this for Chrome developers. For Linux distros, Pawel has added an overlay to change the behavior.
The TODO about the output names is out-of-date. The new output location matches the names generated by the C compiler in the Chrome build.
Review-Url: https://codereview.chromium.org/1972173003
Cr-Original-Commit-Position: refs/heads/master@{#393544}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 09869628d781a977987b65906856bd259e40dd9e
This series is to
a) Add my name to AUTHORS
I have few patches to submit to fix the chromium 64bit browser
build for ARMv8 with clang.
b) Fix FPCR access for 64bit clang compilation
Compilation fails as the MSR and MRS instructions access
the FPCR register in 32bit mode.
c) Fix Build.gn and config files
To build 64bit browser for Android with clang for ARMv8
BUG : http://crbug.com/539781
Signed-off-by: Bernhard Rosenkränzer <bero@linaro.org>
Signed-off-by: Khasim Syed Mohammed <khasim.mohammed@linaro.org>
BUG=539781
R=thakis@chromium.org
TEST=download apk to ARMv8 board and launch
Review-Url: https://codereview.chromium.org/1888763002
Cr-Original-Commit-Position: refs/heads/master@{#393517}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 2c5ec51ea564705b02dcb6aeff6a56722cc3890f
Created by flipping enable_app_list to '0' everywhere except ChromeOS,
ensuring it passes CQ, then flipping it back.
Mostly just splitting app_list source files out to their own gyp
variables.
This will allow us to test new code needed for previously supported
platforms. The code will be required as soon as enable_app_list is
flipped to 0. E.g. calls to --show-app-list will just show chrome://apps
instead.
Builds upon initial work in https://codereview.chromium.org/1747773002/
BUG=600915
COLLABORATOR=wierichs@google.com
Review-Url: https://codereview.chromium.org/1861233003
Cr-Original-Commit-Position: refs/heads/master@{#393474}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: d13e0cdf6fc5fddb580968adb2a5b9c5379a4404
This sets it as a data_deps so that any targets depending on the sanitizer
will also pick up the runtime file when being isolated.
Because the ASan runtime uses @loader_path this will not work for bundled
targets, only standalone executables.
BUG=597066,431177
R=aizatsky@chromium.org
Review-Url: https://codereview.chromium.org/1963253002
Cr-Original-Commit-Position: refs/heads/master@{#393335}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 45384fb36763bb34ac3a7395d2dc941754a276ae
This CL makes sure that frame pointers (used for fast stack unwinding)
are not omitted when enable_profiling is true. There are two changes:
1. Don't add -fomit-frame-pointer flag (Android-specific change).
2. Add -fno-omit-frame-pointer flag even in debug builds. This is needed
for Android where debug builds are optimized too (-Os).
BUG=602701
Review-Url: https://codereview.chromium.org/1965143003
Cr-Original-Commit-Position: refs/heads/master@{#393320}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 14430a4de781aca8e67f6ec7b8893647d7ee26d9
Previously, we were only processing resources on aapt or sdk jar _path_
change.
This also removes an unrelated debug print statement.
BUG=603138
Review-Url: https://codereview.chromium.org/1967153002
Cr-Original-Commit-Position: refs/heads/master@{#392957}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: a211f7633c4dc0f2b1fb1c8a40040e84e9568d47
libjpeg_turbo.gyp is located in third-party and is updated
by rolling to a recent commit:
414f243 Remove unused MJPEG define from libjpeg-turbo GYP file
414f2433e6634942b9ceea9450bdc21dcc5520cf
by Noel Gordon
BUG=608347
Review-Url: https://codereview.chromium.org/1961933002
Cr-Original-Commit-Position: refs/heads/master@{#392934}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 50a66e887857dc4117e64f5150c0bafc5097279e
Add a new target convert_plist to invoke "plutil -convert" only on a
given plist file. This is used as iOS needs to convert all plist to
binary in bundle, including plist that are not Info.plist files.
Fix ios_info_plist and info_plist templates to also forward "visibility"
from the invoker.
BUG=459705
Review-Url: https://codereview.chromium.org/1964393002
Cr-Original-Commit-Position: refs/heads/master@{#392924}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 7f441707e74fd96a04ecdd0c97f1f66d83e7bf5d
Reason for revert:
Seemingly breaks incremental builds.
Original issue's description:
> Add directory option for JUnit coverage files.
>
> Added runtime option --coverage-dir to let the users decide where to store
> coverage.ec.
>
> BUG=608072
>
> Committed: https://crrev.com/de08f6f711ebd74fe493584e0694bcce51693318
> Cr-Commit-Position: refs/heads/master@{#392727}
TBR=mikecase@chromium.org,hzl@google.com
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=608072
Review-Url: https://codereview.chromium.org/1973503002
Cr-Original-Commit-Position: refs/heads/master@{#392908}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 0b730799f2f2f2d9d07b75f3fadd2ed387336a02
This adds the required framework to libs[] wherever they are required (most
of the changes in this CL). It also enables the component build optimization
of creating a non-bundled dylib to roll up all the sources and dependencies.
The framework then links that, which allows the build to not copy the bundled
library if any sources change. This is based on the technique implemented
https://codereview.chromium.org/11420019/.
BUG=431177
R=thakis@chromium.org,brettw@chromium.org
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_optional_gpu_tests_rel;tryserver.chromium.mac:mac_optional_gpu_tests_rel;tryserver.chromium.win:win_optional_gpu_tests_rel
Review-Url: https://codereview.chromium.org/1961473003
Cr-Original-Commit-Position: refs/heads/master@{#392823}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 02aa51cf444626f4781824c17178376c0459ad83
Since the bots run gyp_chromium seperately from runhooks, the hermetic mac
toolchain environment variables need to be set in this script as well.
BUG=474373
Review-Url: https://codereview.chromium.org/1970623002
Cr-Original-Commit-Position: refs/heads/master@{#392822}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 588af0bb9a83d6441c00858ca5ae74a919706e74
lld-link expects LIB to be ;-separated even on non-Windows. Hopefully
it'll eventually use a flag for system lib dirs instead of looking at env vars,
but for now it looks at env vars.
(clang-cl also expects INCLUDE to be ;-separated, but it already uses
-imsvc instead of the INCLUDE env var to find system include dirs.)
BUG=495204
Review-Url: https://codereview.chromium.org/1970443002
Cr-Original-Commit-Position: refs/heads/master@{#392676}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: b61345c8939bfc9e23f9a2442e681b54566120ca
The compiler only needs the INCLUDE environment var, and those contents
can just be passed via flags. clang-cl's -imsvc flag adds include directories
as-if they're from INCLUDE (i.e. they're in the right place in the directory
search order, and they're treated as system headers that don't emit warnings).
In 64-bit builds, this would also work for MSVC, but MSVC happily warns about
questionable code in system headers if enough warnings are turned on, so we would
just use /I there (and make sure the flags are early on the compile command so
that these directories are searched at the same time as they would be with INCLUDE).
However, in 32-bit builds, MSVC needs PATH to contain both the 32-bit and the 64-bit
bin directories to load dlls. Since invoking the compiler so differently for 32-bit
and 64-bit is strange, only do this simplification for clang-cl for now.
goma doesn't yet know the -imsvc flag flag, so this is blocked on goma learning
about this clang-cl flag (https://b//28179421).
Build time impact:
64-bit debug builds symbol_level=1, building some binary ("gn")
before:
clang-cl: 34.9s, 35.1s, 35.1s
cl: 26.3s, 26.1s, 27.6s
after:
clang-cl: 33.8s, 33.7s, 34s
cl: 27s, 34.5s, 26.7s
So no discernible build perf difference, but fewer processes
and less reliance on these environment files seems like a good
change anyhow.
It also helps with a potential cross-compile of chrome/win, since
ninja's -t msvc only exists in ninja/win.
BUG=588831
Review-Url: https://codereview.chromium.org/1724533002
Cr-Original-Commit-Position: refs/heads/master@{#392624}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 8435ab74b05929d290a11808a0a94ea7536531d7
Some Android libraries have started including R.class in their jar
files, so they need to be stripped before dexing.
BUG=585576
Review-Url: https://codereview.chromium.org/1952153002
Cr-Original-Commit-Position: refs/heads/master@{#392620}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: dd2adf0e9718ec28f46dde4c09e379c9df82065e