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
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
Now that Chrome OS uses a recent enough Clang toolchain,
it's possible to enable the check there too.
BUG=683445,649897
Review-Url: https://codereview.chromium.org/2654383002
Cr-Original-Commit-Position: refs/heads/master@{#446503}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 539f64c0e54adc91ae1276948771a3538cf4261b
This is a second attempt to land this change.
Previous attempts failed on some ChromeOS bots
using old version of Clang, on Clang-CL Win bots
and also there were a couple of webkit_tests failed
due to a real use-after-scope issue.
The use-after-scope issue is now fixed by
https://codereview.chromium.org/2649903005/, Windows and
ChromeOS are temporarily blacklisted.
BUG=681136,683459,683966,683445
Review-Url: https://codereview.chromium.org/2654623002
Cr-Original-Commit-Position: refs/heads/master@{#445747}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: a9461af221d3d56769f21b6755a8afbef00d6d7d
At this point, everything but Mac has been fixed. On Mac, there's an outstanding issue, which will be fixed later.
BUG=649897
Review-Url: https://codereview.chromium.org/2451973004
Cr-Original-Commit-Position: refs/heads/master@{#445114}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 866204443431a62c1b6e1404ed3c19c3f529ce45
This will make it possible to fully utilize the sanitizers in other
projects that may need to maintain their own suppressions and blacklists.
This change also removes the requirement on having {asan,lsan,tsan}_suppressions_file
defined in //build_overrides/build.gni, simplifying the build configs.
BUG=webrtc:5006
TESTED=CQ dry run + additional sanitizer trybots:
mac_chromium_asan_rel_ng
linux_chromium_ubsan_rel_ng
linux_chromium_msan_rel_ng
linux_chromium_tsan_rel_ng
linux_chromium_asan_rel_ng
Review-Url: https://codereview.chromium.org/2580313002
Cr-Original-Commit-Position: refs/heads/master@{#439452}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 83d8599fdab6538bc3e9cf6e8c9458214a7a8671
No more --gc-sections in debug mode for test targets either.
Re-enable instrumentation of globals in ASAN builds.
This is effectively a reland of r387491.
BUG=159801, 159847
Review-Url: https://codereview.chromium.org/2384953003
Cr-Original-Commit-Position: refs/heads/master@{#422638}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 404b02529e8f0139fa719f34ffa326014096a7c7
The clang sanitizer runtime library needs to be copied to the application
bundle if any of the sanitizers (ASAN, MSAN, ...) is enabled. Ensure this
is the case and that the library is code signed (required with Xcode 8).
Only copy the runtime library if not using Xcode version of clang (as the
runtime library depends on clang version).
BUG=None
Review-Url: https://codereview.chromium.org/2363953004
Cr-Original-Commit-Position: refs/heads/master@{#421537}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 8f50c630cef2aefee800e3aefc2401c9a2f126e8
* win: Members of base classes now should show up in debugger.
* win: Debugger shouldn't show funny highlights anymore due to
debug info no longer including column information. (we still
force this on if sanitizers are used, mostly for clusterfuzz.
maybe we want to make this toggleable independent of sanitizers
at some point)
* win: -Wextern-initializer no longer warns on midl-generated code
* win: clang-cl now accepts /source-encoding:utf-8 and friends
(utf-8 was the source enconding in clang-cl before already, but
now we don't warn on an explicit flag requesting this)
* all platforms: Three plugin checks are now on-by-default,
remove flags for these (see
https://codereview.chromium.org/2267713003https://codereview.chromium.org/2268203002https://codereview.chromium.org/2265093002
)
* win: clang-cl's /Brepro now does what it's supposed to do
* win: clang-cl now emits absolute paths in diagnostics, by
popular request.
Ran `tools/clang/scripts/upload_revision.py 280106`.
BUG=640254,637456,636109,636091,636099
Review-Url: https://codereview.chromium.org/2292173002
Cr-Original-Commit-Position: refs/heads/master@{#415563}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: a033f395bf2547cf4764f77cc9c86d08f3e22c23
Reason for revert:
We have now rolled past r278139 and this shouldn't be necessary any more.
Original issue's description:
> On asan/win bots building with goma, don't accidentally emit DWARF
>
> This happens to work around a bug we don't yet understand, but seems
> like a good change in its own right too.
>
> BUG=635715
> R=rnk@chromium.org
>
> Committed: https://crrev.com/314120a8cfd5df331d825566d25db1ba1a1983fe
> Cr-Commit-Position: refs/heads/master@{#410785}
TBR=rnk@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=635715
Review-Url: https://codereview.chromium.org/2281583002
Cr-Original-Commit-Position: refs/heads/master@{#414454}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: ed9ae8359c2706c16ca4159f0f2f063aa2034e23
This is the second incremental step towards the full CFI launch.
In the first step, we enabled LinkTimeOptimization (LTO) for the
official Chrome builds, which allowed us to devirtualize
51491 site calls pointing to 23149 virtual methods:
https://storage.googleapis.com/cfi-stats/2016-08-15/devirt-methods.html
That sped up a few layout benchmarks by up to 7%
(see https://crbug.com/580389 and https://crbug.com/617283) and
more by 2%-3%.
In the current step, we add Control Flow Integrity checks for
virtual calls. As of now, some functions are excluded from CFI for
performance reasons by either tools/cfi/blacklist.txt or
DISABLE_CFI_PERF attribute.
Once we have proven that there're no perf regressions, we'll be
working on the compiler optimizations to allow reenabling CFI
on the currently suppressed functions.
The remaining part would be to add bad-cast checks to ensure the
forward-edge Control Flow Integrity works as planned. That 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%.
If we see any slowdown, the regressed microbenchmarks will be profiled,
and a few top methods will have CFI disabled on them. This is
the safety valve we intend to use until Clang is ready to generate
more efficient code in these cases.
BUG=464797
Review-Url: https://codereview.chromium.org/2259293002
Cr-Original-Commit-Position: refs/heads/master@{#413252}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: e4f3427521c7d96fb1772bd74c7938e39346d280
There's currently code to disable sanitizers for non-default toolchains
in gcc_toolchain.gni. Move it to sanitizers.gni, then it's closer to
where all these args are declared and it works on Windows as well.
No intended behavior change on non-Windows.
BUG=598761
TBR=dpranke
Review URL: https://codereview.chromium.org/2216183002 .
Cr-Original-Commit-Position: refs/heads/master@{#409963}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 146d122ae8ed166f294231fbe6ca340ceffc356b
Before this, ScopedHandleTest.MultiProcess would fail because
scoped_handle_test_dll.dll got linked against clang_rt.asan-i386.lib
instead of clang_rt.asan_dll_thunk-i386.lib. This now works.
BUG=598761
Review-Url: https://codereview.chromium.org/2208093003
Cr-Original-Commit-Position: refs/heads/master@{#409662}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 1519f9727ddc675a9e3e1de9b904ef03c7d5b831
This is a step toward a working Asan build with GN.
There are still a few missing pieces to land.
This patch is fixing an assert triggering due to courgette using an
harcoded toolchains.
----------------------
ERROR at //build/config/sanitizers/sanitizers.gni:12:1: Assertion failed.
assert(!using_sanitizer || is_clang,
^-----
Sanitizers (is_*san) require setting is_clang = true in 'gn args'
----------------------
This patch is also fixing the compiler-rt runtime paths for a x64 bit
build. The port of WinASAN-64 is almost done and should part of the next
clang roll-deps.
R=thakis@chromium.org, dpranke@chromium.orgTBR=brettw@chromium.org
BUG=598761
Review-Url: https://codereview.chromium.org/2192833002
Cr-Original-Commit-Position: refs/heads/master@{#408857}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 364deb713883f28d2647c5ff160c1a6f7b7ef342
This causes the ASan library to be copied into a bundle's Contents/MacOS/
directory, so it can be loaded via its @executable_path install name.
BUG=630322
Review-Url: https://codereview.chromium.org/2185833002
Cr-Original-Commit-Position: refs/heads/master@{#408174}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 1cfe20c37872faa5e4d94b9a3b35959294de9462
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
Currently v8_target_cpu can only be set to one particular architecture,
and that won't work for monochrome/webview builds where we need
to be able to build two different snapshots for two different architectures.
The way things are set are also confusing for when you need to do builds
for a target_cpu that is different from the host_cpu and the value of the
v8_target_cpu might get out of sync between target and host.
This change changes all that by making the cpu that v8 targets
a function of the current toolchain (thus declaring a v8_current_cpu
and using that instead).
R=brettw@chromium.org, jochen@chromium.org, michaelbai@chromium.org
BUG=625353
Review-Url: https://codereview.chromium.org/2116183002
Cr-Original-Commit-Position: refs/heads/master@{#405551}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 8a2de90db035b90a891f0b980ab6162fd3995499
1. Build afl-fuzz, afl-cmin, afl-tmin and afl-showmap with fuzzers.
2. Add hash.h from afl-2.16b since afl-tools depend on hash.h and it
has a license header.
3. Fix inconsistencies in README.chromium
BUG=611337
Review-Url: https://codereview.chromium.org/2095843002
Cr-Original-Commit-Position: refs/heads/master@{#402280}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 7243ef31ec3985f24d8e63282d5c68b2ae618e2e
pcc
aizatsky
mmoroz
etienneb
ochang
inferno
krasin
haraken
thakis
kjellander
thomasanderson
thestig
sdefresne
mef
ehmaldonado
krasin
metzman
rnk
rsesek
sammc
dpranke