GnomeKeyringLoader will be moved into a separate utility.
This change makes GnomeKeyringLoader simpler to build on and easier
to move.
Currently, GnomeKeyringLoader compiles different code, depending on
whether keyring is statically linked. Now it will only do dynamic
loading. The only place that requires static linking is tests, and they
don't need GnomeKeyringLoader to do it for them.
BUG=602624
Review-Url: https://codereview.chromium.org/2191873002
Cr-Original-Commit-Position: refs/heads/master@{#408924}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: da4e6a834587d15f7696c5a396099fafa719ddf1
The Ozone X11 platform implements a more complete X11 backend for Ozone
and egltest is unused at this point. Delete the egltest code and all the
accompanying parts of GYP and GN build files.
BUG=none
Review-Url: https://codereview.chromium.org/2167243002
Cr-Original-Commit-Position: refs/heads/master@{#406918}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 3f2b800844a8267d98eb2a1bbbcc4e7c499f5654
Reason for revert:
Too many blink_perf.layout benchmarks regressed by ~3.5%. While the regressions are within predicted upper bound, there're too many of them to ignore:
https://chromeperf.appspot.com/report?sid=ebf0165d8c96c7a70c790d179a9bdc1f9e58e616182522fd961d17ad648fc28f&start_rev=404312&end_rev=405943
We will need to reevaluate the reason for such consistent slowdown and will make another attempt after it's cleared.
Original issue's description:
> Launch CFI for virtual calls on Linux x86-64.
>
> This is the second incremental step towards the full CFI launch.
> In the first step, we enabled LinkTimeOptimization (LTO) for the
> official Chrome builds. In this step we add Control Flow Integrity
> checks for all virtual calls.
>
> The remaining part is to add bad-cast checks to ensure the forward-edge
> Control Flow Integrity works as planned. That remaining part will
> require more work on reducing the overhead for size and speed by these
> CFI checks, so we don't enable them right away.
>
> The expected Perf impact by this CL:
>
> - Chrome binary size is increased by 5%,
> - Some of the benchmarks are slowed down by up to 3.5%.
>
> Note that before making it slower, we made it faster by implementing
> virtual const propagation and a number of heuristics for automatic
> devirtualization in LLVM which sped up some layout benchmarks by up to 7%
> (see https://crbug.com/580389 and https://crbug.com/617283)
>
> If there's a higher (negative) impact, we'll be willing to roll this
> feature back, but please allow the Perf bots to work for a day or two
> to collect more detailed statistics on the regressions, as it will help
> us to identify ways to speed it up (most likely, by inventing new ways
> for automatic devirtualization).
>
> BUG=464797
>
> Committed: https://crrev.com/01f474c48200a1e556a4cf668e2b5dbda0f38a6f
> Cr-Commit-Position: refs/heads/master@{#405894}
TBR=thakis@chromium.org,esprehn@chromium.org,krasin@google.com
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=464797
Review-Url: https://codereview.chromium.org/2154993002
Cr-Original-Commit-Position: refs/heads/master@{#405944}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 532a8777898abba488970f9dc17a067c7c517432
This is the second incremental step towards the full CFI launch.
In the first step, we enabled LinkTimeOptimization (LTO) for the
official Chrome builds. In this step we add Control Flow Integrity
checks for all virtual calls.
The remaining part is to add bad-cast checks to ensure the forward-edge
Control Flow Integrity works as planned. That remaining part will
require more work on reducing the overhead for size and speed by these
CFI checks, so we don't enable them right away.
The expected Perf impact by this CL:
- Chrome binary size is increased by 5%,
- Some of the benchmarks are slowed down by up to 3.5%.
Note that before making it slower, we made it faster by implementing
virtual const propagation and a number of heuristics for automatic
devirtualization in LLVM which sped up some layout benchmarks by up to 7%
(see https://crbug.com/580389 and https://crbug.com/617283)
If there's a higher (negative) impact, we'll be willing to roll this
feature back, but please allow the Perf bots to work for a day or two
to collect more detailed statistics on the regressions, as it will help
us to identify ways to speed it up (most likely, by inventing new ways
for automatic devirtualization).
BUG=464797
Review-Url: https://codereview.chromium.org/2140373002
Cr-Original-Commit-Position: refs/heads/master@{#405894}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 01f474c48200a1e556a4cf668e2b5dbda0f38a6f
This patch adds a mojo interface to load hyphenation dictionaries on
Android.
Calls to Minikin using the loaded dictionary files will be in following
patches.
BUG=605840
Review-Url: https://codereview.chromium.org/2113933003
Cr-Original-Commit-Position: refs/heads/master@{#405405}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 30add38fedb8b9bd44b931aa3adba40d7c79b929
Disable Full-WPO for the x64 official builds (this doesn't
affect the PGO builds).
This should help me to get an official
"non-PGO & non-WPO" build that I can compare against an official PGO
build.
Also I'm not sure if it's worth keeping WPO turned on for the official
builds at the moment ? We don't ship these builds (we ship the PGO ones)
and so this only slowdown the builders that build an official x64 build
for testing purposes (especially considering that they need to link all the unittests with Full-WPO)
BUG=490934, 617982
Review-Url: https://codereview.chromium.org/2142603002
Cr-Original-Commit-Position: refs/heads/master@{#405164}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 0d74d7f71c93bfc3b32653de7958ff84d173937d
`enable_settings_app` was previously enabled for the app launcher on
non-chromeos platforms. But this hasn't been available on those
platforms for 1 milestone (since r394856), so it's time to purge the
associated code.
Note this is different to the ChromeOS Settings "App"
(chrome://flags/#enable-settings-window), and the arc / Android "App
Settings" App (arc:kSettingsAppId and b/28017599).
BUG=263236, 600915
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:closure_compilation
Review-Url: https://codereview.chromium.org/2121303003
Cr-Original-Commit-Position: refs/heads/master@{#404968}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 824bea8069b71ecb4f8c94fbeb78d19196304f1c
We used to not pass /GS since clang-cl used to not implement buffer security
checks and would warn about this flag being ignored. Now clang-cl implements
some form of buffer security checking and no longer warns on /GS, so that's
no longer necessary. This reverts the gyp bits of
https://codereview.chromium.org/1828543003/
/GS is also on by default, and as of https://codereview.chromium.org/1957523005
it's no longer explicitly passed in gn builds -- so no .gn files need to be
changed.
Since /GS is on by default, this CL doesn't change behavior.
BUG=598767
Review-Url: https://codereview.chromium.org/2129213002
Cr-Original-Commit-Position: refs/heads/master@{#404413}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: cc683aecb8e88d03139477b8eba81aeb1e3c2e9c
If a DSO is linked against with --as-needed and the program contains no
strong references to any symbols in the DSO, the documented behaviour
is that the linker should not create a DT_NEEDED entry for that
DSO. However, if the program contains weak references to symbols in
the DSO, this results in an incorrect resolution for that symbol. In
Chromium this happens in particular for the symbol __pthread_key_create
(as a result of code inlined from a pthread header), which causes
the program to segfault. For more details, see the associated bug
and the related LLVM bug: http://llvm.org/pr28335
Work around this by linking against libpthread with --no-as-needed.
Because the problem only affects glibc, only do this when not
targeting NaCl or Android, neither of which normally uses glibc
as the C runtime library (NaCl can use glibc, but we haven't
observed this problem there).
BUG=623236
R=thakis@chromium.org,engedy@chromium.org
Review-Url: https://codereview.chromium.org/2094273003
Cr-Original-Commit-Position: refs/heads/master@{#402650}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 7ebfaa0c5067c77db1b4891ac6571f8d1b97fc4d
This CL removes the out-of-process browser hang instrumentation used to
capture 20s hangs and failed rendezvous crash reports in one-off canary
releases. The Kasko reporter is deprecated, and CrashPad does not yet
support the use case.
The plan is to restore this functionality once CrashPad supports it.
BUG=622314
Review-Url: https://codereview.chromium.org/2086403002
Cr-Original-Commit-Position: refs/heads/master@{#402189}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 32d4643f0c60110d73c0ce8e01d0f88aa95bd8b0
ios used to force a deployment target of OS X 10.7 before we used that for
chrome/mac builds. Hence, iOS used to get deprecation warnings since we hadn't
cleaned up the mac code for a 10.7 deployment target yet. Now that we use
the same deployment target for chrome/mac and iOS host builds, suppressing
deprecation warnings in iOS builds is no longer needed.
No behavior change.
BUG=none
Review-Url: https://codereview.chromium.org/2099773004
Cr-Original-Commit-Position: refs/heads/master@{#401994}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 121329afa514ffa8a976d2eea4ced9824c6380cb
MSVC and clang-cl offer a bunch of functions that are built-in to the compiler: Intrinsics.
When an intrinsic is called, the compiler can emit specialized code for intrinsics.
(It's free to emit a regular call to a function too though.)
intrin.h includes prototypes (and with clang-cl, definitions) for intrinsics. MSVC also supports
`#pragma intrinsics(name)`, which allows marking the intrinsic named "name" as something
that should preferably be treated as an intrinsic (roughly ~inlined) instead of as a call. With this,
it is possible to manually declare an intrinsic and then use that pragma, and since it'll be
treated as an intrinsic, no linker error will happen.
clang-cl doesn't yet implement `#pragma intrinsic`, so e.g.
void __cpuidex(int CPUInfo[4], int info_type, int ecxvalue);
#pragma intrinsic(__cpuidex)
// later, call __cpuidex()
will result in a linker error, since clang-cl sees the declaration for __cpuidex(), but then
clang-cl ignores the pragma line, and then later it thinks the call is just a call to a function
that isn't defined anywhere.
This is not a problem: Just #include <intrin.h> instead of manually declaring the function.
With clang-cl, intrin.h contains a definition of __cpuidex (and the other intrinsics), and
no linker error will be emitted (and the definition is always_inline, so it's fast).
There is just one wrinkle: Some system headers (e.g. windows.h) do manually declare
intrinsics, mark them `#pragma intrinsic`, and then call them from other inline functions
defined in system headers. So if some of our code calls one of these other inline functions,
it needs intrin.h without us knowing about it. Luckily, we know only a single function where
this is an issue in practice: SecureZeroMemory(), which calls __stosb. So we had to add
explicit and mysterious includes for <intrin.h> to the two files that call that function. If
more examples of this pop up, we can reevaluate if we want to force-include this header
everywhere, but for now it seems overkill to inject this header into every translation unit
just because two translation units need it.
BUG=592745
Review-Url: https://codereview.chromium.org/2076483002
Cr-Original-Commit-Position: refs/heads/master@{#401613}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: ac7670452f51ecfd1061749b3d5e15f8544a55ee
This reverts commit 6d4418ff859750f445af6e4612a5665ae2f84837.
Using <(DEPTH) on the v8 side is sufficient. We don't need the
extra variable.
BUG=
Review-Url: https://codereview.chromium.org/2072133003
Cr-Original-Commit-Position: refs/heads/master@{#400457}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: c4775a0549a5128cf1e36491b85d0b06a501c1fc
Since Windows uses a case-insensitive file system, this doesn't matter much,
but if we ever want to turn on -Wnonportable-system-include-path we'll need
this.
(clang's lib/Headers/Intrin.h was renamed to intrin.h to match the Microsoft
header in clang r272701.)
BUG=617318
Review-Url: https://codereview.chromium.org/2066213002
Cr-Original-Commit-Position: refs/heads/master@{#399912}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 4c33b455ce98383000f33e3519ab320d6b8629c0
This change adds support for cross compiling chrome on ARM64 linux.
Temporarily disabled nacl and tcmalloc to fix compilation errors.
BUG=613452
Review-Url: https://codereview.chromium.org/2001523002
Cr-Original-Commit-Position: refs/heads/master@{#399766}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 3026e6886f052160a3ff594801d5b4dbe8a20753
The HandleVerifier prevent you from using any ScopedHandle during a module initialization (i.e. if a DLL use one in DllMain this will call back into its host executable that hasn't been initialized yet and things will derail). In this CL I'm adding a build flag to make it possible to use it in a single module mode..
Committed: https://crrev.com/a89708a5c1bfe778ed1615f0bc92f0e9ae2e2192
Cr-Commit-Position: refs/heads/master@{#398361}
BUG=618205
Review-Url: https://codereview.chromium.org/1977833003
Cr-Original-Commit-Position: refs/heads/master@{#398575}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 82ef0204161f34381ab832a576c4789e1063e0ee
Reason for revert:
ScopedHandleTest.* tests fail to die on try bots.
BUG=618205
Original issue's description:
> Add a buildflag to use the handle verifier in a per module mode.
>
> The HandleVerifier prevent you from using any ScopedHandle during a module initialization (i.e. if a DLL use one in DllMain this will call back into its host executable that hasn't been initialized yet and things will derail). In this CL I'm adding a build flag to make it possible to use it in a single module mode..
>
> Committed: https://crrev.com/a89708a5c1bfe778ed1615f0bc92f0e9ae2e2192
> Cr-Commit-Position: refs/heads/master@{#398361}
TBR=wfh@chromium.org,chrisha@chromium.org,thakis@chromium.org,sebmarchand@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/2047013003
Cr-Original-Commit-Position: refs/heads/master@{#398496}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 71f86049e34c437a0a7498b231bb19353486f81f
The HandleVerifier prevent you from using any ScopedHandle during a module initialization (i.e. if a DLL use one in DllMain this will call back into its host executable that hasn't been initialized yet and things will derail). In this CL I'm adding a build flag to make it possible to use it in a single module mode..
Review-Url: https://codereview.chromium.org/1977833003
Cr-Original-Commit-Position: refs/heads/master@{#398361}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: a89708a5c1bfe778ed1615f0bc92f0e9ae2e2192
Reason for revert:
The Clang warning was removed again in r271761.
Original issue's description:
> Suppress -Wnonportable-include-path on clang tot bots
>
> BUG=617318
> R=hans@chromium.org
>
> Committed: 2bc751024eTBR=thakis@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=617318
Review-Url: https://codereview.chromium.org/2043813002
Cr-Original-Commit-Position: refs/heads/master@{#398065}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 2b359d2e5b4f7639055c9c6ff3ed39a03a2a3a0b
Chromoting no longer relies on the sas.dll so we can clean up some of the
build files and remove these variables.
BUG=
Review-Url: https://codereview.chromium.org/2030423002
Cr-Original-Commit-Position: refs/heads/master@{#398057}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: de1387d31ef6fffe415c947ce3af245882f71fcf
Thus, add USE_EXTERNAL_POPUP_MENU flag so that Blimp Engine can follow the same code path of the external Android popup menus before it reaches WebContentsView.
BUG=598764
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_site_isolation
Review-Url: https://codereview.chromium.org/1992393002
Cr-Original-Commit-Position: refs/heads/master@{#397575}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: c643d33cf668665bac4562e69a72f9ef29b5bbed
Start using bundled gold as default linker for Linux MIPS,
since gold in current bundled binutils (2.26) supports mips32.
BUG=none
TEST=Build Chromium for Linux MIPS
Review-Url: https://codereview.chromium.org/2027173002
Cr-Original-Commit-Position: refs/heads/master@{#397246}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 867134974146cb103320e398e7544b717bbbc0fe
This should reduce binary size quite a bit, without less security.
We currently use different -fstack-protector flags on different platforms,
and I think -fstack-protector-strong is where we eventually want all platforms
to be. Chrome OS has been using that flag for a long time already. Linux
will use it eventually (see bug linked to in the comment I'm adding here.)
clang-cl is very likely going to hook up /GS to -fstack-protector-strong.
BUG=none
Review-Url: https://codereview.chromium.org/2029633002
Cr-Original-Commit-Position: refs/heads/master@{#397174}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 53b9133ec5956418541ae10e40547558ae70b387
cfroussios
kylechar
krasin
krasin
thakis
rnk
kojii
sebmarchand
tapted
skau
tzik
pcc
manzagop
mtrofin
justincohen
apatole
robliao
eugenis
ochang
milko.leporis
battre
jbudorick
hans
joedow
dpranke
Gordana.Cmiljanovic
haibinlu
mmoroz