With these changes, check-asan passes on Linux and Windows.
There are a couple libraries we need to add support for, asan_static, asan_preinit, and the shared library version of asan proper.
Since we need to build the asan proper sources twice, once with -DASAN_DYNAMIC and once without, those sources are no longer in a source_set.
Much of the check-asan target is taken from the existing check-hwasan target.
Reviewed By: thakis
Differential Revision: https://reviews.llvm.org/D118307
crt_code seems to correspond to SANITIZER_COMMON_CFLAGS which contains -fno-builtin.
Reviewed By: thakis
Differential Revision: https://reviews.llvm.org/D118288
This was done for check-hwasan, but compiler-rt/test/hwasan/lit.cfg.py
already does that.
This makes check-asan (to be submitted) fail on Windows due to using
lld-link (as opposed to MSVC link.exe) in tests. That seems like a
problem that should be fixed, but that's orthogonal to this patch.
That way, the build rules are closer to the source files they describe.
No intended behavior change.
Differential Revision: https://reviews.llvm.org/D115155
If a sysroot was specified, it would take precedence over the Android
NDK sysroot since it would appear after in the command line.
Also only build runtimes for enabled target arches. Many places have
copied this around so create and use supported_android_toolchains.
Reviewed By: pcc
Differential Revision: https://reviews.llvm.org/D113606
That way, the headers in llvm/utils/gn/secondary/compiler-rt/include
are copied when running `ninja compiler-rt`. (Previously, they were
only copied when running `check-hwasan` or when building the
compiler-rt/include target.)
(Since they should be copied only once, depend on the target in the
host toolchain. I think default_toolchain should work just as well,
it just needs to be a single fixed toolchain. check-hwasan depends
through host_toolchain, so let's use that here too.)
Prevents errors like
testing/fuzzed_data_provider.h:8:10: fatal error: 'fuzzer/FuzzedDataProvider.h' file not found
when building with locally-built clang. (For now, you still have to
explicitly build the 'compiler-rt' target. Maybe we should make the
clang target depend on that in the GN build?)
Differential Revision: https://reviews.llvm.org/D112238
The gn build doesn't support xray, so there's no reason to make the xray
headers available. Some CMake checks check if xray includes are
available to determine if xray is usable. Since we don't build the xray
runtime, there are link errors.
Reviewed By: thakis
Differential Revision: https://reviews.llvm.org/D108737
Nico Weber