Commit Graph

11 Commits

Author SHA1 Message Date
Kostya Kortchinsky 4a547fb62d [sanitizer] Use -Wl,-z,global on Android
Summary:
Use `-Wl,-z,global` for all Sanitizer shared libraries on
Android. We want them to be in the global group
(https://android.googlesource.com/platform/bionic/+/master/android-changes-for-ndk-developers.md#changes-to-library-search-order)
to avoid any alloc/dealloc mismatch between the libc allocator & said library.

`audioserver` was one of the binary that exhibited the problem with Scudo,
this seems to fix it.

[edited for accuracy]

Reviewers: eugenis, alekseyshl

Reviewed By: eugenis

Subscribers: kubamracek, srhines, mgorny, delcypher, #sanitizers, llvm-commits

Differential Revision: https://reviews.llvm.org/D49198

llvm-svn: 337010
2018-07-13 15:31:05 +00:00
Dan Liew 0de57a676c [CMake] Fix a typo in the variable used to retrieve source file names
for the `RTHwasan_dynamic` target.

Differential Revision: https://reviews.llvm.org/D49178

llvm-svn: 336944
2018-07-12 20:55:02 +00:00
Dan Liew b1f95697c1 [CMake] Add compiler-rt header files to the list of sources for targets
when building with an IDE so that header files show up in the UI.
This massively improves the development workflow in IDEs.

To implement this a new function `compiler_rt_process_sources(...)` has
been added that adds header files to the list of sources when the
generator is an IDE. For non-IDE generators (e.g. Ninja/Makefile) no
changes are made to the list of source files.

The function can be passed a list of headers via the
`ADDITIONAL_HEADERS` argument. For each runtime library a list of
explicit header files has been added and passed via
`ADDITIONAL_HEADERS`. For `tsan` and `sanitizer_common` a list of
headers was already present but it was stale and has been updated
to reflect the current state of the source tree.

The original version of this patch used file globbing (`*.{h,inc,def}`)
to find the headers but the approach was changed due to this being a
CMake anti-pattern (if the list of headers changes CMake won't
automatically re-generate if globbing is used).

The LLVM repo contains a similar function named `llvm_process_sources()`
but we don't use it here for several reasons:

* It depends on the `LLVM_ENABLE_OPTION` cache variable which is
  not set in standalone compiler-rt builds.
* We would have to `include(LLVMProcessSources)` which I'd like to
  avoid because it would include a bunch of stuff we don't need.

Differential Revision: https://reviews.llvm.org/D48422

llvm-svn: 336663
2018-07-10 13:00:17 +00:00
Petr Hosek 1608ca6d64 [CMake] Build shared version of runtimes for Fuchsia
Fuchsia is no longer treated as UNIX which means we need to explicitly
enable building of shared versions of runtimes.

Differential Revision: https://reviews.llvm.org/D46609

llvm-svn: 331922
2018-05-09 21:24:06 +00:00
Alex Shlyapnikov 79866cad6f [HWASan] Introduce non-zero based and dynamic shadow memory (compiler-rt).
Retire the fixed shadow memory mapping to avoid conflicts with default
process memory mapping (currently manifests on Android).

Tests on AArch64 show <1% performance loss and code size increase,
making it possible to use dynamic shadow memory by default.

Keep the fixed shadow memory mapping around to be able to run
performance comparison tests later.

Re-commiting D45847 with fixed shadow for x86-64.

llvm-svn: 330624
2018-04-23 18:19:23 +00:00
Reid Kleckner 061fcd586d Revert r330474 - "[HWASan] Introduce non-zero based and dynamic shadow memory (compiler-rt)."
This commit causes internal errors with ld.bfd 2.24. My guess is that
the ifunc usage in this commit is causing problems. This is the default
system linker on Trusty Tahr, which is from 2014. I claim it's still in
our support window. Maybe we will decide to drop support for it, but
let's get the bots green while we do the investigation and have that
discussion.

Discovered here: https://crbug.com/835864

llvm-svn: 330619
2018-04-23 17:26:33 +00:00
Alex Shlyapnikov c3ec1643f1 [HWASan] Introduce non-zero based and dynamic shadow memory (compiler-rt).
Summary:
Retire the fixed shadow memory mapping to avoid conflicts with default
process memory mapping (currently manifests on Android).

Tests on AArch64 show <1% performance loss and code size increase,
making it possible to use dynamic shadow memory by default.

For the simplicity and unifirmity sake, use dynamic shadow memory mapping
with base address accessed via ifunc resolver on all supported platforms.

Keep the fixed shadow memory mapping around to be able to run
performance comparison tests later.

Complementing D45840.

Reviewers: eugenis

Subscribers: srhines, kubamracek, dberris, mgorny, kristof.beyls, delcypher, #sanitizers, llvm-commits

Differential Revision: https://reviews.llvm.org/D45847

llvm-svn: 330474
2018-04-20 20:03:57 +00:00
Kostya Kortchinsky 596b8b4a22 [sanitizer] Split Symbolizer/StackTraces from core RTSanitizerCommon
Summary:
Host symbolizer & stacktraces related code in their own RT:
`RTSanitizerCommonSymbolizer`, which is "libcdep" by nature. Symbolizer &
stacktraces specific code that used to live in common files is moved to a new
file `sanitizer_symbolizer_report.cc` as is.

The purpose of this is the enforce a separation between code that relies on
symbolization and code that doesn't. This saves the inclusion of spurious code
due to the interface functions with default visibility, and the extra data
associated.

The following sanitizers makefiles were modified & tested locally:
- dfsan: doesn't require the new symbolizer RT
- esan: requires it
- hwasan: requires it
- lsan: requires it
- msan: requires it
- safestack: doesn't require it
- xray: doesn't require it
- tsan: requires it
- ubsan: requires it
- ubsan_minimal: doesn't require it
- scudo: requires it (but not for Fuchsia that has a minimal runtime)

This was tested locally on Linux, Android, Fuchsia.

Reviewers: alekseyshl, eugenis, dberris, kubamracek, vitalybuka, dvyukov, mcgrathr

Reviewed By: alekseyshl, vitalybuka

Subscribers: srhines, kubamracek, mgorny, krytarowski, delcypher, llvm-commits, #sanitizers

Differential Revision: https://reviews.llvm.org/D45457

llvm-svn: 330131
2018-04-16 16:32:19 +00:00
Kostya Kortchinsky 988fab3f66 [sanitizer] Split coverage into separate RT in sanitizer_common
Summary:
`sanitizer_common`'s coverage support is fairly well separated, and libcdep by
default. Several sanitizers don't make use of coverage, and as far as I can
tell do no benefit from the extra dependencies pulled in by the coverage public
interface functions.

The following sanitizers call `InitializeCoverage` explicitely: MSan, ASan,
LSan, HWAsan, UBSan. On top of this, any sanitizer bundling RTUBSan should
add the coverage RT as well: ASan, Scudo, UBSan, CFI (diag), TSan, MSan, HWAsan.

So in the end the following have no need: DFSan, ESan, CFI, SafeStack (nolibc
anyway), XRay, and the upcoming Scudo minimal runtime.

I tested this with all the sanitizers check-* with gcc & clang, and in
standalone on Linux & Android, and there was no issue. I couldn't test this on
Mac, Fuchsia, BSDs, & Windows for lack of an environment, so adding a bunch of
people for additional scrunity. I couldn't test HWAsan either.

Reviewers: eugenis, vitalybuka, alekseyshl, flowerhack, kubamracek, dberris, rnk, krytarowski

Reviewed By: vitalybuka, alekseyshl, flowerhack, dberris

Subscribers: mgorny, delcypher, #sanitizers, llvm-commits

Differential Revision: https://reviews.llvm.org/D44701

llvm-svn: 328204
2018-03-22 15:04:31 +00:00
Evgeniy Stepanov d96b06f2c2 [hwasan] Build runtime library with -fPIC, not -fPIE.
Summary: -fPIE can not be used when building a shared library.

Reviewers: alekseyshl, peter.smith

Subscribers: kubamracek, llvm-commits, mgorny

Differential Revision: https://reviews.llvm.org/D42121

llvm-svn: 322588
2018-01-16 19:21:45 +00:00
Evgeniy Stepanov 9595d16893 Hardware-assisted AddressSanitizer (compiler-rt)
Summary:
Runtime library for HWASan, initial commit.
Does not randomize tags yet, does not handle stack or globals.

Reviewers: kcc, pcc, alekseyshl

Subscribers: srhines, kubamracek, dberris, mgorny, llvm-commits, krytarowski

Differential Revision: https://reviews.llvm.org/D40935

llvm-svn: 320231
2017-12-09 01:31:51 +00:00